No início, o Ethereum tinha duas estratégias de escalonamento no seu roteiro. Uma (por exemplo, ver este artigo inicial de 2015) foi "sharding": em vez de verificar e armazenar todas as transações na cadeia, cada nó só precisaria verificar e armazenar uma pequena fração das transações. É assim que qualquer outra rede peer-to-peer (por exemplo. BitTorrent) também funciona, então certamente poderíamos fazer com que os blockchains funcionassem da mesma maneira. Outro eram os protocolos de camada 2: redes que ficariam em cima do Ethereum de uma forma que lhes permitisse se beneficiar totalmente de sua segurança, mantendo a maioria dos dados e computação fora da cadeia principal. "Protocolos de camada 2" significava canais de estadoem 2015, Plasma em 2017, e depois rollupsem 2019. Os Rollups são mais poderosos do que os canais de estado ou o Plasma, mas requerem uma grande quantidade de largura de banda de dados on-chain. Felizmente, em 2019, a pesquisa de fragmentação tinha resolvidoo problema de verificar a "disponibilidade de dados" em escala. Como resultado, os dois caminhos convergiram e obtivemos o roadmap centrado em rollupque continua a ser a estratégia de escalonamento da Ethereum hoje.

A subida, edição do roteiro de 2023.

O roadmap centrado em rollup propõe uma divisão simples do trabalho: o Ethereum L1 concentra-se 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 judiciário (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 dissorobustobasecamadae levar a humanidade a Marte (de forma metafórica e literal).

Este ano, o roadmap centrado em rollups viu sucessos importantes: a largura de banda de dados do Ethereum L1 aumentou consideravelmente comEIP-4844 blobs, e várias soluções de escalonamento de EVM estão agora na fase 1. A very implementação heterogênea e pluralista de shardagem, onde cada L2 age como um “shard” com suas próprias regras e lógica interna, é agora uma realidade. Mas, como vimos, seguir este caminho tem desafios únicos. E assim, agora nossa tarefa é concluir o roadmap centrado em rollup e resolver esses problemas, ao mesmo tempo que preservamos a robustez e a descentralização que tornam o Ethereum L1 especial.

A Onda: 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 (confiável, aberto, resistente à censura)
• Máxima interoperabilidade entre L2s. Ethereum deve sentir-se como um ecossistema único, não 34 blockchains diferentes.

Neste capítulo

• Além disso: o trilema da escalabilidade
• Mais progressos na amostragem de disponibilidade de dados
• Compressão de dados
• Plasma Generalizado
• Sistemas de prova L2 em amadurecimento
• Interoperabilidade entre L2 e melhorias de UX
• Escalonamento da execução na L1

Além disso: o trilema da escalabilidade

O trilema da escalabilidade era uma ideiaintroduzido em 2017, que argumentou que há 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 falhar mesmo uma única transação).

De notar que o trilema não é um teorema, e o post que introduz o trilema não veio com uma prova matemática. Deu, de facto, um argumento matemático heurístico: se um nó amigável à descentralização (por exemplo, um portátil de consumidor) pode verificar N transações por segundo, e temos 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 de corromper alguns nós para fazer passar uma transação má, ou (ii) os seus nós terão de ser robustos e a sua cadeia não 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.

Durante muitos anos, tem sido comum que algumas cadeias de alto desempenho afirmem que resolvem o trilema sem fazer nada de inteligente a nível de arquitetura fundamental, normalmente usando truques de engenharia de software para otimizar o nó. Isso é sempre enganador, e executar um nó em tais cadeias acaba sempre sendo muito mais difícil do que no Ethereum.Esta publicaçãoentra em algumas das muitas sutilezas por que isso acontece (e, portanto, por que o próprio engenharia de software do cliente L1 não pode escalar o Ethereum sozinho).

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 passos de computação foi realizado corretamente, enquanto faz o download de 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 tem um caráter sutil modelo de confiança de alguns-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 que blocos inválidos sejam aceites pela rede.

Outra forma de resolver o trilema é através das arquiteturas de Plasma, que utilizam técnicas inteligentes para transferir a responsabilidade de verificar a disponibilidade de dados para o utilizador de uma forma compatível com incentivos. Entre 2017 e 2019, quando tudo o que tínhamos para escalar a computação eram provas de fraude, o Plasma tinha limitações no que podia fazer com segurança, mas a popularização dos SNARKs torna as arquiteturas de Plasma muito mais viávelpara uma gama mais ampla de casos de uso do que antes.

Mais progressos na amostragem de disponibilidade de dados

Que problema estamos a resolver?

A partir de 13 de março de 2024, quando o Atualização DencunDesde que entrou em funcionamento, a blockchain Ethereum tem três "blobs" de cerca de 125 kB por intervalo de 12 segundos, ou cerca de 375 kB por intervalo de largura de banda de disponibilidade de dados. Pressupondo que os dados da transação sejam publicados diretamente na cadeia, uma transferência ERC20 tem cerca de 180 bytes, portanto, a TPS máxima de rollups na 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 o alvo de contagem de blob para 8-16, o que nos daria 463-926 TPS em calldatas.

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 é 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 “partilhas” do polinómio, onde cada partilha consiste em 16 avaliações em 16 coordenadas adjacentes retiradas de um conjunto total de 8192 coordenadas. Qualquer conjunto de 4096 das 8192 avaliações (com os parâmetros propostos atuais: qualquer conjunto de 64 das 128 amostras possíveis) pode recuperar o blob.

PeerDAS funciona tendo cada cliente a ouvir um pequeno número de sub-redes, onde a i-ésima sub-rede transmite a i-ésima amostra de qualquer blob, e adicionalmente solicita blobs em outras sub-redes que necessita, perguntando aos seus pares na rede p2p global (que estariam a ouvir sub-redes diferentes). Uma versão mais conservadora, SubnetDAS, usa apenas o mecanismo de sub-rede, sem a camada adicional de perguntar aos pares. Uma proposta atual é que os nós que participam do sistema de prova de participação usem SubnetDAS e que outros nós (ou seja, "clientes") usem PeerDAS.

Teoricamente, podemos escalar a amostragem 1D bastante longe: se aumentarmos o número máximo de blobs para 256 (assim, 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 a cada nó128 blobs512 bytes por amostra por bloco = 1 MB de largura de banda de dados por slot. Isso está quase dentro da nossa tolerância: é possível, mas significaria que clientes com restrições 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 crypto

É crucial, do ponto de vista computacional, calcular a extensão dos compromissos não requer ter os blobs, portanto, o esquema é fundamentalmente amigável à construção de bloco distribuída. O nó que realmente está construindo o bloco só precisaria ter os compromissos de KZG de blob e pode confiar no DAS para verificar a disponibilidade dos blobs. O DAS é também inerentemente amigável à construção de bloco distribuída.

Quais são alguns links para pesquisas existentes?

• Publicação original apresentando a disponibilidade de dados (2018): https://github.com/ethereum/research/wiki/Uma-nota-sobre-disponibilidade-de-dados-e-codificação-de-eliminação
• Artigo de acompanhamento: https://arxiv.org/abs/1809.09044
• Postagem explicativa 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 em ethresear.ch: https://ethresear.ch/t/peerdas-uma-abordagem-mais-simples-de-das-utilizando-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 recoverability in 2D sampling: https://ethresear.ch/t/nuances-of-data-recoverability-in-data-availability-sampling/16256

O que resta fazer e quais são os compromissos?

O próximo passo imediato é concluir a implementação e lançamento do PeerDAS. A partir daí, é uma luta progressiva para continuar aumentando o número de blobs no PeerDAS, enquanto observamos cuidadosamente a rede e melhoramos o software para garantir a segurança. Ao mesmo tempo, queremos mais trabalho acadêmico na formalização do 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 as suas propriedades de segurança. Também queremos eventualmente migrar do KZG para uma alternativa resistente a quântica, sem configuração confiável. Atualmente, não conhecemos candidatos que sejam amigáveis para a construção de blocos distribuídos. Mesmo a técnica cara de "força bruta" de usar STARKs recursivos para gerar provas de validade para reconstruir linhas e colunas não é suficiente, porque tecnicamente um STARK é do tamanho de O(log(n) * log(log(n)) hashes (comSTIR) Na prática, um STARK é quase tão grande quanto um bloco inteiro.

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

• Implemente o DAS 2D ideal
• Fique com o 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
• (Pivô drástico) abandonar DA e abraçar totalmente o Plasma como uma arquitetura de camada 2 primária na qual estamos focando

Podemos ver esses ao longo de um espectro de trade-off:

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

Como interage com outras partes do roteiro?

A necessidade de 2D DAS é 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 coloca um desafio aos protocolos e mecanismos de construção de blocos distribuídos: embora o DAS seja teoricamente favorável à reconstrução distribuída, isso precisa ser combinado na prática com Lista de inclusãopropostas e suas mecânicas de escolha de fork circundante.

Compressão de dados

Que problema estamos a resolver?

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 limita a escalabilidade dos protocolos de camada 2. Com 16 MB por slot, obtemos:

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 é isto e como funciona?

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

Os ganhos mais simples são apenas compressão de zero byte: substituindo cada sequência longa de zero bytes por dois bytes que representam quantos zero bytes existem. Para ir mais longe, 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 maiores, mas em um ambiente de dados escassos como L2s, eles sem dúvida fazem sentido. O recurso de agregação de ERC-4337apresenta um caminho para implementar isso.
• Substituir endereços por apontadores - se um endereço foi usado anteriormente, podemos substituir o endereço de 20 bytes por um apontador de 4 bytes para uma localização no histórico. Isso é necessário para alcançar os maiores ganhos, embora exija esforço para implementar, porque requer que (pelo menos uma parte) da história da 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 e as taxas de prioridade do gás funcionam de forma semelhante. Assim, podemos representar a maioria dos valores de moeda de forma muito compacta com um formato de ponto flutuante decimal personalizado, ou até 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, da ScopeLift: https://github.com/ScopeLift/l2-optimizoooors
• Uma estratégia alternativa - rollups baseados em provas de validade (também conhecidos como rollups ZK) publicam 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 falta fazer e quais são os compromissos?

A principal coisa que resta fazer é implementar realmente os esquemas acima. Os principais compromissos são:

• Mudar 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 apontadores) 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 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 grandemente 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

Que problema estamos a resolver?

Mesmo com blobs de 16 MB e compressão de dados, 58.000 TPS não é necessariamente suficiente para assumir totalmente os pagamentos dos consumidores, as redes sociais descentralizadas ou outros setores de alta largura de banda, e isso se torna especialmente verdadeiro se começarmos a considerar a privacidade, o que poderia reduzir a escalabilidade em 3-8x. Para aplicações de alto volume e baixo valor, uma opção hoje é validium, que mantém os dados fora da cadeia e tem 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 é isto e como funciona?

O Plasma é uma solução de escalabilidade que envolve um operador a publicar blocos offchain e a colocar 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 a cada utilizador um ramo de Merkle que prova o que aconteceu, ou não aconteceu, com os ativos desse utilizador. Os utilizadores podem levantar os seus ativos fornecendo um ramo de Merkle. Importante, este ramo não tem de estar enraizado no estado mais recente - por esta razão, mesmo que a disponibilidade de dados falhe, o utilizador ainda pode recuperar os seus ativos ao levantar o estado mais recente que têm disponível. Se um utilizador submeter um ramo inválido (por exemplo, sair de um ativo que já enviou para outra pessoa, ou o operador criar um ativo do nada), um mecanismo de desafio onchain pode decidir a quem pertence o ativo legítimamente.

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

As primeiras versões do Plasma apenas conseguiam lidar com o caso de uso de pagamentos e não conseguiam generalizar eficazmente mais além. No entanto, se exigirmos que cada raiz seja verificada com um SNARK, o Plasma torna-se 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 as técnicas do Plasma sejam estendidas a uma classe muito mais geral de ativos. Finalmente, no caso em que o operador não trapaceia, os utilizadores podem retirar os seus fundos instantaneamente, sem precisar de esperar por um período de desafio de uma semana.

Uma forma (não a única forma) de criar uma cadeia de plasma EVM: usar um ZK-SNARK para construir uma árvore paralela UTXO que reflete as alterações de saldo feitas pelo EVM, e define um mapeamento único do que é “a mesma moeda” em diferentes momentos 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, mesmo apenas moedas que não se moveram na última semana), você já melhorou significativamente o status quo do EVM ultra-escalável, que é um validium válido.

Outra classe de construções são os híbridos plasma/rollups, como Intmax. Estas construções colocam uma quantidade muito pequena de dados por utilizador onchain (por exemplo, 5 bytes) e, ao fazê-lo, obtêm propriedades que estão em algum lugar entre plasma e rollups: no caso do Intmax, obtém-se um nível muito elevado de escalabilidade e privacidade, embora mesmo no mundo de 16 MB, a capacidade seja teoricamente limitada a cerca de 16.000.000 / 12 / 5 = 266.667 TPS.

Quais são alguns links para pesquisas existentes?

• Papel Original Plasma: https://plasma.io/plasma-deprecated.pdf
• Plasma Cash: https://ethresear.ch/t/plasma-cash-plasma-with-much-less-per-user-data-checking/1298
• Fluxo de Caixa da Plasma: https://hackmd.io/DgzmJIRjSzCYvl4lUjZXNQ?view#🚪-Exit
• Intmax (2023): https://eprint.iacr.org/2023/1082

O que resta a fazer e quais são os compromissos?

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

O principal compromisso 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 possam frequentemente evitar essa fraqueza.

Como 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 atividade para L2 também reduz a pressão do MEV no L1.

Sistemas de prova L2 em maturação

Que problema estamos a resolver?

Atualmente, 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 de validade)sistema de prova. Em alguns casos, o sistema de prova nem sequer está ativo, ou se estiver, tem apenas uma funcionalidade de “advisory”. 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, o Optimism e o Arbitrum, dois rollups completos da EVM que alcançaram um marco de parcial sem confiança conhecido como “stage 1”. A razão pela qual os rollups não foram mais longe é a preocupação com bugs no código. Precisamos de rollups sem confiança, e, portanto, precisamos enfrentar esse problema de frente.

O que é isto e como funciona?

Primeiro, vamos recapitular o sistema de “palco”, originalmente introduzido emesta publicação. Existem requisitos mais detalhados, mas o resumo é:

• Fase 0: deve ser possível para um usuário executar um nó e sincronizar a cadeia. Está tudo bem se a validação for totalmente confiável/centralizada.
• Fase 1: deve existir um sistema de prova (sem confiança) que garanta que apenas transações válidas sejam aceites. É permitido que exista um conselho de segurança que possa anular o sistema de prova, mas apenas com um voto de limiar de 75%. Além disso, uma parte do conselho que bloqueia o quórum (ou seja, 26%+) deve estar fora do edifício principal da empresa que está a construir o rollup. Um mecanismo de atualização com funcionalidades mais fracas (por exemplo, um DAO) é permitido, mas deve ter um atraso suficientemente longo para que, se aprovar uma atualização maliciosa, os utilizadores possam retirar os seus fundos antes de esta ficar disponível.
• Estágio 2: deve haver um sistema de prova (sem confiança) que garanta que apenas transações válidas sejam aceites. Os conselhos de segurança só podem intervir no caso de erros prováveis no código, por exemplo, se dois sistemas de prova redundantes discordarem entre si ou se um sistema de prova aceitar duas raízes de pós-estado diferentes para o mesmo bloco (ou não aceitar 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 é alcançar o Estágio 2. O principal desafio em alcançar o estágio 2 é obter confiança suficiente de que o sistema de prova realmente é confiável o suficiente. 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 passam na especificação do EVM. Essas técnicas existem há décadas, mas avanços recentes como Lean 4 tornaram-nos muito mais práticos, e os avanços na prova assistida por IA podem potencialmente acelerar ainda mais esta tendência.
• Multi-provadores: faça vários sistemas de prova e coloque fundos em um multisig 2-de-3 (ou maior) entre esses sistemas de prova e um conselho de segurança (e/ou outro gadget com pressupostos de confiança, por exemplo. ETEs). Se os sistemas de prova concordarem, o conselho de segurança não tem poder; Se discordarem, o Conselho de Segurança só pode escolher entre um deles, não pode impor unilateralmente a sua própria resposta.

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

Quais são alguns links para pesquisas existentes?

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

O que resta fazer e quais são os compromissos?

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 que já começamos. Existe um truque que simplifica significativamente a tarefa: podemos fazer um verificador SNARK formalmente verificado de uma VM mínima, por exemplo. RISC-VouCairo, e depois escrever uma implementação do EVM nesse VM mínimo (e provar formalmente sua equivalência a alguma outra especificação EVM).

Para multi-provadores, há duas peças principais restantes. Primeiro, precisamos ter confiança suficiente em pelo menos dois sistemas de prova diferentes, ambos de que eles são razoavelmente seguros individualmente e que, se quebrarem, quebrariam por razões diferentes e não relacionadas (e, portanto, não quebrariam ao mesmo tempo). Em segundo lugar, precisamos de obter um nível muito elevado de garantia na lógica subjacente que funde os sistemas de prova. Este é um pedaço de código muito menor. Há maneiras de torná-lo extremamente pequeno - basta armazenar fundos em um Contrato multisig segurocujo signatários são contratos que representam sistemas de prova individuais - mas isso tem o compromisso de custos elevados de gás onchain. Será necessário encontrar um equilíbrio entre eficiência e segurança.

Como interage com outras partes do roteiro?

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

Melhorias na interoperabilidade entre L2

Que problema estamos a resolver?

Um dos principais desafios do ecossistema L2 hoje é que é difícil para os usuários navegar. Além disso, os métodos mais fáceis de fazer isso frequentemente reintroduzem suposições de confiança: pontes centralizadas, clientes RPC, e assim por diante. Se estamos realmente comprometidos com a ideia de que os L2s fazem parte do Ethereum, precisamos fazer com que usar o ecossistema L2 pareça estar a usar um ecossistema Ethereum unificado.

Um exemplo de uma experiência de utilizador transversalmente L2 patologicamente má (e até perigosa: pessoalmente perdi $100 devido a um erro de seleção de cadeia aqui) - embora não seja culpa da Polymarket, a interoperabilidade transversal L2 deve ser da responsabilidade das carteiras e da comunidade de padrões Ethereum (ERC). Num ecossistema Ethereum bem funcional, enviar moedas de L1 para L2, ou de um L2 para outro, deve sentir-se exatamente como enviar moedas dentro do mesmo L1.

O que é e como funciona?

Existem muitas categorias de melhorias de interoperabilidade cruzada-L2. Em geral, a maneira de chegar a isso é perceber que, teoricamente,um Ethereum centrado em rollup é a mesma coisa que shard de execução L1, e depois perguntar onde o atual L2-verse do Ethereum deixa a desejar 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 apenas 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.
• Pedidos de pagamento específicos da cadeia: deve ser fácil e padronizado fazer uma mensagem do tipo "envie-me 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) dapps solicitando fundos, por exemplo, o exemplo da Polymarket acima.
• Trocas 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, eRIP-7755 é uma tentativa desta última, embora ambas sejam também mais gerais do que apenas estes casos de uso específicos.
• Clientes leves: os usuários devem ser capazes de verificar realmente as cadeias com as quais estão interagindo e não apenas confiar nos provedores RPC. A cripto da A16z Heliosfaz isso para o próprio Ethereum, mas precisamos estender essa ausência de confiança para as L2s.ERC-3668 (CCIP-leia)é uma estratégia para fazer isto.

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ê tenha os objetos de estado corretos de L1, você pode usar provas de Merkle (e possivelmente assinaturas, se 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.

• Carteiras de armazenamento seguro: hoje, se quiser atualizar as chaves que controlam a sua carteira de contrato inteligente, terá de o fazer em todas as N cadeias em que essa carteira existe. As carteiras de armazenamento seguro são uma técnica que permite que as chaves existam num único local (seja na L1, ou mais tarde potencialmente numa L2), e depois sejam lidas a partir de qualquer L2 que tenha uma cópia da carteira. Isto significa que as atualizações só precisam de acontecer uma vez. Para ser eficiente, as carteiras de armazenamento seguro requerem que as L2 tenham uma forma padronizada de ler sem custos a L1; duas propostas para isto são L1SLOADeREMOTESTATICCALL.

Um diagrama estilizado de como funcionam as carteiras de keystore.

• Mais ideias radicais de "ponte de tokens compartilhados": imagine um mundo onde todos os L2s são rollups de prova de validade, que se comprometem com o Ethereum em cada slot. Mesmo neste mundo, mover ativos de um L2 para outro L2 "nativamente" exigiria saque e depósito, 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 L2 iniciadas por qualquer um dos L2s. Isso permitiria transferências entre L2s acontecerem sem a necessidade de pagar gás L1 por transferência, e sem a necessidade de técnicas baseadas em provedores de liquidez como o ERC-7683.
• Composabilidade síncrona: permite que chamadas síncronas ocorram entre um L2 específico e um L1, ou entre vários L2s. Isso poderia ser útil para melhorar a eficiência financeira dos protocolos DeFi. O primeiro poderia ser feito sem qualquer coordenação entre L2s; o último exigiriasequenciamento compartilhado. Rollups baseadossão automaticamente amigáveis a todas estas 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 keystore de rolagem: @haichen/keystore"">https://hackmd.io/@haichen/keystore
• Hélio: https://github.com/a16z/helios
• ERC-3668 (por vezes chamado de CCIP-read): https://eips.ethereum.org/EIPS/eip-3668
• Proposta de “pré-confirmações baseadas (partilhadas)” por Justin Drake: https://ethresear.ch/t/based-preconfirmations/17353
• L1SLOAD (RIP-7728): https://ethereum-magicians.org/t/rip-7728-l1sload-precompile/20388
• REMOTESTATICCALL em 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 fazer e quais são os compromissos?

Muitos dos exemplos acima enfrentam dilemas padrão de quando padronizar e em que camadas padronizar. Se você padronizar muito cedo, corre o risco de enraizar 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 com propriedades mais fracas, mas mais fácil de implementar, quanto uma solução de longo prazo que é "ultimamente correta", mas levará alguns anos para chegar lá.

Uma forma pela qual esta secção é única, é que estas tarefas não são apenas problemas técnicos: são também (talvez até principalmente!) problemas sociais. Requerem que as L2s e as carteiras e as L1 cooperem. A nossa capacidade de lidar com este problema com sucesso é um teste à nossa capacidade de permanecer unidos como comunidade.

Como 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 de L1. Uma exceção é o sequenciamento compartilhado, que tem impactos pesados no MEV.

Escalonamento da execução na L1

Que problema estamos a resolver?

Se as L2 se tornarem muito escaláveis e bem-sucedidas, mas a 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 torna-se mais arriscada, o que por sua vez afeta a segurança a longo prazo da rede.
2. Muitos L2s beneficiam por estarem intimamente ligados a um ecossistema financeiro altamente desenvolvido no L1 e, se este 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 L2 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 utilizadores ainda precisariam de passar pelo L1 para recuperar os seus ativos. Portanto, o L1 precisa de ser suficientemente poderoso para ser capaz de lidar pelo menos ocasionalmente com um encerramento altamente complexo e caótico de um L2.

Por estas razões, é valioso continuar a escalonar o L1 em si mesmo e garantir que ele possa continuar a acomodar um número crescente de usos.

O que é isto e como funciona?

A maneira mais fácil de dimensionar é simplesmente aumentar o limite de gás. No entanto, isso arrisca centralizar o L1 e, assim, enfraquecer a outra propriedade importante que torna o Ethereum L1 tão poderoso: sua credibilidade como uma camada base robusta. Existe um debate em curso sobre qual o 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 L1 EVM). Outra coisa importante a melhorar é simplesmente a eficiência do software cliente Ethereum, que hoje está muito mais otimizado do que há cinco anos. Uma estratégia eficaz de aumento do limite de gás L1 envolveria acelerar essas tecnologias de verificação.

Outra estratégia de dimensionamento envolve identificar características específicas e tipos de computação que podem ser tornados mais baratos 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 para análise estática, permitindo implementações mais rápidas. O bytecode EOF poderia ter custos de gás mais baixos para levar em conta essas eficiências.
• Preços de gás multidimensionais- estabelecer taxas 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, temos tidovários rodadasdeaumentandogascustospara 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 estão com preços altos. 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 o ADD mais barato e até mesmo opcodes mais simples como PUSH ainda mais baratos.
• EVM-MAXeSIMD: EVM-MAX (``extensões aritméticas modulares'') é uma proposta para permitir matemática modular com números grandes nativos mais eficiente como um módulo separado do EVM. Os valores calculados pelas computações EVM-MAX só seriam acessíveis por outras operações EVM-MAX, a menos que exportados deliberadamente; 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 num conjunto de valores. Os dois juntos podem criar um poderoso coprocessorao lado do 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, por isso ajudaria tanto na escalabilidade L1 como na L2.

Estas melhorias serão discutidas com mais detalhes numa futura publicação sobre o Splurge.

Finalmente, uma terceira estratégia são 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 nativamente no protocolo.

Quais são alguns links para pesquisas existentes?

• O roteiro de escalonamento 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 escalonamento: https://www.reddit.com/r/ethereum/comments/1f81ntr/comment/llmfi28/

O que falta fazer e quais são os compromissos?

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

• Melhorar a tecnologia (por exemplo, código do cliente, clientes sem estado, expiração de histórico) para facilitar a verificação do L1 e depois aumentar o limite de gás
• Tornar operações específicas mais baratas, aumentando a capacidade média sem aumentar os riscos no pior cenário
• Rollups nativos (ou seja, “criar N cópias paralelas do EVM”, embora potencialmente concedendo aos desenvolvedores muita flexibilidade nos parâmetros das cópias que implantam)

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

Uma grande questão que qualquer roteiro de escalonamento L1 precisa responder é: qual é a visão final do que pertence ao L1 e do que pertence ao L2? Claramente, é absurdo que tudo vá para o L1: os casos de uso potenciais chegam a centenas de milhares de transações por segundo, e isso tornaria o L1 completamente inviável de verificar (a menos que sigamos a rota nativa de rollup). Mas precisamos de algum princípio orientador, para garantir que não estamos criando uma situação em que aumentamos o limite de gás em 10 vezes, danificamos gravemente a descentralização do Ethereum L1 e descobrimos que apenas chegamos a um mundo onde, em vez de 99% da atividade estar no L2, 90% da atividade está no L2, e assim o resultado parece quase o mesmo, exceto por uma perda irreversível de grande parte do que torna o Ethereum L1 especial.

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

Como interage com outras partes do roteiro?

Trazer mais utilizadores para L1 implica não só melhorar a escala, mas também outros aspetos de L1. Significa que mais MEV permanecerá em L1 (em vez de se tornar um problema apenas para L2s) e, portanto, será ainda mais urgente lidar com isso de forma explícita. Aumenta significativamente o valor de ter tempos de slot rápidos em L1. E também depende fortemente da verificação de L1 ("a Verge") correr bem.

Aviso legal：

1. Este artigo foi reproduzido a partir de [ Vitalik Buterin], Todos os direitos de autor pertencem ao autor original [Vitalik Buterin]. Se houver objeções a esta reimpressão, entre em contato com o Gate Aprenderequipa e eles vão tratar disso prontamente.
2. Isenção de Responsabilidade: Os pontos de vista e opiniões expressos 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 Gate Learn. Salvo indicação em contrário, copiar, distribuir ou plagiar os artigos traduzidos é proibido.