Cuidado com o contrato inteligente impossível

Os três equívocos de contrato inteligente mais comuns

Como desenvolvedores de uma plataforma de blockchain popular, às vezes somos questionados se os contratos inteligentes do tipo Ethereum estão no MultiChain roteiro. A resposta que sempre dou é: não, ou pelo menos ainda não.

Mas no mundo repleto de hype dos blockchains, os contratos inteligentes estão na moda, então por que não? Bem, o problema é que, embora agora saibamos de três casos de uso fortes para blockchains do tipo Bitcoin permitido (proveniência, registros entre empresas e finanças leves), ainda não encontramos o equivalente para contratos inteligentes do tipo Ethereum.

Não é que as pessoas não tenham ideias sobre o que desejam que os contratos inteligentes façam. Em vez disso, é que muitas dessas ideias são simplesmente impossíveis. Veja, quando pessoas inteligentes ouvem o termo “contratos inteligentes”, sua imaginação tende a correr solta. Eles invocam sonhos de software inteligente autônomo, indo para o mundo, levando seus dados para um passeio.

Infelizmente, a realidade dos contratos inteligentes é muito mais mundana do que tudo isso:

Um contrato inteligente é um pedaço de código que é armazenado em um blockchain, disparado por transações de blockchain, e que lê e grava dados no banco de dados daquele blockchain.

É isso. Mesmo. Um contrato inteligente é apenas um nome chique para o código que executa em um blockchain e interage com o estado desse blockchain. E o que is código? É Pascal, é Python, é PHP. É Java, é Fortran, é C ++. Se estamos falando de bancos de dados, é procedimentos armazenados escrito em uma extensão do SQL. Todas essas linguagens são fundamentalmente equivalentes, resolvendo os mesmos tipos de problemas da mesma maneira. Claro, cada um tem seus pontos fortes e fracos - você seria louco de construir um site em C ou compactar vídeo HD em Ruby. Mas, em princípio, pelo menos, você poderia se quisesse. Você pagaria um preço alto em termos de conveniência, desempenho e, muito provavelmente, pelo seu cabelo.

O problema com contratos inteligentes não é apenas que as expectativas das pessoas são exageradas. É que essas expectativas estão levando muitos a gastar tempo e dinheiro em ideias que não podem ser implementadas. Parece que as grandes empresas têm recursos suficientes para percorrer um longo caminho - desde o momento em que a alta administração encontra uma nova tecnologia, até quando as vantagens e limitações dessa tecnologia são verdadeiramente compreendidas. Talvez nossa própria experiência possa ajudar a reduzir esse tempo.

Nos últimos nove meses, recebemos muitos casos de uso de contrato inteligente e nos encontramos respondendo, repetidamente, que eles simplesmente não podem ser realizados. Como resultado, identificamos os três equívocos de contrato inteligente que são mais comumente mantidos. Essas ideias não estão erradas porque a tecnologia é imatura ou as ferramentas ainda não estão disponíveis. Em vez disso, eles entendem mal o propriedades fundamentais do código que reside em um banco de dados e é executado de forma descentralizada.

Contactar serviços externos

Freqüentemente, o primeiro caso de uso proposto é um contrato inteligente que muda seu comportamento em resposta a algum evento externo. Por exemplo, uma apólice de seguro agrícola que paga condicionalmente com base na quantidade de chuva em um determinado mês. O processo imaginado é mais ou menos assim: o contrato inteligente espera até o tempo predeterminado, recupera o boletim meteorológico de um serviço externo e se comporta adequadamente com base nos dados recebidos.

Tudo isso parece bastante simples, mas também é impossível. Porque? Porque um blockchain é um sistema baseado em consenso, o que significa que ele só funciona se todos os nós atingirem um estado idêntico após o processamento de todas as transações e blocos. Tudo o que ocorre em um blockchain deve ser completamente determinístico, sem nenhuma maneira possível para que as diferenças apareçam. No momento em que dois nós honestos discordam sobre o estado da cadeia, todo o sistema se torna inútil.

Agora lembre-se de que os contratos inteligentes são executados de forma independente por cada nó de uma cadeia. Portanto, se um contrato inteligente recupera algumas informações de uma fonte externa, essa recuperação é realizada repetidamente e separadamente por cada nó. Mas, como essa fonte está fora do blockchain, não há garantia de que cada nó receberá a mesma resposta. Talvez a fonte mude sua resposta no intervalo entre as solicitações de nós diferentes ou talvez fique temporariamente indisponível. De qualquer forma, o consenso é quebrado e todo o blockchain morre.

Qual é a solução alternativa? Na verdade, é bastante simples. Em vez de um contrato inteligente iniciar a recuperação de dados externos, uma ou mais partes confiáveis ​​(“oráculos”) criam uma transação que incorpora esses dados na cadeia. Cada nó terá uma cópia idêntica desses dados, para que possam ser usados ​​com segurança em um cálculo de contrato inteligente. Em outras palavras, um oráculo empurra os dados no blockchain em vez de um contrato inteligente puxando dentro

Quando se trata de contratos inteligentes que causam eventos no mundo externo, surge um problema semelhante. Por exemplo, muitos gostam da ideia de um contrato inteligente que chama a API de um banco para transferir dinheiro. Mas se cada nó estiver executando de forma independente o código na cadeia, quem é o responsável por chamar essa API? Se a resposta for apenas um nó, o que acontecerá se esse nó em particular funcionar mal, deliberadamente ou não? E se a resposta for cada nó, podemos confiar em cada nó a senha dessa API? E realmente queremos que a API seja chamada centenas de vezes? Pior ainda, se o contrato inteligente precisa saber se a chamada de API foi bem-sucedida, estamos de volta ao problema de depender de dados externos.

Como antes, uma solução alternativa simples está disponível. Em vez do contrato inteligente chamar uma API externa, usamos um serviço confiável que monitora o estado do blockchain e executa certas ações em resposta. Por exemplo, um banco pode monitorar proativamente um blockchain e realizar transferências de dinheiro que refletem as transações on-chain. Isso não representa nenhum risco para o consenso do blockchain porque a cadeia desempenha um papel inteiramente passivo.

Olhando para essas duas soluções alternativas, podemos fazer algumas observações. Primeiro, ambos exigem uma entidade confiável para gerenciar as interações entre o blockchain e o mundo externo. Embora isso seja tecnicamente possível, ele prejudica o objetivo de um sistema descentralizado. Em segundo lugar, os mecanismos usados ​​nessas soluções alternativas são exemplos diretos de lendo e escrevendo um banco de dados. Um oráculo que fornece informações externas está simplesmente escrevendo essas informações na cadeia. E um serviço que reflete o estado do blockchain no mundo real não faz nada mais do que ler essa cadeia. Em outras palavras, qualquer interação entre um blockchain e o mundo externo é restrita às operações regulares do banco de dados. Falaremos mais sobre esse fato mais tarde.

Aplicação de pagamentos em cadeia

Aqui está outra proposta que tendemos a ouvir muito: usar um contrato inteligente para automatizar o pagamento de cupons de um chamado “título inteligente”. A ideia é que o código de contrato inteligente inicie automaticamente os pagamentos nos momentos adequados, evitando processos manuais e garantindo que o emissor não fique inadimplente.

Obviamente, para que isso funcione, os fundos usados ​​para fazer os pagamentos também devem estar dentro do blockchain, caso contrário, um contrato inteligente não poderia garantir o seu pagamento. Agora, lembre-se de que um blockchain é apenas um banco de dados, neste caso um livro-razão financeiro contendo o título emitido e algum dinheiro. Portanto, quando falamos sobre pagamentos de cupons, estamos realmente falando sobre operações de banco de dados que ocorrem automaticamente em um horário acordado.

Embora essa automação seja tecnicamente viável, ela sofre de uma dificuldade financeira. Se os fundos usados ​​para pagamentos de cupons forem controlados pelo contrato inteligente do título, esses pagamentos podem de fato ser garantidos. Mas isso também significa que esses fundos não pode ser usado pelo emissor do título para mais nada. E se esses fundos não são sob o controle do contrato inteligente, então não há como o pagamento ser garantido.

Em outras palavras, um título inteligente não tem sentido para o emissor ou para o investidor. E se você pensar sobre isso, este é um resultado completamente óbvio. Do ponto de vista do investidor, o ponto principal de um título é sua taxa de retorno atraente, ao custo de algum risco de inadimplência. E para o emissor, o objetivo de um título é levantar fundos para uma atividade produtiva, mas um tanto arriscada, como construir uma nova fábrica. Não há como o emissor do título utilizar os recursos captados e, ao mesmo tempo, garantir o reembolso ao investidor. Não deveria ser uma surpresa que a conexão entre risco e retorno não é um problema que os blockchains possam resolver.

Escondendo dados confidenciais

Como eu escrito sobre anteriormente, o maior desafio na implantação de blockchains é a transparência radical que eles fornecem. Por exemplo, se dez bancos estabelecerem um blockchain juntos e dois conduzirem uma transação bilateral, isso ficará imediatamente visível para os outros oito. Embora existam várias estratégias para mitigar esse problema, nenhuma supera a simplicidade e eficiência de um banco de dados centralizado, no qual um administrador confiável tem controle total sobre quem pode ver o quê.

Algumas pessoas pensam que contratos inteligentes podem resolver esse problema. Eles começam com o fato de que cada contrato inteligente contém seu próprio banco de dados em miniatura, sobre o qual tem controle total. Todas as operações de leitura e gravação neste banco de dados são mediadas pelo código do contrato, tornando impossível para um contrato ler os dados de outro diretamente. (Este acoplamento estreito entre dados e código é chamado de encapsulamento e é a base do popular programação orientada a objetos paradigma.)

Portanto, se um contrato inteligente não pode acessar os dados de outro, resolvemos o problema da confidencialidade do blockchain? Faz sentido falar em ocultar informações em um contrato inteligente? Infelizmente, a resposta é não. Porque mesmo que um contrato inteligente não consiga ler os dados de outro, esses dados ainda são armazenados em cada nó da cadeia. Para cada participante do blockchain, está na memória ou disco de um sistema que esse participante controla completamente. E não há nada que os impeça de ler as informações de seu próprio sistema, se e quando quiserem.

Ocultar dados em um contrato inteligente é tão seguro quanto ocultá-los no código HTML de uma página da web. Claro, os usuários regulares da web não o verão, porque não é exibido na janela do navegador. Mas tudo o que é preciso é que um navegador da web adicione uma função 'Exibir código-fonte' (como todos fizeram) e as informações ocultas se tornam universalmente visíveis. Da mesma forma, para dados ocultos em contratos inteligentes, basta que alguém modifique seu software blockchain para exibir o estado completo do contrato e toda a aparência de sigilo é perdida. Um programador decente poderia fazer isso em uma hora ou mais.

Para que servem os contratos inteligentes

Com tantas coisas que os contratos inteligentes não podem fazer, pode-se perguntar para que eles realmente servem. Mas, para responder a essa pergunta, precisamos voltar aos fundamentos das próprias blockchains. Para recapitular, um blockchain permite que um banco de dados seja compartilhado de forma direta e segura por entidades que não confiam umas nas outras, sem a necessidade de um administrador central. Os blockchains permitem a desintermediação de dados e isso pode levar a economias significativas em complexidade e custo.

Qualquer banco de dados é modificado por meio de “transações”, que contêm um conjunto de alterações nesse banco de dados que devem ser bem-sucedidas ou falhar como um todo. Por exemplo, em um livro-razão financeiro, um pagamento de Alice para Bob é representado por uma transação que (a) verifica se Alice tem fundos suficientes, (b) deduz uma quantidade da conta de Alice e (c) adiciona a mesma quantidade à de Bob .

Em um banco de dados centralizado regular, essas transações são criadas por uma única autoridade confiável. Por outro lado, em um banco de dados compartilhado controlado por blockchain, as transações podem ser criadas por qualquer um dos usuários desse blockchain. E como esses usuários não confiam totalmente uns nos outros, o banco de dados deve conter regras que restrinjam as transações realizadas. Por exemplo, em um livro-razão financeiro ponto a ponto, cada transação deve preservar a quantidade total de fundos, caso contrário, os participantes poderiam dar a si mesmos tanto dinheiro quanto quisessem.

Pode-se imaginar várias maneiras de expressar essas regras, mas por enquanto existem dois paradigmas dominantes, inspirados em Bitcoin e Ethereum, respectivamente. O método Bitcoin, que podemos chamar de “restrições de transação”, avalia cada transação em termos de: (a) as entradas do banco de dados excluídas por aquela transação e (b) as entradas criadas. Em um livro razão financeiro, a regra determina que a quantidade total de fundos nas entradas excluídas deve corresponder ao total nas entradas criadas. (Consideramos a modificação de uma entrada existente equivalente a excluir essa entrada e criar uma nova em seu lugar.)

O segundo paradigma, que vem do Ethereum, são os contratos inteligentes. Isso afirma que todas as modificações nos dados de um contrato devem ser executadas por seu código. (No contexto de bancos de dados tradicionais, podemos pensar nisso como um Forçado procedimento armazenado.) Para modificar os dados de um contrato, os usuários do blockchain enviam pedidos ao seu código, que determina se e como atender a essas solicitações. Como em Neste exemplo, o contrato inteligente para um livro-razão financeiro executa as mesmas três tarefas que o administrador de um banco de dados centralizado: verificar fundos suficientes, deduzir de uma conta e adicionar a outra.

Ambos os paradigmas são eficazes e cada um tem suas vantagens e desvantagens, pois eu discutido em profundidade anteriormente. Para resumir, as restrições de transação no estilo Bitcoin fornecem concorrência e desempenho superiores, enquanto os contratos inteligentes no estilo Ethereum oferecem maior flexibilidade. Portanto, voltando à questão de para que servem os contratos inteligentes:

Contratos inteligentes são para casos de uso de blockchain que não podem ser implementados com restrições de transação.

Dado este critério para usar contratos inteligentes, ainda estou para ver um caso de uso forte para blockchains permitidos que se qualifiquem. Todos os aplicativos de blockchain atraentes que conheço podem ser implementados com transações no estilo Bitcoin, que podem lidar com permissão e armazenamento de dados em geral, bem como criação, transferência, depósito, troca e destruição de ativos. No entanto, novos casos de uso ainda estão aparecendo, e eu não ficaria surpreso se alguns do exigem o poder de contratos inteligentes. Ou, pelo menos, uma extensão do paradigma Bitcoin.

Qualquer que seja a resposta, a chave a lembrar é que os contratos inteligentes são simplesmente um método para restringir as transações realizadas em um banco de dados. Sem dúvida, isso é algo útil e essencial para tornar esse banco de dados seguro para compartilhamento. Mas os contratos inteligentes não podem fazer mais nada e certamente não podem escapar dos limites do banco de dados em que residem.

Por favor, poste comentários no LinkedIn.