Novo artigo de Vitalik: O futuro possível do Ethereum, The Surge

Autor do original: Vitalik Buterin

Original text compilation: Karen, Foresight News

Agradecimentos especiais a Justin Drake, Francesco, Hsiao-wei Wang, @antonttc e Georgios Konstantopoulos.

Inicialmente, havia duas estratégias de escalonamento no roteiro da ETH. Um deles (ver um artigo anterior de 2015) é a “fragmentação”: cada Nó só precisa verificar e armazenar uma pequena percentagem das transações, em vez de todas as transações na cadeia. Qualquer outra rede peer-to-peer (por exemplo, BitTorrent) funciona desta forma, então certamente podemos fazer o blockchain funcionar da mesma maneira. O outro é o protocolo Camada 2: essas redes estarão localizadas no topo da praça ETH, permitindo que elas se beneficiem plenamente de sua segurança, mantendo a maioria dos dados e computação fora da cadeia principal. O protocolo Camada 2 refere-se aos canais estaduais em 2015, Plasma em 2017 e depois Rollup em 2019. Os rollups são mais poderosos do que os canais de estado ou plasma, mas exigem muita largura de banda de dados. Felizmente, em 2019, o estudo Fragmentação tinha resolvido o problema da verificação da “disponibilidade de dados” em escala. Como resultado, os dois caminhos se fundiram e obtivemos um roteiro centrado no Rollup que ainda é a estratégia de escalonamento da ETHFANG hoje.

The Surge, 2023 Roadmap Edition

O roteiro centrado no Rollup propõe uma divisão de trabalho simples: o ETH Workshop L1 se concentra em ser uma camada base forte e descentralizadora, enquanto L2 assume a tarefa de ajudar o ecossistema a escalar. Este modelo é onipresente na sociedade: o sistema judicial (L1) não existe em busca de supervelocidade e eficiência, mas para proteger contratos e direitos de propriedade, e os empresários (L2) se baseiam nessa base sólida para levar a humanidade (literal ou figurativamente) a Marte.

Este ano, o roadmap centrado no Rollup alcançou marcos importantes: com o lançamento do EIP-4844 blobs, a largura de banda de dados da camada L1 do Ethereum aumentou significativamente, e vários Rollups da Máquina virtual Ethereum (EVM) entraram na fase inicial. Cada L2 existe como uma ‘Fragmentação’ com suas próprias regras e lógica internas, e a diversidade e pluralidade na implementação da Fragmentação agora é uma realidade. No entanto, como vemos, seguir este caminho também apresenta desafios únicos. Portanto, a nossa tarefa atual é concluir o roadmap centrado no Rollup e resolver esses problemas, ao mesmo tempo que mantemos a robustez e Descentralização distintas do Ethereum L1.

The Surge: Objetivo chave

1、O futuro do Ethereum pode atingir mais de 100.000 TPS através do L2;

2, manter a Descentralização e a robustez do L1;

3. Pelo menos alguns L2 herdam completamente as principais propriedades do Ethereum (Sem confiança, aberto, resistente à censura);

4, O Ethereum deve sentir-se como um ecossistema unificado, e não como 34 blockchains diferentes.

Conteúdo deste capítulo

• O paradoxo do triângulo de escalabilidade
• Further progress in data availability sampling
• Compressão de dados
• Plasma Generalizado
• Sistema de prova de L2 maduro
• Melhoria da interoperabilidade entre camadas L2
• Expandir a execução em L1

O paradoxo do triângulo da escalabilidade

O paradoxo triangular da escalabilidade é uma ideia proposta em 2017, que argumenta que existem contradições entre as três características da blockchain: Descentralização (mais especificamente, baixo custo para operar Nós), escalabilidade (lidar com um grande número de transações) e segurança (um atacante precisa comprometer uma grande parte dos Nós da rede para causar falha em uma transação única).

É importante notar que o paradoxo do triângulo não é um teorema e os posts que o introduzem não vêm com uma prova matemática. Ele realmente fornece um argumento matemático heurístico: se um Nó amigável à descentralização (como um notebook de consumo) pode verificar N transações por segundo e você tem uma cadeia que processa k*N transações por segundo, então (i) cada transação pode ser vista apenas por 1/k Nós, o que significa que um atacante só precisa destruir alguns nós para passar uma transação mal-intencionada, ou (ii) seus nós ficarão poderosos, mas sua cadeia não será descentralizada. O objetivo deste artigo nunca foi provar que quebrar o paradoxo do triângulo é impossível; em vez disso, pretende mostrar que quebrar o paradoxo do triângulo é difícil e requer, até certo ponto, sair do quadro de pensamento implícito no argumento.

Ao longo dos anos, algumas cadeias de alto desempenho têm afirmado resolver o paradoxo dos três generais sem alterar fundamentalmente a arquitetura, geralmente otimizando os Nós com técnicas de engenharia de software. Isso é sempre enganoso, já que executar Nós neste tipo de cadeia é muito mais difícil do que executar Nós na Ethereum. Este artigo discutirá por que isso acontece e por que o software do cliente L1 por si só não pode dimensionar a Ethereum.

No entanto, a combinação de amostragem de disponibilidade de dados com SNARKs realmente resolve o paradoxo triangular: permite que os clientes verifiquem que uma quantidade específica de dados está disponível e que uma quantidade específica de etapas de cálculo é executada corretamente, baixando apenas uma pequena quantidade de dados e executando uma quantidade mínima de cálculos. SNARKs são confiáveis. A amostragem de disponibilidade de dados possui um modelo sutil de confiança few-of-N, mas mantém as características fundamentais de uma cadeia não escalável, ou seja, mesmo um ataque de 51% não pode forçar que blocos ruins sejam aceitos pela rede.

Uma outra forma de resolver o dilema dos três problemas é a arquitetura Plasma, que utiliza tecnologia inteligente para incentivar os utilizadores de forma compatível a assumir a responsabilidade pela disponibilidade dos dados monitorizados. Entre 2017 e 2019, quando só tínhamos a prova de fraude como meio de expandir a capacidade de cálculo, a execução segura do Plasma era bastante limitada, mas com a disseminação dos SNARKs (argumentos de conhecimento zero concisos não interativos), a arquitetura Plasma tornou-se mais viável para cenários de utilização mais amplos do que antes.

Mais avanços na amostragem de disponibilidade de dados

Que problema estamos a resolver?

Em 13 de março de 2024, quando o Dencun for atualizado e lançado, cada slot da blockchain da camada Ethereum terá cerca de 3 blobs de aproximadamente 125 kB a cada 12 segundos, ou uma largura de banda disponível de cerca de 375 kB por slot. Supondo que os dados da transação sejam publicados na cadeia, então a transferência de ERC 20 é de cerca de 180 bytes, portanto, a TPS máxima do Rollup na camada Ethereum é: 375000 / 12 / 180 = 173.6 TPS

Se adicionarmos calldata do ETH (valor máximo teórico: 30 milhões de gás por slot / 16 gás por byte = 1.875.000 bytes por slot), isso se tornará 607 TPS. Com o PeerDAS, o número de blobs pode aumentar para 8-16, o que fornecerá 463-926 TPS para calldata.

Este é um grande avanço para o Ethereum L1, mas não é suficiente. Queremos mais escalabilidade. Nosso objetivo de médio prazo é ter 16 MB por slot, o que, combinado com melhorias na compressão de dados do Rollup, resultará em aproximadamente 58000 TPS.

O que é isto? Como funciona?

PeerDAS é uma implementação relativamente simples de “amostragem 1D”. Na blockchain Ethereum, cada blob é um polinômio de 4096 graus sobre um campo primo de 253 bits. Nós transmitimos as partes do polinômio, onde cada parte contém 16 valores de avaliação em 16 coordenadas adjacentes de um total de 8192 coordenadas. Dentro desses 8192 valores de avaliação, qualquer conjunto de 4096 (qualquer 64 de um possível conjunto de 128, de acordo com os parâmetros propostos atualmente) pode recuperar o blob.

O funcionamento do PeerDAS é fazer com que cada cliente ouça uma pequena sub-rede, onde a sub-rede i transmite qualquer amostra de blob i, e solicite blobs de outras sub-redes necessárias fazendo perguntas aos pares na rede P2P global (que ouvem sub-redes diferentes). A versão mais conservadora, SubnetDAS, usa apenas o mecanismo de sub-rede, sem perguntas adicionais à camada de pares. A proposta atual é que os Nós que participam do Prova de Staking usem o SubnetDAS, enquanto outros Nós (ou seja, clientes) usem o PeerDAS.

Em teoria, podemos expandir a escala de uma amostragem de ‘1 D’ para um tamanho bastante grande: se aumentarmos o número máximo de ‘blobs’ para 256 (almejando 128), poderemos atingir a meta de 16 MB, com 16 amostras por nó de disponibilidade de dados * 128 ‘blobs’ * 512 bytes por amostra por ‘blob’ = 1 MB de largura de banda de dados por slot. Isso está apenas dentro da nossa tolerância: é viável, mas significa que os clientes com largura de banda limitada não conseguirão amostrar. Podemos otimizar isso reduzindo o número de ‘blobs’ e aumentando o tamanho de cada ‘blob’, mas isso aumentará o custo de reconstrução.

Portanto, queremos ir mais longe e realizar amostragem 2D (2D sampling), este método não só realiza amostragem aleatória dentro do blob, mas também entre os blobs. Usando as propriedades lineares do compromisso KZG, expandimos um conjunto de blobs em um Bloco através de um novo conjunto de blobs virtuais, que codificam redundante a mesma informação.

Portanto, no final, queremos levar um passo adiante e realizar amostragem 2D, que não é apenas dentro do bloco, mas também entre os blocos de forma aleatória. As propriedades lineares garantidas por KZG são usadas para expandir o conjunto de blocos em um bloco, que contém uma nova lista de blocos virtuais com codificação redundante das mesmas informações.

Amostragem 2D. Fonte de dados: a16z crypto

É importante notar que a expansão de compromissos de cálculo não requer um blob, por isso esta solução é fundamentalmente amigável para a construção de blocos distribuídos. Os nós que realmente constroem o bloco só precisam ter o compromisso KZG do blob e podem confiar na amostragem de disponibilidade de dados (DAS) para verificar a disponibilidade dos blocos de dados. A amostragem de disponibilidade de dados unidimensional (1 D DAS) também é fundamentalmente amigável para a construção de blocos distribuídos.

Quais são as ligações com a pesquisa existente?

• Postagem original sobre a disponibilidade de dados (2018):
• Paper de acompanhamento:
• Sobre o artigo explicativo do DAS, paradigma:
• Disponibilidade 2D com compromisso KZG:
• PeerDAS on ethresear.ch: and paper:
• EIP-7594:
• SubnetDAS on ethresear.ch:
• Pequenas diferenças recuperáveis na amostragem 2D:

Ainda falta fazer mais alguma coisa? Quais são as outras considerações?

A seguir, será a implementação e lançamento do PeerDAS. Em seguida, aumentaremos continuamente o número de blobs no PeerDAS, ao mesmo tempo em que observamos atentamente a rede e melhoramos o software para garantir a segurança, este é um processo gradual. Ao mesmo tempo, esperamos mais trabalhos acadêmicos para padronizar a interação do PeerDAS e outras versões do DAS, bem como questões de segurança relacionadas à regra de escolha do garfo.

Num futuro mais distante, teremos de fazer mais trabalho para determinar a versão ideal do 2D DAS e provar a sua segurança. Também esperamos, no final, poder mudar do KZG para uma alternativa quântica segura e sem necessidade de configuração confiável. Até à data, não está claro quais são as soluções candidatas amigáveis para a construção de Blocos distribuídos. Mesmo com a utilização da técnica de “força bruta” dispendiosa, ou seja, a utilização de STARK recursivo para gerar prova de validade para reconstruir linhas e colunas, não é suficiente para satisfazer as exigências, uma vez que, tecnicamente, o tamanho de um STARK é O(log(n) * log(log(n)) hash (usando STIR), mas na prática, o STARK é quase tão grande quanto o bloco inteiro.

Minha visão do caminho de longo prazo é:

1. Implementar o ideal 2D DAS;
2. Manter o uso de 1 D DAS, sacrificando a eficiência da largura de banda de amostragem, aceitando um limite inferior de dados em prol da simplicidade e robustez.
3. (Hard pivot) Abandonar DA e adotar completamente o Plasma como nossa principal arquitetura Camada 2 a seguir.

Por favor, note que mesmo se decidirmos implementar diretamente a expansão na camada L1, essa opção ainda existe. Isso ocorre porque, se a camada L1 tiver que lidar com um grande número de TPS, o Bloco L1 se tornará muito grande, e os clientes vão querer uma forma eficiente de verificar sua correção, assim como nós teremos que usar tecnologias semelhantes ao Rollup (como ZK-EVM e DAS) na camada L1.

Como interagir com outras partes do roteiro?

Se a compressão de dados for implementada, a demanda por DAS 2D será reduzida ou pelo menos a latência será reduzida. Se o Plasma for amplamente utilizado, a demanda será reduzida ainda mais. O DAS também apresenta desafios para a construção de protocolos e mecanismos de bloco distribuídos: embora o DAS seja teoricamente amigável para a reconstrução distribuída, isso requer combinação com propostas de inclusão de pacotes e mecanismos de escolha de forquilha em torno dela na prática.

Compressão de dados

Qual problema estamos resolvendo?

Cada transação em Rollup ocupa muito espaço de dados na cadeia: transferências de ERC20 requerem cerca de 180 bytes. Mesmo com amostragem ideal de disponibilidade de dados, isso limita a escalabilidade do protocolo de camada. Com cada slot sendo de 16 MB, chegamos em:

16000000 / 12 / 180 = 7407 TPS

E se não só pudermos resolver o problema do numerador, mas também o problema do denominador, reduzindo o número de bytes ocupados por transações em cada Rollup na cadeia, o que aconteceria?

O que é isso e como funciona?

Na minha opinião, a melhor explicação é esta imagem de dois anos atrás:

Na compressão de zero bytes, substituímos cada sequência longa de zero bytes por dois bytes para indicar quantos zero bytes existem. Além disso, aproveitamos as propriedades específicas da transação:

Assinatura Agregada: Mudamos da assinatura ECDSA para a assinatura BLS, que permite que várias assinaturas sejam combinadas em uma única assinatura que prova a validade de todas as assinaturas originais. Na camada L1, o custo computacional da verificação é alto, mesmo após a agregação, então a assinatura BLS não é usada. Mas na camada L2, onde os dados são escassos, a assinatura BLS faz sentido. A característica de agregação do ERC-4337 fornece um caminho para implementar essa funcionalidade.

Usar ponteiros para substituir Endereço: Se tiver usado um determinado Endereço anteriormente, pode substituir o Endereço de 20 bytes por um ponteiro de 4 bytes que aponte para uma posição no histórico.

Serialização personalizada de valores de transação - a maioria dos valores de transação tem poucas casas decimais, por exemplo, 0,25 ETH é representado como 250.000.000.000.000.000 wei. As taxas máximas de base e prioridade também são semelhantes. Portanto, podemos usar um formato decimal personalizado para representar a maioria dos valores monetários.

Quais são as ligações com a pesquisa existente?

• Explore sequence.xyz:
• L2 Calldata otimiza contrato:
• Rollups baseados em prova de validade (também conhecidos como ZK rollups) diferem do estado de lançamento em vez de transações:
• BLS Carteira - através do ERC-4337 para realizar agregação BLS:

O que mais precisa ser feito, quais são as considerações?

O próximo passo principal é implementar efetivamente o plano acima. As principais considerações incluem:

1、Mudar para a assinatura BLS requer um grande esforço e é Gota compatível com chips de hardware confiáveis que podem aumentar a segurança. Pode ser substituído por invólucros ZK-SNARK de outros esquemas de assinatura.

2, a compressão dinâmica (por exemplo, substituir com pointers Endereço) tornará o código do cliente mais complexo.

3、Publicar as diferenças de estado na cadeia em vez de transações, pode comprometer a auditabilidade e impedir o funcionamento de muitos softwares (por exemplo, explorador de blockchain).

Como interagir com outras partes do mapa de rota?

Adotar o ERC-4337 e finalmente incorporar parte dele no L2 EVM pode acelerar significativamente a implantação da tecnologia de agregação. Colocar parte do conteúdo do ERC-4337 no L1 pode acelerar sua implantação no L2.

Plasma Generalizado

Que problema estamos a resolver?

Mesmo com a utilização de um blob de 16 MB e compressão de dados, 58.000 TPS pode não ser suficiente para atender completamente às necessidades de pagamento dos consumidores, redes sociais Descentralização ou outras áreas de alta largura de banda, especialmente quando começamos a considerar a privacidade, o que poderia aumentar a Gota escalabilidade em 3-8 vezes. Para cenários de alta volume e baixo valor, uma opção atual é usar o Validium, que armazena dados fora da cadeia e adota um modelo de segurança interessante: os operadores não podem roubar os fundos dos usuários, mas podem congelar temporária ou permanentemente os fundos de todos os usuários. Mas podemos fazer melhor.

O que é, como funciona?

Plasma é uma solução de escalonamento que envolve um operador publicando Blocos fora da cadeia e colocando as raízes de Merkle desses Blocos na cadeia (ao contrário do Rollup, que coloca os Blocos completos na cadeia). Para cada Bloco, o operador envia um ramo de Merkle para cada usuário para provar o que aconteceu com seus ativos ou que nada mudou. Os usuários podem recuperar seus ativos fornecendo o ramo de Merkle. É importante notar que este ramo não precisa ter a raiz no estado mais atual. Portanto, mesmo se houver um problema de disponibilidade de dados, os usuários ainda podem recuperar seus ativos acessando o estado mais recente disponível. Se um usuário submeter um ramo inválido (por exemplo, recuperar ativos que já foram enviados a outra pessoa, ou o operador criando ativos do nada), o vesting dos ativos pode ser determinado pelo mecanismo de desafio na cadeia.

Grafo de Plasma Cash. As transações que gastam a moeda i são colocadas na posição i da árvore. Neste exemplo, supondo que todas as árvores anteriores sejam válidas, sabemos que Eve possui o Token 1, David possui o Token 4 e George possui o Token 6.

As versões iniciais do Plasma só conseguiram lidar com casos de uso de pagamentos e não puderam ser promovidas eficientemente. No entanto, se exigirmos que cada raiz seja verificada por SNARK, o Plasma se tornará muito mais poderoso. Cada jogo de desafio pode ser significativamente simplificado, pois excluímos a maioria dos possíveis caminhos para fraudes por parte dos operadores. Ao mesmo tempo, também abrimos novos caminhos para expandir a tecnologia Plasma para uma ampla variedade de categorias de ativos. Por fim, em casos em que os operadores não estejam fraudando, os usuários poderão sacar seus fundos imediatamente, sem a necessidade de esperar uma semana pelo período de desafio.

Uma maneira de criar uma cadeia EVM Plasma (não a única) é usar ZK-SNARK para construir uma árvore UTXO paralela que reflete as mudanças de saldo feitas pelo EVM e define um mapeamento único do ‘mesmo Token’ em diferentes momentos históricos. Em seguida, a estrutura Plasma pode ser construída sobre ela.

Uma visão fundamental é que o sistema Plasma não precisa ser perfeito. Mesmo se você só puder proteger um subconjunto de ativos (por exemplo, apenas Tokens que não foram movidos nas últimas semanas), você já melhorou muito a situação atual do EVM altamente escalável (ou seja, Validium).

Outro tipo de estrutura é o Plasma/Rollup híbrido, como o Intmax. Essas estruturas colocam uma quantidade mínima de dados de cada usuário na cadeia (por exemplo, 5 bytes), o que permite obter algumas características entre o Plasma e o Rollup: no caso do Intmax, é possível obter alta escalabilidade e privacidade, embora teoricamente limitado a cerca de 266.667 TPS em uma capacidade de 16 MB.

Quais são os links relacionados à pesquisa existente?

• Original Paper Plasma:
• Plasma Cash: *Fluxo de Caixa Plasma:
• Intmax (2023):

O que mais precisa ser feito? Quais são as considerações a ter em conta?

A principal tarefa restante é implementar o sistema Plasma em aplicações de produção reais. Como mencionado acima, Plasma e Validium não são uma escolha entre um e outro: qualquer Validium pode melhorar suas propriedades de segurança, pelo menos em certa medida, integrando as características do Plasma em seu mecanismo de saída. O foco da pesquisa é obter as melhores propriedades para o EVM (considerando requisitos de confiança, custos de gás L1 no pior caso e capacidade de resistir a ataques DoS), bem como estruturas de aplicação específicas alternativas. Além disso, em comparação com o Rollup, o Plasma é conceitualmente mais complexo, o que exige abordagens diretas através de pesquisa e construção de estruturas genéricas aprimoradas.

As principais considerações do design do Plasma são a sua maior dependência de operadores e a maior dificuldade de base, embora o design híbrido Plasma/Rollup geralmente possa evitar esse ponto fraco.

Como interagir com outras partes do roteiro?

Quanto mais eficiente for a solução Plasma, menor será a pressão sobre o L1 com funcionalidades de alta disponibilidade de dados. Mover atividades para o L2 também pode reduzir a pressão do MEV no L1.

Sistema de prova de L2 maduro

Que problema estamos a resolver?

No momento, a maioria dos rollups ainda não é realmente Sem confiança. Existe um comitê de segurança que tem a capacidade de anular (otimista ou válido) para provar o comportamento do sistema. Em alguns casos, o sistema de certificação nem sequer está operacional ou, mesmo que o faça, tem apenas uma função de “consultoria”. Os rollups de última geração incluem: (i) alguns rollups específicos de aplicações, tais como Fuel; (ii) No momento em que este artigo foi escrito, Optimism e Arbitrum são dois rollups completos de EVM que alcançaram marcos parciais sem confiança conhecidos como “Fase 1”. A razão pela qual o Rollup não fez mais progresso foi por causa de preocupações com bugs no código. Precisamos de rollups sem confiança, por isso temos de enfrentar e resolver este problema de frente.

O que é, como funciona?

Primeiro, vamos rever o sistema ‘stage’ introduzido inicialmente neste artigo.

Fase 0: Os usuários devem ser capazes de executar Nó e sincronizar a cadeia. Se a verificação for totalmente confiável/centralizada, não há problema.

Fase 1: Deve haver um sistema de prova (não confiável) para garantir que apenas transações válidas sejam aceitas. É permitida a existência de um comitê de segurança que pode anular o sistema de prova, mas deve haver um limite de 75% de votos. Além disso, a parte do comitê que bloqueia o quorum (ou seja, 26% +) deve estar fora da empresa principal que constrói o Rollup. É permitido o uso de um mecanismo de atualização mais fraco (por exemplo, DAO), mas deve haver uma latência suficientemente longa, de modo que os usuários possam retirar seus fundos antes que eles se tornem ativos, caso uma atualização maliciosa seja aprovada.

Fase 2: Deve haver um sistema de prova (não confiável) para garantir que apenas transações válidas sejam aceitas. A Comissão de Segurança só permite intervenção em caso de erros comprováveis no código, por exemplo, se dois sistemas de prova redundantes forem inconsistentes entre si, ou se um sistema de prova aceitar dois post-states diferentes do mesmo Bloco (ou não aceitar nada por tempo suficientemente longo, como uma semana). Atualizações são permitidas, mas com latência bastante longa.

Nosso objetivo é alcançar a Fase 2. O principal desafio da Fase 2 é obter confiança suficiente para demonstrar que o sistema é realmente confiável. Existem duas maneiras principais de fazer isso:

• Verificação formal：podemos usar matemática moderna e tecnologia de computação para provar (otimismo e validade) que o sistema de prova só aceita Blocos conforme a especificação EVM. Essas tecnologias existem há décadas, mas avanços recentes (como o Lean 4) tornaram-nas mais práticas, e os avanços na prova assistida por IA podem acelerar ainda mais essa tendência.
• Múltiplos Provedores (Multi-provers): Crie vários sistemas de prova e coloque recursos nesses sistemas de prova e em comitês de segurança (ou outras ferramentas pequenas com suposições confiáveis, como TEE). Se os sistemas de prova concordarem, o comitê de segurança não terá poder; se eles discordarem, o comitê de segurança só pode escolher entre um deles e não pode impor sua resposta unilateralmente.

O gráfico programático dos múltiplos provadores combina um sistema de prova otimista, um sistema de prova de validade e um comitê de segurança.

Quais são as ligações com a pesquisa existente?

• Semântica EVM K (trabalho de verificação formal de 2017):
• Sobre a ideia de múltiplas provas (2022):
• O projeto Taiko planeja usar várias provas:

O que mais precisa ser feito? Quais são as considerações a ter em conta?

Para a Verificação formal, a carga de trabalho é grande. Precisamos criar uma versão formalmente verificada do verificador SNARK de toda a EVM. Este é um projeto extremamente complexo, embora já tenhamos começado. Existe um truque que pode simplificar muito essa tarefa: podemos criar um verificador SNARK formalmente verificado para uma Máquina virtual minimizada (como RISC-V ou Cairo) e, em seguida, implementar a EVM nessa Máquina virtual minimizada (e formalmente provar sua equivalência com outras especificações de Máquina virtual ETH).

Para o multi-prova, ainda há duas partes principais a serem concluídas. Em primeiro lugar, precisamos ter confiança suficiente em pelo menos dois sistemas de prova diferentes para garantir que eles sejam seguros e que, se houver problemas, esses problemas sejam diferentes e não relacionados (portanto, eles não ocorrerão ao mesmo tempo). Em segundo lugar, precisamos ter uma alta confiança na lógica subjacente do sistema de prova combinado. Este código é muito menor. Existem algumas maneiras de torná-lo muito pequeno, simplesmente armazenando fundos em um contrato de multisig seguro com signatários representando os diferentes sistemas de prova, mas isso aumentará o custo de gás na cadeia. Precisamos encontrar um equilíbrio entre eficiência e segurança.

Como interagir com outras partes do roteiro?

Mover a atividade para L2 pode reduzir a pressão do MEV em Gota na L1.

Melhoria da Interoperabilidade entre L2

Que problema estamos a resolver?

Um dos principais desafios do ecossistema L2 atual é a dificuldade dos usuários em navegar nele. Além disso, os métodos mais simples muitas vezes reintroduzem suposições de confiança, como interações entre cadeias centralizadas, clientes RPC, etc. Precisamos fazer com que a experiência de uso do ecossistema L2 seja semelhante à utilização de um ecossistema unificado da Ethereum.

O que é isso? Como funciona?

Existem muitos tipos de melhorias de interoperabilidade L2 cruzada. Teoricamente, o ETH centrado em Rollup é o mesmo que a Fragmentação L1. O ecossistema L2 atual do ETH ainda tem essas deficiências em relação ao estado ideal na prática:

1、Endereço da cadeia específica: O Endereço deve conter informações sobre a cadeia (L1, Optimism, Arbitrum, etc.). Uma vez feito isso, o processo de envio cruzado para L2 pode ser realizado simplesmente inserindo o Endereço no campo ‘Enviar’, momento em que a Carteira pode lidar internamente com o envio (incluindo o uso de protocolo de interação entre cadeias).

2. Pedidos de pagamento específicos da cadeia: Deve ser fácil e padronizado criar uma mensagem na forma de “Envie-me gerações do tipo X Y na cadeia Z”. Existem dois casos de uso principais para isso: (i) se é um pagamento de pessoa para pessoa ou um serviço de pessoa para comerciante; ii) Pedidos de fundos DApp.

3、Interação entre cadeias兑换和 Gas 支付：应有一个标准化的开放protocolo来表达Interação entre cadeias操作，如「我将向在 Arbitrum 上向我发送 0.9999 个以太币的人发送 1 个以太币（在 Optimism 上）」，以及「我将向在 Arbitrum 上包含此交易的人发送 0.0001 个以太币（在 Optimism 上）」。ERC-7683 是对前者的尝试，而 RIP-7755 是对后者的尝试，尽管这两者的应用范围都比这些特定用例更广。

4. cliente ligeiro: Os utilizadores devem ser capazes de verificar efetivamente a cadeia com a qual estão a interagir, em vez de confiar apenas no fornecedor RPC. O Helios da a16z crypto pode fazer isso (para a própria rede Ethereum), mas precisamos estender essa confiança para a camada L2. ERC-3668 (CCIP-read) é uma estratégia para alcançar esse objetivo.

Como atualizar a visualização da cadeia de cabeçalhos Ethereum do cliente ligeiro. Com a cadeia de cabeçalhos, é possível verificar qualquer objeto de estado usando uma prova de Merkle. Depois de obter o objeto de estado correto L1, você pode usar uma prova de Merkle (e uma assinatura, se você quiser verificar a pré-confirmação) para verificar qualquer objeto de estado na L2. Helios já o fez para o primeiro. Estender para o último é um desafio de padronização.

1. Keystore Carteira: Atualmente, se você quiser atualizar a Chave Secreta que controla seu Contrato Inteligente na Carteira, você deve atualizá-la em todas as N correntes em que a Carteira existe. A Keystore Carteira é uma técnica que permite que a Chave Secreta exista apenas em um lugar (ou na L1 ou possivelmente na L2 no futuro) e qualquer L2 que tenha uma cópia da Carteira pode ler a Chave Secreta dela. Isso significa que a atualização só precisa ser feita uma vez. Para melhorar a eficiência, a Keystore Carteira exige que a L2 tenha uma maneira padronizada de ler informações da L1 sem custo; existem duas propostas para isso, a L1S LOAD e a REMOTESTATICCALL.

O funcionamento da carteira Keystore

2. Conceito mais radical de ‘ponte de Token partilhada’: Imagine um mundo em que todos os L2 são prova de validade Rollup e cada slot é submetido à Ethereum. Mesmo nesse mundo, transferir um ativo de um L2 para outro L2 em seu estado nativo ainda exigiria saques e depósitos, o que incorreria em altas taxas de gás L1. Uma maneira de resolver esse problema é criar um Rollup compartilhado e minimalista, cuja única função é manter o controle de quais L2s possuem cada tipo de Token e os saldos correspondentes, permitindo que esses saldos sejam atualizados em lote por meio de uma série de operações de envio entre L2s iniciadas por qualquer L2. Isso eliminaria a necessidade de pagar taxas de gás L1 a cada transferência entre L2s e não exigiria o uso de tecnologias como ERC-7683 baseadas em provedores de liquidez.

3、Composição síncrona: permite chamadas síncronas entre um L2 específico e L1, ou entre vários L2. Isso ajuda a melhorar a eficiência financeira do protocolo de Finanças Descentralizadas. O primeiro pode ser alcançado sem qualquer coordenação entre L2s; o segundo requer compartilhamento de ordenação. A tecnologia baseada em Rollup é automaticamente aplicável a todas essas tecnologias.

Quais são as ligações com a pesquisa existente?

Endereço específico da cadeia:

ERC-3770 :

ERC-7683:

RIP-7755:

Estilo de design da carteira do Scroll:

Helios:

ERC-3668 (também conhecido como CCIP leitura):

A proposta de ‘pré-confirmação (compartilhada)’ apresentada por Justin Drake:

L1S LOAD (RIP-7728): load-precompile/20388

REMOTESTATICCALL no Optimism:

AggLayer, incluindo a ideia de uma ponte de tokens compartilhada:

O que mais precisa ser feito? Quais são as considerações a ter em conta?

Muitos dos exemplos acima enfrentam o dilema de quando e de quais camadas padronizar. Padronizar muito cedo pode enraizar uma solução inferior. Padronizar muito tarde pode resultar em fragmentação desnecessária. Em alguns casos, há uma solução de curto prazo com desempenho mais fraco, mas mais fácil de implementar, e uma solução de longo prazo ‘correta’, mas que levará anos para ser realizada.

Essas tarefas não são apenas problemas técnicos, elas também são (ou até mesmo podem ser principalmente) problemas sociais que requerem a colaboração de L2, Carteira e L1.

Como interagir com outras partes do roteiro?

A maioria dessas propostas é de natureza mais abstrata, portanto, tem pouco impacto na camada L1. Uma exceção é a ordenação compartilhada, que tem um impacto significativo no valor máximo extraível (MEV).

Execução de extensão em L1

Que problema estamos a resolver?

Se L2 se tornar muito escalável e bem-sucedido, mas L1 ainda só pode lidar com um volume muito pequeno, então o Ethereum pode enfrentar muitos riscos:

1、O estado econômico do ativo ETH se tornará ainda mais instável, o que por sua vez afetará a segurança de longo prazo da rede.

2、Muitos L2 beneficiam de uma ligação estreita com os ecossistemas financeiros altamente desenvolvidos na L1, se esse ecossistema for significativamente enfraquecido, o incentivo para se tornar L2 (em vez de ser independente L1) será enfraquecido.

3、A L2 levará muito tempo para alcançar a mesma segurança que a L1.

4. Se o L2 falhar (por exemplo, devido a comportamentos maliciosos ou desaparecimento do operador), os usuários ainda precisam recuperar seus ativos por meio do L1. Portanto, o L1 precisa ser suficientemente robusto, capaz de lidar ocasionalmente com trabalhos complexos e confusos de L2.

Por estas razões, é muito valioso continuar a expandir o próprio L1 e garantir que ele possa continuar a acomodar cada vez mais casos de uso.

O que é isso? Como funciona?

A forma mais simples de expansão é simplesmente aumentar o limite de gás. No entanto, isso pode resultar na centralização de L1, enfraquecendo assim outra característica importante do Ethereum L1: a credibilidade como uma camada de base robusta. A extensão simples do limite de gás até que ponto é sustentável ainda é motivo de controvérsia, e isso também dependerá das outras tecnologias implementadas para facilitar a validação de blocos maiores (por exemplo, expiração histórica, sem estado, prova de validade do EVM L1). Outro aspecto importante que precisa ser continuamente melhorado é a eficiência do software cliente do Ethereum, que é muito mais eficiente agora do que há cinco anos. Uma estratégia eficaz para aumentar o limite de gás em L1 envolverá acelerar o desenvolvimento dessas tecnologias de validação.

• EOF：um novo formato de bytecode EVM, mais amigável para análise estática, pode levar a implementações mais rápidas. Com essas melhorias de eficiência, o bytecode EOF pode obter custos de gás mais baixos.
• Preço do Gas multidimensional: define custos e limites diferentes para cálculos, dados e armazenamento, permitindo aumentar a capacidade média da camada L1 do Ethereum sem aumentar a capacidade máxima (evitando assim novos riscos de segurança).
• Gota códigos de operação específicos e custo de gás pré-compilado - Historicamente, aumentamos várias vezes o custo de gás de certas operações com preço muito baixo para evitar ataques de negação de serviço. Além disso, podemos reduzir o custo do gás para códigos de operação Gota com preço muito alto. Por exemplo, a adição é muito mais barata do que a multiplicação, mas atualmente os códigos de operação ADD e MUL têm o mesmo custo. Podemos reduzir o custo da adição Gota e até mesmo reduzir o custo de operações mais simples, como PUSH. EOF é otimizado globalmente nesse aspecto.
• EVM-MAX e SIMD: EVM-MAX é uma proposta que permite operações de matemática de grande número nativo mais eficientes como módulo separado do EVM. A menos que seja intencionalmente exportado, o valor calculado pelo EVM-MAX só pode ser acessado por outros códigos de operação EVM-MAX. Isso permite um espaço maior para otimizar o armazenamento desses valores. SIMD (single instruction multiple data) é uma proposta que permite a execução eficiente da mesma instrução em matrizes de valores. Ambos juntos podem criar um coprocessador poderoso ao lado do EVM, que pode ser usado para implementar operações de encriptação de forma mais eficiente. Isso é especialmente útil para protocolos de privacidade e sistemas de proteção L2, por isso ajudará na expansão L1 e L2.

Essas melhorias serão discutidas mais detalhadamente nos próximos artigos do Splurge.

Finalmente, a terceira estratégia é rollups nativos (ou rollups consagrados): essencialmente, criar várias réplicas EVM em execução paralela, resultando em um modelo equivalente ao que o Rollup pode oferecer, mas mais integrado nativamente no protocolo.

Quais são as ligações com a pesquisa existente?

• Roteiro de expansão da camada 1 da ETH da Polynya:
• Preço de gás de várias dimensões:
• EIP-7706:
• EOF:
• EVM-MAX:
• SIMD:
• rollups nativos:
• Valor da expansão L1 discutido por Max Resnick na entrevista:
• Justin Drake fala sobre a expansão usando SNARK e Rollups nativos:

O que mais precisa ser feito, quais são as considerações?

A extensão L1 tem três estratégias que podem ser realizadas separadamente ou em paralelo:

• Melhorar a tecnologia (por exemplo, código do cliente, cliente sem estado, histórico expirado) para tornar o L1 mais fácil de verificar e, em seguida, aumentar o limite de gás.
• Custo específico da operação Gota, aumentando a capacidade média sem aumentar o risco do pior cenário;
• Rollups nativos (ou seja, N réplicas paralelas da EVM).

Ao compreender essas diferentes tecnologias, descobrimos que cada uma tem suas próprias compensações. Por exemplo, os Rollups nativos têm muitas das mesmas fraquezas em termos de composição que os Rollups comuns: você não pode enviar uma única transação para executar operações em vários Rollups, como pode fazer com contratos no mesmo L1 (ou L2). Aumentar o limite de gás enfraquecerá outros benefícios alcançados pela simplificação da verificação L1, como aumentar a proporção de usuários que verificam Nós e aumentar o número de solo stakers. Dependendo da implementação, tornar operações específicas mais baratas na EVM (Máquina Virtual Ethereum) pode aumentar a complexidade geral da EVM.

Uma questão importante que qualquer roadmap de escalabilidade L1 precisa responder é: qual é a visão final do L1 e do L2? Claramente, é absurdo colocar todo o conteúdo no L1: os possíveis casos de uso podem envolver centenas de milhares de transações por segundo, o que tornaria o L1 incapaz de validar (a menos que adotemos o Rollup nativo). No entanto, precisamos de alguns princípios orientadores para garantir que não caiamos nessa situação: aumentar o limite de gás em 10 vezes prejudicaria seriamente a descentralização do Ethereum L1.

Uma visão da divisão do trabalho entre L1 e L2

Como interagir com outras partes do roteiro?

Trazer mais usuários para o L1 não só significa melhorar a escalabilidade, mas também significa melhorar outros aspectos do L1. Isso significa que mais MEV permanecerá no L1 (em vez de ser apenas um problema do L2), tornando assim a necessidade de lidar claramente com o MEV mais urgente. Isso aumentará muito o valor do tempo rápido do slot no L1. Ao mesmo tempo, isso também depende muito do sucesso da verificação do L1 (a Verge).