Nos últimos quatro dias houve algo notável no Ethereum. Tudo começou com um bug numa plataforma chamada Parity, uma carteira para a blockchain de Ethereum, que congelou cerca de 513.000 ethers em novembro de 2017. Essa quantidade significativa de recursos ficou travada, sem acesso por seus proprietários ou qualquer outra pessoa. As soluções passariam por uma intervenção e mudança no código do Ethereum. Diversas propostas diretamente sobre isso – ou mais genéricas, como a Ethereum Improvement Proposal (EIP) 156 – foram propostas: a escolhida foi a EIP 999, que trata diretamente desse caso. Uma votação foi proposta para decidir se essa proposta passaria e, ontem, foi decidida que não.
Um texto para explicar toda essa confusão seria importante, porém mais importantes são três pontos que em geral ficam numa análise em segundo nível. O primeiro é sobre a necessidade ou utilidade de intervenções sobre falhas de código. O segundo é sobre o quanto essas intervenções não representam um poder discricionário dos desenvolvedores e da comunidade: será que há alguma possibilidade de governança que balanceie essa estrutura? O terceiro, finalmente, é sobre votações serem uma forma válida de decidir isso e sobre qual o design de votações ótimo.
Alex Van de Sande, importante membro da comunidade do Ethereum, escreveu um texto que responde parcialmente o primeiro tópico: ao se fechar a porta na cara de desenvolvedores importantes como os do Parity, há a possível perda de uma equipe importante. Não se pode desprezar a influência de desenvolvedores talentosos no sucesso de uma criptomoeda, como sempre afirmo aqui nessa coluna e acompanho constantemente em pesquisas acadêmicas. Esses desenvolvedores precisam ser incentivados a não criarem um hard fork. Apesar de eu acreditar que a matemática financeira subjacente ao argumento exposto por Van de Sande é falha, seu raciocínio sobre incentivos está correto. Ele apoia que, ao invés de deliberações para cada falha, haja um sistema de transferência de ethers a players que foram prejudicados por falhas.
Entretanto, por mais que haja contingenciamentos do tipo, volta e meia há problemas que não são previsíveis ou cuja estrutura é nova. Na economia, isso se dá o nome de contratos incompletos: quando não é possível especificar o que fazer em cada novidade, contratos completos são impossíveis. Para resolver isso, uma estrutura de governança ex-ante deve ser bem estabelecida. Quando houve o problema do TheDAO – com congelamento dos fundos do smart contract defeituoso – podemos discutir se houve um precedente para intervenções dos desenvolvedores core nas decisões sobre falhas. Quando houve um hard fork para evitar que os fundos do TheDAO fossem perdidos, mostrou-se que há vontade do Core de agir discricionariamente. Isso necessariamente é ruim?
A pesquisa em economia política teórica – em especial um artigo de dois prêmios Nobel – diz que a escolha entre “ditadura”, democracia representativa e democracia direta depende de diversos fatores, em particular o escopo das decisões, a qualidade da informação disponível para o público geral. Em geral, a decisão acerca de tópicos muito importantes onde a informação não é custosa tende a ser melhor por democracia direta – votação nesse caso seria o ótimo – porém quando a decisão precisa ser rápida ou a decisão da maioria pode afetar negativamente uma minoria injustamente, a autocracia do Core pode ser um remédio amargo para os problemas. De maneira geral, percebe-se que para questões técnicas, o Core pode e deve ser autocrático em parceria com os mineradores. Para questões gerais, a democracia direta pode ser utilizada, porém no caso de potenciais injustiças é melhor soluções como as de Van de Sande, que automatizam e prescrevem ex-ante as soluções para problemas conhecidos. Isso seria, inclusive, compatível com a literatura em contratos incompletos. Nesse caso, há uma estrutura de governança menos confusa que deve emergir.
Por fim, nos casos de desenho de solução emergencial que exijam a democracia direta, a estrutura da votação deve ser discutida. Na votação do EIP999 houve padrões emergentes que devem levantar sérias preocupações por parte do Core do Ethereum. Em quatro dias de votações, houve grande volatilidade no resultado eleitoral; isto é, frequentemente haveria incerteza e reviravoltas sobre quem – partidários da EIP ou contrários – venceria. Como a votação é baseada no número de ethers possuído, os grandes votantes influenciam demasiado no resultado. Quando um eleitor baleia surge, ele pode fortemente alterar as proporções de voto. Além do mais, apenas uma pequena porção dos ethers votou, acentuando esse efeito.
Uma estrutura representativa pode mitigar esses resultados. Há pessoas de respeito na comunidade que se manifestam sobre esses casos e investidores interessados teriam como delegar seus direitos de voto em EIPs a eles. Apesar de não ótima, essa estrutura, se bem desenhada, pode levar a maior proporção de votos e maior representatividade. Ela, por um lado, cria baleias, porém também com tempo suficiente para a votação ela permite que esses representantes votem e, caso seu voto não seja satisfatório numa questão importante, que seus representados saiam ou procurem representantes mais condizentes com suas crenças, confirmando assim seus votos.
Essas questões podem parecer pouco importantes, porém falhas de código são eventualmente inevitáveis. Assim como na economia real há bailouts para bancos “too big to fail”, o mesmo vale para a governança de criptoativos. Saber diminuir a arbitrariedade no processo é fundamental para plataformas funcionais de aplicativos descentralizados. O Ethereum ainda patina nesse aspecto, porém boas contribuições vêm surgido. Creio que a proposta do Alex Van de Sande é uma discussão importante que a comunidade terá que realizar se quiser maior credibilidade frente a potenciais falhas em suas aplicações. O Core do Ethereum é extremamente sério, felizmente. A questão é esperar para ver para o rumo que ele tomará e seus impactos na valuation dos ativos da blockchain do Ethereum.