A defesa de Vitalik Buterin para transferir boa parte do trabalho criptográfico para fora da Ethereum parte de uma diferença importante: computar não é o mesmo que transportar dados. Uma operação pré-compilada pode baratear a verificação de uma assinatura ou prova, mas a rede ainda precisa receber os dados necessários para conferi-la. A EIP-8288 propõe outro caminho: manter grandes cargas criptográficas fora dos blocos sempre que possível e reunir as verificações em provas STARK recursivas. Por enquanto, a proposta segue marcada como Draft (rascunho).
4
16
Por que não basta criar mais operações pré-compiladas?
As chamadas precompiles são operações embutidas no protocolo que podem tornar certas verificações criptográficas mais baratas. Mas elas não eliminam o custo de transportar as assinaturas, provas ou outros dados que precisam ser verificados. Buterin argumenta que a largura de banda para dados — e não apenas o gasto de gas com a verificação — limita a quantidade de material criptográfico que a Ethereum consegue processar. Na estimativa dele, o teto prático de vazão de dados ficaria em torno de 8 MB por segundo, mesmo com PeerDAS e blocos contendo dados em blobs. É uma estimativa de Buterin, não um limite formal de calldata.
4
12
Há também uma questão de flexibilidade. Dar suporte a cada esquema criptográfico por meio de uma operação pré-compilada específica pode aumentar a complexidade do protocolo e exigir mudanças nas implementações dos clientes. A EIP-8288 busca, em vez disso, oferecer um caminho comum para verificar diferentes esquemas.
7
16
Os exemplos do rascunho ajudam a ilustrar o problema: ele menciona assinaturas baseadas em hash com cerca de 2 a 3 kB e custos diretos de verificação de 150 mil a 200 mil gas. São estimativas para um exemplo da proposta, não valores universais para toda assinatura ou implementação.
10
Como a EIP-8288 funcionaria
A EIP oficial lista Vitalik Buterin e Thomas Coratger como autores e descreve a proposta como uma extensão às transações em frames da EIP-8141. O desenho tem três partes principais:
16
- As transações declaram dependências compactas. Cada dependência identifica um esquema, um hash dos dados e um hash da chave de verificação. A proposta codifica cada conjunto em 96 bytes.
16
13
- Os dados criptográficos completos circulam durante a propagação. Assinaturas ou provas maiores são fornecidas junto com as transações enquanto elas trafegam pela rede, em vez de serem incluídas nos blocos em seu formato original completo. Participantes do mempool podem combinar o trabalho de verificação.
15
16
- As verificações são agregadas. O desenho prevê o uso de provas STARK recursivas para reunir várias verificações. A ideia é incluir uma prova agregada no bloco, em vez de cada carga criptográfica subjacente. Isso busca reduzir a quantidade de dados nos blocos; não aumenta o limite de largura de banda da rede.
6
15
16
Os usuários também poderiam fazer computações criptográficas mais pesadas em seus próprios dispositivos e fornecer provas STARK dessas operações. O objetivo é permitir que a Ethereum dê suporte a uma variedade maior de esquemas sem precisar criar uma operação pré-compilada nativa para cada um.
3
6
O que pode mudar — e o que não muda
Se funcionar como previsto, o uso de dependências compactas e verificações agregadas pode reduzir a quantidade de dados originais de assinaturas e provas que precisa ser incluída nos blocos. O benefício não é simplesmente “criptografia mais rápida”: parte do trabalho passaria para usuários e participantes do mempool, enquanto a quantidade de dados que a Ethereum precisa incluir on-chain seria limitada.
1
13
16
Isso não significa eliminar os custos da criptografia. Usuários e participantes da rede ainda precisariam produzir, transmitir e verificar os dados e as provas relevantes. As fontes disponíveis não demonstram que a EIP-8288 garantirá uma redução específica no gasto de gas ou resolverá os desafios mais amplos de escalabilidade da Ethereum.
O que ainda está em aberto
Segurança das provas e das funções hash. O rascunho aponta a solidez dos circuitos de verificação e das funções hash usadas para as dependências como premissas de segurança. Uma atualização posterior também vincula o hash das dependências do bloco ao circuito de agregação. São salvaguardas importantes para avaliar, mas não comprovam que o sistema tenha sido totalmente verificado ou que sua segurança já esteja demonstrada em produção.
32
Risco de negação de serviço no mempool. A agregação acrescenta trabalho e processamento de dados nessa etapa da rede. A exposição a ataques de negação de serviço é identificada como uma área de risco, mas o material disponível não demonstra que todas as proteções estejam completas ou sejam suficientes.
25
Parâmetros do rascunho não são regras da rede principal. Uma revisão oficial estabelece limites de 16 dependências de assinatura e uma dependência STARK por transação. Esses são parâmetros do rascunho, não regras já implementadas na rede principal da Ethereum.
32
A segurança de assinaturas baseadas em reticulados segue em debate. Reportagens dizem que Buterin deixou aberta a possibilidade de operações pré-compiladas para criptografia baseada em reticulados, em usos como contas e carteiras, caso sua segurança seja demonstrada. Uma preocupação relatada sobre possíveis ataques assistidos por IA é uma questão a investigar — não uma evidência de que assinaturas desse tipo tenham sido quebradas.
17
24
A EIP oficial continua marcada como Draft, e as reportagens descrevem trabalho de simulação e testes, não uma implantação aprovada na rede principal. As fontes disponíveis não confirmam uma decisão definitiva de adoção nem uma data de implementação.
15
16