Boa noite povo!
Continuamos hoje a tradução de “Scarce Objects”, da qual vimos a terceira parte no último versículo. Hoje a quarta.
Esse método de composição de direitos específicos e genéricos, transferidos como um pacote, mas com átomos genéricos exclusivos compensados por TAs diferentes, permite que pacotes de direitos arbitrariamente sofisticados, referentes a objetos com um estado arbitrariamente exclusivo, sejam transferidos de maneira não-vinculável. É possível uma grande variedade de derivativos e combinações. A única restrição é que a obtenção de direitos sobre recursos exclusivos específicos deve ser deferido para a fase de consumo ou transferida com compensação on-line por meio de mix de comunicações custoso.
Se o Provedor desejar oferecer exclusividade a um direito específico, a transferência parece exigir um mix caro de comunicações entre o Provedor e o cessionário, em vez de um ticket cego barato. Por exemplo, “Deep Space Station de 60 para 0500-0900 Domingo” ou “um bloqueio no autoexec.bat agora” exige exclusividade para um direito específico e, portanto, parece exigir um mix de comunicações para transferir de forma não vinculável. Por outro lado, “um bloqueio de uma hora no DSS-60 em maio” e “o direito de bloquear o autoexec.bat em algum momento” são genéricos e podem ser transferidos privadamente com o cegamento muito menos caro, dada a população suficiente de outro ticket para esta classe de direito genérico transferido entre a emissão e o consumo de um determinado ticket.
Clientes podem lidar com o TA sem um mix de comunicação. Eles lidam com o Provedor por meio de um mix de comunicação Se tanto o detentor inicial quanto o final falharem ao fazê-lo, o Provedor poderia vinculá-los. Se apenas o detentor final falhar, o Provedor poderia identificá-lo como o usuário real do recurso. Assim, para privacidade total, transferências genéricas são baratas, e transferências não exclusivas são baratas, enquanto que transferências específicas e exclusivas e o uso de fato do objeto parecem exigir o mix de comunicações caro.
Aqui está uma revisão de nossa arquitetura:
- Objetos atômicos conservados combináveis (objetos escassos propriamente ditos):
- Os tickets (contratos ao portador) são certificados digitais, emitidos por emissores confiáveis ou distribuídos. Cada tipo de ticket representa um direito específico e limitado a um objeto escasso – por exemplo, o direito de invocar um método nesse objeto (por exemplo, usar um serviço fornecido por esse objeto) até N vezes, ou até um certo limite de uso de recursos Os tickets são uma parte essencial do “invólucro de objeto” que faz com que um objeto escasso pareça e aja escassamente.
- Emissores distribuídos, que mantêm títulos de propriedade para determinados contratos ao portador, espaços para nome, e outras entidades publicamente identificáveis que em caso contrário seriam conservadas de maneira insegura.
- Design por contrato (por exemplo, especificação detalhada e testagem de condições pré e pós) como uma parte central e não opcional da programação de objetos.
- Uma infraestrutura avançada de objetos escassos pode incluir também:
- Tratamento de exceções como procedimento de falência ou violação de contrato, para converter relacionamentos rígidos cliente-servidor em relacionamentos cliente-fornecedor mutuamente benéficos e dinamicamente reconfiguráveis (competitivos), adequados para a invocação de objetos através dos limites de confiança.
- Rastreamento de reputação do comportamento das cadeias de suprimentos. Protocolos criptográficos, como aqueles usados para criar logs de transações não-forjáveis e auditáveis confidencialmente, podem ser usados para melhorar o tradeoff de informações entre privacidade e reputação, desde que ocultos sob uma metáfora intuitivamente clara da reputação do comportamento da cadeia de suprimentos.
Objetos escassos, ao criar um modelo muito mais simples e intuitivo de computação entre limites de confiança, podem tornar a distribuição de objetos na internet global uma realidade, assim como a simplificação do hipertexto em HTML tornou a Web uma realidade.
Diagrama da Arquitetura de Objetos Escassos Proposta
Clique para uma versão ampliada
Assim termina a quarta parte da nossa tradução, seguimos no versículo seguinte. Ricas bençãos!!
