L1s vs. L2s, Rollups vs. Integrado, de uso geral vs. específico da aplicação

Introdução

Este pequeno post irá descrever as compensações concretas de:

• L1s vs. L2s
• Rollups vs. integrados
• Específico da aplicação vs. de uso geral

Precisamos de uma melhor compreensão das arquiteturas a construir e quando. Caso contrário, continuaremos a ter uma confusão de infraestruturas confusas que nenhum utilizador pode compreender ou interagir com. Este é o erro mais comum que vejo:

Conforme observado no post introdutório do Eclipse antes do próximo lançamento da mainnet:

Muitas vezes é apresentada uma falsa dicotomia entre a visão modular de rollup versus a capacidade de ter uma única cadeia com escala massiva, execução paralelizada e estado partilhado. “Modular” é muitas vezes confundido com “específico da aplicação”, o que o levaria a acreditar que os rollups significam um mundo de muitas cadeias fragmentadas e de baixo rendimento. Desafiamos essa ideia.

Rollups e L2s não são uma experiência de utilizador ruim. Rollups fragmentados e L2s são uma experiência de utilizador ruim. Rollups e L2s devidamente concebidos devem melhorar a experiência do utilizador.

Rollups vs. Integrado

Todas as cadeias podem eventualmente adotar a melhor tecnologia (por exemplo, DAS + ZK) se for útil. Conforme discutido no meu último relatório Os Rollups herdam a segurança? , a distinção que nos resta é aproximadamente a seguinte:

• “Rollups” a.k.a. “Modular” - Construa cadeias logicamente separadas que publicam dados na sua cadeia anfitriã (camada DA). Reutilizam o consenso da cadeia anfitriã.
• “Integrado” a.k.a. “Monolítico” - Integre tudo num protocolo com o seu próprio consenso. Não publique dados numa cadeia de anfitriões separada. (Mesmo que a camada DA e a camada de execução sejam, em certo sentido, partes logicamente separadas do protocolo partilhado).

Solana e Eclipse representam os caminhos paralelos, como mostrado de forma semelhante na Tese Solana do Syncracy:

Como discuti no meu recente episódio do Uncommon Core com o Hasu, ambas as abordagens terão valor a longo prazo.

Solana adota a abordagem de agrupar tudo num consenso. Persegue a latência mínima (ostempos de slot atualmente são médios ~400-500ms com esperança de atingir 200ms no futuro) enquanto mantém um grande conjunto de validadores(~2,000). Esta incrível conquista exigiu vários avanços técnicos.

No entanto, estes dois objetivos (descentralização máx+latência mínima) estão inerentemente em tensão. É incrivelmente desafiador manter este consenso estável enquanto corre à velocidade máxima e rendimento. O TowerBFT não tem uma análise formal de segurança ou vivacidade, e não está claro se a prova de história é atualmente útil e resiliente num modelo contraditório ou pode simplesmente ser removida. A economia de um sistema de baixa latência também aumenta naturalmente o incentivo para centralizar.

O Eclipse adota a abordagem de desagrupar o consenso. Os rollups podem ter um conjunto de sequenciadores escolhido a dedo mais pequeno (potencialmente até executado por um único operador) para operar um ambiente controlado. Isto pode aumentar a fiabilidade e reduzir ainda mais a latência, oferecendo um produto Web2 com os benefícios dos trilhos cripto. Code, uma aplicação de pagamentos implementada como uma L2 em Solana usando nonces duráveis, é semelhante no seu desejo de pagamentos instantâneos e confiáveis. Para além da grande experiência do utilizador de latência quase instantânea, também é necessário empurrar o limite inferior ainda mais longe para aplicações financeiras de baixo valor e baixa latência.

Os rollups podem então postar os seus dados noutro conjunto de consenso descentralizado para uma verificação mais robusta numa escala de tempo mais lenta. Por exemplo, a Celestia tem tempos de bloco de 15s com finalidade de slot único, o que na verdade nem é tão diferente de Solana! Solana tem confirmações ~400ms, depois a finalidade é atingida após 32 slots (~12.8s).

Não há almoço grátis aqui. Há uma compensação potencial nas propriedades do conjunto de validadores em tempo real (por exemplo, Solana tem muito mais validadores do que rollups fazem sequenciadores) versus as garantias fornecidas (por exemplo, ambiente resiliente controlado, latência ainda mais baixa, etc.). O nível adequado de compromisso dado (e em que escala de tempo) é um espectro. As questões de engenharia em aberto permanecem, e o melhor ajuste provavelmente irá variar de acordo com o caso de uso. Escusado será dizer que o custo também é essencial aqui, pelo que serão necessárias camadas de DA escaláveis como o Celestia (que o Eclipse usa).

Eclipse obviamente não substituirá Solana. Cada um faz compensações diferentes e persegue um mercado diferente. Solana continua a ser o coração e a alma do desenvolvimento SVM, e é provável que veja muitas novas aplicações implementadas lá como resultado. No entanto, é claro que haverá mais de uma cadeia de SVM a longo prazo (o Pyth já é). O futuro não é de cadeia única, e o SVM é simplesmente uma tecnologia incrível. O Eclipse está a começar a tendência de exportá-lo para L2, mas eu esperaria que outros percebessem o valor aqui e seguissem o seu exemplo.

L1 vs. L2

Estou a usar L1 e L2 aqui no sentido mais popular para incluir rollups, validiums, etc. Conforme abordado nos Diferentes tipos de camada 2s do Vitalik:

Pontes de validação bidirecional são quase suficientes para fazer de uma corrente um valídio. O principal ingrediente restante é um compromisso social de que se algo excepcional acontecer no Ethereum que faça com que a ponte não funcione mais, a outra cadeia irá fork em resposta.

O que torna um L1 versus um L2 é efetivamente como ele lida com garfos. Um valídio reverteria se o seu L1 reverter um bloco, e se a sua camada de base forquilharia se a sua camada de base forquilhasse. Para atualizar o L2, alguma forma de governação L2 deve viver no L1 como um contrato de ponte que é legível para o L1.

Agora, porque é que usaríamos tal coisa? Faz sentido para uma cadeia delegar a sua escolha de bifurcação a um L1 subjacente e enraizar-se em torno da sua ponte lá?

Apesar da crença comum de que as guerras L1 acabaram, o Ethereum ganhou e todos os concorrentes do Ethereum querem tornar-se um L2 agora - Ethereum L2s não são a melhor solução para todas as cadeias.

Ethereum L2s são frequentemente vistos como a maneira mais segura e escalável de construir uma cadeia. No entanto, estas propriedades de segurança são muitas vezes profundamente mal compreendidas, conforme discutido no meu último relatório. Apenas postar uma prova no Ethereum e delegar a sua regra de escolha de fork não torna magicamente a sua cadeia super segura.

O argumento de que todas as cadeias devem ser implementadas como Ethereum L2s para a sua própria segurança é na maioria das vezes incorreto. Em vez disso, o principal benefício dos L2s tem sido a capacidade de explorar os efeitos de rede do Ethereum (utilizadores, liquidez, programadores, ferramentas, etc.). É uma estratégia de lançamento no mercado.

Lutar pela atenção faz sentido dado que a atenção é o único recurso escasso em cripto. Os L2s estão naturalmente na frente e no centro com os programadores, utilizadores, meios de comunicação, etc. que mais importam. Ser um L2 costumava ser suficiente para chamar essa atenção.

No entanto, a atenção recebida por ser um L2 está a diminuir. A lista de Ethereum L2s em directo e futuros é agora demasiado longa para qualquer indivíduo acompanhar. As cadeias girando para L2s não recebem o impulso de atenção que os primeiros impulsionadores tiveram (por exemplo, Otimismo e Arbitrum). Até a enxurrada de tão esperados ZKEVMs estão a lutar para atrair utilizadores, aplicações e valor.

Então, ser um L2 sozinho não garante mais a atenção de todos. No entanto, ainda pode oferecer uma vantagem do produto em relação às cadeias autónomas se conseguir atrair a atenção de alguma outra maneira. Por exemplo, transformar um esquema de pirâmide num quadrado pode atrair ~$700 mm para um multisig sem L2. Em alternativa, pode construir o primeiro SVM L2 da Ethereum.

Supondo que tenha um produto com atenção, vamos agora considerar como ser um L2 pode ajudar uma cadeia a explorar a base de utilizadores do Ethereum e oferecer uma melhor experiência de produto. Faria isso principalmente alavancando ativos nativos do Ethereum (por exemplo, ETH) de maneira favorável (por exemplo, pontes com segurança atraente e/ou UX).

O valor disso depende amplamente de dois pressupostos fundamentais:

1.Que os ativos Ethereum existentes são importantes para o caso de uso dado (por exemplo, DeFi dependente de ETH)

Se a sua aplicação depende muito dos ativos do ecossistema Ethereum, então uma arquitetura L2 pode ser valiosa. Se não se importa nem um pouco com os ativos da Ethereum, então ser um Ethereum L2 não é particularmente valioso. Os ativos baseados em Ethereum são claramente os mais importantes em cripto hoje, por isso há um grande mercado a ser servido aqui hoje.

Olhando para o futuro a nível da indústria, a questão central aqui é qual será a nova e valiosa criação de estado das criptomoedas no futuro?

• Se este estado futuro estiver cada vez mais livre do atual estado nativo do Ethereum (por exemplo, novo estado único, RWAs, etc.), então o apelo dos L2s pode ser diminuído.
• Se este estado futuro depender fortemente do atual estado nativo do Ethereum (por exemplo, negociação ETH), então os L2s podem desempenhar um papel proeminente.

O primeiro cenário considera que só vimos uma gota no balde do que será a criptomoeda, e não deve exagerar a indexação do que está aqui hoje. O último cenário considera que o desenvolvimento de criptomoedas e as aplicações serão incrivelmente dependentes do caminho, pelo que o estado atual influenciará o resultado.

Ambos são verdadeiros até certo ponto, mas acho que qualquer visão otimista das perspetivas de longo prazo da indústria inclina-se para a primeira. Haverá muito estado novo e único sobre o qual nem podemos raciocinar que está desamarrado do estado de hoje. O estado atual da cripto é uma gota no balde em comparação com o estado futuro esperado.

Por exemplo, as “garantias de liquidação” comumente citadas do Ethereum significam pouco para ativos do mundo real (RWAs), como stablecoins (por exemplo, USDC) ou títulos do tesouro tokenizados. Estão “resolvidos” quando o emissor (por exemplo, Circle) os considera.

Neste cenário, o empate de ser um Ethereum L2 pode diminuir como uma parcela de aplicações. Um novo aplicativo de pagamento baseado em USDC não se importa inerentemente se é um Ethereum L2 ou não. Querem apenas a infraestrutura mais barata, mais rápida e fiável que lhes permita oferecer aos utilizadores a melhor experiência de produto.

A criação de um novo estado tem sido historicamente um obstáculo para Solana, embora vejamos claramente os ventos a mudar aqui. Muitos projetos conhecidos de DeTI e infraestruturas em Solana estão agora a lançar tokens, com mais por vir. Isto é dar o pontapé inicial no volante Solana.

2.Que as pontes Ethereum ←→ L2 são preferíveis às pontes Ethereum ←→ L1 (por exemplo, devido a razões de segurança e/ou UX)

Vamos supor que a primeira suposição foi realmente cumprida para um determinado caso de uso (ou seja, os nativos do Ethereum são bastante valiosos para a sua aplicação). Então, precisamos de perguntar se um L2 pode expor esses ativos de uma forma mais favorável versus um L1 separado. Digamos que um utilizador tenha algum ETH e queira trocá-lo por USDC. Para onde eles vão?

Embora a segurança da ponte seja frequentemente citada como uma motivação aqui, este argumento parece ténue com base na informação disponível. Muitas das maiores pontes rollup nem têm provas, têm provas na lista de permissões, upgrades controlados por multisigs, ou literalmente nem têm um L2.

Isso se compara à ponte clássica de verificador de consenso (por exemplo, IBC). Na prática, não houve grandes falhas no quórum do validador nesses cenários. As falhas na ponte ocorreram geralmente devido a hacks e/ou multisigs de ponte comprometidos (aos quais os L2s são igualmente suscetíveis).

Embora as melhorias de segurança sejam menos convincentes para mim aqui, o acesso conveniente aos utilizadores e ativos do Ethereum é um grande benefício da ponte L2 hoje, na minha opinião. Rollups como Base, Otimismo e Arbitrum parecem mais extensões do Ethereum. Os utilizadores mantêm as mesmas carteiras e endereços, o token de gás nativo é uma única versão canónica do ETH, o ETH domina o DeFicomo todos os pares de negociação, as aplicações sociais coçam NFTs em ETH e os criadores de pagamento em ETH (por exemplo, friend.tech), os depósitos no L2 são instantâneos (porque eles seriam reagrupados), etc.

Não se pode esperar que os utilizadores raciocinem através de qual ponte usar, analisem as diferentes suposições de segurança, obtenham um dos vários tokens embrulhados disponíveis, adquiram o token nativo da cadeia para gás, etc. Eles só querem fazer a ponte entre os seus ETH, obter ETH do outro lado e continuar a usar o L2 como eles usariam Ethereum ou qualquer outro L2. É por isso que o Eclipse usará apenas ETH como o seu token nativo usado para gás. Forçar a entrada de um novo token de gás é prejudicial para a UX.

Então, porque é que o Solana não pode simplesmente oferecer as mesmas vantagens que um Ethereum L2? Isto torna-se mais uma questão de engenharia do que qualquer coisa fundamental, e vai ficar mais fácil com o tempo. Isto é verdade para os tokens de gás, bem como outros desafios de UX relacionados simplesmente com a não utilização do EVM (que não é inerente ao L1 vs. L2):

• Token de gás - Os pagamentos de gás podem ser abstraídos dos utilizadores, permitindo aos utilizadores pagar em qualquer token de gás que escolherem.
• Bridging - É provável que a ponte endureça e padronize mais ao longo do tempo, levando a menos confusão por parte dos utilizadores e à fragmentação da liquidez.
• Carteiras - Os snaps recentemente revelados pela MetaMask estendem o suporte ao MetaMask a cadeias não EVM através de integrações de terceiros construídas no topo, como através dos Drift's ou MetaMask Snaps da Solflare.
• Experiência do programador - As barreiras linguísticas vão quebrar. Projetos como Solang e Neon podem ajudar os desenvolvedores do Solidity a construir em Solana, e projetos como o Stylus podem ajudar os desenvolvedores do Rust a construir sobre o Arbitum.

No futuro, seria mesmo possível que a ETH desempenhasse um papel no Solana DeFi se os utilizadores expressassem fortes preferências pela ETH com a velocidade e escala de Solana. Na prática, é muito mais provável que estes utilizadores com ativos nativos do Ethereum continuem a usá-los dentro do ecossistema Ethereum L2 pelas razões que discutimos, supondo que tenham acesso a L2s comparavelmente escaláveis.

Específico da aplicação vs. de uso geral

Independentemente de uma cadeia ser um L1 ou um L2, há uma necessidade clara de aumentar a taxa de transferência de cadeia única escalando a execução. Os rollups não devem implicar fragmentação. Unir muitas cadeias homogéneas num sequenciador partilhado com estado acaba por parecer uma cadeia paralelizada a partir de uma perspetiva de escala com UX mais desafiadora.

Muitas vezes vemos o “espaço de bloco dedicado” citado como a razão para implantar um rollup específico da aplicação. No entanto, este equívoco surgiu em grande parte devido às limitações desnecessárias do EVM de encadeamento único com mercados de taxas globais. Um SVM paralelizado com mercados de taxas locais reduz muito a necessidade de cadeias de aplicação. Hospedar mais aplicações numa infraestrutura partilhada reduz significativamente a complexidade do programador e do utilizador. A UX entre cadeias e a complexidade do programador num mundo de muitas cadeias é um risco existencial subestimado.

Isto não quer dizer que haverá literalmente uma cadeia no final do dia. Vejo amplamente quatro argumentos para implantar a sua própria cadeia:

1. Escalabilidade & Espaço de bloco dedicado - Como mencionado acima, este geralmente não é convincente. Uma casa da moeda NFT não deveria efetivamente encerrar o resto da cadeia, mas a resposta geralmente não é ir fazer outra cadeia. Isto é aliviado por uma VM paralelizada com mercados de taxas locais. No entanto, na medida em que a largura de banda de toda a rede estiver saturada, os mercados de taxas locais não ajudarão (ou seja, as taxas para a cadeia partilhada aumentarão globalmente). Então precisa de outra cadeia.
2. Soberania - A governação em cripto ainda é bastante pobre, e ter a sua própria cadeia para bifurcar pode ser um mecanismo de coordenação útil. A minha intuição é que esta é uma circunstância muito rara, mas é difícil dizer com certeza. Isto está em linha com o interesse da MakerDAO numa cadeia de aplicação.
3. Personalização - As personalizações a nível de consenso podem ser valiosas para determinadas aplicações (por exemplo, dYdX v4), mas estes casos são empiricamente poucos e distantes entre si até à data. Até o DydX, o exemplo brilhante de uma cadeia de aplicação, “provavelmente mover-se-á mais para a execução generalizada na cadeia dYdX” de acordo com Antonio no seu recente episódio Bell Curve. A necessidade de personalização de pilha completa que não pode ser resolvida numa cadeia partilhada tem faltado geralmente para a maior parte das criptomoedas. Quase todos os novos rollups continuam a ser apenas garfos EVM de baunilha com novos tokens.
4. Captura de valor - Este é indiscutivelmente um subconjunto da personalização, mas é muito importante por isso vamos dividi-lo. Pode ser mais desafiador internalizar o valor numa infraestrutura partilhada que não é construída apenas com a sua aplicação em mente. As cadeias de aplicativos podem facilitar a atribuição de valor às aplicações responsáveis. No entanto, este é um esforço de engenharia mais do que fundamental, e há pesquisas em curso em Solana sobre como fazer exatamente isso. Além disso, note que há um custo ininterrupto sério na implementação da sua própria cadeia versus custos de amortização em toda a infraestrutura partilhada.

A principal motivação para lançar uma cadeia de aplicação hoje é muitas vezes o aumento narrativo percebido e/ou utilidade simbólica para um projeto em dificuldades. A desaceleração do mercado em baixa e a correspondente falta de crescimento de aplicações incentivaram o desenvolvimento e o financiamento de uma arquitetura excessivamente complicada que resultou em novos projetos necessários para resolver complexidades auto-infligidas.

Lançar a sua própria cadeia hoje traz compensações dolorosas e desnecessárias (complexidade, custo, pior experiência do usuário, liquidez fragmentada, etc.) que a maioria das aplicações não pode justificar para os benefícios incrementais. A infraestrutura necessária para tornar esta UX competitiva parece distante. Isto não quer dizer que não haja razão para as cadeias de aplicação existirem (certamente existem). Em vez disso, acabamos de sobre-indexar maciçamente nesta direção na narrativa enquanto indústria, e por isso a tendência atual para o re-agrupamento é claramente benéfica dado o estado atual.

Conclusão

Solana ganhou legitimamente muito ímpeto nos últimos meses. Esta correcção acentuada tem sido em grande parte um reconhecimento do estado atual da experiência do utilizador multi-cadeia - é fragmentada e dolorosa. A experiência do utilizador de usar aplicações Solana é simplesmente incrível. Suave e rápido.

Os rollups e os L2s têm uma má reputação para a UX, mas o verdadeiro problema é a fragmentação. Associamos rollups e L2s a escalabilidade horizontal fragmentada porque, na prática, a maioria deles bifurcou o EVM tal como está e usa largura de banda DA restrgida. Acabam por ser caros e desajosos de usar.

No entanto, isso não é fundamental. A escalabilidade vertical com uma VM poderosa numa camada DA escalável resolve estes problemas de UX e custos. É provável que ocorra algum nível de reagrupamento da pilha tanto para L1s como para L2s. L2s e rollups devem melhorar a UX se usados corretamente. Esse deve ser o seu verdadeiro argumento de venda.

Ambas as abordagens têm os seus méritos. Só precisamos de fazer um trabalho melhor para nos perguntarmos “que mercado este produto está a tentar abordar?” e “como é que esta arquitetura pode resolver o que eu preciso?” antes de irmos construir o próximo L1, L2, L3...

Isenção de responsabilidade：

1. Este artigo foi reimpresso de [dba]. Todos os direitos de autor pertencem ao autor original [Jon Charbonneau]. Se houver objeções a esta reimpressão, contacte a equipa do Gate Learn, e eles tratarão disso imediatamente.
2. Isenção de responsabilidade: As opiniões e opiniões expressas neste artigo são exclusivamente do autor e não constituem nenhum conselho de investimento.
3. As traduções do artigo para outras línguas são feitas pela equipa do Gate Learn. A menos que mencionado, é proibido copiar, distribuir ou plagiar os artigos traduzidos.