Boa noite amigos!
No anterior demos início à tradução de “The Ricardian Contract“, no de hoje continuamos.
2. Emissões de Valor como Contratos
2.1. Um Esquema de Primeira Geração
Considere o caso do esquema pioneiro de dinheiro digital, eCash, como originalmente criado pela DigiCash BV. A primeira moeda de valor, emitida pelo Mark Twain Bank dos EUA, foi identificado pelo número 4. Reza a lenda que o sistema inicial alocava um pequeno número sequencial para cada moeda. Os sistemas de teste já haviam adquirido 0, 1, 2, 3 e então 4 era o próximo. As premissas de marketing do DigiCash mudaram para assumir uma emissão por país. As deficiências desse esquema se tornaram aparentes, então um novo design foi criado [4]. Foi utilizado um número de 32 bits para descrever a emissão, na suposição pragmática de que isso seria grande o suficiente para cobrir eventualidades previsíveis.
No entanto, as tensões de um emissor e uma moeda eram óbvias quase que imediatamente. Um esquema mais avançado poderia usar uma tupla de (emissor, moeda) para descrever um sistema pelo qual cada emissor é autorizado, em certo sentido, a emitir várias moedas concorrentes [5]. É fácil generalizar esse sistema adicionando elementos adicionais à tupla: (emissor, tipo, identificador) tupla [6]. Por exemplo, um título de cupom zero emitido pela Joint Universal e Nationwide Keiretsu que é pago em janeiro de 2100 pode ter uma tupla de (JUNK, zero, Jan_2100).
2.2. O Problema com Números
Os números como um espaço para identificar instrumentos digitais são limitantes, e ter tuplas como uma extensão não é realmente uma resposta.
Em primeiro lugar, o que eles descrevem? No caso de sistemas de dinheiro eletrônico, eles podem descrever moedas e emissores. É um ou ambos, e como generalizamos para outros aspectos? Em segundo lugar, que garantia temos de que o que é descrito é exato? Embora muita coisa possa ser alcançada simplesmente com base na reputação do emissor, os especialistas financeiros sabem que o valor real é expresso nos detalhes e na confiabilidade da reivindicação. Terceiro, como os números são derivados? É necessário um registro central ou qualquer emissor de valor digital pode adquirir um número conforme os requisitos locais? Finalmente, há um limite para o espaço? Números inteiros, conforme expressos em pacotes, geralmente são limitados a uma quantidade de bits, como 32. Para engenharia prática de software, é preciso haver limites, mas esses limites precisam limitar as possibilidades de negócios?
2.3. O Desafio do Sucesso
Qualquer sistema bem-sucedido será usado de maneira que pareça estar quebrado. Como engenheiros de software, precisamos apresentar nossas invenções com a humildade dos fabricantes de ferramentas para as futuras gerações de construtores, não como burocratas que planejam o zoneamento do espaço de comércio digital.
O que acontece quando passarmos pelos early adopters [primeiros adotantes], dominarmos as mães e os pais, e a competição estiver se voltando ferozmente para o nosso conjunto de idosos aposentados? Imagine mints [casas da moeda] no bolso de bilhões de idosos aposentados jogadores de joguinhos. Ou, imagine um mundo com um emissor digital de pontos de fidelidade em cada parquímetro, ou onde estudantes pagam sua faculdade com parcelas de ganhos futuros. Já vimos músicos populares vendendo títulos lastreados em suas músicas [7], e propostas de correções de bugs de software financiadas por emissões securitizadas a usuários anônimos [8].
2.4. O Cupom de Títulos Zero
Considere cupom de título zero, um instrumento que paga o valor nominal de uma moeda em uma determinada data. O zero é talvez o instrumento financeiro geral mais simples de uso comum e constituiu a referência para o nosso design.
Para descrever o valor nominal, a moeda do valor nominal e a data de vencimento desse título, adicionaríamos elementos adicionais à tupla acima. Mas isso é apenas um começo. Em sua descrição de Eurobonds, Noel Clarke espera dezenas ou centenas de campos [9]. Se examinarmos apenas uma dessas características, por exemplo, opções de venda relacionadas a eventos, descobrimos que um vínculo precisa descrever o que acontece no caso de:
- aquisição hostil ou amigável do emissor,
- aquisição pelo emissor de outra parte,
- uma recapitalização,
- um programa de recompra pelo emissor de suas próprias ações, ou
- uma distribuição de ativos acima de uma certa porcentagem do patrimônio líquido da emissão.
Esses itens se vinculam firmemente ao instrumento em questão, mas representam dificuldades para o arquiteto de software. Podemos fazer uma série de observações.
Em primeiro lugar, cada evento não é simples. Hoje, pode-se ser capaz de calçar a noção de “uma aquisição hostil ou amigável” em um único par nome-valor, mas isso não sobreviveria à cena em evolução de regulamentação e litígio que se aplica a tais eventos.
Em segundo lugar, não há razão para acreditar que a lista acima esteja completa.
Em terceiro lugar, não só será difícil projetar um único campo de qualquer tipo para lidar com isso, como também estará cheio de texto jurídico.
Considere um ponto de vista do layout de dados. Para descrever o documento que forma a base de um título, precisaremos de um banco de dados de tuplas estruturado em árvore, no mínimo. Além disso, esse layout só funcionará para um instrumento, ou um conjunto de instrumentos extremamente rígido e quase fungível.
[4] Bryce Wilcox, open design review, DigiCash’s developer list, <ecash-dev@digicash.com>, August 1997.[5] Ibid, Rachel Willmer, 14 August 1997.
[6] Robert Hettinga, “What’s a Digital Bearer Bond?” e$ rants, 19th November, 1995
[7] Alex Tajirian, “David Bowie Bonds,”
[8] Ian Grigg and C. Petro, “Using Electronic Markets Achieve Efficient Task Distribution,” 1st Conference on Financial Cryptography, Anguilla, 1997, Springer-Verlag LNCS 1318.
[9] Noel Clarke, Guide to Eurobonds, The Economist Intelligence Unit, 1993.
Foi este o segundo versículo, no seguinte a parte 3. Grande abraço virtual, fiquem bem.
