Boa noite irmãos!
Hoje vemos a última parte da tradução de “A Formal Language for Analyzing Contracts”. No versículo de antes vimos a penúltima.
Perguntas Frequentes
P: Já existem linguagem para especificar contratos financeiros [7], qual é a novidade aqui?
R: Essa é a primeira linguagem de especificação a generalizar estruturas contratuais para qualquer tipo de direitos exclusivos, não apenas para dinheiro. Esse também é a primeira linguagem que incorpora a natureza dinâmica de muitos contratos (sua dependência de tempo ou eventos) de maneira sucinta, completa e potencialmente executável. Surpreendentemente, isso geralmente torna a especificação mais, não menos, sucinta.
P: Onde está o dinheiro?
R: Essa linguagem é direcionada para uma economia de software e dispositivos distribuídos que executam serviços um para o outro. Uma economia monetária pode ser construída a partir de uma economia de troca, mas não vice-versa. O dinheiro online real é muito mais sutil do que uma mera variável compartilhada (ou mesmo a especificação de “notas de banco” nessa linguagem). O dinheiro é apenas um tipo de direito exclusivo fungível, e a estrutura dos contratos financeiros é generalizada pela conversão de termos monetários em qualquer direito exclusivo fungível.
P: Que suposições você está fazendo?
R: Essa é a pergunta mais importante a ser feita em qualquer novo esquema! Eu identifiquei pelo menos as seguintes:
- Por enquanto, estou presumindo que questões de proteção e execução de desempenho foram abordadas em outros lugares (http://szabo.vwh.best.com/ tem muitos ensaios que enfocam esse tópico). Um objetivo final é criar protocolos para reforçar os átomos da linguagem e depois compor esses átomos mantendo a aplicabilidade.
- Duas premissas específicas de execução – existe uma fonte de tempo acordada e segura, e a ocorrência de outros eventos definidos pode ser acordada pelas partes e/ou auditada por terceiros.
- Estou assumindo algum tipo de atomicidade para cada desempenho do átomo correto – por exemplo, quando um evento aciona um “when”, um functionPerformance em outro thread é suavemente revertido ou concluído.
- Existem apenas duas partes no contrato, o Titular e a Contraparte.
- Um contrato vem em duas formas de espelho, uma das quais pode ser deduzida da outra. Uma parte sempre se vê como o Titular. As obrigações do Titular sempre podem ser expressas e inferidas a partir dos direitos da Contraparte e vice-versa.
- Provavelmente estou fazendo outras suposições que ainda não descobri – se você encontrar alguma, por favor me avise!
P: Quais são alguns dos problemas dessa linguagem que você gostaria que fossem resolvidos?
R: Implementações que satisfazem as premissas acima para os átomos de linguagem específicos e também para composições dos átomos. (Obviamente, vários protocolos no campo “criptografia financeira”, em minhas próprias propostas, na linguagem E, etc. fornecem muitos blocos de construção valiosos para essas soluções).
Referências
Nas notas de rodapé ao longo do texto
Foi esta a tradução da obra “A Formal Language for Analyzing Contracts”, de Satoshi Nakamoto Nick Szabo. Espero que tenham gostado. No versículo seguinte começamos tradução de nova obra. Até mais!
