Vitalik: um plano de otimização da roadmap de escalabilidade focado em nós locais

Escrito por: Vitalik, fundador do Ethereum

Compilado por: Jinse Caijing xiaozhou

A crítica mais comum ao aumento do limite de Gas L1, além das preocupações com a segurança da rede, é que isso tornaria mais difícil a execução de nós completos. Especialmente no contexto de um roteiro centrado na "desvinculação de nós completos", para resolver esse problema, é necessário primeiro entender o significado da existência de nós completos.

A visão tradicional considera que os nós completos são usados para validar dados on-chain. Se esse for o único problema, então o ZK-EVM pode desbloquear a escalabilidade do L1: a única limitação é manter os custos de construção de blocos e de prova suficientemente baixos, de modo que ambos possam manter a resistência à censura 1 de n e formar um mercado competitivo.

Mas na realidade, esta não é a única consideração. Outro fator importante é: operar um nó completo permite que você tenha um servidor RPC local, permitindo que você leia dados na blockchain de uma maneira que não requer confiança, é resistente à censura e protege a privacidade. Este artigo discutirá como ajustar o atual roteiro de escalabilidade do L1 para alcançar este objetivo.

1. Por que não se contentar com a descentralização e privacidade alcançadas pelo ZK-EVM+PIR?

O roteiro de privacidade que lancei no mês passado defende a adoção de TEEs+ORAM no curto prazo e a mudança para a tecnologia PIR no longo prazo. Combinado com a validação Helios e ZK-EVM, os usuários podem se conectar a RPCs externos com total confiança de que o (i) está recebendo os dados de cadeia corretos e (ii) privacidade de dados está protegida. Isto levanta a questão: por que não parar por aí? Esses esquemas avançados de criptografia tornam os nós auto-hospedados obsoletos?

Tenho algumas respostas a isso:

Soluções criptográficas totalmente sem confiança (como PIR de servidor único) são caras. Os custos atuais são irrealisticamente altos e, mesmo após várias otimizações de eficiência, ainda podem manter um preço elevado.

Questões de privacidade de metadados. O tempo de solicitação do endereço IP, o padrão de solicitações e outros metadados podem expor uma grande quantidade de informações do usuário.

Revisão de vulnerabilidades: A estrutura de mercado dominada por poucos fornecedores de RPC enfrentará forte pressão de bloqueio ou censura por parte dos usuários. Muitos fornecedores de RPC já começaram a bloquear completamente certos países.

Assim, continua a ser valioso garantir a conveniência de funcionamento dos nós pessoais.

2. Prioridades de curto prazo

Priorizar a implementação completa do EIP-4444, alcançando assim que cada nó armazene apenas cerca de 36 dias de dados. Isso reduzirá drasticamente a necessidade de espaço em disco - o principal obstáculo que impede as pessoas de operarem nós atualmente. A partir daí, as necessidades de armazenamento dos nós incluirão apenas: (i) dados de estado, (ii) ramificações Merkle de estado, (iii)36 dias de dados históricos.

Construir uma solução de armazenamento histórico distribuído, de forma que cada nó armazene uma pequena quantidade de dados históricos expirados. Maximizar a confiabilidade através da tecnologia de códigos de correção. Isso garante a característica de "permanência do armazenamento em blockchain" sem depender de fornecedores centralizados ou sobrecarregar os operadores de nó.

Ajustar a estratégia de preços do Gas, aumentar os custos de armazenamento e reduzir os custos de execução. Aumentar especialmente os custos de Gas das seguintes operações: (i) executar SSTORE para um novo slot de armazenamento (storage slot), (ii) criar código de contrato, (iii) transferir ETH para contas com saldo zero / nonce zero.

3. Objetivo de médio prazo: verificação sem estado

Após a implementação da verificação sem estado, os nós que suportam RPC (ou seja, nós que armazenam estado) não precisarão mais manter os ramos de Merkle do estado. Isso pode reduzir a necessidade de armazenamento em cerca de 50%.

4, Novos nós: alguns nós sem estado

Esta ideia inovadora será a chave para manter a operação dos nós pessoais, mesmo após o aumento do limite de gás L1 em 10 a 100 vezes.

Adicionamos um novo tipo de nó: valida blocos de forma sem estado, verificando toda a cadeia através de validação sem estado ou ZK-EVM, mas mantendo apenas um subconjunto dos dados de estado. Desde que os dados necessários para a solicitação RPC estejam dentro desse subconjunto de estado, o nó poderá responder; outros pedidos falharão (ou precisarão recuar para uma solução criptográfica hospedada externamente - se deve recuar deve ser decidido pelo usuário).

A manutenção de quais estados específicos depende da configuração do usuário, por exemplo:

Excluir todos os estados, exceto os contratos lixo conhecidos.

Estado relacionado a todas as contas EOA, SCW e tokens e aplicações ERC20/ERC721 comuns.

Estado das contas EOA/SCW ativas nos últimos dois anos + Estado de alguns tokens ERC20 comuns + Estado de aplicações selecionadas de swap/DeFi/privacidade.

A configuração pode ser gerida através de contratos na cadeia: quando os usuários executam nós, usam o parâmetro "--save_state_by_config 0x12345...67890", que define uma lista de endereços que o nó deve salvar e atualizar em tempo real, juntamente com slots de armazenamento ou regras de filtragem de estado, em uma linguagem específica. Note que os usuários não precisam salvar a ramificação de Merkle, apenas o valor original.

Este tipo de nó pode proporcionar acesso direto local a estados chave, ao mesmo tempo que garante total privacidade de acesso.