No início, o Ethereum tinha duas estratégias de dimensionamento em seu roteiro. Uma (por exemplo, vereste artigo iniciala partir de 2015) foi o “sharding”: em vez de verificar e armazenar todas as transações na cadeia, cada nó precisaria apenas verificar e armazenar uma pequena fração das transações. É assim que qualquer outra rede peer-to-peer (por exemplo, BitTorrent) funciona também, então certamente poderíamos fazer com que as blockchains funcionassem da mesma maneira. Outra foi protocolos de camada 2: redes que ficariam em cima do Ethereum de uma forma que lhes permitisse aproveitar totalmente sua segurança, enquanto mantêm a maior parte dos dados e computação fora da cadeia principal. “Protocolos de camada 2” significavacanais de estadoem 2015, Plasmaem 2017 e depoisrollupsEm 2019. Rollups são mais poderosos do que canais de estado ou Plasma, mas exigem uma grande quantidade de largura de banda de dados on-chain. Felizmente, até 2019, a pesquisa de fragmentação havia resolvidoo problema de verificar a 'disponibilidade de dados' em escala. Como resultado, os dois caminhos convergiram e conseguimos o roadmap centrado em rollupque continua a ser a estratégia de escalonamento da Ethereum hoje.

The Surge, edição do roteiro de 2023.

A rota centrada no rollup propõe uma simples divisão de trabalho: o Ethereum L1 se concentra em ser uma camada de base robusta e descentralizada, enquanto os L2s assumem a tarefa de ajudar o ecossistema a escalar. Este é um padrão que se repete em toda a sociedade: o sistema judicial (L1) não está lá para ser ultra-rápido e eficiente, está lá para proteger contratos e direitos de propriedade, e cabe aos empreendedores (L2) construir em cima disso.robustobasecamadae levar a humanidade a Marte (metafórica e literalmente).

Este ano, o roadmap centrado no rollup viu sucessos importantes: a largura de banda de dados do Ethereum L1 aumentou consideravelmente com EIP-4844 blobs, e vários rollups EVM agora são na etapa 1. Um muito implementação heterogênea e pluralística de fragmentação, onde cada L2 atua como um “fragmento” com suas próprias regras e lógica interna, é agora realidade. Mas, como vimos, seguir por este caminho apresenta desafios únicos. Portanto, agora nossa tarefa é concluir o roadmap centrado em rollup e resolver esses problemas, preservando a robustez e a descentralização que tornam o Ethereum L1 especial.

A Surge: objetivos-chave

• 100.000+ TPS em L1+L2
• Preserve a descentralização e robustez do L1
• Pelo menos alguns L2s herdam totalmente as propriedades principais do Ethereum (sem confiança, aberto, resistente à censura)
• Máxima interoperabilidade entre L2s. O Ethereum deve parecer como um ecossistema único, não como 34 blockchains diferentes.

Neste capítulo

• Além disso: o trilema da escalabilidade
• Mais progresso na amostragem de disponibilidade de dados
• Compressão de dados
• Plasma Generalizado
• Sistemas de prova L2 amadurecendo
• Interoperabilidade entre L2 e melhorias de UX
• Escalonando a execução na L1

Além disso: o trilema da escalabilidade

O trilema de escalabilidade era uma ideia introduzido em 2017, que argumentou que existe uma tensão entre três propriedades de uma blockchain: descentralização (mais especificamente: baixo custo para executar um nó), escalabilidade (mais especificamente: alto número de transações processadas) e segurança (mais especificamente: um atacante precisando corromper uma grande parte dos nós em toda a rede para fazer com que uma única transação falhe).

Vale ressaltar que o trilema não é um teorema, e o post que introduziu o trilema não veio com uma prova matemática. Ele deu um argumento matemático heurístico: se um nó amigável à descentralização (por exemplo, um laptop de consumidor) pode verificar N transações por segundo, e você tem uma cadeia que processa k*N transações por segundo, então ou (i) cada transação é vista apenas por 1/k dos nós, o que implica que um atacante só precisa corromper alguns nós para passar uma transação ruim, ou (ii) seus nós serão robustos e sua cadeia não será descentralizada. O objetivo do post nunca foi mostrar que quebrar o trilema é impossível; pelo contrário, foi mostrar que quebrar o trilema é difícil - requer de alguma forma pensar fora da caixa que o argumento implica.

Por muitos anos, tem sido comum que algumas cadeias de alto desempenho afirmem resolver o trilema sem fazer nada inteligente em um nível de arquitetura fundamental, geralmente usando truques de engenharia de software para otimizar o nó. Isso é sempre enganoso, e executar um nó em tais cadeias sempre acaba sendo muito mais difícil do que no Ethereum.Esta postagementra em algumas das muitas sutilezas que explicam por que isso acontece (e, portanto, por que a engenharia de software do cliente L1 sozinha não pode escalar o Ethereum em si).

No entanto, a combinação de amostragem de disponibilidade de dados e SNARKs resolve o trilema: permite a um cliente verificar que alguma quantidade de dados está disponível e que algum número de etapas de computação foi realizado corretamente, enquanto baixa apenas uma pequena parte desses dados e executa uma quantidade muito menor de computação. SNARKs são sem confiança. A amostragem de disponibilidade de dados possui uma nuance modelo de confiança few-of-N, mas preserva a propriedade fundamental que as cadeias não escaláveis têm, ou seja, mesmo um ataque de 51% não pode forçar blocos ruins a serem aceitos pela rede.

Outra maneira de resolver o trilema são as arquiteturas Plasma, que usam técnicas inteligentes para transferir a responsabilidade de verificar a disponibilidade de dados para o usuário de maneira compatível com incentivos. De volta em 2017-2019, quando tudo o que tínhamos para dimensionar a computação eram provas de fraude, o Plasma era muito limitado no que podia fazer com segurança, mas a popularização dos SNARKs torna as arquiteturas Plasma muito mais viávelpara uma variedade maior de casos de uso do que antes.

Mais progresso na amostragem de disponibilidade de dados

Qual problema estamos resolvendo?

A partir de 13 de março de 2024, quando o Atualização DencunDesde que foi ao ar, a blockchain do Ethereum tem três ~125 kB "blobs" por intervalo de 12 segundos, ou ~375 kB por intervalo de largura de banda de disponibilidade de dados. Supondo que os dados da transação sejam publicados diretamente onchain, uma transferência ERC20 é ~180 bytes, e assim o TPS máximo de rollups no Ethereum é:

375000 / 12 / 180 = 173.6 TPS

Se adicionarmos os calldatas do Ethereum (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 torna 607 TPS. Com o PeerDAS, o plano é aumentar a meta do número de blocos para 8-16, o que nos daria 463-926 TPS em calldata.

Este é um aumento significativo em relação ao Ethereum L1, mas não é suficiente. Queremos muito mais escalabilidade. Nosso objetivo de médio prazo é de 16 MB por slot, o que, combinado com melhorias na compressão de dados do rollup, nos daria ~58.000 TPS.

O que é isso e como funciona?

PeerDAS é uma implementação relativamente simples de “amostragem 1D”. Cada blob no Ethereum é um polinômio de grau 4096 sobre um campo primo de 253 bits. Transmitimos “ações” do polinômio, onde cada ação consiste em 16 avaliações em 16 coordenadas adjacentes tiradas de um conjunto total de 8192 coordenadas. Qualquer 4096 das 8192 avaliações (com os parâmetros propostos atuais: qualquer 64 das 128 amostras possíveis) podem recuperar o blob.

O PeerDAS funciona fazendo com que cada cliente escute em um pequeno número de sub-redes, onde a sub-rede i transmite a i-ésima amostra de qualquer blob, e adicionalmente solicita blobs em outras sub-redes que precisa pedindo aos seus pares na rede p2p global (que estariam escutando em sub-redes diferentes). Uma versão mais conservadora,SubnetDAS, usa apenas o mecanismo de sub-rede, sem a camada adicional de pares de pergunta. Uma proposta atual é que os nós que participam da prova de participação usem o SubnetDAS e para outros nós (ou seja. "clients") para usar o PeerDAS.

Teoricamente, podemos dimensionar a amostragem 1D bastante longe: se aumentarmos o número máximo de blobs para 256 (portanto, o alvo para 128), então chegaríamos ao nosso alvo de 16 MB, enquanto a amostragem de disponibilidade de dados custaria apenas 16 amostras para cada nó128 blobs512 bytes por amostra por bloco = 1 MB de largura de banda de dados por slot. Isso está quase dentro de nossa tolerância: é viável, mas significaria que clientes com restrição de largura de banda não podem amostrar. Poderíamos otimizar isso um pouco diminuindo a contagem de blocos e aumentando o tamanho do bloco, mas isso tornaria a reconstrução mais cara.

E assim, em última análise, queremos ir mais longe e fazeramostragem 2D, que funciona por amostragem aleatória não apenas dentro de blobs, mas também entre blobs. As propriedades lineares dos compromissos KZG são usadas para 'estender' o conjunto de blobs em um bloco com uma lista de novos 'blobs virtuais' que codificam redundante a mesma informação.

Amostragem 2D. Fonte: a16z cripto

É crucial, a computação da extensão dos compromissos não requer ter os blobs, então o esquema é fundamentalmente amigável à construção de blocos distribuídos. O nó que realmente está construindo o bloco só precisaria ter os compromissos do blob KZG, e pode contar com o DAS para verificar a disponibilidade dos blobs. 1D DAS também é inerentemente amigável à construção de blocos distribuídos.

Quais são alguns links para pesquisas existentes?

• Post original apresentando a disponibilidade de dados (2018): https://github.com/ethereum/research/wiki/Uma-nota-sobre-a-disponibilidade-de-dados-e-codificação-de-apagamento
• Artigo de acompanhamento: https://arxiv.org/abs/1809.09044
• Post explicativo sobre DAS, paradigma: https://www.paradigm.xyz/2022/08/das
• Disponibilidade 2D com compromissos KZG: https://ethresear.ch/t/2d-data-availability-with-kate-commitments/8081
• PeerDAS no ethresear.ch: https://ethresear.ch/t/peerdas-uma-abordagem-de-das-mais-simples-usando-componentes-p2p-testados-em-batalha/16541 , e papel: https://eprint.iacr.org/2024/1362
• Apresentação sobre PeerDAS por Francesco: https://www.youtube.com/watch?v=WOdpO1tH_Us
• EIP-7594: https://eips.ethereum.org/EIPS/eip-7594
• SubnetDAS em ethresear.ch: https://ethresear.ch/t/subnetdas-an-intermediate-das-approach/17169
• Nuances of recuperabilidade na amostragem 2D: https://ethresear.ch/t/nuances-of-data-recoverability-in-data-availability-sampling/16256

O que resta a fazer e quais são os trade-offs?

O próximo passo imediato é concluir a implementação e o lançamento do PeerDAS. A partir daí, é uma moagem progressiva para continuar aumentando a contagem de blocos no PeerDAS enquanto observamos cuidadosamente a rede e melhoramos o software para garantir a segurança. Ao mesmo tempo, queremos mais trabalhos acadêmicos para formalizar o PeerDAS e outras versões do DAS e suas interações com questões como a segurança da regra de escolha de fork.

Mais para o futuro, precisamos de muito mais trabalho para descobrir a versão ideal do 2D DAS e provar suas propriedades de segurança. Também queremos eventualmente migrar do KZG para uma alternativa resistente ao quantum e sem configuração confiável. Atualmente, não conhecemos candidatos que sejam amigáveis à construção de blocos distribuídos. Mesmo a cara técnica de "força bruta" de usar STARKs recursivos para gerar provas de validade para reconstruir linhas e colunas não é suficiente, porque enquanto tecnicamente um STARK é O(log(n) * log(log(n)) hashes em tamanho (com STIR) Na prática, um STARK é quase tão grande quanto um blob inteiro.

Os caminhos realistas que vejo a longo prazo são:

• Implementar DAS 2D ideal
• Aderir ao DAS 1D, sacrificando a eficiência da largura de banda de amostragem e aceitando um limite de dados mais baixo em prol da simplicidade e robustez
• (Mudança drástica) abandonar DA e abraçar totalmente o Plasma como uma arquitetura de camada 2 primária na qual estamos focando

Podemos vê-los ao longo de um espectro de compensação:

Observe que essa escolha existe mesmo se decidirmos escalar a execução no L1 diretamente. Isso ocorre porque, se o L1 processar muitos TPS, os blocos do L1 se tornarão muito grandes, e os clientes desejarão uma maneira eficiente de verificar se estão corretos, então teríamos que usar a mesma tecnologia que alimenta os rollups (ZK-EVM e DAS) no L1.

Como isso interage com outras partes do roteiro?

A necessidade de DAS 2D é um pouco reduzida, ou pelo menos adiada, se a compressão de dados (ver abaixo) for implementada, e é ainda mais reduzida se o Plasma for amplamente utilizado. DAS também representa um desafio para os protocolos e mecanismos de construção de blocos distribuídos: embora o DAS seja teoricamente amigável para a reconstrução distribuída, isso precisa ser combinado na prática comlista de inclusãopropostas e sua mecânica de escolha de fork circundante.

Compressão de dados

Qual problema estamos resolvendo?

Cada transação em um rollup ocupa uma quantidade significativa de espaço de dados onchain: uma transferência ERC20 ocupa cerca de 180 bytes. Mesmo com amostragem ideal de disponibilidade de dados, isso coloca um limite na escalabilidade dos protocolos de camada 2. Com 16 MB por slot, temos:

16000000 / 12 / 180 = 7407 TPS

E se, além de lidar com o numerador, também pudermos lidar com o denominador e fazer com que cada transação em um rollup ocupe menos bytes na cadeia?

O que é isso e como funciona?

A melhor explicação, na minha opinião, é este diagramade dois anos atrás:

Os ganhos mais simples são apenas compressão de bytes zero: substituindo cada sequência longa de bytes zero por dois bytes representando quantos bytes zero existem. Para avançar, aproveitamos as propriedades específicas das transações:

• Agregação de assinaturas - mudamos de assinaturas ECDSA para assinaturas BLS, que têm a propriedade de que muitas assinaturas podem ser combinadas em uma única assinatura que atesta a validade de todas as assinaturas originais. Isso não é considerado para L1 porque os custos computacionais de verificação, mesmo com agregação, são mais altos, mas em um ambiente escasso em dados como os L2s, fazem sentido. O recurso de agregação deERC-4337apresenta um caminho para implementar isso.
• Substituindo endereços por ponteiros - se um endereço foi usado antes, podemos substituir o endereço de 20 bytes por um ponteiro de 4 bytes para uma localização na história. Isso é necessário para obter os maiores ganhos, embora demande esforço para implementar, pois requer que (pelo menos uma parte) a história do blockchain efetivamente se torne parte do estado.
• Serialização personalizada para valores de transação - a maioria dos valores de transação tem muito poucos dígitos, por exemplo, 0.25 ETH é representado como 250.000.000.000.000.000 wei. As taxas máximas de base e as taxas de prioridade de gás funcionam de forma semelhante. Assim, podemos representar a maioria dos valores monetários de forma muito compacta com um formato de ponto flutuante decimal personalizado, ou mesmo um dicionário de valores especialmente comuns.

Quais são alguns links para pesquisas existentes?

• Exploração a partir de sequence.xyz: https://sequence.xyz/blog/compressing-calldata
• Contratos otimizados de calldata para L2s, de ScopeLift: https://github.com/ScopeLift/l2-optimizoooors
• Uma estratégia alternativa - rollups baseados em prova de validade (também conhecidos como rollups ZK) postam diferenças de estado em vez de transações: https://ethresear.ch/t/rollup-diff-compression-application-level-compression-strategies-to-reduce-the-l2-data-footprint-on-l1/9975
• Carteira BLS - uma implementação de agregação BLS através do ERC-4337: https://github.com/getwax/bls-wallet

O que resta a fazer e quais são os trade-offs?

A principal coisa que resta a fazer é realmente implementar os esquemas acima. As principais compensações são:

• A mudança para assinaturas BLS requer um esforço significativo e reduz a compatibilidade com chips de hardware confiáveis que podem aumentar a segurança. Um invólucro ZK-SNARK em torno de outros esquemas de assinatura poderia ser usado para substituir isso.
• A compressão dinâmica (por exemplo, substituindo endereços por ponteiros) complica o código do cliente.
• Publicar diferenças de estado na cadeia em vez de transações reduz a auditabilidade e faz com que muitos softwares (por exemplo, exploradores de blocos) não funcionem.

Como isso interage com outras partes do roteiro?

A adoção do ERC-4337 e, eventualmente, a consagração de partes dele nos L2 EVMs, pode acelerar muito a implantação de técnicas de agregação. A consagração de partes do ERC-4337 no L1 pode acelerar sua implantação nos L2s.

Plasma Generalizado

Qual problema estamos resolvendo?

Mesmo com blobs de 16 MB e compressão de dados, 58.000 TPS não é necessariamente suficiente para assumir totalmente os pagamentos do consumidor, redes sociais descentralizadas ou outros setores de alta largura de banda, e isso se torna especialmente verdadeiro se começarmos a levar em consideração a privacidade, o que poderia reduzir a escalabilidade em 3-8x. Para aplicações de alto volume e baixo valor, uma opção hoje é um Validade, que mantém os dados fora da cadeia e possui um modelo de segurança interessante onde o operador não pode roubar os fundos dos usuários, mas eles podem desaparecer e congelar temporariamente ou permanentemente todos os fundos dos usuários. Mas podemos fazer melhor.

O que é isso e como funciona?

Plasma é uma solução de escalabilidade que envolve um operador publicando blocos offchain e colocando as raízes de Merkle desses blocos onchain (ao contrário dos rollups, onde o bloco completo é colocado onchain). Para cada bloco, o operador envia para cada usuário um ramo de Merkle provando o que aconteceu, ou não aconteceu, com os ativos desse usuário. Os usuários podem retirar seus ativos fornecendo um ramo de Merkle. Importante, esse ramo não precisa estar enraizado no estado mais recente - por esse motivo, mesmo se a disponibilidade de dados falhar, o usuário ainda pode recuperar seus ativos ao retirar o estado mais recente que possuem disponível. Se um usuário enviar um ramo inválido (por exemplo, saindo de um ativo que já enviou para outra pessoa, ou o próprio operador criando um ativo do nada), um mecanismo de desafio onchain pode adjudicar a quem o ativo pertence legitimamente.

Um diagrama de uma cadeia de Plasma Cash. As transações que gastam a moeda i são colocadas na posição i na árvore. Neste exemplo, assumindo que todas as árvores anteriores são válidas, sabemos que Eve atualmente possui a moeda 1, David possui a moeda 4 e George possui a moeda 6.

As primeiras versões do Plasma só conseguiam lidar com o caso de uso de pagamentos e não conseguiam generalizar efetivamente além disso. Se exigirmos que cada raiz seja verificada com um SNARK, no entanto, o Plasma se torna muito mais poderoso. Cada jogo de desafio pode ser significativamente simplificado, pois eliminamos a maioria dos caminhos possíveis para o operador trapacear. Novos caminhos também se abrem para permitir que técnicas do Plasma sejam estendidas a uma classe de ativos muito mais geral. Finalmente, no caso em que o operador não trapaceia, os usuários podem sacar seus fundos instantaneamente, sem precisar esperar por um período de desafio de uma semana.

Uma maneira (não a única maneira) de criar uma cadeia de plasma EVM: usar um ZK-SNARK para construir uma árvore UTXO paralela que reflete as alterações de saldo feitas pelo EVM e define um mapeamento único do que é 'a mesma moeda' em diferentes pontos da história. Uma construção de Plasma pode então ser construída em cima disso.

Uma visão fundamental é que o sistema Plasma não precisa ser perfeito. Mesmo que você só consiga proteger um subconjunto de ativos (por exemplo, até mesmo moedas que não se moveram na semana passada), você já melhorou significativamente o status quo do EVM altamente escalável, que é um validium válido.

Outra classe de construções é o plasma/rollups híbridos, como Intmax. Essas construções colocam uma quantidade muito pequena de dados por usuário onchain (por exemplo, 5 bytes), e ao fazer isso, obtêm propriedades que estão em algum lugar entre plasma e rollups: no caso do Intmax, você obtém um nível muito alto de escalabilidade e privacidade, embora mesmo no mundo de 16 MB a capacidade seja teoricamente limitada a aproximadamente 16.000.000 / 12 / 5 = 266.667 TPS.

Quais são alguns links para pesquisas existentes?

• Artigo Original do Plasma: https://plasma.io/plasma-deprecated.pdf
• Plasma Cash: https://ethresear.ch/t/plasma-cash-plasma-com-muito-menos-verificacao-de-dados-por-usuario/1298
• Plasma Cashflow: https://hackmd.io/DgzmJIRjSzCYvl4lUjZXNQ?view#🚪-Exit
• Intmax (2023): https://eprint.iacr.org/2023/1082

O que resta a fazer e quais são os trade-offs?

A principal tarefa restante é levar os sistemas Plasma para produção. Como mencionado anteriormente, “plasma vs validium” não é binário: qualquer validium pode ter suas propriedades de segurança melhoradas pelo menos um pouco ao adicionar características do Plasma ao mecanismo de saída. A parte de pesquisa está em obter propriedades ótimas (em termos de requisitos de confiança, custo de gás L1 caso extremo e vulnerabilidade a DoS) para um EVM, bem como construções específicas de aplicativo alternativas. Além disso, a maior complexidade conceitual do Plasma em relação aos rollups precisa ser abordada diretamente, tanto por meio de pesquisa quanto pela construção de estruturas generalizadas melhores.

A principal compensação ao usar os designs da Plasma é que eles dependem mais dos operadores e são mais difíceis de fazer.”baseadoEmbora os designs híbridos de plasma/rollup frequentemente consigam evitar essa fraqueza.

Como isso interage com outras partes do roteiro?

Quanto mais eficazes forem as soluções de Plasma, menos pressão haverá para que o L1 tenha uma funcionalidade de disponibilidade de dados de alto desempenho. A transferência de atividades para o L2 também reduz a pressão MEV no L1.

Sistemas de prova L2 amadurecendo

Qual problema estamos resolvendo?

Hoje, a maioria dos rollups ainda não é realmente confiável; existe um conselho de segurança que tem a capacidade de anular o comportamento do (otimista ou válido)sistema de provaEm alguns casos, o sistema de prova nem sequer está ativo, ou se estiver, possui apenas uma funcionalidade "consultiva". Os mais avançados são (i) alguns rollups específicos de aplicativos, como o Fuel, que são sem confiança, e (ii) no momento desta escrita, Optimism e Arbitrum, dois rollups completos da EVM que alcançaram um marco de parcial falta de confiança conhecido como "estágio 1". A razão pela qual os rollups não avançaram mais é a preocupação com bugs no código. Precisamos de rollups sem confiança, e, portanto, precisamos enfrentar esse problema de frente.

O que é isso e como funciona?

Primeiro, vamos recapitular o sistema de "estágio", originalmente introduzido emesta postagemExistem requisitos mais detalhados, mas o resumo é:

• Estágio 0: deve ser possível para um usuário executar um nó e sincronizar a cadeia. Tudo bem se a validação for totalmente confiável/centralizada.
• Etapa 1: deve haver um sistema de prova (sem confiança) que garanta que apenas transações válidas sejam aceitas. É permitido que haja um conselho de segurança que possa anular o sistema de prova, mas somente com uma votação de limiar de 75%. Além disso, uma parte do conselho que bloqueia o quórum (ou seja, 26% ou mais) deve estar fora do prédio principal da empresa que constrói o rollup. Um mecanismo de atualização com recursos mais fracos (por exemplo, um DAO) é permitido, mas deve ter um atraso longo o suficiente para que, se aprovar uma atualização maliciosa, os usuários possam retirar seus fundos antes que ela entre em funcionamento.
• Estágio 2: deve haver um sistema de prova (sem confiança) que garanta que apenas transações válidas sejam aceitas. Os conselhos de segurança só podem intervir em caso de bugs comprovados no código, por exemplo. se dois sistemas de prova redundantes discordam um do outro ou se um sistema de prova aceita duas raízes pós-estado diferentes para o mesmo bloco (ou não aceita nada por um período de tempo suficientemente longo, por exemplo, uma semana). Um mecanismo de atualização é permitido, mas deve ter um atraso muito longo.

O objetivo é atingir a Etapa 2. O principal desafio em alcançar a etapa 2 é obter confiança suficiente de que o sistema de prova é realmente confiável o bastante. Existem duas maneiras principais de fazer isso:

• Verificação formal: podemos usar técnicas matemáticas e computacionais modernas para provar que um sistema de prova (otimista ou de validade) só aceita blocos que passem na especificação EVM. Essas técnicas existem há décadas, mas avanços recentes como Lean 4 os tornaram muito mais práticos, e os avanços na prova assistida por IA poderiam potencialmente acelerar ainda mais essa tendência.
• Multiprocedores: criar múltiplos sistemas de prova e colocar fundos em um multisig 2-de-3 (ou maior) entre esses sistemas de prova e um conselho de segurança (e/ou outro dispositivo com suposições de confiança, por exemplo, TEEs). Se os sistemas de prova concordarem, o conselho de segurança não terá poder; se discordarem, o conselho de segurança só pode escolher entre um deles, não pode impor unilateralmente sua própria resposta.

Diagrama estilizado de um multi-provador, combinando um sistema de prova otimista, um sistema de prova de validade e um conselho de segurança.

Quais são alguns links para a pesquisa existente?

• Semântica EVM K (trabalho de verificação formal de 2017): https://github.com/runtimeverification/evm-semantics
• Apresentação sobre a ideia de multi-provers (2022):https://www.youtube.com/watch?v=6hfVzCWT6YI
• Taiko planeja usar multi-provas: https://docs.taiko.xyz/core-concepts/multi-proofs/

O que resta fazer e quais são os trade-offs?

Para verificação formal, muito. Precisamos criar uma versão formalmente verificada de um provador SNARK inteiro de um EVM. Este é um projeto incrivelmente complexo, embora seja um projeto que nós já começamosExiste um truque que simplifica significativamente a tarefa: podemos criar um verificador SNARK formalmente verificado de uma VM mínima, por exemplo.RISC-VouCairo, e então escreva uma implementação do EVM nesse VM mínimo (e prove formalmente sua equivalência a alguma outra especificação do EVM).

Para múltiplos provadores, existem duas peças principais restantes. Primeiro, precisamos ter confiança suficiente em pelo menos dois sistemas de prova diferentes, tanto que sejam razoavelmente seguros individualmente, quanto que se eles falharem, falhariam por razões diferentes e não relacionadas (e assim não falhariam ao mesmo tempo). Em segundo lugar, precisamos obter um nível muito alto de garantia na lógica subjacente que mescla os sistemas de prova. Esta é uma parte muito menor do código. Existem maneiras de torná-lo extremamente pequeno - apenas armazenar fundos em um Contrato multisig segurocuja assinatura são contratos representando sistemas de prova individuais - mas isso tem o tradeoff de altos custos de gás onchain. Será necessário encontrar um equilíbrio entre eficiência e segurança.

Como ele interage com outras partes do roteiro?

Transferir a atividade para L2 reduz a pressão de MEV em L1.

Melhorias de interoperabilidade entre L2 cruzados

Qual problema estamos resolvendo?

Um dos principais desafios do ecossistema L2 hoje é que é difícil para os usuários navegar. Além disso, as maneiras mais fáceis de fazê-lo muitas vezes reintroduzem suposições de confiança: pontes centralizadas, clientes RPC e assim por diante. Se estamos falando sério sobre a ideia de que os L2s fazem parte do Ethereum, precisamos fazer com que o uso do ecossistema L2 pareça usar um ecossistema Ethereum unificado.

Um exemplo de experiência de usuário cruzada entre L2 patologicamente ruim (e até perigosa: pessoalmente perdi $100 devido a um erro de seleção de cadeia aqui) - embora isso não seja culpa do Polymarket, a interoperabilidade entre L2 deve ser responsabilidade das carteiras e da comunidade de padrões Ethereum (ERC). Em um ecossistema Ethereum bem funcional, enviar moedas do L1 para o L2, ou de um L2 para outro, deve ser tão simples quanto enviar moedas dentro do mesmo L1.

O que é isso e como funciona?

Existem muitas categorias de melhorias de interoperabilidade cruzada entre L2. Em geral, a maneira de chegar a elas é perceber que, na teoria, um Ethereum centrado em rollup é a mesma coisa que shard de execução L1, e depois perguntar onde o atual L2-verse do Ethereum fica aquém desse ideal na prática. Aqui estão alguns:

• Endereços específicos da cadeia: a cadeia (L1, Optimism, Arbitrum...) deve fazer parte do endereço. Uma vez implementado, os fluxos de envio entre L2 podem ser implementados simplesmente colocando o endereço no campo "enviar", momento em que a carteira pode descobrir como fazer o envio (incluindo o uso de protocolos de ponte) em segundo plano.
• Solicitações de pagamento específicas da cadeia: deve ser fácil e padronizado fazer uma mensagem do tipo "me envie X tokens do tipo Y na cadeia Z". Isso tem dois casos de uso principais: (i) pagamentos, seja de pessoa para pessoa ou de pessoa para serviço de comerciante, e (ii) aplicativos solicitando fundos, por exemplo, o exemplo da Polymarket acima.
• Swaps entre cadeias e pagamento de gás: deve haver um protocolo aberto padronizado para expressar operações entre cadeias, como "Estou enviando 1 ETH na Optimism para quem me enviar 0,9999 ETH na Arbitrum", e "Estou enviando 0,0001 ETH na Optimism para quem incluir esta transação na Arbitrum".ERC-7683é uma tentativa do primeiro, e RIP-7755é uma tentativa do último, embora ambos sejam também mais gerais do que apenas esses casos de uso específicos.
• Clientes leves: os usuários devem ser capazes de verificar efetivamente as cadeias com as quais estão interagindo e não apenas confiar nos provedores de RPC. A16z crypto’sHeliosfaz isso para o Ethereum em si, mas precisamos estender essa falta de confiança para L2s.ERC-3668 (CCIP-read)é uma estratégia para fazer isso.

Como um cliente leve pode atualizar sua visão da cadeia de cabeçalhos do Ethereum. Depois de ter a cadeia de cabeçalhos, você pode usar provas de Merkle para validar qualquer objeto de estado. E uma vez que você tem os objetos de estado corretos L1, você pode usar provas de Merkle (e possivelmente assinaturas, se você quiser verificar pré-confirmações) para validar qualquer objeto de estado em L2. Helios já faz o primeiro. Estender para o último é um desafio de padronização.

• Keystore wallets: hoje, se você quiser atualizar as chaves que controlam sua carteira de contrato inteligente, você tem que fazê-lo em todas as N cadeias em que essa carteira existe. As carteiras Keystore são uma técnica que permite que as chaves existam em um só lugar (seja em L1 ou mais tarde potencialmente em uma L2) e, em seguida, sejam lidas de qualquer L2 que tenha uma cópia da carteira. Isso significa que as atualizações só precisam acontecer uma vez. Para serem eficientes, as carteiras keystore exigem que as L2s tenham uma maneira padronizada de ler L1 sem custos; Duas propostas nesse sentido são: L1SLOADeREMOTESTATICCALL.

Um diagrama estilizado de como as carteiras de keystore funcionam.

• Ideias mais radicais de "ponte de tokens compartilhada": imagine um mundo onde todos os L2s são rollups de prova de validade, que se comprometem com o Ethereum a cada slot. Mesmo neste mundo, mover ativos de um L2 para outro L2 "nativamente" exigiria saquear e depositar, o que requer o pagamento de uma quantidade substancial de gás L1. Uma maneira de resolver isso é criar um rollup mínimo compartilhado, cuja única função seria manter os saldos de quantos tokens de que tipo são de propriedade de qual L2, e permitir que esses saldos sejam atualizados em massa por uma série de operações de envio entre L2s iniciadas por qualquer um dos L2s. Isso permitiria que transferências entre L2s acontecessem sem a necessidade de pagar gás L1 por transferência, e sem a necessidade de técnicas baseadas em provedores de liquidez como ERC-7683.
• Capacidade de composição síncrona: permite que chamadas síncronas aconteçam entre um L2 e L1 específicos ou entre vários L2s. Isso poderia ser útil para melhorar a eficiência financeira dos protocolos defi. A primeira poderia ser feita sem qualquer coordenação cruzada L2; este último exigiria sequenciamento compartilhado. Rollups baseadossão automaticamente amigáveis com todas essas técnicas.

Quais são alguns links para pesquisas existentes?

• Endereços específicos da cadeia: ERC-3770: https://eips.ethereum.org/EIPS/eip-3770
• ERC-7683: https://eips.ethereum.org/EIPS/eip-7683
• RIP-7755: https://github.com/wilsoncusack/RIPs/blob/cross-l2-call-standard/RIPS/rip-7755.md
• Design da carteira de chaves de armazenamento: @haichen/keystore"">https://hackmd.io/@haichen/keystore
• Helios: https://github.com/a16z/helios
• ERC-3668 (às vezes chamado de CCIP-read): https://eips.ethereum.org/EIPS/eip-3668
• Proposta de "pré-confirmações baseadas (compartilhadas)" por Justin Drake: https://ethresear.ch/t/based-preconfirmations/17353
• L1SLOAD (RIP-7728): https://ethereum-magicians.org/t/rip-7728-l1sload-precompile/20388
• REMOTESTATICCALL no Optimism: https://github.com/ethereum-optimism/ecosystem-contributions/issues/76
• AggLayer, que inclui ideias de ponte de token compartilhado: https://github.com/AggLayer

O que resta a fazer e quais são os trade-offs?

Muitos dos exemplos acima enfrentam dilemas padrão sobre quando padronizar e em quais camadas padronizar. Se você padronizar muito cedo, corre o risco de consolidar uma solução inferior. Se você padronizar muito tarde, corre o risco de criar fragmentação desnecessária. Em alguns casos, há tanto uma solução de curto prazo que tem propriedades mais fracas, mas é mais fácil de implementar, quanto uma solução de longo prazo que é "em última instância correta", mas levará alguns anos para chegar lá.

Uma maneira pela qual esta seção é única, é que essas tarefas não são apenas problemas técnicos: são também (talvez até principalmente!) problemas sociais. Eles exigem que as L2s e carteiras e L1 cooperem. Nossa capacidade de lidar com esse problema com sucesso é um teste de nossa capacidade de permanecer unidos como comunidade.

Como isso interage com outras partes do roteiro?

A maioria dessas propostas são construções de “camada superior” e, portanto, não afetam muito as considerações da L1. Uma exceção é a sequenciação compartilhada, que tem grandes impactos no MEV.

Execução de escala em L1

Qual problema estamos resolvendo?

Se os L2s se tornarem muito escaláveis e bem-sucedidos, mas o L1 continuar capaz de processar apenas um volume muito baixo de transações, existem muitos riscos para o Ethereum que podem surgir:

1. A situação econômica do ativo ETH se torna mais arriscada, o que por sua vez afeta a segurança de longo prazo da rede.
2. Muitos L2s se beneficiam de estar intimamente ligados a um ecossistema financeiro altamente desenvolvido no L1, e se esse ecossistema enfraquecer significativamente, o incentivo para se tornar um L2 (em vez de ser um L1 independente) enfraquece
3. Vai demorar muito tempo antes que as L2s tenham exatamente as mesmas garantias de segurança que as L1.
4. Se um L2 falhar (por exemplo, devido a um operador malicioso ou desaparecido), os usuários ainda precisariam passar pelo L1 para recuperar seus ativos. Portanto, o L1 precisa ser poderoso o suficiente para poder lidar pelo menos ocasionalmente com um encerramento altamente complexo e caótico de um L2.

Por essas razões, é valioso continuar escalando o L1 em si e garantir que ele possa continuar acomodando um número crescente de usos.

O que é e como funciona?

A maneira mais fácil de escalar é simplesmente aumentar o limite de gás. No entanto, isso arrisca a centralização do L1, enfraquecendo assim a outra propriedade importante que torna o Ethereum L1 tão poderoso: sua credibilidade como uma camada base robusta. Há um debate em andamento sobre qual grau de aumento simples do limite de gás é sustentável, e isso também muda com base em quais outras tecnologias são implementadas para tornar blocos maiores mais fáceis de verificar (por exemplo, expiração de histórico, estado sem estado, provas de validade do L1 EVM). Outra coisa importante a melhorar é simplesmente a eficiência do software do cliente Ethereum, que hoje está muito mais otimizado do que era há cinco anos. Uma estratégia eficaz de aumento do limite de gás do L1 envolveria acelerar essas tecnologias de verificação.

Outra estratégia de escalonamento envolve a identificação de recursos e tipos específicos de computação que podem ser barateados sem prejudicar a descentralização da rede ou suas propriedades de segurança. Exemplos disso incluem:

• EOF- um novo formato de bytecode EVM que é mais amigável à análise estática, permitindo implementações mais rápidas. O bytecode EOF poderia ter custos de gás mais baixos para levar essas eficiências em consideração.
• Preços de gás multidimensionais- estabelecer taxas-base e limites separados para computação, dados e armazenamento pode aumentar a capacidade média do Ethereum L1 sem aumentar sua capacidade máxima (e, portanto, criar novos riscos de segurança).
• Reduzir os custos de gás de opcodes e pré-cálculos específicos - historicamente, tivemosvários rodadasdeAumentargascustospara certas operações que estavam com preços baixos para evitar ataques de negação de serviço. O que tivemos menos e poderíamos fazer muito mais é reduzir os custos de gás para operações que são muito caras. Por exemplo, a adição é muito mais barata do que a multiplicação, mas os custos dos opcodes ADD e MUL são atualmente os mesmos. Poderíamos tornar a ADD mais barata e até opcodes mais simples como PUSH ainda mais baratos.
• EVM-MAXeSIMD: EVM-MAX (“extensões de aritmética modular”) é uma proposta para permitir matemática modular de números grandes nativa mais eficiente como um módulo separado do EVM. Os valores calculados pelas computações do EVM-MAX só seriam acessíveis por outras operações do EVM-MAX, a menos que sejam deliberadamente exportados; isso permite maior espaço para armazenar esses valores em formatos otimizados. SIMD (“single instruction multiple data”) é uma proposta para permitir a execução eficiente da mesma instrução em uma matriz de valores. Os dois juntos podem criar um poderoso coprocessorjunto com o EVM que poderia ser usado para implementar de forma muito mais eficiente operações criptográficas. Isso seria especialmente útil para protocolos de privacidade e para sistemas de prova L2, então ajudaria tanto na escalabilidade L1 quanto L2.

Essas melhorias serão discutidas com mais detalhes em um post futuro no Splurge.

Finalmente, uma terceira estratégia são os rollups nativos (ou "rollups consagrados"): essencialmente, criando muitas cópias do EVM que funcionam em paralelo, levando a um modelo que é equivalente ao que os rollups podem fornecer, mas muito mais integrado de forma nativa no protocolo.

Quais são alguns links para pesquisas existentes?

• O roadmap de escalabilidade da Polynya para Ethereum L1: https://polynya.mirror.xyz/epju72rsymfB-JK52_uYI7HuhJ-W_zM735NdP7alkAQ
• Preços de gás multidimensionais: https://vitalik.eth.limo/general/2024/05/09/multidim.html
• EIP-7706: https://eips.ethereum.org/EIPS/eip-7706
• EOF: https://evmobjectformat.org/
• EVM-MAX: https://ethereum-magicians.org/t/eip-6601-evm-modular-arithmetic-extensions-evmmax/13168
• SIMD: https://eips.ethereum.org/EIPS/eip-616
• Rollups nativos: https://mirror.xyz/ohotties.eth/P1qSCcwj2FZ9cqo3_6kYI4S2chW5K5tmEgogk6io1GE
• Entrevista com Max Resnick sobre o valor da escalabilidade L1: https://x.com/BanklessHQ/status/1831319419739361321
• Justin Drake sobre o uso de SNARKs e rollups nativos para escala: https://www.reddit.com/r/ethereum/comments/1f81ntr/comment/llmfi28/

O que resta fazer e quais são os trade-offs?

Existem três estratégias para escalonamento L1, que podem ser seguidas individualmente ou em paralelo:

• Melhorar a tecnologia (por exemplo, código do cliente, clientes sem estado, expiração de histórico) para tornar o L1 mais fácil de verificar e, em seguida, aumentar o limite de gás
• Tornar operações específicas mais baratas, aumentando a capacidade média sem aumentar os riscos no pior dos casos
• Rollups nativos (ou seja. "criar N cópias paralelas do EVM", embora potencialmente dando aos desenvolvedores muita flexibilidade nos parâmetros das cópias que implantam)

Vale a pena entender que essas são técnicas diferentes que têm compensações diferentes. Por exemplo, os rollups nativos têm muitas das mesmas fraquezas na composabilidade que os rollups regulares: você não pode enviar uma única transação que execute sincronamente operações em muitos deles, como você pode com contratos no mesmo L1 (ou L2). Aumentar o limite de gás tira outros benefícios que podem ser alcançados tornando o L1 mais fácil de verificar, como aumentar a parcela de usuários que executam nós verificadores e aumentar os stakers solos. Tornar operações específicas no EVM mais baratas, dependendo de como é feito, pode aumentar a complexidade total do EVM.

Uma grande pergunta que qualquer roadmap de escala L1 precisa responder é: qual é a visão final para o que pertence a L1 e o que pertence a L2? Claramente, é absurdo que tudo vá em L1: os casos de uso potenciais vão para as centenas de milhares de transações por segundo, e isso tornaria o L1 completamente inviável de verificar (a menos que sigamos a rota de rollup nativo). Mas precisamos de algum princípio orientador, para que possamos ter certeza de que não estamos criando uma situação em que aumentamos o limite de gás em 10x, prejudicamos fortemente a descentralização do Ethereum L1 e descobrimos que só chegamos a um mundo onde em vez de 99% da atividade estar em L2, 90% da atividade está em L2, 90% da atividade está em L2, e, portanto, o resultado parece quase o mesmo, exceto por uma perda irreversível de muito do que torna o Ethereum L1 especial.

Uma visão proposta de uma "divisão do trabalho" entre L1 e L2s, fonte.

Como ela interage com outras partes do roteiro?

Trazer mais usuários para L1 implica em melhorar não apenas a escala, mas também outros aspectos de L1. Isso significa que mais MEV permanecerá em L1 (ao invés de se tornar um problema apenas para L2s), e assim será ainda mais necessário lidar explicitamente com isso. Isso aumenta consideravelmente o valor de ter tempos de slot rápidos em L1. E também depende fortemente da verificação de L1 ("a Verge") correndo bem.

Aviso legal：

1. Este artigo é reproduzido a partir de [Vitalik Buterin], Todos os direitos autorais pertencem ao autor original [Vitalik Buterin]. Se houver objeções a esta reimpressão, entre em contato com o Gate Learnequipe e eles lidarão com isso prontamente.
2. Isenção de Responsabilidade: As opiniões expressas neste artigo são exclusivamente do autor e não constituem qualquer conselho de investimento.
3. As traduções do artigo para outros idiomas são feitas pela equipe do Gate Learn. A menos que mencionado, copiar, distribuir ou plagiar os artigos traduzidos é proibido.