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

Um agradecimento especial 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 Layer2: essas redes estarão localizadas no topo do ETH Workshop, permitindo que elas se beneficiem plenamente de sua segurança, mantendo a maioria dos dados e computação fora da cadeia principal. O protocolo Layer2 refere-se a canais estatais 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

A roadmap centered on Rollup proposes a simple division of labor: ETH L1 focuses on being a powerful and decentralized base layer, while L2 takes on the task of helping the ecosystem scale. This pattern is ubiquitous in society: the existence of the court system (L1) is not for pursuing super speed and efficiency, but for protecting contracts and property rights, and entrepreneurs (L2) must build on this solid base layer to lead humanity towards Mars (both literally and metaphorically).

Este ano, a roadmap centrada no Rollup alcançou resultados importantes: com o lançamento do EIP-4844 blobs, a largura de banda de dados do ETH L1 aumentou significativamente e vários Rollups baseados na Máquina Virtual Ethereum (EVM) entraram na fase 1. Cada L2 existe como uma ‘fragmentação’ com suas próprias regras e lógica interna, e a diversidade e a pluralidade de abordagens da fragmentação são agora uma realidade. No entanto, como podemos ver, seguir por este caminho também apresenta alguns desafios exclusivos. Portanto, nossa tarefa agora é concluir a roadmap centrada no Rollup e resolver esses problemas, ao mesmo tempo em que mantemos a robustez e a descentralização características do ETH L1.

The Surge: Alvo Chave

1. A Ethereum no futuro 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 totalmente as propriedades principais do Ethereum (Sem confiança, aberto e resistente à censura);

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

Este capítulo

1. Trilema da escalabilidade

2. Mais avanços na amostragem de disponibilidade de dados

3. Compressão de dados

4. Plasma Generalizado

5. Sistema de prova L2 maduro

6. Melhorias na interoperabilidade L2

7. Expandir execução em L1

Tríade paradoxal 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, um baixo custo para executar nós), escalabilidade (processar 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 a pena 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. De fato, ele fornece um argumento matemático heurístico: se um Nó amigável à Descentralização (por exemplo, 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 mais poderosos, mas sua cadeia não será Descentralização. O objetivo deste artigo nunca foi provar que quebrar o paradoxo do triângulo é impossível; pelo contrário, visa mostrar que quebrar o paradoxo do triângulo é difícil e requer, de certa forma, sair do quadro de pensamento implícito no argumento.

Ao longo dos anos, algumas cadeias de alto desempenho frequentemente alegam ter resolvido o trilema de forma não fundamentalmente alterando a arquitetura, geralmente otimizando o Nó através de técnicas de engenharia de software. Isso é sempre enganador, pois é muito mais difícil executar um Nó na cadeia do que na Ethereum. Este artigo irá explorar por que isso acontece, e por que a engenharia de software do cliente L1 por si só não pode escalar 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 a disponibilidade de uma quantidade específica de dados e a execução correta de uma quantidade específica de etapas de cálculo, fazendo o download de apenas uma pequena quantidade de dados e realizando uma quantidade mínima de cálculos. SNARKs é confiável. A amostragem de disponibilidade de dados possui um modelo de confiança few-of-N sutil, 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 a rede a aceitar blocos inválidos.

Outra maneira de resolver o dilema dos três problemas é a arquitetura Plasma, que utiliza tecnologia inteligente para transferir a responsabilidade pela disponibilidade dos dados de monitorização de forma compatível para os utilizadores. Entre 2017 e 2019, quando só tínhamos a prova de fraude como meio de expandir a capacidade de cálculo, a segurança da execução do Plasma era bastante limitada, mas com a disseminação dos SNARKs (provas de conhecimento zero sucintas não interativas), a arquitetura Plasma tornou-se mais viável para uma gama mais ampla de cenários de utilização.

Mais progressos na amostragem de disponibilidade de dados

Qual problema estamos a resolver?

Em 13 de março de 2024, quando Dencun for atualizado e lançado, há cerca de 3 blobs de aproximadamente 125 kB a cada 12 segundos na cadeia de blocos Ethereum. Ou seja, a largura de banda disponível para cada slot é de aproximadamente 375 kB. Supondo que os dados de transação sejam publicados diretamente na cadeia, a transferência de ERC20 é de cerca de 180 bytes, portanto, a capacidade máxima de TPS do Rollup da Ethereum é de 375.000 / 12 / 180 = 173,6 TPS.

Se adicionarmos o calldata do Ethereum (valor teórico máximo: 30 milhões de Gas 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 proporcionará 463-926 TPS para o calldata.

Esta é uma grande melhoria para a camada 1 do Ethereum, mas ainda não é suficiente. Queremos mais escalabilidade. Nosso objetivo a médio prazo é cada slot de 16 MB, o que, combinado com melhorias na compressão de dados Rollup, trará 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 partes do polinômio, onde cada parte contém 16 valores de avaliação das 16 coordenadas adjacentes de um total de 8192 coordenadas. Dentro desses 8192 valores de avaliação, qualquer conjunto de 4096 (de acordo com os parâmetros propostos atuais: qualquer 64 de 128 possíveis amostras) pode recuperar o blob.

O funcionamento do PeerDAS é fazer com que cada cliente escute uma pequena sub-rede, onde a sub-rede i transmite qualquer blob da amostra i e solicita outros blobs na sub-rede necessária, através da consulta aos pares na rede p2p global (que escutarão diferentes sub-redes). A versão mais conservadora, SubnetDAS, utiliza apenas o mecanismo de sub-rede, sem a camada adicional de consulta aos pares. A proposta atual é que os Nós participantes 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 amostra de ‘1D’ bastante grande: se aumentarmos o número máximo de ‘blobs’ para 256 (com uma meta de 128), podemos atingir a meta de 16MB, com cada Nó de amostragem de disponibilidade de dados contendo 16 amostras * 128 blobs * 512 bytes por amostra de blob = 1MB de largura de banda de dados por slot. Isso está apenas dentro do limite do que podemos tolerar: é factível, mas significa que clientes com largura de banda limitada não podem amostrar. Podemos otimizar isso até certo ponto, reduzindo a quantidade de blobs e aumentando o tamanho dos blobs, mas isso aumentará o custo de reconstrução.

Portanto, finalmente queremos ir mais longe e fazer uma amostragem 2D (2D sampling), este método não apenas faz amostragem aleatória dentro do blob, mas também faz amostragem aleatória entre blobs. Usando as propriedades lineares do compromisso KZG, ampliamos o conjunto de blobs em um Bloco com um novo conjunto de blobs virtuais, que codifica redundante mente a mesma informação.

Portanto, finalmente, queremos avançar ainda mais, realizando uma amostragem 2D, que não é apenas dentro do blob, mas também entre blobs de amostragem aleatória. As propriedades lineares prometidas por KZG são usadas para expandir o conjunto de blobs em um bloco, que contém uma nova lista virtual de blobs redundantes que codificam as mesmas informações.

2D amostragem. Fonte de dados: a16z crypto

É crucial que a extensão do compromisso de cálculo não precise ter um bloco, tornando essa solução fundamentalmente amigável para a construção de blocos distribuídos. Os Nós que constroem o Bloco só precisam ter o compromisso KZG do bloco e podem confiar na 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 de blocos distribuídos.

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

1. Introdução ao post original sobre a disponibilidade de dados (2018):

2. Documento de acompanhamento:

3. Explicação do DAS no artigo paradigm:

4. Disponibilidade 2D com compromisso KZG:

PeerDAS on 5.ethresear.ch: And the paper:

6.EIP-7594:

SubnetDAS em 7.ethresear.ch:

Pequenas diferenças na recuperabilidade na amostragem 8.2D:

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

A seguir, será a implementação e lançamento do PeerDAS. Posteriormente, continuaremos a aumentar gradualmente o número de blobs no PeerDAS, enquanto observamos atentamente a rede e melhoramos o software para garantir a segurança. Ao mesmo tempo, esperamos ter mais trabalhos académicos para padronizar a interação do PeerDAS e outras versões do DAS, incluindo questões de segurança da regra da escolha do garfo.

Num estágio futuro mais distante, precisaremos fazer mais trabalho para determinar a versão ideal do 2D DAS e provar suas propriedades de segurança. Esperamos também poder eventualmente mudar do KZG para uma alternativa quântica segura e sem configuração confiável. Atualmente, não está claro quais soluções candidatas são amigáveis para a construção de bloco distribuído. Mesmo o uso da tecnologia ‘brute force’, ou mesmo o uso de STARK recursivo para gerar prova de validade para reconstruir linhas e colunas, não é suficiente para atender às demandas, pois, embora tecnicamente o tamanho de um STARK seja O(log(n)*log(log(n)) hashes (usando STIR), na prática, um STARK é quase tão grande quanto o blob inteiro.

A trajetória de longo prazo que eu considero como realidade é:

1. Implemente o DAS 2D ideal;

2. Persistir no uso de 1D DAS, sacrificar a eficiência da largura de banda de amostragem em prol da simplicidade e robustez, aceitando um limite de dados mais baixo.

3. (Hard pivot) Abandonar DA e adotar completamente Plasma como nossa principal arquitetura Layer2 a seguir.

Por favor, note que, mesmo que optemos por escalar diretamente 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 maneira eficiente de verificar sua correção, então teremos que usar a mesma tecnologia que 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 2D DAS será reduzida ou pelo menos haverá uma latência. Se o Plasma for amplamente utilizado, a demanda será ainda menor. DAS também apresenta desafios para a construção de blocos e mecanismos de protocolo distribuídos: embora DAS seja teoricamente amigável para reconstrução distribuída, isso precisa ser combinado na prática com a proposta de inclusão de pacotes e mecanismos de escolha de forquilha ao redor.

Compressão de dados

Qual problema estamos resolvendo?

Cada transação em Rollup ocupará um grande espaço de dados na cadeia: uma transferência ERC20 requer aproximadamente 180 bytes. Mesmo com uma amostragem ideal de disponibilidade de dados, isso limita a escalabilidade do protocolo de camada. Com cada slot de 16 MB, temos:

16000000 / 12 / 180 = 7407 TPS

Se não só podemos resolver o problema do numerador, mas também o problema do denominador, e fazer com que cada transação em cada Rollup ocupe menos bytes na cadeia, o que aconteceria?

O que é, como funciona?

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

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

Agregação de Assinaturas: Mudamos de assinatura ECDSA para assinatura BLS. A característica da assinatura BLS é que várias assinaturas podem ser combinadas em uma única assinatura, que pode provar a validade de todas as assinaturas originais. No nível 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 o 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 ponteiros para substituir Endereço: Se tivermos usado um determinado Endereço anteriormente, podemos substituir o Endereço de 20 bytes por um ponteiro de 4 bytes apontando para uma posição no histórico.

Serialização personalizada de valores de transação - a maioria dos valores de transação tem 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 prioritárias 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 as pesquisas existentes?

1. Explore sequence.xyz:

2. Otimizar contrato calldata L2:

3. Rollups baseados em prova de validade (também conhecidos como ZK rollups) diferem em relação ao estado de lançamento, não às transações:

4. Carteira BLS - Agregação BLS implementada através de ERC-4337:

O que mais precisa ser feito e quais são as considerações a serem feitas?

O próximo passo é 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 encapsulamento ZK-SNARK de outros esquemas de assinatura.

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

3、Publicar as diferenças de estado na cadeia em vez de transações, pode Gota auditabilidade e tornar muitos softwares (como explorador de blockchain) inoperantes.

Como interagir com outras partes do roteiro?

Ao adotar o ERC-4337 e, finalmente, incorporar parte dele no L2 EVM, pode-se 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

Qual 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 pagamentos do consumidor, redes sociais descentralizadas ou outras áreas de alta largura de banda, especialmente quando começamos a considerar a privacidade, o que pode aumentar a descentralização 3-8 vezes. Para aplicativos de alto 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 blocos completos na cadeia). Para cada bloco, o operador envia um ramo de Merkle para cada usuário para provar o que aconteceu com os seus ativos, ou se nada aconteceu. Os usuários podem recuperar seus ativos fornecendo o ramo de Merkle. É importante destacar que esse ramo não precisa ter a raiz do estado mais recente. Portanto, mesmo em caso de problemas de disponibilidade de dados, os usuários ainda podem recuperar seus ativos, extraindo o estado mais recente disponível. Se um usuário fornecer um ramo inválido (por exemplo, tentando recuperar ativos que já foram enviados para outra pessoa, ou o operador criando ativos do nada), a legalidade do vesting dos ativos pode ser determinada através de um mecanismo de desafio fora da cadeia.

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

A versão inicial do Plasma só podia lidar com casos de uso de pagamento e não podia ser eficazmente expandida. No entanto, se exigirmos que cada raiz seja verificada com SNARK, o Plasma se tornará muito mais poderoso. Todos os jogos de desafio podem ser muito simplificados, pois excluímos a maioria das possíveis maneiras de os operadores trapacearem. Ao mesmo tempo, também abrimos novos caminhos para que a tecnologia Plasma possa se expandir para uma gama mais ampla de ativos. Por fim, na ausência de trapaça por parte dos operadores, os usuários podem sacar fundos imediatamente, sem a necessidade de esperar uma semana de período de desafio.

Uma forma de construir uma cadeia EVM Plasma (não a única forma): construir uma árvore UTXO paralela usando ZK-SNARK que reflete as alterações de saldo feitas pela EVM e define um mapeamento único para o ‘mesmo Token’ em pontos temporais históricos diferentes. Em seguida, pode-se construir uma estrutura Plasma sobre ela.

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

Outro tipo de estrutura é a mistura Plasma/Rollup, como Intmax. Essas estruturas colocam uma quantidade muito pequena de dados para cada usuário na cadeia (por exemplo, 5 bytes), o que pode obter algumas características intermediárias entre Plasma e Rollup: no caso do Intmax, você pode 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. Paper Plasma Original:

2.Plasma Cash:

3. Fluxo de caixa do Plasma Cash

4.Intmax (2023):

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

A principal tarefa restante é colocar o sistema Plasma em uso prático. Como mencionado acima, o Plasma e o Validium não são uma escolha exclusiva: qualquer Validium pode aumentar sua segurança em certa medida integrando características do Plasma em seu mecanismo de saída. A pesquisa se concentra em obter as melhores propriedades para o EVM (considerando requisitos de confiança, custos de gás L1 no pior cenário e capacidade de resistir a ataques DoS), bem como estruturas de aplicação alternativas. Além disso, em comparação com o Rollup, o Plasma é conceitualmente mais complexo, o que requer pesquisa e construção de estruturas gerais aprimoradas para lidar diretamente com isso.

A principal trade-off na utilização de Plasma é que eles dependem mais dos operadores e são mais difíceis de escalar, embora um design misto Plasma/Rollup geralmente possa contornar essa fraqueza.

Como interagir com outras partes do roteiro?

À medida que a solução Plasma se torna mais eficaz, a pressão sobre o desempenho e a disponibilidade de dados de alto desempenho do L1 diminui. Mover atividades para L2 também pode reduzir a pressão MEV no L1.

Sistema de Prova L2 Maduro

Qual problema estamos a resolver?

Atualmente, a maioria dos Rollup na verdade não é Sem confiança. Existe um comitê de segurança que tem a capacidade de substituir o comportamento do sistema de prova (otimista ou válido). Em algumas situações, o sistema de prova pode até não funcionar completamente, ou mesmo que funcione, só tem funções de “consulta”. Os Rollup mais avançados incluem: (i) alguns Rollup específicos de aplicações Sem confiança, como Fuel; (ii) até à data desta redação, Optimism e Arbitrum são duas implementações de marcos parciais sem confiança chamados de “Fase Um” em Rollup EVM completo. A razão pela qual o Rollup não avançou mais é o medo de bugs no código. Precisamos de Rollup sem confiança, portanto, devemos enfrentar e resolver este problema.

O que é, como funciona?

Primeiro, vamos analisar o sistema de “estágio” que foi originalmente introduzido neste artigo.

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

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 possa 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. A utilização de um mecanismo de atualização mais fraco (por exemplo, DAO) é permitida, mas deve haver uma latência suficientemente longa, de modo que, se aprovar uma atualização maliciosa, os usuários possam retirar seus fundos antes que eles estejam disponíveis.

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 no código quando erros comprováveis estiverem presentes, por exemplo. Se dois sistemas de prova redundantes forem inconsistentes entre si, ou se um sistema de prova aceitar dois estados posteriores diferentes para o mesmo Bloco (ou não aceitar qualquer conteúdo por tempo suficientemente longo, como uma semana). A atualização é permitida, mas deve ter uma latência muito longa.

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

1. 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 que seguem as especificações do EVM. Essas técnicas existem há décadas, mas os 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.

2. Multi-provadores: Faça vários sistemas de certificação e coloque dinheiro nesses sistemas de certificação com comitês de segurança (ou outros gadgets com pressupostos de confiança, como TEEs). Se se provar que o sistema está de acordo, o comité de segurança não tem autoridade; Se não estiverem de acordo, o Conselho de Segurança só pode escolher entre uma ou outra, não pode impor unilateralmente as suas próprias respostas.

O gráfico do Prova de Validade dos Multi-Proofers 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 as pesquisas existentes?

1. Semântica K do EVM (trabalho de verificação formal de 2017):

2. Discurso sobre a ideia de prova múltipla (2022):

3. Planeja usar prova múltipla:

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

Para a Verificação formal, o trabalho é árduo. Precisamos criar uma versão de verificação formal do SNARK Prover inteiro da Máquina Virtual Ethereum. Este é um projeto extremamente complexo, embora já tenhamos começado. Existe uma solução que pode simplificar muito essa tarefa: podemos criar um Prover SNARK verificado formalmente 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áquinas virtuais Ethereum).

Para provas múltiplas, existem ainda duas partes principais que estão por concluir. Em primeiro lugar, precisamos ter confiança suficiente em pelo menos dois sistemas de prova diferentes, garantindo que sejam igualmente seguros e que, se ocorrerem problemas, estes sejam distintos e não relacionados (para que não ocorram simultaneamente). Em segundo lugar, precisamos ter uma confiança muito elevada na lógica subjacente do sistema de combinação de provas. Esta parte do código deve ser muito mais reduzida. Existem algumas técnicas para reduzi-la significativamente, como armazenar os fundos num contrato de multi-assinatura seguro, com os representantes de cada sistema de prova como signatários, mas isto aumentará o custo do gás. Precisamos encontrar um equilíbrio entre eficiência e segurança.

Como interagir com outras partes do roteiro?

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

Melhorias na interoperabilidade entre camadas L2

Qual problema estamos a resolver?

Um dos principais desafios enfrentados pelo ecossistema L2 atualmente é 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 centralizadas entre cadeias, clientes RPC, etc. Precisamos fazer com que a experiência de usar o ecossistema L2 seja semelhante à de usar um ecossistema unificado de Ethereum.

O que é isso? Como funciona?

A interoperabilidade L2 melhorada tem várias categorias. Em teoria, o Ethereum centrado no Rollup é o mesmo que a fragmentação L1. O ecossistema atual da camada L2 do Ethereum ainda tem essas deficiências em relação ao estado ideal:

1. Endereço da cadeia específica: O Endereço deve conter informações da cadeia (L1, Optimism, Arbitrum…). Uma vez feito isso, o processo de envio entre L2 pode ser realizado simplesmente inserindo o Endereço no campo ‘enviar’, e a Carteira pode lidar com o envio em segundo plano (incluindo o uso do protocolo de interação entre cadeias).

2. Solicitações de pagamento em uma cadeia específica: deve ser possível criar facilmente e padronizar mensagens com o formato ‘envie X unidades de moeda Y para mim na cadeia Z’. Isso é útil em dois cenários principais: (i) pagamentos entre pessoas ou entre pessoas e serviços de comerciantes; (ii) solicitações de fundos por DApps.

3. Interação entre cadeias de troca e pagamento de gás: Deve haver um protocolo aberto padronizado para expressar a interação entre cadeias, como ‘Vou enviar 1 ETH para a pessoa que me enviou 0,9999 ETH no Arbitrum (no Optimism)’ e ‘Vou enviar 0,0001 ETH para a pessoa que incluiu esta transação no Arbitrum (no Optimism)’. ERC-7683 é uma tentativa para o primeiro caso, enquanto RIP-7755 é uma tentativa para o segundo caso, embora ambos tenham escopo mais amplo do que esses casos específicos.

4. cliente ligeiro: Os usuários devem ser capazes de verificar efetivamente a cadeia com a qual estão interagindo, em vez de confiar apenas no provedor RPC. O Helios da a16z crypto pode fazer isso (para o próprio ETH), mas precisamos estender essa desconfiança para L2. 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 obter a cadeia de cabeçalho, pode-se usar provas de Merkle para verificar qualquer objeto de estado. Uma vez que se tem o objeto de estado L1 correto, pode-se usar provas de Merkle (e assinaturas, se desejar verificar pré-confirmações) para verificar qualquer objeto de estado em L2. A Helios já fez o primeiro. A extensão para o segundo é um desafio de padronização.

1、Keystore Carteira: Atualmente, se você quiser atualizar o seu Contrato inteligenteCarteiraChave Secreta, você terá que atualizá-lo em todas as N correntes em que a Carteira existe. Keystore Carteira é uma técnica que permite que a Chave Secreta exista apenas em um lugar (seja na L1 ou possivelmente na L2 no futuro), e então 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 aumentar a eficiência, Keystore Carteira exige que L2 tenha um meio padronizado de ler informações da L1 sem custo; existem duas propostas para isso, que são L1SLOAD e REMOTESTATICCALL.

O funcionamento da Carteira Keystore

2、Conceito mais agressivo de ‘ponte de Token compartilhado’: Imagine um mundo onde todos os L2 são prova de validade Rollup e cada slot envia para a Ethereum. Mesmo nesse mundo, transferir ativos de um L2 para outro ainda requer saque e depósito no estado nativo, o que acarreta em uma grande quantidade de taxas de gás L1. Uma forma de resolver esse problema é criar um Rollup compartilhado extremamente simples, cuja única função é manter o proprietário de cada tipo de Token de L2 e o saldo de cada um, permitindo que esses saldos sejam atualizados em lote por meio de uma série de operações de envio entre L2 iniciadas por qualquer L2. Isso permitirá transferências entre L2 sem a necessidade de pagar taxas de gás L1 a cada transferência, ou usar tecnologias baseadas em provedores de liquidez como ERC-7683.

3、Sincronização Combinatória: Permite chamadas síncronas entre L2 específicos 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 cruzada L2; o último requer compartilhamento de ordenação. A tecnologia baseada em Rollup é automaticamente aplicável a todas essas tecnologias.

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

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

2.ERC-7683:

3.RIP-7755:

4. Design de estilo de carteira de armazenamento de chaves:

5. Helios:

6. ERC-3668 (às vezes referido como leitura CCIP):

7. A proposta de Justin Drake para “baseada em pré-confirmação (partilhada)”:

8.L1SLOAD (RIP-7728):

9.REMOTESTATICCALL em Optimism:

10.AggLayer, que inclui a ideia de uma ponte de token compartilhado:

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

Muitos dos exemplos acima enfrentam o dilema de quando padronizar e quais camadas padronizar. Se padronizado muito cedo, pode enraizar uma solução inferior. Se padronizado muito tarde, pode causar fragmentação desnecessária. Em alguns casos, existe uma solução de curto prazo com uma propriedade mais fraca, mas mais fácil de implementar, e também uma solução de longo prazo ‘correta’, mas que levará anos para ser realizada.

Estas tarefas não são apenas problemas técnicos, mas também (e possivelmente principalmente) problemas sociais que requerem cooperação L2 e Carteira, bem como L1.

Como interagir com outras partes do roteiro?

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

Extensão de execução em L1

Qual problema estamos a resolver?

Se L2 se tornar altamente escalável e bem-sucedida, mas L1 ainda só puder lidar com uma quantidade muito pequena de volume, pode haver muitos riscos para a rede Ethereum (ETH).

1、A situação económica dos ativos ETH tornar-se-á ainda mais instável, o que por sua vez afetará a segurança a longo prazo da rede.

Muitos L2 se beneficiam de uma estreita ligação com um ecossistema financeiro altamente desenvolvido na L1, e se esse ecossistema for enfraquecido, o incentivo para se tornar um L2 (em vez de um L1 independente) será enfraquecido.

3. Levará muito tempo para que a L2 alcance a mesma segurança que a L1.

4、Se L2 falhar (por exemplo, devido a comportamento malicioso ou desaparecimento do operador), os utilizadores ainda precisam de recorrer ao L1 para recuperar os seus ativos. Portanto, o L1 precisa de ser suficientemente robusto para, pelo menos ocasionalmente, lidar efetivamente com o trabalho complexo e caótico de encerramento do L2.

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

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 da L1, enfraquecendo assim outra característica importante do Ethereum L1: sua credibilidade como uma base sólida. A extensão simples do limite de gás até que ponto é sustentável ainda é objeto de controvérsia, e isso também pode variar dependendo de quais outras tecnologias estão sendo implementadas para facilitar a validação de blocos maiores (por exemplo, expiração histórica, estado sem estado, prova de validade do EVM L1). Outro aspecto importante que precisa ser continuamente aprimorado é a eficiência do software do cliente Ethereum, que hoje é muito mais eficiente do que há cinco anos. Uma estratégia eficaz para aumentar o limite de gás da L1 envolverá acelerar o desenvolvimento dessas tecnologias de validação.

1.EOF: um novo formato de bytecode EVM, mais amigável para análise estática e mais rápido para implementação. Levando em consideração essas melhorias de eficiência, o bytecode EOF pode obter custos de gás mais baixos.

2. Preço do Gas Multidimensional: estabelece custos e restrições diferentes para cálculos, dados e armazenamento, o que pode aumentar a capacidade média do Ethereum L1 ETH sem aumentar a capacidade máxima (evitando assim novos riscos de segurança).

3. Custos específicos de Gas e pré-compilação de operações Gota - Historicamente, para evitar ataques de negação de serviço, aumentámos várias vezes o custo de Gas de operações com preços muito baixos. Algo mais que podemos fazer é aumentar o custo de Gas de operações Gota com preços muito altos. Por exemplo, a adição é muito mais barata do que a multiplicação, mas atualmente o custo das operações de ADD e MUL é o mesmo. Podemos diminuir o custo de ADD da Gota e até mesmo reduzir o custo de operações mais simples como PUSH. No geral, podemos otimizar mais nesse aspecto.

4. EVM-MAX e SIMD: EVM-MAX é uma proposta que permite a realização de cálculos de grande módulo de números nativos de forma mais eficiente como um módulo separado do EVM. A menos que seja explicitamente exportado, os valores calculados pelo EVM-MAX só podem ser acessados por outros códigos de operação EVM-MAX, permitindo assim maior espaço para otimizar o armazenamento desses valores. SIMD (Single Instruction Multiple Data) é uma proposta que permite a execução eficiente de instruções idênticas em matrizes de valores. Ambos juntos podem criar um co-processador poderoso ao lado do EVM, que pode ser usado para implementar operações de encriptação de forma mais eficiente. Isso é particularmente útil para protocolos de privacidade e sistemas de proteção L2, e ajudará na expansão L1 e L2.

Estas melhorias serão discutidas mais detalhadamente em futuros artigos do Splurge.

Por último, a terceira estratégia é Rollups nativos (ou rollups enraizados): essencialmente, criar muitas cópias paralelas em execução do EVM, resultando num modelo equivalente ao que rollup pode oferecer, mas mais integrado no protocolo.

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

1. Mapa de expansão da camada L1 da Polynya para Ethereum:

2. Preço de gás multidimensional:

3.EIP-7706:

4.EOF:

5.EVM-MAX:

6.SIMD:

7. Rollups nativos:

8.Max Resnick entrevistou sobre o valor da expansão L1

9. Justin Drake fala sobre a expansão usando SNARK e Rollups nativos:

O que mais precisa ser feito e quais são as considerações a serem feitas?

A extensão L1 tem três estratégias que podem ser realizadas separadamente 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. Gota custo específico de operações, aumentando a capacidade média sem aumentar o risco de pior cenário;

3. Rollups nativos (ou seja, criar N réplicas paralelas do EVM).

Ao entender 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, assim como pode fazer com contratos em um mesmo L1 (ou L2). Aumentar o limite de gás enfraquecerá outros benefícios que podem ser alcançados através da simplificação da verificação L1, como aumentar a proporção de usuários que validam nós e aumentar o número de participantes solo. Dependendo da implementação, tornar operações específicas da EVM (Máquina Virtual Ethereum) mais baratas pode aumentar a complexidade geral da EVM.

Uma grande questão que qualquer roteiro de expansão L1 precisa responder é: qual é a visão final do L1 e do L2? É claro que é absurdo colocar tudo no L1: os possíveis casos de uso podem envolver centenas de milhares de transações por segundo, o que tornaria o L1 inviável para validação (a menos que usemos a abordagem de Rollup nativo). No entanto, precisamos de algumas diretrizes para garantir que não acabemos em uma situação em que o limite máximo de gás seja aumentado em 10 vezes, prejudicando seriamente a Descentralização do L1 do Ethereum.

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

Como interagir com outras partes do roteiro?

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

Leitura relacionada: “Novo artigo de Vitalik: O que mais pode ser melhorado no PoS do Ethereum? Como implementar?”

Link original