Boa noite amigos!
No versículo anterior vimos a terceira parte da tradução de “The Ricardian Contract“, seguimos para a quarta
3. Um Sistema de Contratos Digitais para Emissão
Quase todos os aspectos de Contratos Ricardianos são melhores vistos ao examinar exemplos, e esta seção apenas cobre brevemente os detalhes salientes, antes de discutir suas ramificações. Exemplos podem ser encontrados em http://webfunds.org/ricardo/contracts/
3.1 Definição
Um contrato ricardiano pode ser definido como um único documento que é a) um contrato oferecido por um emissor aos detentores, b) por um direito valioso detido pelos detentores e administrado pelo emissor, c) facilmente legível por pessoas (como um contrato em papel), d) legível por programas (analisável como um banco de dados), e) assinado digitalmente, f) carrega as chaves e as informações do servidor e g) aliado a um identificador único e seguro.
Nos termos mais simples possíveis, um Contrato Ricardiano é um documento que define um tipo de valor a ser emitido pela Internet [11]. Identifica o Emissor, quem é o signatário e quaisquer termos e cláusulas que o Emissor julgar convenientes acrescentar para que o documento se constitua em um contrato.
O mesmo documento deve ser lido por pessoas e analisado por programas. O contrato ricardiano é formatado como um arquivo de texto que pode ser facilmente lido (exibido ou impresso), e os programas podem convertê-lo em formas internas para pesquisar pares nome-valor. Inclui uma seção especial para cada tipo de contrato, como título, ação, moeda, etc. As seções adicionais descrevem, em termos analisáveis pelo programa, o uso de casas decimais, títulos e símbolos.
Como signatário legal, o Emissor assina o documento na forma de texto não criptografado OpenPGP com sua chave de assinatura de contrato [12]. Ele inclui a cadeia completa de chaves OpenPGP dentro do documento para permitir que os programas verifiquem e autentiquem diretamente.
Para identificar o contrato de forma exclusiva, qualquer usuário pode calcular um resumo da mensagem canônica sobre o documento assinado. Este resumo da mensagem está incluído em todos os registros de transações e fornece um link seguro (não-forjável) do documento para a contabilização da emissão.
Por exemplo, e3b445c2a6d82df81ef46b54d386da23ce8f3775 é o resumo de mensagem completo para a emissão de dólares de serviços pré-pagos da Systemics Inc. comumente chamado de hash, o resumo da mensagem é uma técnica criptográfica para criar um número relativamente pequeno de um para um com o documento. Ou seja, para cada documento, há apenas um hash, e o hash refere-se exclusivamente a esse documento. O algoritmo é o padrão conhecido, SHA1.
3.1 Algumas Observações
As observações a seguir destacam o quão forte é o resultado.
Hash Limita o frog-boiling [fervura do sapo] . Uma mudança gradual no contrato pela parte mais forte ao longo do tempo é conhecida como frog-boiling [fervura do sapo]. A parte mais forte é geralmente o emissor e pode-se esperar que altere o contrato se houver um benefício. Este é um ataque frequente. Um resultado do uso do identificador hash é que nenhuma das partes pode alterar o contrato arbitrária ou sub-repticiamente.
Para ver se isso é verdade, precisamos examinar os registros que se referem ao hash. Um aplicativo pode assinar todos os registros importantes (por exemplo, pagamentos, tokens, recibos, saldos) e esses registros assinados incluem o hash de um contrato ricardiano. O hash dentro do registro não pode ser alterado sem perder sua capacidade de passar no teste de validade da assinatura. Da mesma forma, o contrato não pode ser alterado sem perder sua relação com os registros já assinados e entregues. Em outras palavras, cada registro, mantido por cada usuário, incorpora uma cópia inalterável desse hash. Qualquer mudança no contrato cria um novo hash, e esse novo hash não é aquele que os usuários têm ou valorizam.
Isso cristaliza o contrato para ambas as partes, impedindo a parte mais forte de modificar sutilmente o contrato em algum estágio posterior. Até certo ponto, isso corrige o desequilíbrio de poder entre o provedor e o cliente na oferta de um contrato formal. A parte inferior não tem opção de negociar, mas nem a parte maior tem a opção de reivindicar um contrato distinto em um momento posterior. A limitação vem com algum custo, pois pode ser um incômodo para a equipe de suporte desse instrumento financeiro.
[12] Jon Callas, et al, “OpenPGP Message Format,” Internet Draft, RFC2440bis (-10 draft).
Terminamos a parte quatro, no próximo a quinta.
