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.
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.
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.
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.