Vitalik sobre o possível futuro do Ethereum (Parte Seis): The Splurge

No design do protocolo Ethereum, cerca de metade do conteúdo envolve diferentes tipos de melhorias na EVM, enquanto o restante é composto por vários temas de nicho, e é isso que significa "The Splurge" (A Prosperidade).

Título original: 《Possible futures of the Ethereum protocol, part 6: The Splurge》

Autor: Vitalik Buterin

Tradução: zhouzhou, BlockBeats

O conteúdo a seguir é do texto original (editado para facilitar a leitura e compreensão):

Algumas coisas são difíceis de categorizar em apenas uma classe; no design do protocolo Ethereum, há muitos "detalhes" que são extremamente importantes para o sucesso do Ethereum. Na prática, cerca de metade do conteúdo envolve diferentes tipos de melhorias na EVM, enquanto o restante é composto por vários temas de nicho, e é isso que significa "The Splurge" (A Prosperidade).

Roteiro de 2023: The Splurge

The Splurge: Objetivos-chave

• Tornar a EVM de alto desempenho e estável como "estado final"
• Introduzir abstração de contas no protocolo, permitindo que todos os usuários desfrutem de contas mais seguras e convenientes
<liOtimizar a economia das taxas de transação, aumentando a escalabilidade e reduzindo riscos
• Explorar criptografia avançada para melhorar significativamente o Ethereum a longo prazo

Melhorias na EVM

Que problema resolve?

Atualmente, a EVM é difícil de analisar estaticamente, o que dificulta a criação de implementações eficientes, a verificação formal do código e a expansão adicional. Além disso, a eficiência da EVM é baixa, tornando difícil implementar muitas formas de criptografia avançada, a menos que haja suporte explícito via pré-compilados.

O que é e como funciona?

O primeiro passo do roteiro atual de melhorias da EVM é o EVM Object Format (EOF), planejado para ser incluído no próximo hard fork. O EOF é uma série de EIPs que especificam uma nova versão do código da EVM, com várias características únicas, das quais as mais notáveis são:

• Separação entre código (executável, mas não pode ser lido pela EVM) e dados (legíveis, mas não executáveis)
• Proibição de saltos dinâmicos, permitindo apenas saltos estáticos
• O código da EVM não pode mais observar informações relacionadas ao gás
• Adição de um novo mecanismo explícito de sub-rotinas

Estrutura do código EOF

The Splurge: Melhorias na EVM (continuação)

Contratos antigos continuarão existindo e poderão ser criados, embora eventualmente possam ser descontinuados (ou até mesmo forçados a serem convertidos em código EOF). Contratos novos se beneficiarão do aumento de eficiência trazido pelo EOF — primeiro, por meio do recurso de sub-rotinas que reduz levemente o bytecode, e depois por novas funcionalidades específicas do EOF ou custos de gás reduzidos.

Após a introdução do EOF, futuras atualizações se tornam mais fáceis. Atualmente, a mais desenvolvida é a EVM Modular Arithmetic eXtension (EVM-MAX). O EVM-MAX cria um conjunto de operações voltadas para aritmética modular e as coloca em um novo espaço de memória inacessível por outros opcodes, permitindo otimizações como multiplicação de Montgomery.

Uma ideia mais recente é combinar EVM-MAX com Single Instruction Multiple Data (SIMD). O conceito de SIMD existe há muito tempo no Ethereum, proposto inicialmente por Greg Colvin no EIP-616. SIMD pode ser usado para acelerar várias formas de criptografia, incluindo funções hash, STARKs de 32 bits e criptografia baseada em reticulados. A combinação de EVM-MAX e SIMD faz dessas duas extensões orientadas à performance um par natural.

Um design aproximado de EIP combinado começaria com o EIP-6690 e, então:

• Permitir (i) qualquer número ímpar ou (ii) qualquer potência de 2 até 2768 como módulo
• Para cada opcode EVM-MAX (adição, subtração, multiplicação), adicionar uma versão que não usa mais 3 números imediatos x, y, z, mas sim 7: x_start, x_skip, y_start, y_skip, z_start, z_skip, count. Em Python, esses opcodes funcionariam assim:

for i in range(count):

mem[z_start + z_skip * count] = op(

mem[x_start + x_skip * count],

mem[y_start + y_skip * count]

)

Na implementação real, isso seria processado em paralelo.

• Pode-se adicionar XOR, AND, OR, NOT e SHIFT (incluindo circular e não circular), pelo menos para módulos potência de 2. Também adicionar ISZERO (que empurra a saída para a pilha principal da EVM), o que é suficientemente poderoso para implementar criptografia de curva elíptica, criptografia de campo pequeno (como Poseidon, Circle STARKs), funções hash tradicionais (como SHA256, KECCAK, BLAKE) e criptografia baseada em reticulados. Outras atualizações da EVM também podem ser implementadas, mas até agora receberam menos atenção.

Links de pesquisas existentes

• EOF: 
• EVM-MAX: 
• SIMD: 

Trabalho restante e trade-offs

Atualmente, o EOF está planejado para ser incluído no próximo hard fork. Embora sempre haja a possibilidade de ser removido no último minuto — funções já foram removidas temporariamente em hard forks anteriores — isso seria um grande desafio. Remover o EOF significaria que futuras atualizações da EVM teriam que ser feitas sem o EOF, o que é possível, mas provavelmente mais difícil.

O principal trade-off da EVM é a complexidade do L1 versus a complexidade da infraestrutura. O EOF é uma grande quantidade de código a ser adicionada à implementação da EVM, e a verificação estática do código também é relativamente complexa. No entanto, em troca, podemos simplificar linguagens de alto nível, simplificar a implementação da EVM e obter outros benefícios. Pode-se argumentar que um roteiro que priorize melhorias contínuas no L1 do Ethereum deve incluir e se basear no EOF.

Um trabalho importante a ser feito é implementar recursos semelhantes ao EVM-MAX + SIMD e fazer benchmarks do consumo de gás para várias operações criptográficas.

Como interage com outras partes do roteiro?

O L1 ajustando sua EVM facilita que o L2 também faça ajustes correspondentes; se ambos não se ajustarem em sincronia, pode haver incompatibilidades e impactos negativos. Além disso, EVM-MAX e SIMD podem reduzir o custo de gás de muitos sistemas de prova, tornando o L2 mais eficiente. Também facilita substituir mais pré-compilados por código EVM capaz de executar as mesmas tarefas, sem grande impacto na eficiência.

Abstração de contas

Que problema resolve?

Atualmente, as transações só podem ser validadas de uma maneira: assinatura ECDSA. Inicialmente, a abstração de contas visava ir além disso, permitindo que a lógica de validação da conta fosse qualquer código EVM. Isso pode habilitar uma série de aplicações:

• Migração para criptografia resistente a quânticos
• Rotação de chaves antigas (amplamente considerada uma prática recomendada de segurança)
• Carteiras multiassinatura e carteiras de recuperação social
• Usar uma chave para operações de baixo valor e outra (ou um conjunto de chaves) para operações de alto valor

Permitir que protocolos de privacidade funcionem sem relays, reduzindo significativamente sua complexidade e eliminando um ponto central de dependência

Desde que a abstração de contas foi proposta em 2015, seus objetivos também se expandiram para incluir muitos "objetivos de conveniência", como permitir que uma conta sem ETH, mas com algum ERC20, pague o gás com ERC20. Veja abaixo um gráfico resumindo esses objetivos:

MPC (Computação Multi-Party) é uma tecnologia existente há 40 anos, usada para dividir uma chave em várias partes e armazená-las em vários dispositivos, usando técnicas criptográficas para gerar assinaturas sem combinar diretamente essas partes da chave.

EIP-7702 é uma proposta planejada para ser introduzida no próximo hard fork. O EIP-7702 é resultado do reconhecimento crescente da necessidade de fornecer conveniência de abstração de contas para todos os usuários (incluindo usuários EOA), visando melhorar a experiência de todos no curto prazo e evitar a divisão em dois ecossistemas.

Esse trabalho começou com o EIP-3074 e, finalmente, resultou no EIP-7702. O EIP-7702 fornece as "funções de conveniência" da abstração de contas para todos os usuários, incluindo os EOAs de hoje (contas controladas por assinatura ECDSA).

Como pode ser visto no gráfico, embora alguns desafios (especialmente os de "conveniência") possam ser resolvidos por tecnologias progressivas como MPC ou EIP-7702, os principais objetivos de segurança que motivaram a proposta original de abstração de contas só podem ser alcançados voltando e resolvendo o problema original: permitir que código de contrato inteligente controle a validação de transações. Até agora, isso não foi realizado devido ao desafio de implementá-lo com segurança.

O que é e como funciona?

O núcleo da abstração de contas é simples: permitir que contratos inteligentes iniciem transações, não apenas EOAs. Toda a complexidade vem de implementar isso de uma forma amigável à manutenção de uma rede descentralizada e resistente a ataques de negação de serviço.

Um desafio típico é o problema de múltiplas invalidações:

Se 1000 contas tiverem funções de validação que dependem de um único valor S, e o valor atual de S faz com que as transações no mempool sejam válidas, então uma única transação que altera S pode invalidar todas as outras transações no mempool. Isso permite que um atacante envie transações lixo ao mempool a baixo custo, congestionando os recursos dos nós da rede.

Após anos de trabalho para expandir funcionalidades enquanto limita o risco de DoS, chegou-se à solução para implementar a "abstração de contas ideal": ERC-4337.

O ERC-4337 funciona dividindo o processamento das operações do usuário em duas fases: verificação e execução. Todas as verificações são processadas primeiro, seguidas de todas as execuções. No mempool, apenas operações de usuário cuja fase de verificação envolva apenas sua própria conta e não leia variáveis de ambiente são aceitas. Isso previne ataques de múltiplas invalidações. Além disso, limites rígidos de gás são impostos à etapa de verificação.

O ERC-4337 foi projetado como um padrão de protocolo adicional (ERC), pois, na época, os desenvolvedores do cliente Ethereum estavam focados no Merge e não tinham recursos para outras funcionalidades. Por isso, o ERC-4337 usa objetos chamados operações de usuário, em vez de transações regulares. No entanto, recentemente percebemos a necessidade de incorporar pelo menos parte disso ao protocolo.

Dois motivos principais são:

1. EntryPoint como contrato é inerentemente ineficiente: cada bundle tem uma sobrecarga fixa de cerca de 100.000 gás, além de milhares de gás extras por operação de usuário.
2. Necessidade de garantir propriedades do Ethereum: como as garantias de inclusão criadas pela inclusion list precisam ser transferidas para usuários de abstração de contas.

Além disso, o ERC-4337 expande dois recursos:

• Paymasters: permite que uma conta pague taxas em nome de outra, o que viola a regra de que a verificação só pode acessar a conta do remetente, então um tratamento especial é necessário para garantir a segurança do mecanismo.
• Aggregators: suporte à agregação de assinaturas, como agregação BLS ou baseada em SNARK. Isso é necessário para máxima eficiência de dados em Rollups.

Links de pesquisas existentes

• Palestra sobre a história da abstração de contas:
• ERC-4337:
• EIP-7702:
• Código BLSWallet (usando agregação):
• EIP-7562 (abstração de contas no protocolo):
• EIP-7701 (abstração de contas baseada em EOF no protocolo):

Trabalho restante e trade-offs

O principal ponto a ser resolvido atualmente é como incorporar totalmente a abstração de contas ao protocolo. O EIP de abstração de contas no protocolo mais popular recentemente é o EIP-7701, que implementa abstração de contas sobre o EOF. Uma conta pode ter uma parte separada de código para verificação; se a conta definir esse código, ele será executado na etapa de verificação das transações originadas dessa conta.

O interessante dessa abordagem é que ela mostra claramente duas perspectivas equivalentes de abstração de contas nativa:

1. Incorporar o EIP-4337 como parte do protocolo
2. Um novo tipo de EOA, onde o algoritmo de assinatura é a execução de código EVM

Se começarmos impondo limites estritos à complexidade do código executável durante a verificação — sem acesso a estado externo, e até mesmo limites de gás tão baixos que não permitam aplicações resistentes a quânticos ou de privacidade — então a segurança dessa abordagem é clara: apenas substitui a verificação ECDSA por execução de código EVM de tempo semelhante.

No entanto, com o tempo, precisaremos relaxar esses limites, pois permitir aplicações de privacidade sem relays e resistência a quânticos é muito importante. Para isso, precisamos encontrar maneiras mais flexíveis de mitigar riscos de DoS sem exigir que a etapa de verificação seja extremamente simples.

O principal trade-off parece ser "implementar rapidamente uma solução menos satisfatória" versus "esperar mais por uma solução ideal". O ideal pode ser uma abordagem híbrida: implementar rapidamente alguns casos de uso e deixar mais tempo para explorar outros. Outra abordagem é implementar versões mais ambiciosas de abstração de contas primeiro no L2. O desafio é que as equipes de L2 precisam confiar que a proposta será adotada para se comprometerem com a implementação, especialmente para garantir que o L1 e/ou outros L2 possam adotar soluções compatíveis no futuro.

Outro caso de uso a ser considerado explicitamente são as contas de armazenamento de chaves, que armazenam estado relacionado à conta no L1 ou em um L2 dedicado, mas podem ser usadas tanto no L1 quanto em qualquer L2 compatível. Fazer isso de forma eficiente pode exigir que o L2 suporte opcodes como L1SLOAD ou REMOTESTATICCALL, mas isso também requer que a implementação de abstração de contas no L2 suporte essas operações.

Como interage com outras partes do roteiro?

Inclusion lists precisam suportar transações de abstração de contas. Na prática, as necessidades de inclusion lists e de mempools descentralizados são muito semelhantes, embora as inclusion lists sejam um pouco mais flexíveis. Além disso, a implementação de abstração de contas deve ser coordenada entre L1 e L2 sempre que possível. Se no futuro a maioria dos usuários usar rollups de armazenamento de chaves, o design da abstração de contas deve partir desse princípio.

Melhorias no EIP-1559

Que problema resolve?

O EIP-1559 foi ativado no Ethereum em 2021, melhorando significativamente o tempo médio de inclusão de blocos.

Tempo de espera

No entanto, a implementação atual do EIP-1559 não é perfeita em vários aspectos:

1. A fórmula é um pouco falha: não visa 50% dos blocos, mas cerca de 50-53% dos blocos cheios, dependendo da variância (isso se relaciona à "desigualdade aritmética-geométrica" da matemática).
2. Não se ajusta rapidamente em situações extremas.

A fórmula usada para blobs (EIP-4844) foi projetada para resolver o primeiro problema e é mais simples no geral. No entanto, tanto o EIP-1559 quanto o EIP-4844 não tentam resolver o segundo problema. Assim, temos um estado intermediário confuso, com dois mecanismos diferentes, e há quem acredite que ambos precisarão ser aprimorados com o tempo.

Além disso, há outras fraquezas no modelo de precificação de recursos do Ethereum não relacionadas ao EIP-1559, mas que podem ser resolvidas ajustando o EIP-1559. Um dos principais problemas é a diferença entre o caso médio e o pior caso: os preços dos recursos no Ethereum precisam ser definidos para lidar com o pior caso (um bloco inteiro consumindo todo o gás em um recurso), mas o uso médio real é muito menor, levando à ineficiência.

O que é Gas multidimensional e como funciona?

A solução para esses problemas de ineficiência é o Gas multidimensional: definir preços e limites diferentes para diferentes recursos. Esse conceito é tecnicamente independente do EIP-1559, mas a existência do EIP-1559 facilita sua implementação. Sem o EIP-1559, empacotar de forma ótima um bloco com múltiplas restrições de recursos é um problema complexo de mochila multidimensional. Com o EIP-1559, a maioria dos blocos não atinge o limite em nenhum recurso, então um algoritmo simples de "aceitar qualquer transação que pague o suficiente" é suficiente.

Atualmente, já temos Gas multidimensional para execução e blobs de dados; em princípio, podemos expandir para mais dimensões: como calldata (dados de transação), leitura/gravação de estado e expansão do tamanho do estado.

O EIP-7706 introduz uma nova dimensão de gás, especificamente para calldata. Ao mesmo tempo, unifica os três tipos de gás em uma estrutura (no estilo EIP-4844), simplificando o mecanismo de Gas multidimensional e resolvendo o defeito matemático do EIP-1559. O EIP-7623 é uma solução mais precisa para o problema de recursos do caso médio versus o pior caso, limitando mais estritamente o calldata máximo sem introduzir uma nova dimensão.

Uma direção de pesquisa adicional é resolver o problema da taxa de atualização, buscando um algoritmo de cálculo de taxa base mais rápido, mantendo os invariantes críticos introduzidos pelo EIP-4844 (ou seja, uso médio a longo prazo próximo ao valor alvo).

Links de pesquisas existentes

• EIP-1559 FAQ: 
• Análise empírica do EIP-1559: 
• Propostas de melhoria para ajustes rápidos: 
• Parte sobre o mecanismo de taxa base no FAQ do EIP-4844: 
• EIP-7706: 
• EIP-7623: 
• Gas multidimensional: 

Quais trabalhos restam e quais são os trade-offs?

Os principais trade-offs do Gas multidimensional são dois:

1. Aumento da complexidade do protocolo: adicionar Gas multidimensional torna o protocolo mais complexo.
2. Aumento da complexidade do algoritmo ótimo para preencher blocos: o algoritmo ótimo para preencher blocos até a capacidade também se torna mais complexo.

A complexidade do protocolo é relativamente pequena para calldata, mas para dimensões de gás internas à EVM (como leitura e gravação de armazenamento), a complexidade aumenta. O problema é que não apenas os usuários definem limites de gás, mas contratos também definem limites ao chamar outros contratos. Atualmente, eles só podem definir limites unidimensionais.

Uma solução simples é tornar o Gas multidimensional disponível apenas dentro do EOF, já que o EOF não permite que contratos definam limites de gás ao chamar outros contratos. Contratos não EOF pagariam todas as taxas de gás (por exemplo, se SLOAD consome 0,03% do limite de acesso a armazenamento do bloco, usuários não EOF também pagariam 0,03% do limite de execução de gás).

Mais pesquisas sobre Gas multidimensional ajudarão a entender esses trade-offs e encontrar o equilíbrio ideal.

Como interage com outras partes do roteiro?

Implementar com sucesso o Gas multidimensional pode reduzir drasticamente o uso de recursos em certos "piores casos", reduzindo a pressão por otimização de performance para suportar, por exemplo, árvores binárias baseadas em hash STARKed. Definir uma meta clara para o crescimento do tamanho do estado facilitará o planejamento e a estimativa de necessidades para desenvolvedores de clientes no futuro.

Como mencionado, a existência do EOF facilita a implementação de versões mais extremas de Gas multidimensional, devido à sua característica de gás não observável.

Funções de atraso verificáveis (VDFs)

Que problema resolve?

Atualmente, o Ethereum usa aleatoriedade baseada em RANDAO para selecionar proponentes. A aleatoriedade do RANDAO funciona exigindo que cada proponente revele um segredo previamente comprometido, misturando cada segredo revelado na aleatoriedade.

Cada proponente, portanto, tem "1 bit de poder de manipulação": pode alterar a aleatoriedade não aparecendo (com custo). Isso é razoável para seleção de proponentes, pois abrir mão de uma chance para ganhar duas novas é raro. Mas para aplicações on-chain que precisam de aleatoriedade, não é o ideal. O ideal seria encontrar uma fonte de aleatoriedade mais robusta.

O que é VDF e como funciona?

Funções de atraso verificáveis são funções que só podem ser computadas sequencialmente, sem aceleração por paralelismo. Um exemplo simples é hash repetido: for i in range(10**9): x = hash(x). O resultado, provado com SNARK, pode ser usado como valor aleatório.

A ideia é escolher a entrada com base em informações disponíveis no tempo T, mas o resultado não é conhecido em T: só estará disponível após alguém executar todo o cálculo. Como qualquer um pode executar o cálculo, não há como ocultar o resultado, nem manipulá-lo.

O principal risco das VDFs é otimização inesperada: alguém descobre como executar a função mais rápido do que o esperado, manipulando as informações reveladas em T.

Otimização inesperada pode ocorrer de duas formas:

1. Aceleração por hardware: alguém fabrica um ASIC que executa o loop mais rápido que o hardware existente.
2. Paralelização inesperada: alguém encontra uma maneira de paralelizar a função para executá-la mais rápido, mesmo que isso exija 100 vezes mais recursos.

O desafio de criar uma VDF bem-sucedida é evitar ambos os problemas, mantendo a eficiência prática (por exemplo, provar hashes em tempo real com SNARKs exige hardware pesado). A aceleração por hardware geralmente é resolvida por um participante de interesse público criando e distribuindo um ASIC VDF quase ótimo.

Links de pesquisas existentes

• Site de pesquisa VDF: 
• Pensamentos sobre ataques a VDFs no Ethereum, 2018: 
• Ataques ao VDF MinRoot proposto: 

Trabalho restante e trade-offs

Atualmente, não existe uma construção de VDF que atenda totalmente aos requisitos dos pesquisadores do Ethereum em todos os aspectos. Mais trabalho é necessário para encontrar tal função. Se encontrada, o principal trade-off será se deve ser incluída: funcionalidade versus complexidade do protocolo e riscos de segurança.

Se considerarmos a VDF segura, mas ela não for, dependendo da implementação, a segurança regride para a suposição do RANDAO (1 bit de manipulação por atacante) ou um pouco pior. Assim, mesmo que a VDF falhe, não quebra o protocolo, mas prejudica aplicações ou recursos que dependem fortemente dela.

Como interage com outras partes do roteiro?

A VDF é um componente relativamente autocontido no protocolo Ethereum. Além de aumentar a segurança da seleção de proponentes, tem aplicações em (i) aplicações on-chain que dependem de aleatoriedade e (ii) mempools criptográficos, embora a criação de mempools criptográficos baseados em VDF ainda dependa de descobertas criptográficas adicionais.

Um ponto a lembrar é que, devido à incerteza do hardware, haverá uma "folga" entre a geração da saída da VDF e a necessidade dela. Isso significa que a informação estará disponível alguns blocos antes. Isso pode ser um custo aceitável, mas deve ser considerado em projetos de finalização de slot único ou seleção de comitê.

Ofuscação e assinaturas de uso único: o futuro distante da criptografia

Que problema resolve?

Um dos artigos mais famosos de Nick Szabo é o de 1997 sobre o "Protocolo de Deus". Nele, ele aponta que muitos aplicativos multi-parte dependem de um "terceiro confiável" para gerenciar interações. Para ele, o papel da criptografia é criar um terceiro confiável simulado, que faz o mesmo trabalho sem exigir confiança em nenhum participante específico.

Até agora, só conseguimos realizar parcialmente esse ideal. Se tudo o que precisamos é de uma máquina virtual transparente, cujos dados e cálculos não podem ser desligados, censurados ou adulterados, e a privacidade não é o objetivo, então blockchains podem alcançar isso, embora com escalabilidade limitada.

Se a privacidade for o objetivo, até recentemente só podíamos desenvolver protocolos específicos para aplicações específicas: assinaturas digitais para autenticação básica, assinaturas de anel e de anel vinculáveis para anonimato bruto, criptografia baseada em identidade para criptografia conveniente sob suposições de emissores confiáveis, e assinaturas cegas para dinheiro eletrônico Chaumiano, etc. Esse método exige muito trabalho para cada nova aplicação.

Na década de 2010, vimos pela primeira vez um método diferente e mais poderoso, baseado em criptografia programável. Em vez de criar um novo protocolo para cada aplicação, podemos usar novos protocolos poderosos — especificamente ZK-SNARKs — para adicionar garantias criptográficas a qualquer programa.

ZK-SNARKs permitem que usuários provem qualquer declaração sobre dados que possuem, e a prova (i) é fácil de verificar e (ii) não revela nada além da declaração em si. Isso é um grande avanço em privacidade e escalabilidade, comparável ao impacto dos transformers em IA. Milhares de anos-homem de trabalho específico de aplicação foram de repente substituídos por uma solução geral capaz de lidar com problemas inesperadamente amplos.

No entanto, ZK-SNARKs são apenas o primeiro de três primitivos universais extremamente poderosos. Esses protocolos são tão poderosos que me lembram um conjunto de cartas muito fortes em Yu-Gi-Oh! — um jogo de cartas e programa de TV que eu jogava quando criança: as Cartas dos Deuses Egípcios.

As Cartas dos Deuses Egípcios são três cartas extremamente poderosas, cuja criação, segundo a lenda, poderia ser fatal, e seu poder era tal que eram proibidas em duelos. Da mesma forma, na criptografia, temos esse trio de protocolos dos Deuses Egípcios:

O que são ZK-SNARKs e como funcionam?

ZK-SNARKs são um dos três protocolos que já temos, com alto grau de maturidade. Nos últimos cinco anos, o aumento da velocidade dos provadores e da facilidade de desenvolvimento tornou os ZK-SNARKs a base das estratégias de escalabilidade e privacidade do Ethereum. Mas ZK-SNARKs têm uma limitação importante: você precisa conhecer os dados para prová-los. O estado em cada aplicação ZK-SNARK deve ter um "proprietário" único, que deve estar presente para aprovar leituras ou gravações desse estado.

O segundo protocolo, sem essa limitação, é a Criptografia Homomórfica Total (FHE), que permite realizar qualquer cálculo sobre dados criptografados sem vê-los. Isso permite cálculos sobre dados do usuário em benefício do usuário, mantendo dados e algoritmos privados.

Também permite expandir sistemas de votação como MACI para obter quase perfeitas garantias de segurança e privacidade. Por muito tempo, FHE foi considerado ineficiente demais para uso prático, mas agora está se tornando eficiente o suficiente para aplicações reais.

Cursive é um aplicativo que usa computação de duas partes e FHE para descoberta de interesses comuns com privacidade.

No entanto, FHE também tem limitações: qualquer tecnologia baseada em FHE ainda requer que alguém detenha a chave de descriptografia. Pode ser uma configuração distribuída M-de-N, ou até usar TEEs para uma segunda camada de proteção, mas ainda é uma limitação.

O terceiro protocolo, mais poderoso que a combinação dos dois anteriores, é a Ofuscação Indistinguível (indistinguishability obfuscation). Embora ainda distante da maturidade, desde 2020 temos protocolos teoricamente válidos baseados em hipóteses de segurança padrão, e recentemente começaram as tentativas de implementação.

A ofuscação indistinguível permite criar um "programa criptografado" que executa qualquer cálculo, ocultando todos os detalhes internos do programa. Por exemplo, você pode colocar uma chave privada em um programa ofuscado que só permite assinar números primos, e distribuir esse programa para outros. Eles podem assinar qualquer primo, mas não extrair a chave. E vai além: combinada com hash, pode implementar qualquer outro primitivo criptográfico e mais.

A única coisa que a ofuscação indistinguível não pode fazer é impedir que o próprio programa seja copiado. Para isso, há uma tecnologia ainda mais forte no horizonte, embora dependa de todos terem computadores quânticos: assinaturas quânticas de uso único (quantum one-shot signatures).

Combinando ofuscação e assinaturas de uso único, podemos construir terceiros quase perfeitamente confiáveis. O único objetivo que ainda exige blockchains para garantir é a resistência à censura. Essas tecnologias podem tornar o próprio Ethereum mais seguro e permitir aplicações ainda mais poderosas.

Para entender melhor como esses primitivos adicionam capacidades, vejamos a votação como exemplo. Votação é interessante porque exige muitos atributos de segurança complexos, incluindo verificabilidade e privacidade muito fortes. Protocolos de votação seguros existem há décadas, mas podemos nos desafiar a projetar para qualquer protocolo de votação: votação quadrática, financiamento quadrático com restrições de pares, financiamento quadrático em clusters, etc. Em outras palavras, queremos que a etapa de "contagem" seja um programa arbitrário.

Primeiro, suponha que publicamos os resultados da votação na blockchain. Isso nos dá verificabilidade pública (qualquer um pode verificar o resultado final, incluindo regras de contagem e elegibilidade) e resistência à censura (ninguém pode impedir votos). Mas não temos privacidade.

Depois, adicionamos ZK-SNARKs, e agora temos privacidade: cada voto é anônimo, garantindo que apenas eleitores autorizados possam votar e cada um só possa votar uma vez.

Em seguida, introduzimos o mecanismo MACI, onde os votos são criptografados para a chave de descriptografia de um servidor central. O servidor realiza a contagem, elimina votos duplicados e publica uma prova ZK-SNARK do resultado. Isso mantém as garantias anteriores (mesmo se o servidor trapacear!), mas se o servidor for honesto, adiciona uma garantia anti-coerção: usuários não podem provar como votaram, mesmo que queiram. Isso porque, embora possam provar que votaram, não podem provar que não votaram para anular esse voto. Isso previne suborno e outros ataques.

Executamos a contagem em FHE, depois fazemos uma descriptografia de limiar N/2-de-N. Isso eleva a garantia anti-coerção para N/2-de-N, em vez de 1-de-1.

Ofuscamos o programa de contagem e projetamos para só liberar o resultado mediante autorização, que pode ser prova de consenso da blockchain, algum tipo de prova de trabalho, ou ambos. Isso torna a garantia anti-coerção quase perfeita: no caso do consenso da blockchain, seria necessário 51% dos validadores conspirando; no caso de prova de trabalho, mesmo todos conspirando, recalcular para diferentes subconjuntos de eleitores seria extremamente caro. Podemos até fazer o programa ajustar levemente o resultado final para dificultar ainda mais a extração do comportamento de um eleitor.

Adicionamos assinaturas de uso único, um primitivo dependente de computação quântica, permitindo que assinaturas sejam usadas apenas uma vez para um tipo específico de informação. Isso torna a garantia anti-coerção realmente perfeita.

A ofuscação indistinguível também suporta outras aplicações poderosas. Por exemplo:

1. DAOs, leilões on-chain e outros aplicativos com estado secreto arbitrário interno.
2. Configuração confiável verdadeiramente universal: alguém pode criar um programa ofuscado com uma chave e executar qualquer programa, fornecendo a saída, com hash(key, program) como entrada. Dado tal programa, qualquer um pode inserir o programa 3 em si mesmo, combinando a chave prévia do programa e sua própria chave, estendendo a configuração. Isso pode ser usado para gerar configuração confiável 1-de-N para qualquer protocolo.
3. Verificação de ZK-SNARKs com apenas uma assinatura: basta configurar um ambiente confiável para criar um programa ofuscado que só assina mensagens com a chave se o ZK-SNARK for válido.
4. Mempool criptografado: transações criptografadas se tornam triviais, só podendo ser descriptografadas após um evento on-chain futuro. Isso pode incluir até a execução bem-sucedida de uma VDF.

Com assinaturas de uso único, podemos proteger blockchains contra ataques de reversão de finalização de 51%, embora ataques de censura ainda sejam possíveis. Primitivos semelhantes tornam possível o dinheiro quântico, resolvendo o problema do double-spending sem blockchain, embora aplicações mais complexas ainda exijam uma chain.

Se esses primitivos se tornarem eficientes o suficiente, a maioria das aplicações do mundo poderá ser descentralizada. O principal gargalo será verificar a correção das implementações.

Aqui estão alguns links de pesquisas existentes:

• Protocolo de ofuscação indistinguível (2021): 
• Como a ofuscação pode ajudar o Ethereum: 
• Primeira construção conhecida de assinatura de uso único: 
• Tentativa de implementação de ofuscação (1): 
• Tentativa de implementação de ofuscação (2): 

Que trabalhos restam e quais são os trade-offs?

Há muito trabalho a ser feito; a ofuscação indistinguível ainda é muito imatura, e as construções candidatas são incrivelmente lentas (ou piores), tornando-as impraticáveis para uso real. A ofuscação indistinguível é "teoricamente" em tempo polinomial, mas na prática pode levar mais tempo que a vida do universo. Protocolos recentes melhoraram o tempo de execução, mas ainda é muito alto para uso comum: um implementador estimou um ano de execução.

Computadores quânticos nem existem ainda: todas as construções que você vê online são protótipos que não fazem mais que 4 bits, ou nem são computadores quânticos de verdade, embora possam ter partes quânticas, mas não executam algoritmos significativos como Shor ou Grover. Há sinais de que "verdadeiros" computadores quânticos estão próximos. No entanto, mesmo que surjam em breve, pode levar décadas até que pessoas comuns possam usá-los em laptops ou celulares, antes que instituições poderosas possam quebrar criptografia de curva elíptica.

Para ofuscação indistinguível, um trade-off chave é a hipótese de segurança: há designs mais agressivos usando hipóteses especiais, geralmente com tempos de execução mais realistas, mas essas hipóteses às vezes acabam sendo quebradas. Com o tempo, podemos entender melhor reticulados e propor hipóteses mais robustas. Mas esse caminho é mais arriscado. A abordagem conservadora é usar protocolos cuja segurança pode ser reduzida a hipóteses "padrão", mas isso pode significar esperar mais por protocolos rápidos o suficiente.

Como interage com outras partes do roteiro?

Criptografia extremamente poderosa pode mudar completamente o jogo, por exemplo:

1. Se obtivermos verificação de ZK-SNARKs tão simples quanto assinaturas, talvez não precisemos mais de protocolos de agregação; podemos verificar diretamente on-chain.
2. Assinaturas de uso único podem significar protocolos de proof-of-stake mais seguros.
3. Muitos protocolos de privacidade complexos podem ser substituídos por uma EVM de privacidade.
4. Mempools criptografados se tornam mais fáceis de implementar.

No início, os benefícios aparecerão na camada de aplicação, pois o L1 do Ethereum precisa ser conservador em hipóteses de segurança. No entanto, só o uso na camada de aplicação já pode ser disruptivo, como foi com os ZK-SNARKs.