Autor: Vitalik, fundador da Ethereum; Tradução: 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", resolver esse problema requer entender primeiro 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 na cadeia. 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 de 1 de n e formar 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, permitindo ler dados na cadeia de forma não confiável, resistente à censura e protegendo a privacidade. Este artigo discutirá como ajustar o atual roteiro de escalabilidade 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 verificação Helios e ZK-EVM, os usuários podem estar completamente confiantes de que os dados da cadeia obtidos pelo (i) estão corretos ao se conectar ao RPC externo, (ii) a privacidade dos 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 considerações a fazer sobre isso:
--Soluções criptográficas completamente sem confiança (como PIR de servidor único) são muito caras. O custo atual é irrealista, mesmo após várias otimizações de eficiência, ainda pode manter um preço elevado.
--Questões de privacidade de metadados. O horário do pedido do endereço IP, o padrão de pedidos 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 provedores de RPC já começaram a bloquear completamente certos países.
Portanto, continuar a garantir a conveniência do funcionamento dos nós pessoais ainda tem valor.
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á significativamente a necessidade de espaço em disco - o principal obstáculo atual que impede as pessoas de executar nós. Após isso, a necessidade de armazenamento dos nós incluirá apenas: (i) dados de estado, (ii) ramificações Merkle de estado, (iii) dados históricos de 36 dias.
Construir uma solução de armazenamento histórico distribuído, onde cada nó armazena uma pequena quantidade de dados históricos expirados. Maximizar a fiabilidade através da tecnologia de codificação de correção. Assim, pode-se garantir a característica de "armazenamento permanente da blockchain" sem depender de fornecedores centralizados ou sobrecarregar os operadores dos 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 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/número nonce zero.
3, Objetivo de médio prazo: validaçã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 manter as ramificações de Merkle de estado. Isso pode reduzir ainda mais 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 de nós individuais, 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 da validação sem estado ou validação ZK-EVM, mas mantendo apenas 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 voltar a uma solução criptográfica hospedada externamente - se voltar deverá ser uma escolha do usuário).
A manutenção de quais estados específicos depende da configuração do usuário, por exemplo:
--Excluir todos os estados, exceto 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 comumente usados + estado de aplicações selecionadas de swap/DeFi/privacidade.
A configuração pode ser gerida através de contratos na blockchain: quando os utilizadores executam o nó, utilizam o parâmetro "--save_state_by_config 0x12345...67890", que define uma lista de endereços que o nó deve guardar e atualizar em tempo real, bem como slots de armazenamento (storage slot) ou regras de filtragem de estado, em uma linguagem específica. Note que os utilizadores não precisam guardar 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 serve apenas de referência e não constitui uma solicitação ou oferta. Não é prestado qualquer aconselhamento em matéria de investimento, fiscal ou jurídica. Consulte a Declaração de exoneração de responsabilidade para obter mais informações sobre os riscos.
Vitalik: um plano de otimização da rota de escalabilidade focado em nós locais
Autor: Vitalik, fundador da Ethereum; Tradução: 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", resolver esse problema requer entender primeiro 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 na cadeia. 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 de 1 de n e formar 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, permitindo ler dados na cadeia de forma não confiável, resistente à censura e protegendo a privacidade. Este artigo discutirá como ajustar o atual roteiro de escalabilidade 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 verificação Helios e ZK-EVM, os usuários podem estar completamente confiantes de que os dados da cadeia obtidos pelo (i) estão corretos ao se conectar ao RPC externo, (ii) a privacidade dos 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 considerações a fazer sobre isso:
--Soluções criptográficas completamente sem confiança (como PIR de servidor único) são muito caras. O custo atual é irrealista, mesmo após várias otimizações de eficiência, ainda pode manter um preço elevado.
--Questões de privacidade de metadados. O horário do pedido do endereço IP, o padrão de pedidos 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 provedores de RPC já começaram a bloquear completamente certos países.
Portanto, continuar a garantir a conveniência do funcionamento dos nós pessoais ainda tem valor.
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á significativamente a necessidade de espaço em disco - o principal obstáculo atual que impede as pessoas de executar nós. Após isso, a necessidade de armazenamento dos nós incluirá apenas: (i) dados de estado, (ii) ramificações Merkle de estado, (iii) dados históricos de 36 dias.
Construir uma solução de armazenamento histórico distribuído, onde cada nó armazena uma pequena quantidade de dados históricos expirados. Maximizar a fiabilidade através da tecnologia de codificação de correção. Assim, pode-se garantir a característica de "armazenamento permanente da blockchain" sem depender de fornecedores centralizados ou sobrecarregar os operadores dos 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 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/número nonce zero.
3, Objetivo de médio prazo: validaçã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 manter as ramificações de Merkle de estado. Isso pode reduzir ainda mais 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 de nós individuais, 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 da validação sem estado ou validação ZK-EVM, mas mantendo apenas 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 voltar a uma solução criptográfica hospedada externamente - se voltar deverá ser uma escolha do usuário).
A manutenção de quais estados específicos depende da configuração do usuário, por exemplo:
--Excluir todos os estados, exceto 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 comumente usados + estado de aplicações selecionadas de swap/DeFi/privacidade.
A configuração pode ser gerida através de contratos na blockchain: quando os utilizadores executam o nó, utilizam o parâmetro "--save_state_by_config 0x12345...67890", que define uma lista de endereços que o nó deve guardar e atualizar em tempo real, bem como slots de armazenamento (storage slot) ou regras de filtragem de estado, em uma linguagem específica. Note que os utilizadores não precisam guardar 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.