Um delta favorável ao nó local para o roteiro de escalonamento

Avançado5/21/2025, 5:52:14 AM
Vitalik Buterin propôs modificar a roadmap de escalabilidade do Ethereum, defendendo o conceito de 'clientes sem estado' para lidar simultaneamente com os desafios de desempenho, privacidade e verificabilidade. O artigo fornece uma análise aprofundada dos caminhos de evolução futura para otimização de armazenamento de dados, mecanismos de preservação de privacidade e paradigmas de acesso on-chain.

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 roadmap focado emdesagregaçã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; ver aquipara 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 bloco e de prova suficientemente baixos 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 ao atual roadmap de escalonamento L1 que tornam isso possível.

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

A o roadmap de privacidade que publiquei no mês passadoconcentra-se em TEEs + ORAMcomo uma solução temporária adicionalPIRcomo solução a longo prazo. Isso, juntamente com a verificação de Helios e ZK-EVM, permitiria a qualquer usuário se conectar a RPCs externos e ter total confiança de que (i) a cadeia que estão obtendo está correta e (ii) sua privacidade de dados está protegida. Portanto, vale a pena perguntar: 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 confiáveis (ou seja, PIR de 1 servidor) serão caras. Atualmente, o custo operacional é impraticavelmente alto e, mesmo após muitas melhorias de eficiência, provavelmente continuará sendo caro.
  • Privacidade de metadados. Os dados do endereço IP que faz pedidos em que momentos e o padrão de pedidos, são suficientes para revelar muitas informações sobre os utilizadores.
  • Vulnerabilidade à censura: uma estrutura de mercado dominada por alguns fornecedores de RPC é aquela que enfrentará forte pressão para desativar ou censurar usuários. Muitos fornecedores de RPC já excluem países inteiros.

Por estas razões, há valor em continuar a garantir uma maior facilidade na execução de um nó pessoal.

Prioridades a curto prazo

  • Reorganizar a implementação completa do EIP-4444, até ao estado final em que cada nó armazena dados apenas durante ~36 dias. Isto reduz consideravelmente os requisitos de espaço em disco, que são o principal problema que impede mais pessoas de executarem nós. Após isto, os requisitos de espaço em disco para um nó serão (i) tamanho do estado, (ii) ramos do Merkle do estado, (iii) 36 dias de histórico.
  • Construa uma solução de armazenamento de histórico distribuída, pela qual cada nó pode armazenar uma pequena percentagem de dados históricos mais antigos do que o limite. Use codificação de apagamento para maximizar a robustez. Isso garante a propriedade de que 'uma blockchain é para sempre' sem depender de fornecedores centralizados ou colocar pesados encargos nos operadores de nós
  • 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 criar novo estado: (i) SSTORE para novos slots de armazenamento, (ii) criação de código de contrato, (iii) enviar 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ós pessoais mesmo num contexto em que o limite de gás L1 aumenta de 10 a 100 vezes.

Adicionamos um tipo de nó que verifica blocos sem estado e verifica toda a cadeia (seja através de validação sem estado ou ZK-EVM) e mantém atualizada uma parte do estado. O nó é capaz de responder a pedidos de RPC, desde que os dados necessários estejam dentro desse subconjunto do estado; outros pedidos falharão (ou terão que recorrer a uma solução criptográfica hospedada externamente; se deve ou não 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 todos os EOAs e SCWs e a todos os tokens e aplicações ERC20 e ERC721 comumente utilizados
  • Estado associado a todas as EOAs e SCWs que foram acedidas nos últimos dois anos, alguns tokens ERC20 comumente utilizados, além de um conjunto limitado e selecionado de aplicações de troca, defi e privacidade

A configuração poderia ser gerida por um contrato onchain: 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 do estado que o nó salvaria e manteria atualizado. Note que não há necessidade de o usuário salvar ramos de Merkle; eles só precisam salvar os valores brutos.

Este tipo de nó proporcionaria os benefícios do 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.

Aviso Legal:

  1. Este artigo foi reproduzido a partir de [ethresear]. Todos os direitos de autor pertencem ao autor original [vbuterin]. Se houver objeções a esta reimpressão, por favor contacte o Gate Learnequipa e eles vão lidar com isso prontamente.
  2. Aviso 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 do Gate Learn. Salvo indicação em contrário, é proibido copiar, distribuir ou plagiar os artigos traduzidos.

Um delta favorável ao nó local para o roteiro de escalonamento

Avançado5/21/2025, 5:52:14 AM
Vitalik Buterin propôs modificar a roadmap de escalabilidade do Ethereum, defendendo o conceito de 'clientes sem estado' para lidar simultaneamente com os desafios de desempenho, privacidade e verificabilidade. O artigo fornece uma análise aprofundada dos caminhos de evolução futura para otimização de armazenamento de dados, mecanismos de preservação de privacidade e paradigmas de acesso on-chain.

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 roadmap focado emdesagregaçã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; ver aquipara 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 bloco e de prova suficientemente baixos 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 ao atual roadmap de escalonamento L1 que tornam isso possível.

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

A o roadmap de privacidade que publiquei no mês passadoconcentra-se em TEEs + ORAMcomo uma solução temporária adicionalPIRcomo solução a longo prazo. Isso, juntamente com a verificação de Helios e ZK-EVM, permitiria a qualquer usuário se conectar a RPCs externos e ter total confiança de que (i) a cadeia que estão obtendo está correta e (ii) sua privacidade de dados está protegida. Portanto, vale a pena perguntar: 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 confiáveis (ou seja, PIR de 1 servidor) serão caras. Atualmente, o custo operacional é impraticavelmente alto e, mesmo após muitas melhorias de eficiência, provavelmente continuará sendo caro.
  • Privacidade de metadados. Os dados do endereço IP que faz pedidos em que momentos e o padrão de pedidos, são suficientes para revelar muitas informações sobre os utilizadores.
  • Vulnerabilidade à censura: uma estrutura de mercado dominada por alguns fornecedores de RPC é aquela que enfrentará forte pressão para desativar ou censurar usuários. Muitos fornecedores de RPC já excluem países inteiros.

Por estas razões, há valor em continuar a garantir uma maior facilidade na execução de um nó pessoal.

Prioridades a curto prazo

  • Reorganizar a implementação completa do EIP-4444, até ao estado final em que cada nó armazena dados apenas durante ~36 dias. Isto reduz consideravelmente os requisitos de espaço em disco, que são o principal problema que impede mais pessoas de executarem nós. Após isto, os requisitos de espaço em disco para um nó serão (i) tamanho do estado, (ii) ramos do Merkle do estado, (iii) 36 dias de histórico.
  • Construa uma solução de armazenamento de histórico distribuída, pela qual cada nó pode armazenar uma pequena percentagem de dados históricos mais antigos do que o limite. Use codificação de apagamento para maximizar a robustez. Isso garante a propriedade de que 'uma blockchain é para sempre' sem depender de fornecedores centralizados ou colocar pesados encargos nos operadores de nós
  • 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 criar novo estado: (i) SSTORE para novos slots de armazenamento, (ii) criação de código de contrato, (iii) enviar 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ós pessoais mesmo num contexto em que o limite de gás L1 aumenta de 10 a 100 vezes.

Adicionamos um tipo de nó que verifica blocos sem estado e verifica toda a cadeia (seja através de validação sem estado ou ZK-EVM) e mantém atualizada uma parte do estado. O nó é capaz de responder a pedidos de RPC, desde que os dados necessários estejam dentro desse subconjunto do estado; outros pedidos falharão (ou terão que recorrer a uma solução criptográfica hospedada externamente; se deve ou não 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 todos os EOAs e SCWs e a todos os tokens e aplicações ERC20 e ERC721 comumente utilizados
  • Estado associado a todas as EOAs e SCWs que foram acedidas nos últimos dois anos, alguns tokens ERC20 comumente utilizados, além de um conjunto limitado e selecionado de aplicações de troca, defi e privacidade

A configuração poderia ser gerida por um contrato onchain: 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 do estado que o nó salvaria e manteria atualizado. Note que não há necessidade de o usuário salvar ramos de Merkle; eles só precisam salvar os valores brutos.

Este tipo de nó proporcionaria os benefícios do 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.

Aviso Legal:

  1. Este artigo foi reproduzido a partir de [ethresear]. Todos os direitos de autor pertencem ao autor original [vbuterin]. Se houver objeções a esta reimpressão, por favor contacte o Gate Learnequipa e eles vão lidar com isso prontamente.
  2. Aviso 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 do Gate Learn. Salvo indicação em contrário, é proibido copiar, distribuir ou plagiar os artigos traduzidos.
Comece agora
Inscreva-se e ganhe um cupom de
$100
!