O Evangelho de Satoshi Nakamoto – Cap. 27 vers. 9

Boa noite povo!

No versículo de ontem vimos a oitava parte de “Financial Cryptography in 7 Layers”. Hoje a parte nove.

Espelhando o Modelo de Governança

É importante notar também que quando uma moeda é reservada por um ativo subjacente (por exemplo, se uma moeda denominada em ouro tinha metal físico garantido para reserva), os recursos de governança acima devem ser espelhados para as reservas.

Ou seja, para continuar o exemplo do ouro, deve haver partes separadas responsáveis pelo ingresso e saída de metal no armazenamento, e deve haver verificação independente do número de barras atualmente colocadas em depósito.

Contabilidade

Para atender aos objetivos conflitantes de privacidade e flexibilidade, Ricardo usa um modelo contábil convencional com alguns recursos adicionais:

• Contas são unidades de alocação de propriedade e não são identidades. Um usuário pode criá-las sob demanda e descartá-las da mesma forma. As camadas inferiores devem fornecer algum mecanismo para essas contas.
• As subcontas gerenciam uma forma específica de valor em uma conta. A subconta é simplesmente a interseção da autenticação de propriedade (a conta) com a descrição do valor (o contrato).
• Transações são movimentos de valor de uma conta para outra, dentro da subconta do instrumento.
• O mecanismo de contabilidade backend é responsável por garantir que cada transação seja atômica e persistente. O resultado da conclusão da transação é a emissão de um recibo assinado.
• Cada transação é liquidada em tempo real, conforme medido pela emissão do recibo.
• O backend e o cliente mantêm uma lista de recibos como subconta.
• Para atender aos requisitos da camada de Governança para auditoria aberta, algumas contas devem apresentar balanços sob demanda, e contas selecionadas devem ser examináveis.

Por causa do requisito de nível mais alto de barateamento, o modelo contábil foi projetado para confiabilidade total, até o nível do suporte técnico. Isso é feito empregando um grupo de técnicas não óbvias:

• o Emissor força por backend o cliente a manter os mesmos dados, conforme discutido na camada de Direitos, abaixo [51]. Isso ajuda a reduzir a frequência da chamada de suporte “solicitação de informações” [52].
• Um pedido assinado pelo usuário é meramente uma solicitação para o backend tentar uma transação, e o backend tem a liberdade de ignorá-lo [53]. Apenas o recibo assinado é prova de uma transação [54].
• Para aumentar o perfil do recibo assinado, os saldos não são mantidos em nenhum lugar do sistema [55].

Usando essas técnicas, o modelo contábil suporta a exigência do nível financeiro de ser barato de operar. Se o software do cliente está faltando alguma coisa, então é um bug, e ele pertence adequadamente ao desenvolvedor do software, em vez de ser coberto como um problema do help desk do Emissor. 

51. Para forçar o cliente a manter os dados, o recurso de email SOX, introduzido na camada 3, exige assinaturas para todos os documentos importantes, como recibos.
52. Ou, mais corretamente, para tratar essa chamada de suporte como um bug, em que o cliente não está disponibilizando as informações.
53. Uma solicitação assinada do usuário tem mais significado para o usuário – o software cliente deve manter o controle deles como promessas de pagamento e, nesse sentido, o sistema é análogo a um sistema de cheque.
54. O recibo inclui o pedido de autenticação fornecido pelo cliente para fornecer a cadeia de autenticação de volta ao usuário.
55. Em termos de programação, os saldos armazenados são proibidos. Os saldos que são exibidos pelo software cliente são calculados rapidamente, incluindo sempre que o cliente é redefinido.Conseguir este direito provou ser um custo considerável em tempo de desenvolvimento, mas acredita-se que os requisitos são válidos e os custos são cobertos a longo prazo. 

Fim da nona parte, amanhã a décima. Grande abraço!