O caso contra os “contratos inteligentes atualizáveis”

Uma das primeiras coisas que notei como um programador de um cliente-servidor “tradicional” para o desenvolvimento de contratos inteligentes é que os aplicativos construídos sobre contratos inteligentes (“dapps”) não são atualizáveis. Embora seja fácil, no mundo cliente-servidor, alterar a lógica de um aplicativo já implantado (mantendo a integridade de seus dados), os contratos inteligentes são imutáveis. Mudar a lógica de um contrato inteligente já implantado significaria alterar o histórico do blockchain, o que é (por design/definição) impossível.

No começo, isso parecia uma barreira intransponível para minha percepção do que a criação de software implicava. Eu (e muitos outros como eu) aprendemos a construir software para pessoas de maneira iterativa, usando a implantação contínua como um mecanismo para testar o comportamento do usuário e eliminar bugs. Você não pode fazer isso se só puder implantar seu software uma vez.

Algumas pessoas notáveis ​​no espaço forneceram soluções para esse problema. E muitas outras pessoas inteligentes parecem estar trabalhando nessa questão também. Uma das abordagens mais populares é usar um contrato inteligente “despachante” (dispatcher) estático que delega as chamadas metódicas para a versão adequada da lógica real do contrato. Apenas um administrador designado (geralmente o desenvolvedor do contrato) pode alterar o contrato do dispatcher para apontar para a versão correta do contrato delegado.

Embora eu goste dessa solução esteticamente, não posso deixar de sentir que estão faltando esforços aqui. Os aplicativos descentralizados não devem ser mutáveis. Uma das principais razões pelas quais a descentralização é útil em redes de software é que ela elimina a confiança em uma autoridade central. Isso pode criar novas dinâmicas que não podem ser representadas na Internet cliente-servidor.

Ao tornar publicamente um contrato mutável por um administrador, um desenvolvedor está criando um nível de confiança semelhante àquele envolvido no uso de um serviço da web. Eu realmente acho que se você for tão longe, você deve apenas criar um serviço da web; a economia da unidade é muito melhor na web2. A maioria dos aplicativos web3 deve ser projetada com a expectativa de que a lógica não mude (ou pelo menos que ela não mude de forma controlada pelos desenvolvedores, mas vou adiar o mergulho na governança blockchain aqui).

Eu acho que essa má alocação de esforço fala de um fenômeno mais geral. No momento, há uma grande migração de criadores de produtos cliente-servidor para o desenvolvimento de blockchain e contratos inteligentes (do qual eu faço parte). Ao longo de anos de experiência na criação de material em um ambiente, tivemos intuições sobre “como criar produtos” que podem não ser apropriados no ambiente em que estamos entrando. Uma expectativa de “upgradability” (“capacidade de ser atualizado”) é apenas um exemplo.

Se você estiver explorando a capacidade de atualização em seu contrato inteligente, dê um passo para trás e pergunte se essa é a decisão certa em um contexto descentralizado. Ou talvez eu é que esteja completamente fora da base aqui; se eu sou, por favor me diga por que estou errado.

(Lakshman Sankar)
Fonte: medium.com/

Guia do Bitcoin

Mantenha-se informado todos os dias sobre Bitcoin!
Telegram: https://telegram.me/guiadobitcoin
Facebook: https://www.facebook.com/guiadobitcoin/
Twitter: https://twitter.com/guiadobitcoin
Feed RSS: https://guiadobitcoin.com.br/feed/