Por que muitos casos de uso de contratos inteligentes são simplesmente impossíveis

O Dr. Gideon Greenspan é o fundador e CEO da Coin Sciences, a empresa por trás da plataforma MultiChain para blockchains privadas.

Neste artigo de Opinião , Greenspan discute contratos inteligentes habilitados para blockchain e por que essa aplicação da Tecnologia pode estar sofrendo com expectativas infladas.

Como desenvolvedor de uma plataforma blockchain popular, às vezes me perguntam se contratos inteligentes como o Ethereum estão no roteiro do MultiChain. A resposta que sempre dou é: 'Não, ou pelo menos ainda não'.

Mas no mundo cheio de entusiasmo das blockchains,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 de estilo bitcoin autorizados (proveniência, manutenção de registros de empresas e Finanças leves), ainda não encontramos o equivalente para Ethereumcontratos inteligentes.

Não é que as pessoas T entendam o que querem que os contratos inteligentes façam. Em vez disso, é que muitas dessas ideias são simplesmente impossíveis. Quando pessoas inteligentes ouvem o termo "contratos inteligentes", suas imaginações tendem a correr soltas. Elas evocam sonhos de software inteligente autônomo, indo para o mundo, levando dados junto para o passeio. Infelizmente, a realidade dos contratos inteligentes é mais mundana.

Um contrato inteligente é um pedaço de código que é armazenado em um blockchain, acionado por transações de blockchain e que lê e grava dados no banco de dados desse blockchain. É isso. Sério.

Um contrato inteligente é apenas um nome chique para um código que roda em um blockchain e interage com o estado desse blockchain. E qual é o código? É Pascal, é Python, é PHP. É Java, é Fortran, é C++. Se estamos falando de bancos de dados, são procedimentos armazenados escritos em uma extensão do SQL.

Todas essas linguagens são fundamentalmente equivalentes, resolvendo os mesmos tipos de problemas das mesmas maneiras. Claro, cada uma tem seus pontos fortes e fracos – você seria louco se construísse um site em C ou comprimisse um vídeo HD em Ruby. Mas, pelo menos em princípio, você poderia, se quisesse. Você só pagaria um preço alto em termos de conveniência, desempenho e, muito provavelmente, seu cabelo.

O problema com contratos inteligentes T é apenas que as expectativas das pessoas são exageradas, mas que essas expectativas estão levando muitas pessoas 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 – do momento em que a alta gerência 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 encurtar esse tempo.

Nos últimos nove meses, nos foram apresentados muitos casos de uso de contratos inteligentes e nos vimos respondendo, repetidamente, que eles simplesmente não podem ser feitos.

Como resultado, identificamos os três equívocos de contrato inteligente mais comumente mantidos. Essas ideias T estão erradas porque a Tecnologia é imatura ou as ferramentas ainda não estão disponíveis.

Em vez disso, eles entendem mal as propriedades fundamentais do código que reside em um banco de dados e é executado de forma descentralizada.

1. Contato com serviços externos

Frequentemente, o primeiro caso de uso proposto é um contrato inteligente que muda seu comportamento em resposta a algum evento externo. Por exemplo, uma Política 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 horário 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. Por quê? Porque um blockchain é um sistema baseado em consenso, o que significa que ele só funciona se cada nó atingir um estado idêntico após processar cada transação e bloco.

Tudo o que acontece em uma blockchain deve ser completamente determinístico, sem nenhuma possibilidade de diferenças surgirem. No momento em que dois nós honestos discordam sobre o estado da cadeia, o sistema inteiro se torna inútil.

Agora, lembre-se de que os contratos inteligentes são executados independentemente por cada nó em uma cadeia. Portanto, se um contrato inteligente recupera alguma informação 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 tempo entre solicitações de diferentes nós, ou talvez ela fique temporariamente indisponível. De qualquer forma, o consenso é quebrado e todo o blockchain morre.

Então, qual é a solução alternativa? Na verdade, é bem 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 uma computação de contrato inteligente.

Em outras palavras, um oráculo envia os dados para o blockchain em vez de um contrato inteligente extraí-los.

Quando se trata de contratos inteligentes causando Eventos no mundo externo, um problema semelhante aparece. 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 o código na cadeia de forma independente, quem é responsável por chamar essa API?

Se a resposta for apenas um nó, o que acontece se esse nó em particular apresentar mau funcionamento, deliberadamente ou não? E se a resposta for todos os nós, podemos confiar em todos os nós com 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 da API foi bem-sucedida, voltamos 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 poderia observar proativamente um blockchain e executar transferências de dinheiro que espelham as transações on-chain. Isso não apresenta risco ao consenso do blockchain porque a cadeia desempenha um papel totalmente passivo.

Observando 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, isso prejudica o objetivo de um sistema descentralizado.

Segundo, os mecanismos usados nessas soluções alternativas são exemplos diretos de leitura e escrita de 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 espelha o estado do blockchain no mundo real não está fazendo nada mais do que ler dessa cadeia. Em outras palavras, qualquer interação entre um blockchain e o mundo externo é restrita a operações regulares de banco de dados.

Falaremos mais sobre esse fato mais tarde.

2. Aplicação de pagamentos on-chain

Aqui está outra proposta que costumamos ouvir muito: usar um contrato inteligente para automatizar o pagamento de cupons para um chamado " BOND inteligente". A ideia é que o código do contrato inteligente inicie automaticamente os pagamentos nos momentos apropriados, evitando processos manuais e garantindo que o emissor não possa entrar em default.

É claro que, 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 pagamento.

Lembre-se de que um blockchain é apenas um banco de dados, neste caso um livro-razão financeiro contendo o BOND emitido e algum dinheiro. Então, quando falamos sobre pagamentos de cupons, o que estamos falando na verdade são 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, então esses pagamentos podem de fato ser garantidos. Mas isso também significa que esses fundos não podem ser usados ​​pelo emissor do BOND para mais nada. E se esses fundos T estiverem sob o controle do contrato inteligente, então não há como garantir o pagamento.

Em outras palavras, um smart BOND é inútil para o emissor ou inútil para o investidor. E se você pensar sobre isso, esse é um resultado completamente óbvio.

Da perspectiva de um investidor, o ponto principal de um BOND é sua taxa de retorno atrativa, ao custo de algum risco de inadimplência. E para o emissor, o propósito 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 BOND fazer uso dos fundos levantados e, ao mesmo tempo, garantir que o investidor será reembolsado. Não deveria ser surpresa que a conexão entre risco e retorno não seja um problema que os blockchains possam resolver.

3. Ocultar dados confidenciais

Como já escrevi anteriormente, o maior desafio na implantação de blockchains é a transparência radical que eles fornecem.

Por exemplo, se 10 bancos configuram um blockchain juntos, e dois conduzem uma transação bilateral, isso será imediatamente visível para os outros oito. Embora existam várias estratégias para mitigar esse problema, nenhuma supera a simplicidade e a 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 acham que contratos inteligentes podem resolver esse problema. Elas começam com o fato de que cada contrato inteligente contém seu próprio banco de dados em miniatura, sobre o qual ele 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. (Esse acoplamento estreito entre dados e código é chamado de encapsulamento e é a base do popular paradigma de programação orientada a objetos).

Então, se um contrato inteligente T pode acessar os dados de outro, resolvemos o problema da confidencialidade do blockchain? Faz sentido falar em esconder informações em um contrato inteligente? Infelizmente, a resposta é não.

Porque mesmo que um contrato inteligente T consiga ler os dados de outro, esses dados ainda são armazenados em cada nó da cadeia. Para cada participante do blockchain, eles estão na memória ou no 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 eles escolherem fazê-lo.

Ocultar dados em um contrato inteligente é quase tão seguro quanto ocultá-los no código HTML de uma página da web. Claro, usuários comuns da web T os verão, porque eles não são exibidos na janela do navegador. Mas tudo o que é preciso é que um navegador da web adicione uma função 'View Source' (como todos eles têm), e as informações se tornam universalmente visíveis.

Da mesma forma, para dados ocultos em contratos inteligentes, tudo o que é preciso é que alguém modifique seu software blockchain para exibir o estado completo do contrato, e toda a aparência de sigilo é perdida.

Um programador razoavelmente decente conseguiria fazer isso em mais ou menos uma hora.

Para que servem os contratos inteligentes

Com tantas coisas que os contratos inteligentes não podem fazer, ONE pode se perguntar para que eles realmente servem. Mas para responder a essa pergunta, precisamos voltar aos fundamentos dos próprios blockchains. Para recapitular, um blockchain permite que um banco de dados seja compartilhado direta e seguramente por entidades que não confiam umas nas outras, sem exigir um administrador central.

Blockchains permitem a desintermediação de dados, o que 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 naquele banco de dados que devem ter sucesso 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. Em contraste, em um banco de dados compartilhado orientado 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 tem que 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 livremente dar a si mesmos tanto dinheiro quanto quisessem.

Pode- ONE imaginar várias maneiras de expressar essas regras, mas por enquanto há dois paradigmas dominantes, inspirados por 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 deletadas por essa transação e (b) as entradas criadas.

Em um livro-razão financeiro, a regra estabelece que a quantidade total de fundos nas entradas excluídas deve corresponder ao total daquelas criadas. (Consideramos a modificação de uma entrada existente equivalente a excluir essa entrada e criar uma ONE 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 realizadas por seu código. (No contexto de bancos de dados tradicionais, podemos pensar nisso como um procedimento armazenado imposto.) Para modificar os dados de um contrato, os usuários do blockchain enviam solicitações ao seu código, que determina se e como atender a essas solicitações.

Como 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 se há fundos suficientes, deduzir de uma conta e adicionar em outra.

Ambos os paradigmas são eficazes, e cada um tem suas vantagens e desvantagens. Para resumir, as restrições de transação no estilo bitcoin fornecem simultaneidade e desempenho superiores, enquanto os contratos inteligentes no estilo Ethereum oferecem maior flexibilidade.

Então, voltando à questão sobre para que servem os contratos inteligentes: os contratos inteligentes são para casos de uso de blockchain que T podem ser implementados com restrições de transação.

Dado esse critério para usar contratos inteligentes, ainda não vi um caso de uso forte para blockchains com permissão que se qualifique.

Todos os aplicativos blockchain atraentes que conheço podem ser implementados com transações no estilo bitcoin, que podem lidar com permissão e armazenamento geral de dados, bem como criação de ativos, transferência, custódia, troca e destruição. No entanto, novos casos de uso ainda estão aparecendo, e eu T ficaria surpreso se alguns exigissem o poder dos contratos inteligentes. Ou, pelo menos, uma extensão do paradigma Bitcoin .

Seja qual for a resposta, o importante é lembrar que os contratos inteligentes são apenas um método para restringir as transações realizadas em um banco de dados.

Isso é, sem dúvida, algo útil, e é essencial para tornar esse banco de dados seguro para compartilhamento. Mas contratos inteligentes não podem fazer mais nada, e certamente não podem escapar dos limites do banco de dados no qual residem.

Imagem de lápis e borrachavia Shutterstock