Um dos pontos que eu mencionei no meu post há dois anos e meio em "o Endgame"é que os diferentes caminhos de desenvolvimento futuro para uma blockchain, pelo menos tecnologicamente, parecem surpreendentemente semelhantes. Em ambos os casos, você tem um número muito grande de transações onchain, e processá-las requer (i) uma grande quantidade de computação e (ii) uma grande quantidade de largura de banda de dados. Nós regulares do Ethereum, como os 2 TB nó de arquivo rethrodando no laptop que estou usando para escrever este artigo, não são poderosos o suficiente para verificar uma quantidade tão grande de dados e cálculos diretamente, mesmo com um trabalho heróico de engenharia de software e Verkle árvores. Em vez disso, tanto no "L1 sharding" quanto em um rollup-centricmundo, ZK-SNARKssão usados para verificar a computação eDASpara verificar a disponibilidade de dados. O DAS em ambos os casos é o mesmo. Os ZK-SNARKs em ambos os casos são a mesma tecnologia, exceto em um caso em que são código de contrato inteligente e, no outro caso, são um recurso consagrado do protocolo. Em um sentido técnico muito real, o Ethereum está fazendo shardagem, e rollups são shards.

Isso levanta uma questão natural: qual é a diferença entre esses dois mundos? Uma resposta é que as consequências dos bugs de código são diferentes: em um mundo de rollup, as moedas se perdem e em um mundo de cadeia de fragmentos, você tem falhas de consenso. Mas espero que, à medida que os protocolos se solidificam e a tecnologia de verificação formal melhora, a importância dos bugs diminuirá. Então, quais são as diferenças entre as duas visões que podemos esperar que permaneçam a longo prazo?

Diversidade de ambientes de execução

Uma das ideias com as quais brincamos brevemente no Ethereum em 2019 foi ambientes de execuçãoEssencialmente, o Ethereum teria diferentes “zonas” que poderiam ter regras diferentes para o funcionamento das contas (incluindo abordagens totalmente diferentes como UTXOs), como a máquina virtual funciona e outros recursos. Isso permitiria uma diversidade de abordagens em partes da pilha onde seria difícil de alcançar se o Ethereum tentasse fazer tudo sozinho.

No final, acabamos por abandonar alguns dos planos mais ambiciosos e simplesmente mantivemos o EVM. No entanto, as L2s do Ethereum (incluindo rollups, valdiums e Plasmas) acabaram servindo o papel de ambientes de execução. Hoje, geralmente nos concentramos em L2s equivalentes ao EVM, mas isso ignora a diversidade de muitas abordagens alternativas:

• Arbitrum Stylus, que adiciona uma segunda máquina virtual com base emWASMao lado do EVM.
• Combustível, que utiliza uma arquitetura baseada em UTXO semelhante ao Bitcoin (mas mais completa em recursos).
• Azteca, que introduz uma nova linguagem e paradigma de programação projetado em torno de contratos inteligentes de preservação de privacidade baseados em ZK-SNARK.

Arquitetura baseada em UTXO. Fonte: documentação do Fuel.

Poderíamos tentar transformar o EVM em um super-VM que abrange todos os paradigmas possíveis, mas isso teria levado a implementações muito menos eficazes de cada um desses conceitos do que permitir que plataformas como essas se especializassem.

Trade-offs de segurança: escala e velocidade

Ethereum L1 fornece uma garantia de segurança muito forte. Se algum dado estiver dentro de um bloco que é finalizado no L1, todo o consenso (incluindo, em situações extremas, o consenso social) trabalha para garantir que os dados não serão editados de forma que vá contra as regras da aplicação que colocou esses dados lá, que qualquer execução acionada pelos dados não será revertida, e que os dados permanecerão acessíveis. Para alcançar essas garantias, o Ethereum L1 está disposto a aceitar altos custos. No momento desta escrita, as taxas de transação são relativamente baixas: camadas 2 cobram menos de um centavopor transação, e até mesmo a L1 está abaixo de $1 para uma transferência básica de ETH. Esses custos podem permanecer baixos no futuro se a tecnologia melhorar rápido o suficiente para que o espaço de bloco disponível aumente para acompanhar a demanda - mas pode não. E mesmo $0.01 por transação é muito alto para muitas aplicações não financeiras, por exemplo, mídias sociais ou jogos.

Mas as redes sociais e os jogos não requerem o mesmo modelo de segurança que o L1. Está tudo bem se alguém puder pagar um milhão de dólares para reverter um registro deles perdendo um jogo de xadrez, ou fazer com que uma de suas postagens no Twitter pareça ter sido publicada três dias depois do que realmente foi. E, portanto, essas aplicações não devem ter que pagar pelos mesmos custos de segurança. Uma abordagem centrada no L2 permite isso, apoiando um espectro de abordagens de disponibilidade de dados a partirrollupsparaplasmaparavalidiums.

Diferentes tipos de L2 para diferentes casos de uso. Leia maisaqui.

Outra compensação de segurança surge em torno da questão de transferir ativos de L2 para L2. No limite (5-10 anos no futuro), espero que todos os rollups sejam rollups ZK e sistemas de prova hiper eficientes como Binius e Círculo STARKscompesquisas, mais camadas de agregação de prova, tornará possível para as L2s fornecer raízes de estado finalizadas em cada slot. Por enquanto, no entanto, temos uma mistura complicada de rollups otimistas e rollups ZK com várias janelas de tempo de prova. Se tivéssemos implementado o shard de execução em 2021, o modelo de segurança para manter os shards honestos teria sido rollups otimistas, não ZK - e assim o L1 teria que gerenciar o complexo sistemicamentelógica à prova de fraude on-chain e ter um período de retirada de uma semana para mover ativos de shard para shard. Mas assim como bugs de código, acredito que esse problema é, em última instância, temporário.

Uma terceira, e mais uma vez mais duradoura, dimensão de troca de segurança é a velocidade da transação. O Ethereum tem blocos a cada 12 segundos e não está disposto a ser muito mais rápido, pois isso centralizaria demais a rede. No entanto, muitos L2s estão explorando tempos de bloco de alguns centenas de milissegundos. 12 segundos já não é tão ruim: em média, um usuário que envia uma transação precisa esperar ~6-7 segundos para ser incluído em um bloco (não apenas 6 por causa da possibilidade de que o próximo bloco não os inclua). Isso é comparável ao que tenho que esperar ao fazer um pagamento no meu cartão de crédito. Mas muitos aplicativos exigem uma velocidade muito maior, e os L2s a fornecem.

Para fornecer essa velocidade mais alta, os L2s dependem de mecanismos de pré-confirmação: os validadores próprios do L2 assinam digitalmente uma promessa de incluir a transação em um horário específico e, se a transação não for incluída, podem ser penalizados. Um mecanismo chamado StakeSuregeneraliza isso ainda mais.

Pré-confirmações L2.

Agora, poderíamos tentar fazer tudo isso na camada 1. A camada 1 poderia incorporar um sistema de “pré-confirmação rápida” e “confirmação final lenta”. Poderia incorporar diferentes fragmentos com diferentes níveis de segurança. No entanto, isso adicionaria muita complexidade ao protocolo. Além disso, fazer tudo na camada 1 correriasobrecarregando o consenso, porque muitas das abordagens de maior escala ou maior throughput têm riscos mais elevados de centralização ou exigem formas mais fortes de 'governança', e se feito no L1, os efeitos dessas demandas mais fortes transbordariam para o restante do protocolo. Ao oferecer esses trade-offs por meio da camada 2, o Ethereum pode evitar em sua maioria esses riscos.

Os benefícios da camada 2 na organização e na cultura

Imagine que um país seja dividido ao meio, e uma metade se torne capitalista e a outra se torne altamente conduzida pelo governo (diferente de quando isso aconteceemrealidade, suponha que neste experimento mental não seja o resultado de nenhum tipo de guerra traumática; em vez disso, um dia uma fronteira magicamente se ergue e é isso). Na parte capitalista, os restaurantes são todos administrados por várias combinações de propriedade descentralizada, cadeias e franquias. Na parte governamental, são todos filiais do governo, como postos policiais. No primeiro dia, não muita coisa mudaria. As pessoas seguem em grande parte seus hábitos existentes, e o que funciona e o que não funciona depende de realidades técnicas como habilidade de trabalho e infraestrutura. Um ano depois, no entanto, você esperaria ver grandes mudanças, porque as diferentes estruturas de incentivos e controle levam a grandes mudanças de comportamento, o que afeta quem vem, quem fica e quem vai embora, o que é construído, o que é mantido e o que é deixado para apodrecer.

Organização industriala teoria abrange muitas dessas distinções: fala sobre as diferenças não apenas entre uma economia governamental e uma economia capitalista, mas também entre uma economia dominada por grandes franquias e uma economia onde, por exemplo, cada supermercado é administrado por um empreendedor independente. Eu argumentaria que a diferença entre um ecossistema centrado na camada 1 e um ecossistema centrado na camada 2 segue linhas semelhantes.

Uma arquitetura de "os desenvolvedores principais controlam tudo" que deu muito errado.

Eu expressaria o principal benefício para o Ethereum de ser um ecossistema centrado na camada 2 da seguinte forma:

Porque o Ethereum é um ecossistema centrado na camada 2, você está livre para construir independentemente um subecossistema que seja seu com suas características exclusivas e, ao mesmo tempo, faça parte de um Ethereum maior.

Se você está apenas construindo um cliente Ethereum, você faz parte de um Ethereum maior, e embora tenha algum espaço para criatividade, é muito menor do que o disponível para as L2s. E se você estiver construindo uma cadeia completamente independente, terá o máximo de espaço para criatividade, mas perderá os benefícios como segurança compartilhada e efeitos de rede compartilhados. As L2s formam um meio-termo feliz.

As camadas 2 não apenas criam uma oportunidade técnica para experimentar novos ambientes de execução e compensações de segurança para alcançar escala, flexibilidade e velocidade: elas também criam um incentivo para: tanto para os desenvolvedores construírem e manterem isso, quanto para a comunidade se formar ao redor e apoiá-lo.

O fato de que cada L2 é isolado também significa que implantar novas abordagens é sem permissão: não há necessidade de convencer todos os desenvolvedores principais de que sua nova abordagem é "segura" para o resto da cadeia. Se o seu L2 falhar, a responsabilidade é sua. Qualquer um pode trabalhar em ideias totalmente estranhas (por exemplo,Abordagem da Intmax ao Plasma) e mesmo que sejam completamente ignorados pelos desenvolvedores principais do Ethereum, eles podem continuar construindo e eventualmente implantando. Recursos da L1 e pré-cálculos não são assim, e mesmo no Ethereum, o que tem sucesso e o que falha no desenvolvimento da L1 muitas vezes acaba dependendo da política em um grau maior do que gostaríamos. Independentemente do que teoricamente poderia ser construído, os incentivos distintos criados por um ecossistema centrado na L1 e um ecossistema centrado na L2 acabam influenciando fortemente o que é construído na prática, com que nível de qualidade e em que ordem.

Quais desafios o ecossistema centrado na camada 2 do Ethereum enfrenta?

Uma arquitetura de camada 1 + camada 2 que deu muito errado.Fonte.

Há um desafio-chave para este tipo de abordagem centrada na camada 2, e é um problema que os ecossistemas centrados na camada 1 não têm que enfrentar em quase a mesma extensão: coordenação. Em outras palavras, enquanto o Ethereum se ramifica, o desafio está em preservar a propriedade fundamental de que ainda parece tudo como "Ethereum", e tem os efeitos de rede de ser Ethereum em vez de ser N cadeias separadas. Hoje, a situação é subótima de várias maneiras:

• Transferir tokens de uma camada 2 para outra frequentemente requer plataformas de ponte centralizadas e é complicado para o usuário médio. Se você tem moedas na Optimism, não pode simplesmente colar o endereço do Arbitrum de alguém em sua carteira e enviar fundos para eles.
• O suporte para carteira de contratos inteligentes entre cadeias não é ótimo - tanto para carteiras de contratos inteligentes pessoais quanto para carteiras organizacionais (incluindo DAOs). Se você alterar sua chave em uma L2, também precisará alterar sua chave em todas as outras L2.
• A infraestrutura de validação descentralizada frequentemente é deficiente. O Ethereum finalmente está começando a ter clientes leves decentes, como HeliosNo entanto, não há ponto nisso se a atividade estiver acontecendo em camadas 2 que exigem seus próprios RPCs centralizados. Em princípio, uma vez que você tenha a cadeia de cabeçalhos do Ethereum, fazer clientes leves para L2s não é difícil; na prática, há muito pouca ênfase nisso.

Existem esforços trabalhando para melhorar todos os três. Para a troca de tokens entre cadeias, o ERC-7683 O padrão é uma opção emergente e, ao contrário das "pontes centralizadas" existentes, não tem nenhum operador central, token ou governança consagrados. Para contas cross-chain, a abordagem que a maioria das carteiras está adotando é usar mensagens rejogáveis cross-chain para atualizar chaves a curto prazo, e agrupamentos de keystore a longo prazo. Clientes leves para L2s estão começando a surgir, por exemplo. Beeruspara Starknet. Além disso, melhorias recentes na experiência do usuário por meio de carteiras de próxima geração já resolveram problemas muito mais básicos, como remover a necessidade de os usuários alternarem manualmente para a rede correta para acessar um dapp.

Rabby mostrando uma visão integrada dos saldos de ativos em várias cadeias. Nos não tão distantes e sombrios dias antigos, as carteiras não faziam isso!

Mas é importante reconhecer que os ecossistemas centrados na camada 2 nadam um pouco contra a corrente ao tentar coordenar. As camadas 2 individuais não têm um incentivo econômico natural para construir a infraestrutura de coordenação: as pequenas não o fazem, porque veriam apenas uma pequena parte do benefício de suas contribuições, e as grandes não o fazem, porque se beneficiariam tanto ou mais ao fortalecer seus próprios efeitos de rede locais. Se cada camada 2 estiver otimizando separadamente sua peça individual, e ninguém estiver pensando em como cada peça se encaixa no todo maior, teremos falhas como a distopia urbanística na imagem alguns parágrafos acima.

Não afirmo ter soluções mágicas perfeitas para este problema. O melhor que posso dizer é que o ecossistema precisa reconhecer mais plenamente que a infraestrutura cross-L2 é um tipo de infraestrutura Ethereum, ao lado de clientes L1, ferramentas de desenvolvimento e linguagens de programação, e deve ser valorizada e financiada como tal. Temos Protocol Guild; talvez precisemos da Basic Infrastructure Guild.

Conclusões

"Layer 2s" e "sharding" muitas vezes são descritos no discurso público como sendo duas estratégias opostas de como dimensionar um blockchain. Mas quando você olha para a tecnologia subjacente, há um quebra-cabeça: as abordagens subjacentes reais para dimensionamento são exatamente as mesmas. Você tem algum tipo de fragmentação de dados. Você tem provadores de fraudes ou provadores de ZK-SNARK. Você tem soluções para comunicação entre {rollup, shard}. A principal diferença é: quem é responsável por construir e atualizar essas peças, e quanto de autonomia eles têm?

Um ecossistema centrado na camada 2 está fragmentando em um sentido técnico muito real, mas é uma fragmentação onde você pode criar sua própria partição com suas próprias regras. Isso é poderoso e permite muita criatividade e inovação independente. Mas também tem desafios-chave, especialmente em torno da coordenação. Para um ecossistema centrado na camada 2 como o Ethereum ter sucesso, ele precisa entender esses desafios e enfrentá-los de frente, a fim de obter o máximo dos benefícios dos ecossistemas centrados na camada 1, e chegar o mais perto possível de ter o melhor dos dois mundos.

Aviso legal:

1. Este artigo é republicado de [Gatevitalik], Encaminhe o Título Original 'Como as camadas 2 realmente diferem do sharding de execução?', Se houver objeções a esta reediçã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 Gate Learn. A menos que seja mencionado, copiar, distribuir ou plagiar os artigos traduzidos é proibido.