Boa tarde povo!
No versículo passado vimos a sexta parte de “Financial Cryptography in 7 Layers”. Hoje a sétima.
Governança
Uma vez que o contexto de valor é definido, indicando o tamanho e a natureza dos instrumentos, podemos abordar as questões de governança dos sistemas de pagamento e negociação.
Estes são substancialmente complexos [44]. A fim de preservar os sistemas intactos na presença de fraude ativa no domínio não técnico, muitas obrigações de divulgação e informação são abundantes. No sistema Ricardo, abordamos a camada de governança de três maneiras principais:
- Governança Estática: persistência e disponibilidade de contrato.
- Governança Estrutural: separação de preocupações e garantia de que partes confiáveis sejam empregadas para realizar elementos singulares do protocolo.
- Governança Dinâmica: auditoria em tempo real do balanço patrimonial e outros valores-chave.
Cada um deles é discutido abaixo [45].
Governança Estática
Na governança estática, garantimos que o usuário tenha o contrato e que todos os envolvidos saibam que o usuário tem o contrato [46].
A fim de assegurar que o contrato Ricardiano esteja sempre presente e disponível ao usuário, e seja continuamente vinculante para o Emissor, tomamos o resumo da mensagem do documento e usamos esse resumo da mensagem como o identificador do instrumento [47].
Considere um resumo de mensagem, por exemplo, 9c7c9e7bb564224977aea8674623a37407b8f6ee sendo um grande número de bits codificados em hexadecimal. O usuário não pode interpretar significativamente essa sequência de informações aparentemente aleatórias, de modo que o software (e, portanto, o engenheiro de software) seja mais ou menos forçado a manter um banco de dados que descreva o que o resumo da mensagem representa. Como o contrato é legível pelo software, ele cria uma fonte de dados superior a qualquer outra (como um banco de dados intermediário que armazena o conteúdo) e assim podemos razoavelmente assumir, na medida em que o software pode, que o usuário tenha o contrato completo disponível [48].
O sistema garantirá, assim, que, para todos os efeitos práticos, o usuário tenha o contrato. Isso proporciona duas economias de custo, limitando tanto o suporte contínuo quanto a probabilidade de litígio [49].
44. Muitos projetos de sistemas de Criptografia Financeira limitaram os Emissores a serem bancos, o que permite o projetista assumir muitas complicações.
45. Esta seção é baseada nas sessões comerciais Talk on DigiGold Governance, Financial Cryptography 1999, de Ian Grigg.
46. A mesma lógica também implicaria que o usuário deve ter acesso a informações dinâmicas de negociação, como preços, mas passamos por cima disso aqui.
47. Tendo abstraído o conteúdo da identidade do documento tomando um resumo da mensagem dele, podemos discutir o valor, da perspectiva dos sistemas de pagamento, como sendo total e exclusivamente definido pelo resumo da mensagem. Isso garante que o Emissor da security não possa alterar os termos do contrato de forma alguma sem oferecer aos termos do usuário para troca.
48. Isso também tem um efeito secundário de encurtar a distância entre o contrato e o software que o gerencia, simplificando assim o design. No entanto, o principal objetivo era, e continua sendo, um sistema em que sabemos que o usuário tem um forte acesso às informações do contrato.
49. Tal esquema pode não impedir que o engenheiro de software forneça um aplicativo cliente que deturpe o contrato. No entanto, isso seria um problema entre o usuário e o fornecedor do software, em vez do próprio sistema, especialmente, os operadores do sistema e os emissores de securities não estariam claramente errados.
Foi esta a sétima parte da obra, amanhã segunda a oitava. Deus os abençoe!
