Um agradecimento especial a Micah Zoltu, Toni Wahrstätter, Justin Traglia e pcaversaccio pela discussão

A crítica mais comum ao aumentar o limite de gás L1, além das preocupações com a segurança da rede, é que torna mais difícil executar um nó completo.

Especialmente no contexto de um roteiro focado em desagregaçãoo nó completo, abordar isso requer uma compreensão do que os nós completos são para.

Historicamente, o pensamento tem sido que os nós completos são para validar a cadeia; vejaaquipara a minha própria exposição do que poderia acontecer se os usuários regulares não puderem verificar. Se este for o único problema, então a escalabilidade L1 é desbloqueada pelos ZK-EVMs: o único limite é manter os custos de construção de blocos e de prova baixos o suficiente para que ambos possam permanecer1-de-nresistente à censura e um mercado competitivo.

No entanto, na realidade, esta não é realmente a única preocupação. A outra grande preocupação é: é valioso ter um nó completo para que você possa ter um servidor RPC local que você possa usar para ler a cadeia de forma confiável, resistente à censura e amigável à privacidade. Este documento discutirá ajustes no roteiro atual de escalonamento L1 para que isso aconteça.

Por que não parar com a falta de confiança e privacidade via ZK-EVM + PIR?

O o roteiro de privacidade que publiquei no mês passadoconcentra-se em TEEs +ORAMcomo uma correção de curto prazo maisPIRcomo uma solução de longo prazo. Isso, juntamente com a verificação Helios e ZK-EVM, permitiria que qualquer usuário se conectasse a RPCs externos e tivesse total confiança de que (i) a cadeia que estão recebendo está correta e (ii) sua privacidade de dados está protegida. Portanto, vale a pena fazer a pergunta: por que não parar por aqui? Esses tipos de soluções criptográficas avançadas não tornam os nós auto-hospedados um relicário desatualizado?

Aqui posso dar algumas respostas:

• Soluções criptográficas totalmente sem confiança (ou seja, PIR de 1 servidor) serão caras. Atualmente, o overhead é impraticavelmente alto e, mesmo após muitas melhorias de eficiência, é provável que continue caro.
• Privacidade de metadados. Os dados do endereço IP que faz solicitações em determinados momentos e o padrão das solicitações são suficientes para revelar muitas informações sobre os usuários.
• Vulnerabilidade à censura: uma estrutura de mercado dominada por alguns provedores de RPC é aquela que enfrentará forte pressão para desplataformar ou censurar usuários. Muitos provedores de RPC já excluem países inteiros.

Por esses motivos, há valor em continuar a garantir maior facilidade na execução de um nó pessoal.

Prioridades de curto prazo

• Priorize totalmente a implementação do EIP-4444, até o estado final em que cada nó armazena dados por apenas ~36 dias. Isso reduz significativamente os requisitos de espaço em disco, que são o principal problema que impede mais pessoas de executar nós. Após isso, os requisitos de espaço em disco para um nó serão (i) tamanho do estado, (ii) ramos de estado Merkle, (iii) 36 dias de histórico.
• Construa uma solução de armazenamento de histórico distribuído, em que cada nó pode armazenar uma pequena porcentagem de dados históricos mais antigos que o corte. Use codificação de apagamento para maximizar a robustez. Isso garante a propriedade de que 'um blockchain é para sempre' sem depender de provedores centralizados ou sobrecarregar os operadores de nó
• Ajustar o preço do gás para tornar o armazenamento mais caro e a execução menos cara. Uma prioridade especialmente alta é aumentar o custo do gás para a criação de novo estado: (i) SSTORE para novos slots de armazenamento, (ii) criação de código de contrato, (iii) envio de ETH para contas que ainda não têm saldo ou nonce.

Prioridade a médio prazo: verificação sem estado

Uma vez que ativamos a verificação sem estado, torna-se possível executar um nó capaz de RPC (ou seja, um que armazena o estado) sem armazenar ramos de Merkle de estado. Isso diminui ainda mais os requisitos de armazenamento em cerca de 2x.

Um novo tipo de nó: nós parcialmente sem estado

Esta é a nova ideia e será fundamental para permitir a operação de nó pessoal mesmo em um contexto onde o limite de gás L1 cresce de 10 a 100 vezes.

Adicionamos um tipo de nó que verifica os blocos de forma stateless e verifica toda a cadeia (seja por meio de validação stateless ou ZK-EVM) e mantém atualizada uma parte do estado. O nó é capaz de responder a solicitações RPC desde que os dados necessários estejam dentro desse subconjunto do estado; outras solicitações falharão (ou terão que recorrer a uma solução criptográfica hospedada externamente; se fazer isso deve ser escolha do usuário).

partial_statelessness.drawio776×341 19.9 KB

A parte exata do estado a ser mantida dependerá de uma configuração escolhida pelo usuário. Alguns exemplos podem ser:

• Todos os estados, exceto os contratos que são conhecidos por serem spam
• Estado associado a todas as EOAs e SCWs e a todos os tokens e aplicativos ERC20 e ERC721 comumente usados
• Estado associado a todas as EOAs e SCWs que foram acessadas nos últimos dois anos, alguns tokens ERC20 comumente utilizados, além de um conjunto limitado e selecionado de aplicativos de troca, defi e privacidade

A configuração poderia ser gerenciada por um contrato on-chain: um usuário executaria seu nó com —save_state_by_config 0x12345…67890, e o endereço especificaria em algum idioma uma lista de endereços, slots de armazenamento ou regiões filtradas de estado que o nó salvaria e manteria atualizado. Observe que não há necessidade de o usuário salvar ramos de Merkle; eles só precisam salvar os valores brutos.

Esse tipo de nó forneceria os benefícios de acesso local direto ao estado com o qual um usuário precisa se preocupar, bem como a máxima privacidade total de acesso a esse estado.

Isenção de responsabilidade:

1. Este artigo foi reimpresso de [ethresear]. Todos os direitos autorais pertencem ao autor original [vbuterin]. Se houver objeções a este reenvio, entre em contato com oGate Learnequipe e eles vão lidar com isso prontamente.
2. Isenção de responsabilidade: As opiniões expressas neste artigo são exclusivamente do autor e não constituem qualquer conselho de investimento.
3. As traduções do artigo para outros idiomas são feitas pela equipe Gate Learn. A menos que mencionado, copiar, distribuir ou plagiar os artigos traduzidos é proibido.