Além das preocupações com a segurança da rede, a crítica mais comum ao aumento do limite de Gas L1 é que isso tornará mais difícil operar nós completos. Especialmente no contexto do roteiro que se concentra na divisão de nós completos, para resolver essa questão, é necessário entender o papel dos nós completos.
Historicamente, as pessoas sempre acreditaram que os nós completos eram usados para validar dados na cadeia; consulte aqui para entender a minha própria explicação sobre o que pode acontecer se os usuários comuns não puderem validar. Se este for o único problema, então o ZK-EVM pode desbloquear a expansão L1: a única limitação é manter os custos de construção de blocos e de prova em um nível suficientemente baixo para que ambos possam manter a resistência à censura 1-of-n e a competitividade de mercado.
Mas na verdade, este não é o único problema. Outro problema principal é que ter um nó completo é extremamente valioso, pois assim você pode ter um servidor RPC local para ler a cadeia de uma maneira sem confiança, resistente à censura e amigável à privacidade. Este documento discutirá os ajustes feitos na atual rota de expansão L1 para alcançar esse objetivo.
Por que continuar a implementar confiança zero e privacidade através de ZK-EVM + PIR?
No mapa de privacidade que publiquei no mês passado, coloquei TEE + ORAM como uma solução temporária, juntamente com PIR como uma solução a longo prazo. Assim, juntamente com a validação do Helios e do ZK-EVM, qualquer usuário pode se conectar ao RPC externo e ter plena certeza de que: (i) a cadeia que eles obtêm está correta; (ii) a privacidade dos seus dados está protegida. Portanto, não podemos deixar de nos perguntar: por que parar por aqui? Essas soluções criptográficas avançadas não tornariam os nós autogeridos uma relíquia obsoleta?
Aqui, posso dar algumas respostas:
Soluções criptográficas completamente sem confiança (ou seja, 1-server PIR) serão extremamente caras. Os custos atuais são irrealistas e, mesmo após várias melhorias de eficiência, provavelmente ainda serão caros.
Privacidade de metadados. Qualquer endereço IP que faça uma solicitação em um determinado momento, bem como o padrão da solicitação, são dados que por si só podem revelar uma quantidade significativa de informações sobre o usuário.
Revisão de vulnerabilidades: a estrutura de mercado dominada por poucos fornecedores de RPC enfrentará uma forte pressão para cancelar plataformas ou censurar usuários. Muitos fornecedores de RPC já excluíram países inteiros.
Por estas razões, há valor em continuar a garantir que é mais conveniente executar um nó pessoal.
Prioridades de curto prazo
Aumentar a prioridade da promoção do EIP-4444 até que cada nó armazene apenas o estado final de dados de cerca de 36 dias. Isso reduzirá significativamente a necessidade de espaço em disco, que é o principal obstáculo para mais pessoas executarem nós. Após isso, a necessidade de espaço em disco dos nós será: (i) tamanho do estado; (ii) ramo Merkle do estado; (iii) 36 dias de histórico.
Construir soluções de armazenamento histórico distribuído, onde cada nó pode armazenar uma pequena parte de dados históricos anteriores à data limite. Utilizar códigos de correção para maximizar a robustez. Isso pode garantir que a característica de "a blockchain é eterna" seja mantida, sem depender de provedores centralizados ou sobrecarregar os operadores de nós.
Ajustar a precificação do Gas para tornar os custos de armazenamento mais altos e os custos de execução mais baixos. A prioridade especial é aumentar o custo de Gas para criar um novo estado: (i) SSTORE de 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.
Prioridades de médio prazo: verificação sem estado
Uma vez ativada a validação sem estado, será possível executar nós com funcionalidade RPC (ou seja, nós que armazenam estado) sem armazenar o ramo Merkle do estado. Isso reduzirá ainda mais a necessidade de armazenamento em cerca de 2 vezes.
Um novo tipo de nó: Nós sem estado parcial
Esta é uma nova ideia, e é a chave para permitir a operação de nós individuais sob uma limitação de gás L1 que cresce entre 10 a 100 vezes.
Adicionámos um tipo de nó que pode validar blocos sem estado, validar toda a cadeia (através de validação sem estado ou ZK-EVM), e manter a parte do estado atualizada. Desde que os dados necessários estejam dentro desse subconjunto de estado, o nó pode responder a solicitações RPC; outras solicitações falharão (ou devem ser revertidas para uma solução criptográfica hospedada externamente; cabe ao utilizador decidir se deve fazer isso).
A parte específica do estado a ser mantido depende da configuração selecionada pelo usuário. Eis alguns exemplos:
Todos os estados exceto os conhecidos como contratos lixo
Estado relacionado a todos os EOA e SCW, bem como a todos os tokens e aplicações ERC 20 e ERC 721 comuns.
Estado relacionado a todos os EOA e SCW visitados nos últimos dois anos, assim como alguns tokens ERC 20 comuns, além de um conjunto limitado de aplicações de troca, defi e privacidade.
A configuração pode ser gerida através de contratos on-chain: os usuários podem executar seu nó usando --save_state_by_config 0x 12345...67890 e esse endereço irá especificar em alguma linguagem a lista de endereços, slots de armazenamento ou outras áreas filtradas onde o nó deve salvar e manter o estado atualizado. Note que os usuários não precisam salvar a ramificação Merkle; eles apenas precisam salvar o valor original.
Este tipo de nó permite que os utilizadores acedam diretamente, a partir da sua localização, ao estado que precisam de monitorizar, maximizando a proteção da privacidade ao aceder a esse estado.
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: nova solução para resolver o problema de escalabilidade do Ethereum L1
Este artigo é de: cofundador do Ethereum Vitalik
Compilação | Odaily Planet Daily (@OdailyChina)
Tradutor | Ethan（@ethanzhang_web3）
Além das preocupações com a segurança da rede, a crítica mais comum ao aumento do limite de Gas L1 é que isso tornará mais difícil operar nós completos. Especialmente no contexto do roteiro que se concentra na divisão de nós completos, para resolver essa questão, é necessário entender o papel dos nós completos.
Historicamente, as pessoas sempre acreditaram que os nós completos eram usados para validar dados na cadeia; consulte aqui para entender a minha própria explicação sobre o que pode acontecer se os usuários comuns não puderem validar. Se este for o único problema, então o ZK-EVM pode desbloquear a expansão L1: a única limitação é manter os custos de construção de blocos e de prova em um nível suficientemente baixo para que ambos possam manter a resistência à censura 1-of-n e a competitividade de mercado.
Mas na verdade, este não é o único problema. Outro problema principal é que ter um nó completo é extremamente valioso, pois assim você pode ter um servidor RPC local para ler a cadeia de uma maneira sem confiança, resistente à censura e amigável à privacidade. Este documento discutirá os ajustes feitos na atual rota de expansão L1 para alcançar esse objetivo.
Por que continuar a implementar confiança zero e privacidade através de ZK-EVM + PIR?
No mapa de privacidade que publiquei no mês passado, coloquei TEE + ORAM como uma solução temporária, juntamente com PIR como uma solução a longo prazo. Assim, juntamente com a validação do Helios e do ZK-EVM, qualquer usuário pode se conectar ao RPC externo e ter plena certeza de que: (i) a cadeia que eles obtêm está correta; (ii) a privacidade dos seus dados está protegida. Portanto, não podemos deixar de nos perguntar: por que parar por aqui? Essas soluções criptográficas avançadas não tornariam os nós autogeridos uma relíquia obsoleta?
Aqui, posso dar algumas respostas:
Por estas razões, há valor em continuar a garantir que é mais conveniente executar um nó pessoal.
Prioridades de curto prazo
Prioridades de médio prazo: verificação sem estado
Uma vez ativada a validação sem estado, será possível executar nós com funcionalidade RPC (ou seja, nós que armazenam estado) sem armazenar o ramo Merkle do estado. Isso reduzirá ainda mais a necessidade de armazenamento em cerca de 2 vezes.
Um novo tipo de nó: Nós sem estado parcial
Esta é uma nova ideia, e é a chave para permitir a operação de nós individuais sob uma limitação de gás L1 que cresce entre 10 a 100 vezes.
Adicionámos um tipo de nó que pode validar blocos sem estado, validar toda a cadeia (através de validação sem estado ou ZK-EVM), e manter a parte do estado atualizada. Desde que os dados necessários estejam dentro desse subconjunto de estado, o nó pode responder a solicitações RPC; outras solicitações falharão (ou devem ser revertidas para uma solução criptográfica hospedada externamente; cabe ao utilizador decidir se deve fazer isso).
A parte específica do estado a ser mantido depende da configuração selecionada pelo usuário. Eis alguns exemplos:
A configuração pode ser gerida através de contratos on-chain: os usuários podem executar seu nó usando --save_state_by_config 0x 12345...67890 e esse endereço irá especificar em alguma linguagem a lista de endereços, slots de armazenamento ou outras áreas filtradas onde o nó deve salvar e manter o estado atualizado. Note que os usuários não precisam salvar a ramificação Merkle; eles apenas precisam salvar o valor original.
Este tipo de nó permite que os utilizadores acedam diretamente, a partir da sua localização, ao estado que precisam de monitorizar, maximizando a proteção da privacidade ao aceder a esse estado.