Executar um nó completo permite que você tenha um servidor RPC local, permitindo ler dados na cadeia de forma não confiável, resistente à censura e que protege a privacidade.
Escrito por: Vitalik, fundador do Ethereum
Compilado por: Gold Finance xiaozhou
A crítica mais comum ao aumento do limite de gás 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", é necessário entender primeiro o significado da existência de nós completos para resolver esse problema.
A visão tradicional considera que os nós completos são utilizados para validar dados na cadeia. Se este fosse o único problema, então o ZK-EVM poderia desbloquear a escalabilidade L1: a única limitação é manter os custos de construção de blocos e de prova suficientemente baixos, de forma a garantir que ambos mantenham a resistência à censura de 1 de n, e ao mesmo tempo formem um mercado competitivo.
Mas na realidade, essa não é a única consideração. Outro fator importante é: executar um nó completo permite que você tenha um servidor RPC local, assim você pode ler dados na cadeia de maneira sem confiança, resistente à censura e que protege a privacidade. Este artigo discutirá como ajustar o roteiro de expansão atual do L1 para alcançar esse objetivo.
1、Por que não se satisfazer com a descentralização e privacidade implementadas 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?
Em relação a isso, tenho algumas respostas:
Soluções criptográficas completamente sem confiança (como PIR de servidor único) são caras. Os custos atuais são irrealisticamente altos, mesmo após várias otimizações de eficiência ainda podem manter um preço elevado.
Questões de privacidade dos metadados. O tempo de solicitação do endereço IP, padrões de solicitação e outros metadados podem expor uma quantidade significativa de informações dos usuários.
Revisão de vulnerabilidades: A estrutura de mercado dominada por poucos fornecedores de RPC enfrentará uma forte pressão de bloqueio ou censura por parte dos usuários. Muitos fornecedores de RPC começaram a bloquear completamente certos países.
Portanto, continuar a garantir a conveniência de operação dos nós pessoais ainda é valioso.
2、Prioridades de curto prazo
Priorizar a implementação completa do EIP-4444, permitindo que cada nó armazene apenas cerca de 36 dias de dados. Isso reduzirá significativamente a necessidade de espaço em disco - o principal obstáculo que impede as pessoas de operar nós. A partir daí, a necessidade de armazenamento do nó incluirá 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 modo que cada nó armazene uma pequena quantidade de dados históricos expirados. Maximizar a fiabilidade através da tecnologia de códigos de correção de erros. Isso pode garantir a característica de "armazenamento permanente da cadeia", sem depender de fornecedores centralizados ou sobrecarregar os operadores de nós.
Ajustar a estratégia de preços de Gas, aumentar os custos de armazenamento e reduzir os custos de execução. Focar em aumentar os custos de Gas para as seguintes operações: (i) executar SSTORE para um novo nó de armazenamento (storage slot), (ii) criar código de contrato, (iii) transferir ETH para contas com saldo zero / nonce zero.
3, Objetivo a médio prazo: verificação sem estado
Após a implementação da verificação sem estado, a execução de nós que suportam RPC (ou seja, nós que armazenam estado) não precisará salvar a ramificação de Merkle do estado. Isso pode reduzir ainda mais a necessidade de armazenamento em cerca de 50%.
4, Novos nós: alguns nós sem estado
Esta inovação será a chave para manter a operação de nós pessoais mesmo após o aumento do limite de gás L1 em 10-100 vezes.
Adicionamos um novo tipo de nó: um nó que valida blocos de forma sem estado, verificando toda a cadeia através da validação sem estado ou da validação ZK-EVM, mas mantendo apenas uma parte 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; outras solicitações falharão (ou precisarão reverter para uma solução criptográfica hospedada externamente - se deve reverter deve ser decidido pelo usuário).
A manutenção de quais estados específicos depende das configurações do usuário, por exemplo:
Excluir todos os estados exceto os contratos de lixo conhecidos.
Estado relacionado a todas as contas EOA, SCW e aos tokens e aplicações ERC20/ERC721 mais utilizados.
Estado de 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 um nó, utilizam o parâmetro "--save_state_by_config 0x12345...67890", que irá definir uma lista de endereços que o nó deve salvar e atualizar em tempo real em uma linguagem específica, bem como os slots de armazenamento ou regras de filtragem de estado. Note que os usuários não precisam salvar a ramificação de Merkle, apenas o valor original.
Este tipo de nó oferece tanto a vantagem de acesso direto local a estados críticos, como garante total privacidade de acesso.
Ver original
O conteúdo é apenas para referência, não uma solicitação ou oferta. Nenhum aconselhamento fiscal, de investimento ou jurídico é fornecido. Consulte a isenção de responsabilidade para obter mais informações sobre riscos.
Vitalik: Um plano de otimização de roteiro de escalabilidade focado em nós locais
Escrito por: Vitalik, fundador do Ethereum
Compilado por: Gold Finance xiaozhou
A crítica mais comum ao aumento do limite de gás 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", é necessário entender primeiro o significado da existência de nós completos para resolver esse problema.
A visão tradicional considera que os nós completos são utilizados para validar dados na cadeia. Se este fosse o único problema, então o ZK-EVM poderia desbloquear a escalabilidade L1: a única limitação é manter os custos de construção de blocos e de prova suficientemente baixos, de forma a garantir que ambos mantenham a resistência à censura de 1 de n, e ao mesmo tempo formem um mercado competitivo.
Mas na realidade, essa não é a única consideração. Outro fator importante é: executar um nó completo permite que você tenha um servidor RPC local, assim você pode ler dados na cadeia de maneira sem confiança, resistente à censura e que protege a privacidade. Este artigo discutirá como ajustar o roteiro de expansão atual do L1 para alcançar esse objetivo.
1、Por que não se satisfazer com a descentralização e privacidade implementadas 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?
Em relação a isso, tenho algumas respostas:
Portanto, continuar a garantir a conveniência de operação dos nós pessoais ainda é valioso.
2、Prioridades de curto prazo
Priorizar a implementação completa do EIP-4444, permitindo que cada nó armazene apenas cerca de 36 dias de dados. Isso reduzirá significativamente a necessidade de espaço em disco - o principal obstáculo que impede as pessoas de operar nós. A partir daí, a necessidade de armazenamento do nó incluirá 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 modo que cada nó armazene uma pequena quantidade de dados históricos expirados. Maximizar a fiabilidade através da tecnologia de códigos de correção de erros. Isso pode garantir a característica de "armazenamento permanente da cadeia", sem depender de fornecedores centralizados ou sobrecarregar os operadores de nós.
Ajustar a estratégia de preços de Gas, aumentar os custos de armazenamento e reduzir os custos de execução. Focar em aumentar os custos de Gas para as seguintes operações: (i) executar SSTORE para um novo nó de armazenamento (storage slot), (ii) criar código de contrato, (iii) transferir ETH para contas com saldo zero / nonce zero.
3, Objetivo a médio prazo: verificação sem estado
Após a implementação da verificação sem estado, a execução de nós que suportam RPC (ou seja, nós que armazenam estado) não precisará salvar a ramificação de Merkle do estado. Isso pode reduzir ainda mais a necessidade de armazenamento em cerca de 50%.
4, Novos nós: alguns nós sem estado
Esta inovação será a chave para manter a operação de nós pessoais mesmo após o aumento do limite de gás L1 em 10-100 vezes.
Adicionamos um novo tipo de nó: um nó que valida blocos de forma sem estado, verificando toda a cadeia através da validação sem estado ou da validação ZK-EVM, mas mantendo apenas uma parte 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; outras solicitações falharão (ou precisarão reverter para uma solução criptográfica hospedada externamente - se deve reverter deve ser decidido pelo usuário).
A manutenção de quais estados específicos depende das configurações do usuário, por exemplo:
A configuração pode ser gerida através de contratos na cadeia: quando os usuários executam um nó, utilizam o parâmetro "--save_state_by_config 0x12345...67890", que irá definir uma lista de endereços que o nó deve salvar e atualizar em tempo real em uma linguagem específica, bem como os slots de armazenamento ou regras de filtragem de estado. Note que os usuários não precisam salvar a ramificação de Merkle, apenas o valor original.
Este tipo de nó oferece tanto a vantagem de acesso direto local a estados críticos, como garante total privacidade de acesso.