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

Autor: Vitalik Buterin

Compilação: Karen, Foresight News

Um agradecimento especial a Justin Drake, Francesco, Hsiao-wei Wang, @antonttc e Georgios Konstantopoulos.

Inicialmente, o roteiro do Ethereum tinha duas estratégias de dimensionamento. Um (ver um artigo preliminar de 2015) é a ‘Fragmentação’ (sharding): cada nó só precisa verificar e armazenar uma pequena parte das transações, em vez de verificar e armazenar todas as transações na cadeia. Qualquer outra rede ponto a ponto (por exemplo, BitTorrent) funciona da mesma forma, então é claro que podemos fazer a blockchain funcionar da mesma maneira. A outra é o protocolo de Camada 2: essas redes ficarão acima do Ethereum, permitindo que ele se beneficie totalmente de sua segurança, ao mesmo tempo em que mantém a maior parte dos dados e cálculos fora da cadeia principal. O protocolo de Camada 2 refere-se aos canais de estado de 2015, ao Plasma de 2017 e, em seguida, ao Rollup de 2019. O Rollup é mais poderoso do que os canais de estado ou o Plasma, mas requer uma grande largura de banda de dados na cadeia. Felizmente, até 2019, a pesquisa de Fragmentação havia resolvido o problema de verificação em grande escala da ‘disponibilidade de dados’. Como resultado, os dois caminhos se fundiram e obtivemos um roteiro centrado no Rollup, que ainda é a estratégia de expansão do Ethereum hoje.

The Surge, versão do mapa de rota de 2023

O roteiro centrado no Rollup propõe uma divisão simples: o ETH L1 se concentra em ser uma camada base robusta e descentralizada, enquanto o L2 assume a tarefa de ajudar a expandir o ecossistema. Esse modelo está em toda parte na sociedade: a existência do sistema judiciário (L1) não é para buscar velocidade e eficiência extrema, mas sim para proteger contratos e direitos de propriedade, enquanto os empreendedores (L2) constroem sobre essa base sólida, liderando a humanidade em direção a Marte, seja literalmente ou metaforicamente.

Este ano, o roteiro centrado no Rollup produziu resultados importantes: com o lançamento dos blobs EIP-4844, a largura de banda de dados do ETH Workshop L1 aumentou significativamente, e vários Rollups do ETH Workshop Máquina virtual (EVM) entraram na primeira fase. Cada L2 existe como uma “Fragmentação” com regras e lógicas internas próprias, e a diversidade e pluralismo das formas como a Fragmentação é implementada é agora uma realidade. Mas, como vimos, existem alguns desafios únicos para seguir esse caminho. Portanto, nossa tarefa agora é completar o roteiro centrado no Rollup e abordar essas questões, mantendo a robustez e a descentralização que caracterizam a ETH L1.

O Surge: Objetivo Crucial

1、No futuro, o 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 herdaram completamente as propriedades principais do Ethereum (Sem confiança, aberto, resistente à censura);

4. O ETH deve parecer um ecossistema unificado em vez de 34 blockchains diferentes.

Conteúdo deste capítulo

1. O paradoxo da tríade da escalabilidade
2. Mais avanços na amostragem de disponibilidade de dados
3. Compressão de dados
4. Plasma Generalizado
5. Sistema de prova de L2 maduro
6. Melhorias na interoperabilidade L2
7. Expansão de execução em L1

Paradoxo da Tríade da Escalabilidade

O paradoxo do triângulo de escalabilidade é uma ideia proposta em 2017, que argumenta que existe uma contradição entre as três características da blockchain: Descentralização (mais especificamente, o baixo custo de execução de Nós), escalabilidade (processamento de um grande número de transações) e segurança (um atacante precisa comprometer uma grande parte dos Nós na rede para fazer uma única transação falhar).

Vale ressaltar que o paradoxo do triângulo não é um teorema e posts que o introduzem não vêm acompanhados de provas matemáticas. Ele fornece, de fato, um argumento matemático heurístico: se um Nó amigável à Descentralização (como um laptop 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 só pode ser vista por 1/k dos Nós, o que significa que um atacante só precisa comprometer alguns Nós para passar uma transação maliciosa, ou (ii) seus Nós se tornarão poderosos, mas sua cadeia não será Descentralização. O objetivo deste artigo não é provar que quebrar o paradoxo do triângulo é impossível; pelo contrário, ele visa mostrar que quebrar o triângulo é difícil, e requer de alguma forma transcender o quadro de pensamento implícito no argumento.

Por muitos anos, algumas cadeias de alta performance afirmaram ter resolvido a tricotomia sem mudar fundamentalmente a arquitetura, geralmente otimizando o Nó com técnicas de engenharia de software. Isso sempre foi enganoso, pois executar um Nó nessas cadeias é muito mais difícil do que na rede Ethereum. Este artigo explora por que isso acontece e por que a engenharia de software do cliente L1 por si só não pode escalar o Ethereum.

No entanto, a combinação de amostragem de disponibilidade de dados com SNARKs realmente resolveu o paradoxo triangular: permite que o cliente verifique a disponibilidade de um certo número de dados e a execução correta de um certo número de etapas de cálculo, 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 tem um modelo de confiança sutil few-of-N, mas preserva as características fundamentais de uma cadeia não escalável, ou seja, mesmo um ataque de 51% não pode forçar a rede a aceitar blocos ruins.

Uma outra maneira de resolver o dilema dos três problemas é através da arquitetura Plasma, que utiliza técnicas inteligentes para transferir a responsabilidade de monitorar a disponibilidade de dados para os usuários de forma compatível e incentivada. Nos anos de 2017 a 2019, quando só tínhamos a prova de fraude como meio de expandir a capacidade computacional, o Plasma tinha grandes limitações em termos de execução segura, mas com a popularização dos SNARKs (argumentos não interativos de conhecimento-zero), a arquitetura Plasma tornou-se viável para uma variedade mais ampla de casos de uso do que nunca.

Mais progressos 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 de bloco ETH terá cerca de 3 blobs de 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, uma transferência ERC20 é de cerca de 180 bytes, então a TPS máxima do Rollup na camada ETH é: 375000 / 12 / 180 = 173.6 TPS

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

Esta é uma melhoria significativa para a Ethereum L1, mas não é suficiente. Queremos mais escalabilidade. Nosso objetivo a médio prazo é ter 16 MB por slot, o que, combinado com melhorias na compressão de dados do Rollup, resultará em cerca de 58000 TPS.

O que é isso? Como funciona?

PeerDAS é uma implementação relativamente simples de ‘amostragem 1D’. Na rede Ethereum, cada blob é um polinômio de 4096 graus sobre um campo primo de 253 bits. 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. Com estes 8192 valores de avaliação, qualquer conjunto de 4096 (de acordo com os parâmetros propostos atuais: qualquer 64 de 128 amostras possíveis) pode recuperar o blob.

O funcionamento do PeerDAS é fazer com que cada cliente escute uma quantidade reduzida de sub-redes, em que a i-ésima sub-rede transmite qualquer blob da i-ésima amostra e solicita blobs de outras sub-redes necessárias, consultando os pares na rede P2P global (que estarão escutando sub-redes diferentes). A versão mais conservadora SubnetDAS usa apenas o mecanismo de sub-rede, sem a camada adicional de consulta a pares. A proposta atual é que os nós que participam da Prova de Staking usem o SubnetDAS, enquanto outros nós (ou seja, clientes) usem o PeerDAS.

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

Portanto, queremos avançar ainda mais, realizando amostragem 2D (2D sampling), este método não só realiza amostragem aleatória dentro do blob, mas também entre os blobs. Usando a propriedade linear do compromisso de KZG, expandimos um conjunto de blobs em um bloco com um conjunto de novos blobs virtuais, que codificam redundantemente as mesmas informações.

Portanto, finalmente, queremos ir mais longe e realizar amostragem 2D, que não apenas dentro do bloco, mas também entre os blocos, de forma aleatória. As propriedades lineares prometidas pelo KZG são usadas para expandir um conjunto de blocos, que contém uma nova lista de blocos virtuais que codificam redundâncias das mesmas informações dentro de um Bloco.

Amostragem 2D. Fonte de dados: a16z crypto

É importante destacar que a expansão do compromisso de cálculo não requer um bloco, tornando esse plano fundamentalmente amigável para a construção distribuída de blocos. Os nós que constroem o bloco só precisam ter o compromisso KZG do blob e podem depender da amostragem de disponibilidade de dados (DAS) para verificar a disponibilidade do bloco de dados. A amostragem de disponibilidade de dados unidimensionais (1D DAS) também é essencialmente amigável para a construção distribuída de blocos.

Quais são as ligações com pesquisas existentes?

1. Post original sobre disponibilidade de dados (2018):
2. Documento de acompanhamento:
3. Sobre o artigo de explicação do DAS, paradigma:
4. Disponibilidade 2D com compromisso KZG:
5. PeerDAS em ethresear.ch: e o artigo:
6. EIP-7594:
7. SubnetDAS em ethresear.ch:
8. 2D amostragem de diferenças sutis reversíveis:

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

Em seguida, será concluída a implementação e lançamento do PeerDAS. Em seguida, continuaremos a aumentar o número de blobs no PeerDAS, enquanto observamos cuidadosamente a rede e aprimoramos o software para garantir a segurança, um processo gradual. Ao mesmo tempo, esperamos mais trabalhos acadêmicos para padronizar a interação do PeerDAS e outras versões do DAS, juntamente com a regra de escolha do garfo e questões de segurança relacionadas.

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, mudar de KZG para uma alternativa quântica segura e sem necessidade de configuração confiável. Atualmente, não sabemos quais das soluções candidatas são amigáveis para a construção de Blocos distribuídos. Mesmo usando a técnica de ‘força bruta’ cara, ou seja, usando STARK recursivo para gerar prova de validade usada na reconstrução de linhas e colunas, não é suficiente para atender às necessidades, pois, embora tecnicamente o tamanho de um STARK seja O(log(n) * log(log(n)) valores de hash (usando STIR), na prática, o STARK é quase tão grande quanto o blob inteiro.

A minha visão a longo prazo é:

1. Implementar o ideal do DAS 2D;
2. Persistir no uso de 1D DAS, sacrificando a eficiência da largura de banda de amostragem, em prol da simplicidade e robustez, aceitando um limite de dados mais baixo.
3. Abandonar o DA e adotar totalmente o Plasma como a principal arquitetura Layer2 que seguimos.

Por favor, note que, mesmo que optemos por escalar diretamente na camada L1, essa opção é possível. Isso ocorre porque, se a camada L1 tiver que lidar com um grande volume de TPS, o Bloco L1 se tornará muito grande, e os clientes desejariam ter uma maneira eficiente de verificar sua correção, portanto, teríamos que usar na camada L1 a mesma tecnologia que Rollup (como ZK-EVM e DAS).

Como interagir com outras partes do roadmap?

Se a compressão de dados for implementada, a demanda por 2D DAS será reduzida, ou pelo menos a latência será aumentada, se Plasma for amplamente utilizado, a demanda será reduzida ainda mais. DAS também desafia a construção de protocolo e mecanismo de Bloco distribuído: embora DAS seja teoricamente amigável para reconstrução distribuída, na prática, isso precisa ser combinado com propostas de inclusão de pacotes e os mecanismos de forquilha ao redor.

Compressão de Dados

Que problema estamos resolvendo?

Cada transação em Rollup ocupará uma quantidade significativa de espaço de dados na cadeia: a transferência de ERC20 requer cerca de 180 bytes. Mesmo com amostragem ideal de disponibilidade de dados, isso também limita a escalabilidade do protocolo de camada. Com 16 MB por slot, obtemos:

16000000 / 12 / 180 = 7407 TPS

E se pudermos resolver não apenas o problema do numerador, mas também o problema do denominador, reduzindo o número de bytes ocupados por cada transação no Rollup na cadeia?

O que é isto, como funciona?

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

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

Agregração de assinaturas: Mudamos de assinaturas ECDSA para assinaturas BLS, onde a característica das assinaturas BLS é que várias assinaturas podem ser combinadas em uma única assinatura, que pode provar a validade de todas as assinaturas originais. Na camada L1, devido ao alto custo computacional da verificação, mesmo após a agregação, não consideramos o uso de assinaturas BLS. No entanto, em ambientes como a camada L2, onde os dados são escassos, o uso de assinaturas BLS faz sentido. A característica de agregação do ERC-4337 fornece uma maneira de implementar essa funcionalidade.

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

A serialização personalizada do valor da transação - a maioria dos valores de transação possui poucos dígitos, por exemplo, 0.25 ETH é representado como 250.000.000.000.000.000 wei. As taxas básicas máximas e as taxas de prioridade também são semelhantes. Portanto, podemos usar um formato decimal de ponto flutuante personalizado para representar a maioria dos valores monetários.

Quais são as ligações com pesquisas existentes?

1. Explore sequence.xyz:
2. Otimização de contrato L2 Calldata:
3. Rollups baseados em prova de validade (também conhecidos como ZK rollups) diferem no estado de publicação, não nas transações:
4. BLS Carteira - através da agregação BLS implementada pelo ERC-4337:

Ainda precisa fazer alguma coisa, quais são as considerações?

A próxima coisa a fazer é realmente implementar o cenário acima. Os principais compromissos incluem:

1. Mudar para a assinatura BLS requer muito esforço e é incompatível com chips de hardware confiáveis que podem aumentar a segurança. Você pode usar o encapsulamento ZK-SNARK de outras soluções de assinatura em vez disso.

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

3、Publicar a diferença de estado na cadeia em vez de na transação, tornará Gota auditável e impedirá que muitos softwares (por exemplo, explorador de blockchain) funcionem.

Como interagir com outras partes do mapa de estradas?

Usando o ERC-4337 e, finalmente, incorporando 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 16 MB de blob e compressão de dados, 58.000 TPS pode não ser suficiente para atender totalmente às necessidades de pagamento do consumidor, redes sociais Descentralização ou outras áreas de alta largura de banda, especialmente quando começamos a considerar a privacidade, o que pode aumentar a escalabilidade Gota entre 3-8 vezes. Para cenários de alto volume e baixo valor, uma opção atual é usar o Validium, que armazena dados fora da cadeia e adota um interessante modelo de segurança: os operadores não podem roubar fundos dos usuários, mas eles podem congelar temporariamente ou permanentemente os fundos de todos os usuários. Mas podemos fazer melhor.

O que é isto e como funciona?

Plasma é uma solução de escalonamento, que envolve um operador publicando um Bloco fora da cadeia e colocando as raízes de Merkle desses Blocos na cadeia (ao contrário do Rollup, que coloca o bloco completo na cadeia). Para cada Bloco, o operador envia a cada usuário um ramo de Merkle para provar o que mudou ou não mudou em seus ativos. 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 recente. Portanto, mesmo se houver problemas de disponibilidade de dados, os usuários ainda podem recuperar seus ativos fornecendo o estado mais recente disponível. Se um usuário apresentar um ramo inválido (por exemplo, recuperar ativos que já foram transferidos para outra pessoa, ou se o operador criou ativos do nada), a legalidade do vesting dos ativos pode ser determinada pelo mecanismo de desafio na cadeia.

Cadeia Plasma Cash 图。花费硬币 i 的交易被放在 tree 中的第 i 个位置。在此示例中，假设所有先前的 tree 都有效，我们知道 Eve 当前拥有Token 1，David 拥有Token 4，George 拥有Token 6。

As versões iniciais do Plasma só podiam lidar com casos de uso de pagamento e não podiam ser amplamente promovidas de forma eficaz. No entanto, se exigirmos que cada raiz seja verificada com SNARK, o Plasma se tornará muito mais poderoso. Cada jogo de desafio pode ser muito simplificado, pois eliminamos a maioria das possíveis rotas de trapaça do operador. Ao mesmo tempo, também abrimos novas oportunidades para expandir a tecnologia Plasma para uma variedade mais ampla de ativos. Por fim, em casos em que o operador não está trapaceando, os usuários podem retirar os fundos imediatamente, sem a necessidade de esperar uma semana pelo período de desafio.

Um método de construção de uma cadeia EVM Plasma (não o único método): usando ZK-SNARK para construir uma árvore UTXO paralela, refletindo as alterações de saldo feitas pelo EVM e definindo uma única correspondência para o mesmo token em diferentes pontos no tempo histórico. Então, a estrutura Plasma pode ser construída com base nessa árvore.

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

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

Quais são os links relacionados à pesquisa existente?

1. Artigo Original do Plasma:
2. Plasma Cash:
3. Fluxo de Caixa Plasma:
4. Intmax (2023):

O que mais precisa ser feito? Quais são as compensações?

A principal tarefa restante é colocar o sistema Plasma em uso prático. Como mencionado acima, Plasma e Validium não são uma escolha exclusiva: qualquer Validium pode melhorar sua segurança em certa medida incorporando as características do Plasma em seu mecanismo de saída. O foco da pesquisa está em obter as melhores propriedades para o EVM (considerando requisitos de confiança, custo de gás L1 no pior cenário e capacidade de resistir a ataques DoS), bem como estruturas de aplicação específicas alternativas. Além disso, em comparação com Rollup, Plasma é mais complexo em termos conceituais, o que requer abordagens diretas para resolvê-lo por meio de pesquisa e construção de estruturas genéricas aprimoradas.

As principais trade-offs do design baseado em Plasma residem no fato de que eles dependem mais dos operadores e são mais difíceis de basear, embora o design híbrido Plasma/Rollup geralmente possa evitar esse ponto fraco.

Como interagir com outras partes do roadmap?

Quanto mais eficiente for a solução Plasma, menos pressão haverá sobre a capacidade de disponibilidade de dados de alto desempenho do L1. Mover atividades para o L2 também pode reduzir a pressão de MEV no L1.

Sistema de Prova L2 Madura

Que problema estamos a resolver?

Atualmente, a maioria dos Rollups ainda não é confiável. Existe um comitê de segurança que tem a capacidade de substituir o comportamento do sistema de prova (otimista ou de validade). Em alguns casos, o sistema de prova nem mesmo funciona ou, se funciona, apenas em modo de ‘consulta’. Os Rollups mais avançados incluem: (i) alguns Rollups específicos de aplicativos sem confiança, como Fuel; (ii) até o momento desta escrita, Optimism e Arbitrum são dois Rollups EVM completos que implementaram uma parte do marco sem confiança chamada ‘fase um’. A falta de progresso nos Rollups ocorre devido à preocupação com bugs no código. Precisamos de Rollups sem confiança, portanto, devemos enfrentar e resolver esse problema.

O que é isto e como funciona?

Primeiro, vamos revisitar o sistema “stage” introduzido inicialmente neste artigo.

Fase 0: Os usuários devem ser capazes de executar o Nó e sincronizar a cadeia. Se a verificação for totalmente confiável/centralizada, também está tudo bem.

Fase 1: Deve haver um sistema de prova (não confiável) para garantir que apenas transações válidas sejam aceitas. Permite-se um comitê de segurança que possa anular o sistema de prova, mas deve haver um limiar de votação de 75%. Além disso, a parte do comitê quorum-blocking (ou seja, 26%+) deve estar fora da empresa principal que constrói o Rollup. Um mecanismo de atualização mais fraco (por exemplo, DAO) é permitido, mas deve ter uma latência suficientemente longa para que os usuários possam retirar seus fundos antes que o limite de fundos seja atingido se a atualização maliciosa for aprovada.

Fase 2: Deve haver um sistema de prova (não confiável) para garantir que apenas transações válidas sejam aceitas. O comitê de segurança só permite intervenção quando há 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 duas raízes de post-estado diferentes para o mesmo bloco (ou não aceitar nenhum conteúdo por um período de tempo suficientemente longo, como uma semana). Atualizações são permitidas, mas devem ter uma latência significativa.

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

1. Verificação formal：podemos usar matemática moderna e tecnologia de computação para provar (otimista e válida) que o sistema só aceita Bloco conforme especificação EVM. Essas tecnologias existem há décadas, mas avanços recentes (como Lean 4) as tornaram mais práticas, e avanços na prova assistida por IA podem acelerar ainda mais essa tendência.
2. Multi-provers: Create multiple proof systems and invest funds in these proof systems and the security committee (or other small tools with trust assumptions, such as TEE). If the proof systems agree, the security committee has no power; if they disagree, the security committee can only choose between them, it cannot unilaterally impose its own answer.

O gráfico programático do Multi-Proof combinou um sistema de prova otimista, um sistema de prova de validade e um comitê de segurança.

Quais são as ligações com pesquisas existentes?

1. EVM K Semantics (trabalho de verificação formal a partir de 2017):
2. Discurso sobre a ideia de múltiplas provas (2022):
3. O plano Taiko usa prova múltipla:

O que mais precisa ser feito? Quais são as compensações?

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

Para a prova de múltiplas provas, ainda existem duas partes principais a serem concluídas. Primeiro, precisamos ter confiança em pelo menos dois sistemas de prova diferentes, garantindo que sejam igualmente seguros e que, se houver problemas, eles sejam diferentes e não relacionados (para que não ocorram problemas simultaneamente). Em segundo lugar, precisamos ter uma confiança muito alta na lógica subjacente ao sistema de prova combinada. Essa parte do código deve ser muito menor. Existem algumas maneiras de torná-lo muito pequeno, armazenando fundos em um contrato de múltiplas assinaturas seguras (Safe multisig) com contratos representando os diferentes sistemas de prova como signatários, 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 roadmap?

Mova a atividade para L2 para reduzir a pressão MEV no L1.

Melhorias na interoperabilidade 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 usar o ecossistema L2 seja semelhante à experiência de usar um ecossistema unificado de Ethereum.

O que é isto? Como funciona?

Existem muitos tipos de melhorias de interoperabilidade cruzada L2. Teoricamente, o centro do ETH Rollup é o mesmo que a execução da Fragmentação L1. O atual ecossistema L2 do ETH está longe do ideal na prática, com as seguintes deficiências:

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 entre L2 pode ser realizado simplesmente colocando o endereço no campo ‘Enviar’, e a Carteira pode cuidar automaticamente do processo de envio nos bastidores (incluindo o uso de protocolo de interação entre cadeias).

2. Pedido de pagamento de uma cadeia específica: deve ser fácil criar e padronizar uma mensagem com a forma “envie-me X unidades da criptomoeda Y na cadeia Z”. Isso é usado principalmente em dois cenários: (i) pagamentos entre pessoas ou entre pessoas e serviços de comércio; (ii) solicitação de fundos para DApps.

3、Interação entre cadeias兑换和 gás 支付：应有一个标准化的开放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 interagindo, em vez de apenas confiar no fornecedor de RPC. O Helios da a16z crypto pode fazer isso (para a própria rede ETH), mas precisamos estender essa confiança para a camada L2. O ERC-3668 (CCIP-read) é uma estratégia para alcançar esse objetivo.

Como atualizar a visualização da cadeia de cabeçalho Ethereum do cliente ligeiro. Depois de possuir a cadeia de cabeçalho, você pode usar provas de Merkle para verificar qualquer objeto de estado. Uma vez que você tenha o objeto de estado L1 correto, pode usar provas de Merkle (e, se desejar verificar pré-confirmação, também pode usar assinaturas) para verificar qualquer objeto de estado em L2. O Helios já fez o primeiro. Estender para o último é um desafio de padronização.

1. Carteira Keystore: Atualmente, se você quiser atualizar a Chave Secreta da sua Carteira de Contratos Inteligentes, você precisa atualizá-la em todas as cadeias em que a Carteira esteja presente. A Carteira Keystore é uma tecnologia que permite que a Chave Secreta exista apenas em um local (seja na L1 ou possivelmente na L2 no futuro), e qualquer L2 que possua uma cópia da Carteira pode ler a Chave Secreta dela. Isso significa que a atualização só precisa ser feita uma vez. Para aumentar a eficiência, a Carteira Keystore requer que a L2 tenha uma maneira padronizada de ler as informações da L1 sem custos; para isso, existem duas propostas, L1SLOAD e REMOTESTATICCALL.

Keystore Carteira工作原理

2. Um conceito mais radical de “ponte de token compartilhado”: Imagine um mundo onde todo L2 é um rollup de prova de validade e cada slot é submetido ao workshop ETH. Mesmo em tal mundo, para transferir ativos de um L2 para outro em seu estado natal, saques e depósitos ainda são necessários, o que implica pagar uma quantidade significativa de taxas de gás L1. Uma maneira de resolver esse problema é criar um rollup compartilhado e minimalista cuja única função é manter qual L2 possui cada tipo de token e quanto saldo cada um tem, e permite que esses saldos sejam atualizados em massa através de uma série de operações de envio cross-L2 iniciadas por qualquer L2. Isso eliminará a necessidade de transferências entre L2 para pagar taxas de gás L1 por cada transferência, bem como o uso de tecnologias baseadas em Liquidez, como ERC-7683.

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

Quais são as ligações com pesquisas existentes?

Endereço específico da cadeia: ERC-3770:

**ERC-7683:

**RIP-7755:

**Scroll keystore Carteira设计式样：

**Helios:

**ERC-3668 (sometimes referred to as CCIP Read):

**A proposta de Justin Drake para ‘Preimage Sharing’ (Pré-confirmação) é:

**L1SLOAD (RIP-7728):

**REMOTESTATICCALL em Optimism:

AggLayer, incluindo a ideia de ponte de token compartilhado:

O que mais precisa ser feito? Quais são as compensações?

Muitos dos exemplos acima enfrentam o dilema de quando e quais camadas devem ser padronizadas. Se a padronização ocorrer cedo demais, pode enraizar uma solução inferior. Se a padronização ocorrer tarde demais, pode causar fragmentação desnecessária. Em alguns casos, existe uma solução de curto prazo com menos recursos, mas mais fácil de implementar, e também uma solução de longo prazo, considerada a ‘correta final’, mas que levará anos para ser realizada.

Essas tarefas não são apenas problemas técnicos, mas também (e possivelmente principalmente) problemas sociais que requerem colaboração entre L2, Carteira e L1.

Como interagir com outras partes do roadmap?

A maioria dessas propostas são estruturas de ‘alto nível’, portanto, têm pouco impacto no nível L1. Uma exceção é a ordenação compartilhada, que tem um impacto significativo no valor máximo extraível (MEV).

Expandindo execução na L1

Que problema estamos a resolver?

Se L2 se tornar altamente escalável e bem-sucedido, mas L1 ainda só pode lidar com uma quantidade muito baixa de volume, pode haver muitos riscos para a Ethereum.

1、O estado económico dos ativos ETH se tornará 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 do L1; se este ecossistema for significativamente enfraquecido, o incentivo para se tornar L2 (em vez de ser um L1 independente) será reduzido.

3. A L2 levará muito tempo para alcançar o mesmo nível de segurança que a L1.

4. Se L2 falhar (por exemplo, devido a comportamento malicioso ou desaparecimento do operador), os usuários ainda precisam recuperar seus ativos através de L1. Portanto, L1 precisa ser poderoso o suficiente para lidar ocasionalmente com o trabalho complexo e confuso de encerramento de L2.

Por essas razões, expandir continuamente o L1 em si e garantir que ele possa acomodar cada vez mais casos de uso é muito valioso.

O que é isso? Como funciona?

A forma mais simples de expansão é aumentar diretamente o limite de gás. No entanto, isso pode levar à centralização do L1, enfraquecendo assim outra característica importante do Ethereum L1: a confiabilidade como uma camada base robusta. A extensão sustentável do limite de gás ainda é objeto de debate e pode variar dependendo da implementação de outras tecnologias para facilitar a validação de blocos maiores (por exemplo, expiração histórica, estado sem estado, prova de validade do L1 EVM). Outro aspecto importante que precisa ser continuamente melhorado é a eficiência do software do cliente Ethereum, que é muito maior do que há cinco anos. Uma estratégia eficaz de aumento do limite de gás L1 envolverá acelerar o desenvolvimento dessas tecnologias de validação.

1. EOF: um novo formato de bytecodes EVM, mais amigável para análise estática, pode levar a implementações mais rápidas. Com essas melhorias de eficiência, os bytecodes EOF podem resultar em custos de gás mais baixos.
2. Precificação de gás multidimensional: estabelecer custos e limites básicos diferentes para cálculos, dados e armazenamento, pode aumentar a capacidade média da camada L1 do Ethereum (EVITANDO assim novos riscos de segurança) sem aumentar a capacidade máxima.
3. Custos específicos de gas e pré-compilados Gota - Historicamente, para evitar ataques de negação de serviço, aumentamos várias vezes o custo do gas de certas operações com preços muito baixos. Além disso, pode ser feito mais otimizando os custos de gas de operações com preços muito elevados. Por exemplo, a adição é muito mais barata do que a multiplicação, mas atualmente o custo dos códigos de operação ADD e MUL é o mesmo. Podemos reduzir o custo do gas para ADD e até mesmo reduzir o custo de operações mais simples como PUSH. Em termos gerais, há mais otimização a ser feita nesse aspecto.
4. EVM-MAX e SIMD: EVM-MAX é uma proposta que permite a realização de cálculos mais eficientes de grandes números nativos como um módulo separado para o EVM. A menos que intencionalmente expostos, os valores calculados pelo EVM-MAX só podem ser acessados 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 arrays de valores. Juntos, eles podem criar um coprocessador poderoso ao lado do EVM, que pode ser usado para realizar a encriptação de forma mais eficiente. Isso é especialmente útil para protocolos de privacidade e sistemas de proteção L2, e portanto, contribuirá para a expansão de L1 e L2.

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

Por fim, a terceira estratégia são os Rollups nativos (ou rollups enshrined): essencialmente, cria várias cópias paralelas do EVM em execução, gerando assim um modelo equivalente ao oferecido pelos Rollups, mas integrado de forma mais nativa ao protocolo.

Quais são as ligações com pesquisas existentes?

1. Roteiro de expansão do ETH Workshop L1 da Polynya:
2. Preço do Gas Multidimensional:
3. EIP-7706:
4. EOF:
5. EVM-MAX:
6. SIMD:
7. Rollups nativos:
8. Max Resnick entrevista sobre o valor da expansão L1:
9. Justin Drake fala sobre a expansão usando SNARK e Rollups nativos:

Ainda precisa fazer alguma coisa, quais são as considerações?

Existem três estratégias para a expansão da L1, que podem ser realizadas de forma isolada ou em paralelo:

1. Melhorar a tecnologia (como 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.
2. Aumentar o custo de operação específico de Gota aumenta a capacidade média sem aumentar o risco de pior cenário;
3. Rollups nativos (ou seja, criação de N réplicas paralelas da EVM).

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

Uma questão importante que qualquer roteiro de escalabilidade L1 precisa responder é: qual é a visão final do L1 e do L2? É claro que é absurdo colocar todo o conteúdo no L1: os cenários de aplicação potenciais podem envolver centenas de milhares de transações por segundo, o que tornaria impossível para o L1 verificar (a menos que adotemos o Rollup nativo). Mas precisamos de algumas diretrizes para garantir que não caiamos em uma situação em que o limite de gás seja aumentado em 10 vezes, prejudicando 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 roadmap?

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

Recomendação de leitura: “Novo artigo de Vitalik: O futuro potencial do Éter, the Merge”