Um dos pontos que eu fiz 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 on-chain 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 retha correr no computador que estou a usar para escrever este artigo, não são suficientemente poderosos para verificar uma quantidade tão grande de dados e cálculos diretamente, mesmo com um trabalho heróico de engenharia de software eVerkle árvoresEm vez disso, tanto no “L1 sharding” como em umrollup-centricmundo, ZK-SNARKssão usados para verificar cálculos e DASpara 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 em outro caso em que são uma característica consagrada do protocolo. Num sentido técnico muito real, Ethereum está fazendo shardagem, e os rollups são shards.

Isto levanta uma questão natural: qual é a diferença entre estes dois mundos? Uma resposta é que as consequências dos bugs de código são diferentes: num mundo de rollup, as moedas são perdidas, e num mundo de cadeia de fragmentos, existem falhas de consenso. Mas espero que, à medida que os protocolos se solidifiquem e à medida que a tecnologia de verificação formal melhore, a importância dos bugs diminuirá. Então, quais são as diferenças entre as duas visões que podemos esperar que se mantenham a longo prazo?

Diversidade de ambientes de execução

Uma das ideias com que brincámos 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 completamente diferentes como UTXOs), para o funcionamento da máquina virtual e outras funcionalidades. Isso permitiria uma diversidade de abordagens em partes do sistema em que 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 da Ethereum (incluindo rollups, valdiums e Plasmas) acabaram por servir o papel de ambientes de execução. Hoje, geralmente focamo-nos em L2s equivalentes ao EVM, mas isso ignora a diversidade de muitas abordagens alternativas:

• Arbitrum Stylus, que adiciona uma segunda máquina virtual baseada emWASMao lado do EVM.
• Combustível, que utiliza uma arquitetura baseada em UTXO semelhante ao Bitcoin (mas mais completa em recursos).
• Asteca, 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 numa 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 estas se especializem.

Trade-offs de segurança: escala e velocidade

A Ethereum L1 fornece uma garantia de segurança muito forte. Se algum dado estiver dentro de um bloco que está finalizado no L1, todo o consenso (incluindo, em situações extremas, o consenso social) trabalha para garantir que os dados não sejam editados de forma contrária às regras da aplicação que colocou esses dados lá, que qualquer execução desencadeada pelos dados não seja revertida e que os dados permaneçam acessíveis. Para alcançar essas garantias, a Ethereum L1 está disposta a aceitar custos elevados. No momento da redação deste texto, as taxas de transação são relativamente baixas: A camada 2 carrega menos de um centavopor transação, e até mesmo o L1 está abaixo de $1 para uma transferência básica de ETH. Estes custos podem permanecer baixos no futuro se a tecnologia melhorar rápido o suficiente para que o espaço de bloco disponível cresça para acompanhar a demanda - mas podem não. E até $0.01 por transação é muito alto para muitas aplicações não financeiras, por exemplo, redes 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 registo de ter perdido um jogo de xadrez, ou fazer com que um dos seus posts no Twitter pareça ter sido publicado três dias depois do que realmente foi. E assim, essas aplicações não devem ter de pagar os mesmos custos de segurança. Uma abordagem centrada no L2 permite isso, ao apoiar 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 passar 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 comoBiniuseCírculo STARKscomconsultas, mais camadas de agregação de prova, tornará possível que os L2s forneçam 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 sistematicamentelógica à prova de fraude on-chain e tem um período de retirada de uma semana para mover ativos de shard para shard. Mas, como erros de código, acho que este problema é, em última análise, temporário.

Uma terceira, e mais uma vez mais duradoura, dimensão do trade-off de segurança é a velocidade da transação. Ethereum tem blocos a cada 12 segundos e não está disposto a ficar muito mais rápido, porque isso centralizaria demais a rede. Muitos L2s, no entanto, estão a explorar tempos de bloco de alguns centésimos de segundo. 12 segundos já não é assim tão mau: em média, um utilizador que submete uma transação precisa de esperar ~6-7 segundos para ser incluído num bloco (não apenas 6 devido à possibilidade de o próximo bloco não os incluir). Isto é comparável ao que tenho de esperar quando faço um pagamento com o meu cartão de crédito. Mas muitas aplicações exigem uma velocidade muito maior, e os L2s fornecem-na.

Para fornecer esta maior velocidade, os L2s dependem de mecanismos de pré-confirmação: os validadores próprios do L2 assinam digitalmente uma promessa de incluir a transação num momento específico e, caso a transação não seja incluída, podem ser penalizados. Um mecanismo chamado StakeSuregeneraliza isso ainda mais.

L2 preconfirmations.

Agora, poderíamos tentar fazer tudo isso na camada 1. A camada 1 poderia incorporar um sistema de "pré-confirmação rápida" e de "confirmação final lenta". Poderia incorporar diferentes fragmentos com diferentes níveis de segurança. No entanto, isso acrescentaria muita complexidade ao protocolo. Além disso, fazer tudo isso na camada 1 seria arriscado sobrecarregando o consenso, porque muitas das abordagens de maior escala ou maior throughput têm maiores riscos 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 resto do protocolo. Ao oferecer esses compromissos através da camada 2, a Ethereum pode evitar principalmente esses riscos.

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

Imagina que um país é dividido ao meio, e uma metade se torna capitalista e a outra se torna altamente orientada pelo governo (ao contrário do queisto aconteceemrealidade, suponha que neste experimento mental não seja resultado de nenhum tipo de guerra traumática; antes, um dia, uma fronteira magicamente é erguida 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 estações de polícia. No primeiro dia, não mudaria muito. 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, seria de esperar ver grandes mudanças, porque as estruturas diferentes de incentivos e controle levam a grandes mudanças de comportamento, o que afeta quem vem, quem fica e quem sai, o que é construído, o que é mantido e o que é deixado ao abandono.

organização industriala teoria abrange muitas dessas distinções: fala não apenas das diferenças entre uma economia controlada pelo governo e uma economia capitalista, mas também entre uma economia dominada por grandes franquias e uma economia em que, 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 correu muito mal.

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

Porque a Ethereum é um ecossistema centrado na camada 2, você está livre para construir independentemente um subecossistema que é seu com suas características únicas, e ao mesmo tempo faz parte de uma Ethereum maior.

Se estiver a construir apenas um cliente Ethereum, 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 estiver a construir uma cadeia completamente independente, tem espaço máximo para criatividade, mas perde os benefícios como segurança partilhada e efeitos de rede partilhados. As L2s formam um meio-termo feliz.

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

O facto de cada L2 estar isolado significa também que implementar novas abordagens é livre de permissões: não é necessário convencer todos os principais devs de que a sua nova abordagem é 'segura' para o resto da cadeia. Se o seu L2 falhar, a responsabilidade é sua. Qualquer pessoa pode trabalhar em ideias totalmente estranhas (por exemplo, A abordagem da Intmax ao Plasma), e mesmo que sejam completamente ignorados pelos desenvolvedores principais do Ethereum, eles podem continuar a construir e eventualmente implementar. As funcionalidades e precompiles da L1 não são assim, e mesmo no Ethereum, o que tem sucesso e o que falha no desenvolvimento da L1 acaba muitas vezes dependendo mais da política 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.

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

Uma arquitetura de camada 1 + camada 2 que correu muito mal.Origem.

Existe 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 de enfrentar até quase ao mesmo nível: a 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 em muitos aspectos:

• Mover tokens de uma camada 2 para outra requer frequentemente plataformas de ponte centralizadas e é complicado para o utilizador comum. Se tiver moedas na Optimism, não pode simplesmente colar o endereço do Arbitrum de alguém na sua carteira e enviar-lhes fundos.
• O suporte para carteiras de contratos inteligentes entre cadeias não é ótimo - tanto para carteiras de contratos inteligentes pessoais como para carteiras organizacionais (incluindo DAOs). Se mudar a sua chave em uma L2, também terá de mudar a sua chave em todas as outras L2.
• A infraestrutura de validação descentralizada muitas vezes é insuficiente. O Ethereum está finalmente começando a ter clientes leves decentes, como HeliosNo entanto, não faz sentido se toda a atividade estiver a ocorrer em camadas 2 que exigem os seus próprios RPCs centralizados. Em princípio, uma vez que tenha a cadeia de cabeçalhos Ethereum, a criação de clientes leves para L2s não é difícil; na prática, há muito pouco ênfase nisso.

Existem esforços a trabalhar para melhorar os três. Para a troca de tokens entre cadeias, o ERC-7683O 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 entre cadeias, a abordagem que a maioria das carteiras está adotando é usar mensagens repetíveis entre cadeias para atualizar chaves a curto prazo ekeystore rollupsa longo prazo. Os clientes leves para L2s estão começando a surgir, por exemplo. Beeruspara a Starknet. Além disso, melhorias recentes na experiência do usuário através de carteiras de próxima geração já resolveram muitos problemas 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-longos dias escuros de antigamente, 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 para coordenar: as pequenas não o fazem, porque apenas veriam uma pequena parte do benefício de suas contribuições, e as grandes não o fazem, porque se beneficiariam tanto ou mais de 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 mais amplo, teremos falhas como a distopia urbanística na imagem algumas parágrafos acima.

Não afirmo ter soluções perfeitas mágicas para este problema. O melhor que posso dizer é que o ecossistema precisa reconhecer mais plenamente que a infraestrutura cruzada 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. Nós temos Protocol Guild; talvez precisemos da Guilda de Infraestrutura Básica.

Conclusões

Os "Layer 2s" e o "sharding" são frequentemente descritos no discurso público como sendo duas estratégias opostas de como dimensionar um blockchain. Mas quando se analisa 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 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 num sentido técnico muito real, mas é uma fragmentação onde pode criar a sua própria fragmentação com as suas próprias regras. Isto é 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, precisa de compreender 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 de ambos os mundos.

Aviso Legal:

1. Este artigo é reproduzido a partir de [Gatevitalik], Encaminhe o Título Original 'Como é que as camadas 2 realmente diferem da fragmentação de execução?', Se houver objeções a esta republicação, por favor entre em contato com oGate Learnequipa e eles vão lidar com isso prontamente.

2. Aviso 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 equipa Gate Learn. Salvo indicação em contrário, é proibido copiar, distribuir ou plagiar os artigos traduzidos.