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.
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:
Por estas razões, há valor em continuar a garantir uma maior facilidade na execução de um nó pessoal.
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.
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:
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.
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.
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:
Por estas razões, há valor em continuar a garantir uma maior facilidade na execução de um nó pessoal.
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.
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:
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.