L1s x L2s, rollups x integrados, uso geral x específico do aplicativo

Introdução

Esta breve postagem descreverá as compensações concretas de:

• L1s x L2s
• Rollups vs. integrados
• Específico do aplicativo versus uso geral

Precisamos de uma melhor compreensão de quais arquiteturas construir e quando. Caso contrário, continuaremos a ter uma mistura de infraestrutura confusa que nenhum usuário pode entender ou interagir. Este é o erro mais comum que vejo:

Conforme observado na postagem introdutória do Eclipse antes do lançamento da mainnet:

Freqüentemente, há uma falsa dicotomia entre a visão de rollup modular e a capacidade de ter uma cadeia única com escala massiva, execução paralelizada e estado compartilhado. “Modular” é frequentemente confundido com “específico do aplicativo”, o que levaria você a acreditar que rollups significam um mundo de muitas cadeias fragmentadas e de baixo rendimento. Desafiamos essa ideia.

Rollups e L2s não são uma UX ruim. Rollups fragmentados e L2s são UX ruins. Rollups e L2s adequadamente projetados devem melhorar a UX.

Rollups vs. Integrados

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” também conhecidos como “Modular” – Construa cadeias logicamente separadas que postam dados em sua cadeia host (camada DA). Eles reutilizam o consenso da cadeia hospedeira.
• “Integrado”, também conhecido como “Monolítico” - Integre tudo em um protocolo com consenso próprio. Não publique dados em uma cadeia de hosts separada. (Mesmo que a camada DA e a camada de execução sejam, em certo sentido, partes logicamente separadas do protocolo compartilhado).

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

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

Solana adota a abordagem de agrupar tudo em um consenso. Ele busca latência mínima (atualmente, os tempos dos slots são em média de ~400-500ms , com esperança de atingir 200ms no futuro), enquanto mantém um grande conjunto de validadores (~2.000). Esta conquista incrível exigiu vários avanços técnicos.

No entanto, estes dois objetivos (descentralização máxima + latência mínima) estão inerentemente em tensão. É incrivelmente desafiador manter esse consenso estável enquanto funciona em velocidade e rendimento máximos. TowerBFT não possui análise formal de segurança ou vivacidade, e não está claro se a prova do histórico é atualmente útil e resiliente em um modelo adversário ou pode simplesmente ser removida. A economia de um sistema de baixa latência também aumenta o incentivo à centralização.

Eclipse adota a abordagem de desagregação do consenso. Os rollups podem ter um conjunto menor de sequenciadores escolhidos a dedo (potencialmente até mesmo executado por um único operador) para operar um ambiente controlado. Isso pode aumentar a confiabilidade e reduzir ainda mais a latência, oferecendo um produto Web2 com os benefícios dos crypto rails. Code, um aplicativo de pagamentos implantado como uma espécie de L2 em Solana usando nonces duráveis, é semelhante em seu desejo de pagamentos instantâneos e confiáveis. Além da excelente UX de latência quase instantânea, ampliar ainda mais o limite inferior também é necessário para aplicações financeiras de alto valor e baixa latência.

Os rollups podem então postar seus dados em outro conjunto de consenso descentralizado para verificação mais robusta em uma escala de tempo mais lenta. Por exemplo, Celestia tem tempos de bloco de 15s com finalidade de slot único, o que na verdade não é tão diferente de Solana! Solana tem confirmações de aproximadamente 400ms, então a finalidade é alcançada após 32 slots (~12,8s).

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

Obviamente, o Eclipse não substituirá Solana. Cada um faz compensações diferentes e busca um mercado diferente. Solana continua sendo o coração e a alma do desenvolvimento de SVM e, como resultado, é provável que muitos novos aplicativos sejam implantados lá. No entanto, está claro que haverá mais de uma cadeia SVM de longo prazo (o Pyth já existe). O futuro não é de cadeia única e o SVM é uma tecnologia simplesmente incrível. O Eclipse está iniciando a tendência de exportá-lo para L2, mas espero que outros percebam o valor aqui e sigam seu exemplo.

L1 x L2

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

Pontes de validação bidirecionais são quase suficientes para transformar uma cadeia em validium. 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 fará um hard fork em resposta.

O que diferencia um L1 de um L2 é efetivamente como ele lida com os garfos. Um validium seria revertido se seu L1 revertesse um bloco, e seria um hard fork se sua camada base fosse hard fork. Para atualizar a L2, alguma forma de governança da L2 deve residir na L1 como um contrato-ponte que seja legível para a L1.

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

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

Ethereum L2s são frequentemente vistos como a forma mais segura e escalável de construir uma cadeia. No entanto, essas 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 sua regra de escolha de garfo não torna sua cadeia super segura magicamente.

O argumento de que todas as cadeias devem ser implantadas como Ethereum L2s para sua própria segurança é geralmente incorreto. Em vez disso, o principal benefício dos L2s tem sido a capacidade de aproveitar os efeitos de rede do Ethereum (usuários, liquidez, desenvolvedores, ferramentas, etc.). É uma estratégia de entrada no mercado.

Lutar por atenção faz sentido, visto que a atenção é o único recurso escasso na criptografia. Os L2s naturalmente ficam na frente e no centro dos desenvolvedores, usuários, mídia, etc., que são mais importantes. Ser um L2 costumava ser suficiente para chamar essa atenção.

No entanto, a atenção recebida por ser um L2 está diminuindo. A lista de Ethereum L2s ativos e futuros agora é longa demais para qualquer indivíduo acompanhar. As cadeias que giram em direção aos L2s não recebem o mesmo impulso de atenção que os pioneiros (por exemplo, Optimism e Arbitrum). Até mesmo a enxurrada de zkEVMs há muito aguardados está lutando para atrair usuários, aplicativos e valor.

Então, ser L2 sozinho não garante mais a atenção de todos. No entanto, ainda pode oferecer uma vantagem de produto em relação às cadeias independentes se você puder atrair a atenção de alguma outra maneira. Por exemplo, transformar um esquema de pirâmide em um quadrado pode atrair aproximadamente US$ 700 milhões para um multisig sem L2. Alternativamente, você poderia construir o primeiro SVM L2 do Ethereum.

Supondo que você tenha um produto com atenção, vamos agora considerar como ser um L2 pode ajudar uma rede a explorar a base de usuários do Ethereum e oferecer uma melhor experiência de produto. Isso seria feito principalmente aproveitando ativos nativos do Ethereum (por exemplo, ETH) de maneira favorável (por exemplo, pontes com segurança e/ou UX atraentes).

O valor disso depende amplamente de duas suposições principais:

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

Se a sua aplicação depende fortemente dos ativos do ecossistema Ethereum, então uma arquitetura L2 pode ser valiosa. Se você não se importa com os ativos do Ethereum, então ser um Ethereum L2 não é particularmente valioso. Os ativos baseados em Ethereum são claramente os mais importantes na criptografia hoje, então há um grande mercado a ser atendido aqui hoje.

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

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

O primeiro cenário considera que vimos apenas uma gota no oceano sobre o que será a criptografia, e você não deve indexar demais o que está aqui hoje. O último cenário considera que o desenvolvimento e as aplicações criptográficas serão incrivelmente dependentes do caminho, de modo que o estado atual influenciará o resultado.

Ambas são verdadeiras até certo ponto, mas penso que qualquer visão optimista das perspectivas a longo prazo da indústria se inclina para a primeira. Haverá muitos estados novos e únicos sobre os quais não podemos sequer raciocinar e que estejam desvinculados do estado atual. O estado atual da criptografia é uma gota no oceano em comparação com o estado futuro esperado.

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

Nesse cenário, o atrativo de ser um Ethereum L2 pode diminuir em proporção às aplicações. Um novo aplicativo de pagamento baseado em USDC não se importa inerentemente se é um Ethereum L2 ou não. Eles querem apenas a infraestrutura mais barata, rápida e confiável que lhes permita oferecer aos usuários a melhor experiência de produto.

A criação de um novo estado tem sido historicamente um obstáculo para Solana, embora vejamos claramente a mudança dos ventos aqui. Muitos projetos DeFi e de infraestrutura bem conhecidos em Solana estão agora lançando tokens, com mais por vir. Isso está dando início ao 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 atendida para um determinado caso de uso (ou seja, os nativos do Ethereum são bastante valiosos para sua aplicação). Então, precisamos perguntar se um L2 pode expor esses ativos de uma maneira mais favorável do que um L1 separado. Digamos que um usuário tenha algum ETH e queira trocá-lo por USDC. Onde eles vão?

Embora a segurança da ponte seja frequentemente citada como motivação aqui, este argumento parece tênue com base nas informações disponíveis. Muitas das maiores pontes rollup nem sequer possuem provas, possuem provas na lista de permissões, atualizações controladas por multisig ou literalmente nem possuem um L2.

Isso se compara à ponte clássica do verificador de consenso (por exemplo, IBC). Na prática, não houve grandes falhas de quórum de validadores em tais cenários. As falhas de ponte geralmente ocorreram 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 usuários e ativos do Ethereum é um grande benefício da ponte L2 hoje, na minha opinião. Rollups como Base, Optimism e Arbitrum parecem mais extensões do Ethereum. Os usuários mantêm as mesmas carteiras e endereços, o token de gás nativo é uma versão canônica única do ETH, o ETH domina o DeFi, como todos os pares de negociação, os aplicativos sociais precificam NFTs em ETH e pagam criadores em ETH (por exemplo, friend.tech), os depósitos no L2 são instantâneos (porque seriam reorganizados juntos), etc.

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

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

• Token de gás - Os pagamentos de gás podem ser abstraídos dos usuários, permitindo que os usuários paguem com qualquer token de gás que escolherem.
• Bridging - A ponte provavelmente se tornará mais rígida e padronizada ao longo do tempo, levando a menos confusão por parte dos usuários e à fragmentação da liquidez.
• Carteiras - Os Snaps recentemente revelados da MetaMask estendem o suporte MetaMask para cadeias não-EVM por meio de integrações de terceiros construídas no topo, como via Drift's ou MetaMask Snaps da Solflare.
• Experiência do desenvolvedor – As barreiras linguísticas serão quebradas. Projetos como Solang e Neon podem ajudar os desenvolvedores do Solidity a construir no Solana, e projetos como o Stylus podem ajudar os desenvolvedores do Rust a construir no Arbitrum.

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

Específico do aplicativo versus uso geral

Independentemente de uma cadeia ser L1 ou L2, há uma clara necessidade de aumentar o rendimento da cadeia única, escalonando a execução. Rollups não devem implicar fragmentação. Unir muitas cadeias homogêneas em um sequenciador compartilhado com estado acaba parecendo uma cadeia paralelizada de uma perspectiva de escala com UX mais desafiadora.

Muitas vezes vemos “blockspace dedicado” citado como o motivo para implantar um rollup específico do aplicativo. No entanto, este equívoco surgiu em grande parte devido às limitações desnecessárias do EVM de thread único com os mercados de taxas globais. Um SVM paralelizado com mercados de taxas locais reduz muito a necessidade de cadeias de aplicativos. Hospedar mais aplicativos em infraestrutura compartilhada reduz significativamente a complexidade do desenvolvedor e do usuário. A UX entre cadeias e a complexidade do desenvolvedor em um mundo de muitas cadeias é um risco existencial subestimado.

Isso não quer dizer que haverá literalmente uma rede no final do dia. Em termos gerais, vejo quatro argumentos para implantar sua própria cadeia:

1. Escalabilidade e Blockspace Dedicado - Como mencionado acima, este geralmente não é convincente. Uma casa da moeda NFT não deveria encerrar efetivamente o resto da cadeia, mas a resposta geralmente não é criar outra cadeia. Isto é atenuado por uma VM paralela com mercados de taxas locais. Porém, 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 você precisa de outra corrente.
2. Soberania - A governança em criptografia ainda é bastante fraca, e ter sua própria cadeia até a bifurcação pode ser um mecanismo de coordenação útil. Minha intuição é que esta é uma circunstância muito rara, mas é difícil dizer com certeza. Isso está de acordo com o interesse da MakerDAO em uma cadeia de aplicativos.
3. Personalização - As personalizações em nível de consenso podem ser valiosas para determinadas aplicações (por exemplo, dYdX v4), mas esses casos são empiricamente poucos e raros até o momento. Mesmo o dYdX, o exemplo brilhante de uma cadeia de aplicativos, “provavelmente avançará mais em direção à execução generalizada na cadeia dYdX”, de acordo com Antonio em seu recente episódio Bell Curve. A necessidade de personalização full-stack, que não pode ser resolvida em uma cadeia compartilhada, geralmente falta na maior parte das criptomoedas. Quase todos os novos rollups continuam a ser apenas garfos EVM básicos com novos tokens.
4. Captura de valor – Este é sem dúvida um subconjunto da capacidade de personalização, mas é muito importante, por isso vamos dividi-lo. Pode ser mais desafiador internalizar valor em infraestrutura compartilhada que não é construída apenas com a sua aplicação em mente. As cadeias de aplicativos podem facilitar a alocação de valor aos aplicativos responsáveis. No entanto, este é um esforço de engenharia mais do que fundamental, e há pesquisas em andamento em Solana sobre como fazer exatamente isso. Além disso, observe que há um sério custo indireto na implantação de sua própria cadeia em comparação com a amortização de custos em uma infraestrutura compartilhada.

A principal motivação para lançar uma cadeia de aplicativos hoje é muitas vezes o impulso narrativo percebido e/ou a utilidade do token para um projeto em dificuldades. A recessão do mercado em baixa e a correspondente falta de crescimento das aplicações incentivaram o desenvolvimento e o financiamento de uma arquitectura excessivamente complicada que resultou em novos projectos necessários para resolver complexidades auto-infligidas.

Lançar sua própria cadeia hoje traz compensações dolorosas e desnecessárias (complexidade, custo, pior UX, liquidez fragmentada, etc.) que a maioria dos aplicativos não consegue justificar pelos benefícios incrementais. A infraestrutura necessária para tornar esta UX competitiva parece distante. Isso não quer dizer que não haja razão para a existência de cadeias de aplicativos (certamente existem). Em vez disso, acabamos de indexar excessivamente nesta direção a narrativa como indústria e, portanto, a tendência atual de reagrupamento é claramente benéfica, dado o estado atual.

Conclusão

Solana ganhou muito impulso nos últimos meses. Esta correção acentuada tem sido em grande parte um reconhecimento do estado atual da UX multi-chain – ela é fragmentada e dolorosa. A experiência do usuário de usar aplicativos Solana é simplesmente incrível. Suave e rápido.

Rollups e L2s têm uma má reputação para UX, mas o verdadeiro problema é a fragmentação. Associamos rollups e L2s ao escalonamento horizontal fragmentado porque, na prática, a maioria deles bifurcou o EVM no estado em que se encontra e usa largura de banda DA restrita. Eles acabam sendo caros e difíceis de usar.

No entanto, isso não é fundamental. O dimensionamento vertical com uma VM poderosa em uma camada DA escalonável resolve esses problemas de UX e de custo. É provável que ocorra algum nível de reagrupamento da pilha para L1s e L2s. L2s e rollups devem melhorar a UX se usados corretamente. Esse deve ser o seu verdadeiro ponto de venda.

Ambas as abordagens têm seus méritos. Só precisamos fazer um trabalho melhor, primeiro nos perguntando “que mercado este produto está tentando atingir?” e “como essa arquitetura pode resolver o que eu preciso?” antes de construirmos o próximo L1, L2, L3…

Isenção de responsabilidade:

1. Este artigo foi reimpresso de [dba]. Todos os direitos autorais pertencem ao autor original [Jon Charbonneau]. Se houver objeções a esta reimpressão, entre em contato com a equipe do Gate Learn e eles cuidarão disso imediatamente.
2. Isenção de responsabilidade: As opiniões e pontos de vista 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 do Gate Learn. A menos que mencionado, é proibido copiar, distribuir ou plagiar os artigos traduzidos.