O cenário de L1 vs. L2: entendendo as diferenças de design, os trade-offs e os possíveis desfechos

Insights práticos

• Entenda os recursos primitivos disponíveis e as limitações técnicas: conheça profundamente os blocos fundamentais e as nuances técnicas. Esse conhecimento é essencial para identificar como esses fatores podem afetar a funcionalidade e a escalabilidade da sua aplicação e, em última análise, do seu negócio, além de permitir decisões embasadas no processo de desenvolvimento em blockchain.
• Avalie a infraestrutura e a liquidez: avalie a infraestrutura e a liquidez disponíveis nas soluções L1 e L2, além de ambientes de execução alternativos para implantação. Faça projeções sobre o estado da infraestrutura a partir de princípios fundamentais. Entenda as premissas reais de confiança e descentralização a partir desses princípios.
• Otimize a experiência do usuário: otimize incansavelmente a experiência do usuário, considerando a facilidade de uso, a velocidade das transações e a eficiência geral oferecida por cada blockchain. Procure criar um ambiente simples e intuitivo, reconhecendo o que já está disponível hoje e aonde os roadmaps levarão.

Introdução

À medida que o cenário das blockchains continua evoluindo, decidir onde criar aplicações se tornou cada vez mais complexo para os desenvolvedores. Este relatório analisa as diferenças entre soluções de Layer 1 (L1) e Layer 2 (L2) para plataformas generalistas de contratos inteligentes, explorando as implicações para o engajamento dos usuários, as margens econômicas e o crescimento dos negócios.

Apesar da diversidade e dos avanços no setor de blockchain, a base de usuários continua modesta em comparação com plataformas digitais de massa. Por exemplo, atualmente o setor cripto envolve cerca de 5,5 milhões de endereços únicos atribuíveis por dia, em comparação com os cerca de 2 bilhões de usuários diários de plataformas como o Facebook.

Hoje, os clientes das blockchains são os desenvolvedores. As blockchains vendem espaço de bloco para que desenvolvedores de aplicações criem novos produtos. Escolher onde criar sua aplicação é uma das decisões mais importantes que um desenvolvedor enfrenta atualmente. Do ponto de vista comercial, escolher onde desenvolver é uma das decisões mais relevantes, pois afeta usuários potenciais, liquidez e cultura no futuro. Migrar sistemas após o lançamento é uma tarefa difícil, tanto do ponto de vista técnico quanto social, embora não seja impossível. Equipes como a dydx migraram com sucesso da Ethereum para uma appchain da Cosmos, enquanto a y00ts enfrentou desafios ao migrar da Solana para a Polygon e, agora, para a Ethereum.

Este relatório não pretende adotar uma posição parcial no debate mais recente entre sistemas modulares e integrados. Em vez disso, oferece uma visão prática para que desenvolvedores, potenciais desenvolvedores e executivos entendam melhor o cenário de L1/L2, com exemplos concretos dos trade-offs de aplicações em determinados designs.

Características de uma blockchain

Antes de discutir as diferenças entre L1s e L2s, precisamos definir as características de uma blockchain.

Uma blockchain é uma máquina de estados replicada e determinística. Trata-se de um sistema complexo criado para alcançar consenso e manter um registro unificado e seguro em uma rede distribuída.

Determinística

Os processos de uma blockchain são predeterminados pelo protocolo subjacente. Quando a “função de transição de estado” (STF) de uma blockchain é executada com uma determinada entrada e o estado atual, ela produz o mesmo novo estado em todos os nós. Essa natureza determinística garante que, independentemente de quem execute a função ou do nó que processe a transação, o resultado será consistente. Processos determinísticos garantem confiabilidade e previsibilidade nas operações da rede.

Replicada

As blockchains utilizam uma rede de nós, e cada um mantém uma cópia de todo o estado da blockchain. Essa replicação contribui para a descentralização e oferece resiliência contra perda e adulteração de dados. Como cada nó mantém uma réplica do estado, qualquer tentativa de alterar o registro histórico exigiria modificações simultâneas na maioria dos nós. Isso é praticamente inviável em uma rede suficientemente grande e distribuída.

Máquina de estados

Em sua essência, uma blockchain é um sistema que gerencia estados — instantâneos de um ponto específico no tempo que abrangem todas as informações acordadas, como saldos de contas, estados de contratos inteligentes e registros de propriedade. A blockchain transita por meio de transações, que são solicitações para mudar de um estado para o seguinte. Essas transições são regidas pelas regras codificadas no protocolo da blockchain.

O resultado dessas propriedades é um ledger que qualquer pessoa pode ler ou no qual pode escrever. Como Balaji observou em 2019, blockchains públicas são bancos de dados globais e multiclientes nos quais cada usuário é um usuário root. Isso permite uma visão global de quantos ativos (tokens, NFTs etc.) cada usuário possui e possibilita inovação sem permissão em torno do estado global público e compartilhado.

Participantes do mercado de blockchain

As blockchains viabilizam um mercado global de informações acordadas com base em confiança descentralizada. Há dois grupos principais de participantes em uma rede blockchain:

• Fornecedores de confiança: participantes de staking, validadores e mineradores (dependendo de a rede usar PoW ou PoS)
• Consumidores de confiança: aplicações (que frequentemente agrupam transações e repassam o custo operacional marginal ao usuário)

Em outras palavras, as blockchains viabilizam um mercado bilateral entre compradores e vendedores, assim como qualquer outro mercado econômico. Conforme ditam a oferta e a demanda, o mercado atribui um custo à facilitação das negociações entre os dois lados.

Blockchains públicas precisam de taxas para evitar spam e alocar recursos escassos. Essas taxas são a principal forma de remuneração/receita de validadores e mineradores para cobrir despesas gerais, como equipamentos, eletricidade e outros recursos. Embora diferentes protocolos tenham mecanismos distintos de precificação de taxas, todas as principais blockchains públicas integram gas ao protocolo de alguma forma. Alguém opera equipamentos de computação em algum lugar do mundo e precisa ser remunerado para ter incentivo.

Definição de L1s e L2s

Com uma compreensão melhor do que é uma blockchain e do que ela possibilita, podemos formalizar as definições de L1 e L2.

Uma definição abrangente e rigorosa de L1s e L2s, assim como de suas respectivas conotações, é tema de um debate controverso entre pesquisadores e a comunidade cripto em geral. Surgiram diferentes tipos de rollups (otimistas, de conhecimento zero, integrados ao protocolo), com diferentes detalhes de implementação e premissas de confiança (validiums, volitions, soberanos, entre outros).

Antes de discutir os trade-offs entre L1s e L2s, precisamos defini-las.

Layer 1s (L1s)

As blockchains L1 são redes fundamentais que operam como infraestrutura principal de uma criptomoeda. São redes independentes, com seus próprios protocolos subjacentes, mecanismos de consenso e tokens nativos. As L1s costumam ser chamadas de camada base de um ecossistema blockchain porque fornecem a estrutura fundamental de segurança e governança.

A Ethereum foi pioneira no conceito de confiança modular quando foi lançada em 2015. No entanto, ela não era e ainda não é otimizada para a escala necessária para integrar milhões de usuários. Como resultado, novas soluções de escalabilidade, como rollups, surgiram como uma alternativa promissora para escalar a Ethereum.

Layer 2s (L2s)

As soluções L2 são construídas sobre blockchains L1 para aumentar a escalabilidade e o throughput de transações sem alterar a camada base. Os rollups estão entre as soluções L2 mais promissoras e estudadas.

Os rollups retiram transações da L1, processam-nas separadamente e depois registram o estado final de volta na L1, muitas vezes na forma de uma raiz de estado. Essa abordagem permite que o próprio rollup execute transações adicionais em um ambiente de estado separado, a um custo menor do que seria possível diretamente na L1. Os rollups agrupam várias transações em uma única transação na L1 para reduzir a carga e aumentar a eficiência. Diferentes soluções L2 têm premissas de confiança distintas e, em geral, buscam herdar os aspectos de segurança e descentralização da L1 subjacente, tornando-se alternativas seguras, porém mais escaláveis, ao processamento de cada transação na L1.

A Celestia formalizou esta definição de rollups:

Na prática, a Ethereum tem os ativos mais interessantes e valiosos em termos nominais no setor cripto. Os usuários demonstram disposição para transferir ativos por bridges para várias soluções L2, sem muita preocupação com alguns dos aspectos mais centralizadores da L2 — que estão sendo desenvolvidos ativamente, mas muitas vezes ainda não estão disponíveis — em troca de taxas muito mais baixas do que as da mainnet da Ethereum. 

A segurança é uma preocupação comum ao transferir ativos entre blockchains por meio de bridges. Embora muitas bridges de rollups importantes não tenham sistemas de prova rigorosos e sejam criticadas por possíveis pontos de controle centralizados, elas oferecem uma extensão simples da experiência da Ethereum, com uma experiência semelhante à EVM e uniformidade de carteiras. Rollups como Base, Optimism e Arbitrum preservam, na medida do possível, a infraestrutura existente de carteira e endereço do usuário na Ethereum, tornando as transições entre a blockchain principal e as L2s muito mais simples. Essa conveniência, aliada ao domínio do ETH em aplicações DeFi e sociais, torna a L2 uma proposta atraente para usuários que buscam familiaridade e facilidade de uso. A Ethereum tem o estado mais popular com o qual outros desenvolvedores querem interagir, e as L2s são vistas como uma extensão natural da Ethereum.

Tudo isso significa que “herdar” determinadas garantias de segurança da Ethereum está longe de ser um dos principais motivos para uma equipe lançar uma L2 da Ethereum ou migrar de uma L1 independente para uma L2.

Novos desenvolvimentos, como Solang e Neon, estão reduzindo a distância para desenvolvedores acostumados à Solidity da Ethereum, enquanto o Snaps da Metamask amplia o suporte da carteira para blockchains não EVM. Esses avanços apontam para um futuro no qual a UX abstrai efetivamente muitas complexidades entre diferentes ambientes de execução.

Embora a Ethereum Foundation tenha financiado grande parte das pesquisas sobre L2s, todas elas são entidades independentes e não são operadas pela Ethereum Foundation. A inovação sem permissão não é exclusiva da camada de aplicações descentralizadas, e nenhuma L1 com neutralidade confiável tem capacidade técnica para decidir quais L2s podem ser implantadas sobre ela.

Implementações e arquitetura “típicas” de L1 e L2

Para entender melhor os trade-offs entre L1s e L2s, é essencial compreender suas respectivas cadeias de suprimentos, os participantes relevantes e as premissas de confiança.

Ciclo de vida de uma transação L1

Embora cada L1 tenha detalhes de implementação específicos, todas as principais L1s têm participantes e ciclos de vida de transações relativamente semelhantes. Esta seção descreve o fluxo comum de uma transação, desde a geração até a inclusão final.

1. Intenção

O usuário começa com um objetivo ou uma ação clara que deseja realizar na rede Ethereum, como enviar ETH, interagir com um contrato inteligente ou trocar tokens. Essa etapa envolve o processo de decisão do usuário e a compreensão do que ele deseja realizar, definindo o percurso da transação.

2. Geração da transação

Aqui, a transação toma forma. O usuário, geralmente por meio de uma interface como uma carteira ou aplicação descentralizada, insere as informações necessárias, como o endereço do destinatário, o valor a enviar ou o método do contrato a chamar. Essa etapa transforma a intenção do usuário em uma solicitação estruturada que a rede Ethereum pode processar. Nesse momento, o usuário determina o custo da transação, que inclui o preço e o limite de gas. Isso depende muito da blockchain e costuma ser abstraído pelo provedor da carteira. Tanto a Ethereum quanto a Solana implementam uma versão disso por meio de uma taxa base e uma taxa de prioridade (gorjeta), com implementações e níveis de determinismo distintos em relação à inclusão da transação.

3. Transmissão

O usuário assina a transação com sua chave privada, uma assinatura digital que comprova sua autorização. Depois de assinada, a transação é transmitida para a rede, normalmente por meio de um provedor de RPC integrado à carteira, geralmente pelo mempool público ou por leilões privados de fluxo de ordens, onde aguarda processamento.

4. Confirmação da inclusão

A transação chega à conclusão nesta última etapa. O usuário recebe a confirmação de que ela foi incluída com sucesso em um bloco, com níveis de finalidade variáveis conforme o protocolo específico. A finalidade encerra o processo e permite que os usuários verifiquem os resultados, como saldos ou estados de contratos atualizados.

A cadeia de suprimentos da Ethereum

Com o objetivo de ser uma camada de infraestrutura com neutralidade confiável para aplicações resistentes à censura, a Ethereum passou por uma evolução significativa no mecanismo de sua cadeia de suprimentos. Inicialmente operando com Proof of Work (PoW), os mineradores controlavam a inclusão e a ordenação das transações da Ethereum. Isso levou ao surgimento de leilões prioritários de gas (PGAs), nos quais os buscadores competiam por espaço de bloco, causando congestionamento do mempool e uso ineficiente da blockchain. A introdução do Flashbots Auction, um relay fora do protocolo para bundles de MEV, reduziu alguns efeitos centralizadores do MEV ao transferir os mercados de MEV para fora da blockchain, embora dependesse da honestidade tanto do operador do relay quanto dos mineradores.

Com a transição para Proof of Stake (PoS), a produção de blocos da Ethereum passou para validadores com staking, introduzindo novas dinâmicas e possíveis problemas de centralização. Sob PoS, as economias de escala na extração de MEV podem levar à centralização do stake, ameaçando a resistência à censura da Ethereum.

Para abordar as preocupações com a centralização do stake, a Proposer-Builder Separation (PBS) foi introduzida pela Flashbots. Inicialmente, ela foi implementada como MEV-Boost, um novo regime de produção de blocos. Nesse sistema, os buscadores enviam bundles aos construtores de blocos, que então constroem blocos e fazem lances por meio de relays de blocos para o proponente. O MEV-Boost transfere as forças centralizadoras para a camada dos construtores de blocos, exigindo confiança nesses construtores e nos relays. Em dezembro de 2023, mais de 93% dos blocos da Ethereum eram propostos por validadores que executavam o MEV-Boost.

No entanto, MEV-Boost e PBS não estão livres de problemas. O relay do MEV-Boost, operado pela Flashbots, impõe conformidade com a OFAC, um equilíbrio indesejável para um sistema justo e sem permissão. A centralização dos relays cria risco de censura e comportamento desonesto, pois eles se tornam intermediários essenciais entre construtores e validadores. Também há uma forte dependência de software fora do protocolo, como o MEV-Boost, o que aumenta a vulnerabilidade da Ethereum a exploits e ataques, como demonstram incidentes como o exploit low-carb-crusader. Há discussões em andamento para incorporar a PBS ao protocolo (ePBS) central da Ethereum, aproveitando grande parte do trabalho financiado pela Flashbots. A centralização dos construtores é outra preocupação: poucos deles dominam o mercado, o que pode levar à censura e à influência sobre a rede. Novas soluções, como a SUAVE, buscam reduzir essas preocupações.

A cadeia de suprimentos da Solana

Lançada em 2020, a Solana, uma L1 separada, trouxe diversos avanços para resolver o problema de escalabilidade na camada base sem soluções adicionais de terceiros, como L2s. O foco absoluto da Solana em permitir que as aplicações “compartilhem estado” entre si possibilita a composabilidade nativa entre aplicações, com o mínimo de trabalho para seus desenvolvedores e sem operações complexas adicionais para o usuário ou premissas extras de confiança, como ocorre com bridges.

Na Solana, uma transação consiste em três componentes principais: um conjunto de instruções que determina as operações da transação, uma lista de contas com as respectivas permissões com as quais ela interagirá e as assinaturas necessárias para autenticá-la. Quando o usuário confirma a transação, ela é enviada a um servidor RPC da Solana, que a encaminha ao líder atual da rede, responsável pela produção de blocos. Isso é conhecido como Gulf Stream, uma das oito inovações exclusivas viabilizadas pela Solana.

Ao recebê-la, o líder valida a transação e agenda sua execução. O modelo de execução paralela da Solana permite processar várias transações simultaneamente, viabilizando o paralelismo e os “mercados locais de taxas”. Isso é feito por meio de um agendador multithread, no qual as transações entram em fila com base nas taxas de prioridade e no tempo.

Após a execução, o líder registra a transação no ledger e a distribui pela rede. O status da transação é então atualizado em etapas: da execução para “confirmada” quando recebe votos de consenso suficientes e, por fim, para “finalizada” após o número necessário de blocos adicionais (31+) ser construído com segurança sobre ela.

Ao contrário da Ethereum, que empiricamente oferece garantias muito mais robustas de ordenação de transações com base em taxas, a Solana não tem ordenação determinística de transações. Embora transações com taxas de prioridade maiores geralmente tenham mais chances de ocupar posições superiores em um bloco, e situações de disputa pelo estado frequentemente exijam taxas mais altas, esse resultado não é garantido. A probabilidade dessas ocorrências é influenciada pela natureza não determinística do algoritmo padrão de agendamento da Solana, que determina a inclusão e a posição das transações em um bloco. Isso incentiva atividades fora do protocolo, incluindo acordos paralelos entre buscadores e validadores, o que gera externalidades negativas para o usuário mediano.

Sem dúvida, o MEV na Ethereum é um mercado muito maior, com mais de US$ 750 milhões (373.701 ETH) extraídos desde o Merge. Como resultado, mais tempo e recursos foram alocados ao MEV, que é consideravelmente mais compreendido e pesquisado, com mecanismos compatíveis com incentivos.

Essa é uma das principais diferenças filosóficas entre Ethereum e Solana, refletida na alocação de recursos e na cultura de cada ecossistema. Enquanto a Ethereum investe muito na pesquisa e no design de mecanismos compatíveis com incentivos, como a PBS, com discussões contínuas sobre a ePBS, o protocolo central da Solana foi projetado especificamente para sincronizar o estado global e delega a equipes do ecossistema, como a Jito, serviços e garantias especializados de ordenação. Anatoly (CEO da Solana Labs) deixa clara sua visão de que o estado atual da Solana é um equilíbrio melhor, ainda que temporário, para o usuário mediano.

Experiência do usuário (UX) em L1s

Do ponto de vista do usuário, enviar uma transação para uma blockchain Layer 1, como Ethereum ou Solana, é uma das ações mais simples no setor cripto e normalmente envolve as seguintes etapas:

1. Configuração da carteira

Primeiro, o usuário precisa baixar uma carteira. Pode ser uma carteira de software, como a MetaMask, um aplicativo móvel ou uma carteira de hardware para maior segurança.

2. Adquira o token nativo da L1

Verifique se sua carteira tem ETH/SOL suficiente para cobrir a transação e as taxas de gas. Você pode comprar ETH em várias exchanges centralizadas. Equipes e protocolos estão trabalhando em abstração de contas; um de seus recursos é permitir o pagamento de gas com qualquer token, não apenas com o token nativo da L1. A Ethereum implementa isso por meio da EIP-4337. A Solana tem abstração de contas nativa integrada ao protocolo e um relay de transações sem gas chamado Octane.

3. Insira os detalhes da transação

Acesse sua carteira e escolha a opção para enviar ETH ou tokens. Insira o endereço Ethereum do destinatário, a quantidade de ETH ou o número de tokens que deseja enviar e quaisquer dados adicionais, se necessário, para interações com contratos inteligentes. Se estiver interagindo com uma aplicação, a transação normalmente já estará preparada para você pelo desenvolvedor da aplicação.

4. Defina o preço e o limite de gas

A carteira definirá esses valores automaticamente ou permitirá que você os escolha. A implementação exata do gas varia conforme a L1 com a qual você interage.

5. Assine e envie

Assine a transação com sua carteira; esse processo varia conforme a carteira. Em seguida, ela transmitirá a transação para a rede, geralmente por meio de um nó RPC.

6. Confirmação

Quando sua transação é incluída em um bloco e adicionada à blockchain, ela é confirmada. A maioria das carteiras avisa quando a transação é concluída, e você também pode acompanhá-la em um explorador de blockchain, como Etherscan ou Solscan.

Experiência do usuário (UX) em L2s

Há diferenças claras de UX ao interagir com uma L2. Veja como um novo usuário começaria a usar a Optimism, uma das maiores L2s da Ethereum:

1. Baixe uma carteira

Se você ainda não tiver uma, baixe e configure uma carteira. Normalmente, os usuários utilizam a mesma carteira em diferentes ecossistemas EVM, como a Metamask.

2. Adicione a rede Optimism

3. Deposite ETH na Optimism

• Em L2s grandes, isso geralmente pode ser feito de forma nativa na carteira.
• Como alternativa, você pode acessar a bridge oficial da Optimism.
• Escolha a quantidade de ETH que deseja transferir para a Optimism e confirme a transação.

4. Mude para a rede Optimism na sua carteira

Abra sua carteira e selecione "Optimism" no menu suspenso de redes.

5. Interaja com aplicações e front-ends compatíveis com a Optimism

Escolha “Optimism” nas aplicações compatíveis com a rede Optimism.

As L2s avançaram em UX, especificamente em ativos nativos e integração inicial. A Circle, que opera o USDC, oferece versões nativas do USDC na maioria das principais L2s, eliminando o risco adicional de contraparte normalmente associado a bridges e tokens wrapped. Além disso, a vantagem de distribuição da Coinbase permitiu integrações estreitas entre sua plataforma e a Base, uma L2 da Ethereum na qual ela é a única operadora do sequenciador.

Componentes de uma L2

Depois de transferir fundos para uma L2 por uma bridge — um processo que pode ser pouco claro e complexo, dependendo da L2 usada —, a experiência do usuário ao fazer transações em uma L2 costuma ser semelhante à de uma L1. Embora, no passado, as L2s tenham usado principalmente a Ethereum para diferentes partes da stack da blockchain, muitas L2s atuais estão adotando uma abordagem “modular”. Essa abordagem permite combinar diferentes ecossistemas e infraestruturas, separando os principais componentes de uma L2: execução, liquidação e disponibilidade de dados. Antes, as L2s usavam a Ethereum para tudo, exceto execução, mas isso está mudando rapidamente com novas soluções de liquidação e disponibilidade de dados. As L1s, por sua vez, oferecem todos esses componentes de forma integrada e prescritiva, sem permitir que os desenvolvedores escolham a arquitetura desejada sem aprovação da governança.

Execução

O objetivo da execução é aplicar uma função de transição de estado ao estado anterior para gerar o estado posterior. Diferentes máquinas virtuais (VMs), como a Ethereum Virtual Machine (EVM), a Sealevel da Solana (SVM) e outras, como MoveVM e FuelVM, são usadas como padrões para reger essas transições de estado. Cada VM oferece recursos únicos que afetam a compatibilidade, a disponibilidade de ferramentas para desenvolvedores e a eficiência no processamento de transações. Elas criam o ambiente para executar contratos inteligentes e protocolos.

É na interação com a camada de execução que os desenvolvedores de aplicações efetivamente implantam código, as transações ocorrem e os usuários interagem com o estado da blockchain. Essa camada foi projetada para processar transações rapidamente, delegando as responsabilidades de segurança e disponibilidade de dados a outras camadas especializadas.

Não é necessário que a máquina virtual da L2 corresponda à máquina virtual da L1. Embora historicamente esse tenha sido o caso — a maioria das L2s são rollups EVM ou compatíveis com EVM —, mais equipes estão explorando esse espaço de design com diferentes máquinas virtuais que “liquidam” na Ethereum, como Eclipse e Movement Labs.

Liquidação

Neste momento, muitos consideram a palavra “liquidação” um termo sobrecarregado. Para entendê-la, é importante distinguir o ponto de vista do “rollup” do ponto de vista da “bridge”. As bridges costumam seguir um processo de finalização de uma semana, mas a bridge não é o rollup. Do ponto de vista do rollup, a finalização ocorre após a verificação da transição de estado e a publicação dos dados relevantes em uma camada de disponibilidade de dados.

As camadas de liquidação cumprem várias funções essenciais para os rollups:

• Verificação e gestão de disputas: funcionam como plataformas nas quais os rollups podem publicar suas provas para validação externa, algo essencial para rollups otimistas que dependem de provas interativas de falha.
• Hub de bridges: ao atuar como um ponto central, as camadas de liquidação permitem a interconexão dos rollups, eliminando a necessidade de bridges individuais entre cada rollup.
• Fonte de liquidez: todos os rollups associados podem acessar a liquidez presente na camada de liquidação, facilitando transações e interações.

Como mencionado, a Ethereum tem os ativos mais interessantes e valiosos em termos nominais no setor cripto — as pessoas querem interagir com o estado da Ethereum. Ela é usada como uma “camada de liquidação” porque os usuários demonstram forte preferência por interagir com uma bridge integrada ao protocolo para uma blockchain separada, isto é, a L2 da Ethereum que utilizam. O mercado não enxerga as bridges entre L1s da mesma forma, provavelmente devido a hacks anteriores e a uma UX mais complexa, já que a transferência entre L1 e L2 por bridge muitas vezes pode ser estreitamente integrada a uma única carteira. A UX está melhorando rapidamente com carteiras como a Phantom, que oferece suporte a Ethereum e Solana, e com o lançamento do Snaps pela Metamask. Em termos mais formais, os usuários se sentem confortáveis interagindo com a bridge integrada ao protocolo definida por determinado rollup.

O comportamento dos usuários está mudando rapidamente. A Wormhole movimentou mais de US$ 500 milhões em volume nos últimos 30 dias, reduzindo a diferença para o volume de US$ 825 milhões da bridge da Optimism no mesmo período de 30 dias.

Pode-se argumentar que as bridges entre L1s enfrentaram dificuldades devido à dependência da trajetória, com grandes ataques como o hack da Wormhole no início de 2022. Embora o compartilhamento de DA possibilite premissas de confiança técnicas específicas, as implementações reais de bridges entre L1 e L2 e entre L1s costumam ser protegidas por uma multisig.

A principal conclusão é que os rollups “liquidam na Ethereum” — ou, mais precisamente, finalizam uma bridge integrada ao protocolo para a Ethereum — a fim de acessar o estado da Ethereum com o propósito explícito de alcançar usuários e liquidez. A liquidação em si não é uma atividade lucrativa para a Ethereum, pois rollups como a Optimism pagam menos de US$ 50 por dia em ETH à Ethereum pela liquidação. Mais de 80% dos custos dos rollups correspondem à publicação de dados em blocos da L1 da Ethereum como calldata. É por isso que hoje vemos tanta concorrência entre soluções de disponibilidade de dados. No total, as L2s representam aproximadamente ~6% das taxas da L1 da Ethereum, ao usarem a Ethereum para disponibilidade de dados.

Disponibilidade de dados (DA)

A disponibilidade de dados em blockchains se refere à garantia de que todos os dados de um bloco sejam realmente publicados e acessíveis à rede. Esse conceito é essencial para o funcionamento e a segurança das blockchains, especialmente ao escalá-las. Normalmente, um bloco é composto por um cabeçalho e pelos dados das transações. Nós completos baixam e validam todas as transações, enquanto clientes leves, que exigem menos recursos, dependem apenas do cabeçalho do bloco e presumem que as transações sejam válidas. O problema da disponibilidade de dados surge quando um produtor publica o cabeçalho de um bloco, mas retém parte ou a totalidade dos dados das transações.

Embora ainda não tenham ocorrido, ataques de retenção de dados representam uma ameaça às redes blockchain. Nesse tipo de ataque, um produtor de blocos mal-intencionado retém deliberadamente parte dos dados de transações de um novo bloco. Isso impede que outros participantes da rede validem as transações do bloco. As consequências da retenção de dados podem variar de interrupções na rede a problemas mais graves, como permitir transações fraudulentas. A gravidade e o impacto desses ataques variam de acordo com a estrutura da blockchain (Layer 1 ou Layer 2) e com a gestão da disponibilidade de dados on-chain ou off-chain. Esse risco ressalta a importância de mecanismos robustos para garantir a disponibilidade de dados e a necessidade de estratégias eficazes para reduzir esses ataques.

Resolver o problema da disponibilidade de dados envolve métodos como fazer com que todos os nós completos baixem todos os dados, o que pode exigir muitos recursos, ou abordagens inovadoras, como provas de disponibilidade de dados e amostragem de disponibilidade de dados (DAS). Essas provas usam técnicas como codificação de apagamento, permitindo que os clientes verifiquem a disponibilidade dos dados baixando apenas uma pequena parte do bloco.

Um verdadeiro “rollup da Ethereum” — de acordo com a terminologia mais atual — precisa usar a Ethereum para disponibilidade de dados. Isso significa que o rollup deve publicar os dados das transações na L1 da Ethereum como calldata para ser considerado um rollup. A Ethereum trabalha atualmente na implementação da EIP-4844, que criará um mercado separado para blobspace (dados de transações) e permitirá que blobs de dados sejam publicados a uma tarifa ainda mais reduzida. Mesmo quando a 4844 estiver disponível, ela aumentará a disponibilidade de dados apenas por um fator de ~7, o que corresponde a cerca de 100 TPS (transações por segundo) em todos os rollups. Como referência, a demanda da Solana por espaço de bloco é de cerca de 500 TPS, e ela já demonstrou a capacidade de processar mais de 2.000 TPS. Além disso, a Solana foi projetada para escalar com avanços de hardware (Lei de Moore) e de software, como o Firedancer.

Embora a disponibilidade de dados possa apresentar alguns efeitos de rede modestos, a concorrência provavelmente reduzirá o custo de publicação dos dados em uma solução de disponibilidade de dados até muito próximo do custo operacional marginal.

A DA garante que todos os dados de transações necessários estejam acessíveis para reconstruir o estado de uma L2 durante um período predefinido. No curto prazo, validiums e volitions usam camadas separadas de disponibilidade de dados, enquanto o roadmap de longo prazo da Ethereum inclui uma solução aprimorada de disponibilidade de dados por meio de atualizações como a EIP-4844. Espera-se que soluções alternativas de disponibilidade de dados, como Polygon Avail, Celestia e EigenDA, desempenhem papéis importantes e explorem ainda mais diferentes designs de DA. No entanto, é importante observar que essas soluções ainda não estão disponíveis, com exceção da Celestia, que acabou de lançar sua mainnet, mas ainda não tem rollups publicando dados. Todas são construídas sobre sistemas novos e ainda não comprovaram seu funcionamento em escala em ambientes de produção, com um amplo espectro de premissas específicas de segurança e confiança. Essas soluções oferecem uma correção temporária até que a camada abrangente de disponibilidade de dados da Ethereum entre em operação e podem demonstrar efeitos de rede mesmo após a integração com a Ethereum.

Ciclo de vida de uma transação L2

O ciclo de vida de uma transação na Arbitrum, um protocolo Layer 2, envolve várias etapas, da iniciação à confirmação e finalização:

1. O sequenciador recebe a transação

As transações começam no sequenciador, que as recebe diretamente/off-chain no caso de transações L2 ou da L1 por meio da Delayed Inbox no caso de depósitos.

2. O sequenciador ordena a transação off-chain

O sequenciador ordena a transação em sua Inbox off-chain e a executa usando a Arbitrum Nitro VM, fornecendo um recibo "instantâneo" ao cliente. A finalidade dessa fase depende da confiança no sequenciador.

3. O sequenciador publica a transação on-chain em um lote

Em intervalos regulares, o sequenciador publica lotes de transações L2 na L1, incluindo os dados relevantes como calldata. Se o sequenciador não incluir uma transação, o cliente poderá forçar sua inclusão após um atraso, isto é, usar a inclusão forçada. Nessa etapa, se houver pelo menos um validador ativo e bem-comportado da Arbitrum, a finalidade da transação será equivalente à de uma transação da Ethereum.

4. O validador declara um bloco do rollup (RBlock) que inclui a transação

Os validadores declaram o estado da blockchain L2 na L1 em intervalos regulares. As declarações de RBlock incluem afirmações sobre o estado da Outbox para mensagens da L2 para a L1. Em caso de contestação: se houver uma disputa, os validadores participam de um processo detalhado de verificação até uma única operação, arbitrado por contratos na L1.‍

5. O RBlock é confirmado na L1

Após a resolução das disputas e uma janela de tempo suficiente, o RBlock é confirmado na L1, atualizando a raiz da Outbox.

Esse processo garante que, quando uma transação L1 que registra um lote é confirmada, a transação L2 contida nele tem o mesmo nível de finalidade de uma transação comum da Ethereum. Se a transação incluir mensagens da L2 para a L1, elas só poderão ser executadas na L1 após a confirmação do RBlock.

Como os rollups existem fora da Ethereum — o que não deve ser confundido com o fato de muitos rollups atuais serem construídos na EVM ou equivalentes à EVM —, há considerações e participantes adicionais na cadeia de suprimentos das transações. Veja a seguir as características da Arbitrum e da Optimism, os rollups dominantes na Ethereum atualmente:

• Sequenciador centralizado: Arbitrum e Optimism, os maiores rollups otimistas da Ethereum, operam atualmente com um único sequenciador centralizado. Esse sequenciador é responsável por ordenar todas as transações. Os planos futuros envolvem descentralizar essa função, possivelmente com nós L2 escolhidos pela comunidade, mas os detalhes e os prazos ainda não estão claros. Os usuários confiam que o sequenciador não venderá o fluxo de ordens, não reordenará transações nem extrairá MEV de outras formas. As provas de falha estão no roadmap, mas ainda não estão disponíveis para contestações sem permissão.
• Premissa de confiança: a finalidade nessa etapa depende da confiança no sequenciador. A função do sequenciador se limita a ordenar ou atrasar transações, não a alterá-las. A Arbitrum permite que transações atrasadas por mais de 24 horas sejam incluídas à força, enquanto a Optimism inclui automaticamente as transações da L1 no próximo bloco L2 disponível.
• Reorganizações da L1: se ocorrer uma reorganização da L1, a política de continuidade e tratamento dos blocos L2 não está explicitamente detalhada. Isso deixa alguma incerteza sobre a finalidade das transações durante reorganizações da L1.
• Finalidade: os sequenciadores agrupam transações L2 e as publicam na Ethereum como calldata, alcançando uma “finalidade forte” equivalente à finalidade do bloco da Ethereum no qual estão incluídas. A raiz da árvore de estados da L2, que representa o estado mais recente do rollup, é então atualizada na L1, garantindo mudanças de estado irreversíveis.
• Período de contestação e saque: os validadores da Arbitrum podem contestar raízes de estado, iniciando um processo de resolução de disputas. Se um compromisso de estado não for contestado durante o período designado, ele se torna final. Após o período de contestação, são permitidos saques da L2 para a L1 com base no estado final.
• Bridges: os protocolos de bridge consideram diferentes níveis de finalidade, desde recibos instantâneos sob “finalidade branda” até calldata em lotes sob “finalidade forte”. As bridges podem optar por mensagens mais rápidas com base nas necessidades dos clientes ou seguir padrões de finalidade mais rigorosos, dependendo do tipo de transação e da avaliação de risco.

Onde as L2s fazem sentido

L2s são sistemas com estado. Cada L2 adicional fragmenta o estado entre as diferentes L2s. Embora a composabilidade atômica seja sacrificada — o que pode ou não ser superestimado —, fazer deploy em uma L2 faz sentido para algumas aplicações. Além disso, escolher a L2 correta é muito importante, mesmo quando elas são executadas em um ambiente popular como a EVM. Diferentes L2s oferecem experiências de usuário, integrações e distribuição muito distintas.

Sem entrar em muitos detalhes técnicos, as L2s podem ser amplamente divididas em rollups específicos de aplicações e rollups de uso geral.

Rollups específicos de aplicações

Ao contrário das L1s e de outras L2s mencionadas anteriormente, os rollups específicos de aplicações não compartilham espaço de bloco com outras aplicações. Em vez disso, são blockchains dedicadas a uma aplicação específica — ou a um conjunto de aplicações. Como resultado, você é responsável por operar toda a infraestrutura correspondente.

Embora algumas equipes sejam verticalmente integradas e operem efetivamente a própria infraestrutura (dydx), isso exige um enorme esforço de engenharia e, em geral, só é feito com sucesso por equipes que já alcançaram adequação do produto ao mercado (PMF). No caso da dydx, ela tem adequação do produto ao mercado, uma comunidade forte e recursos suficientes para isso — depois de encontrar PMF na Ethereum e, posteriormente, em uma L2 da Ethereum. Outros projetos, como a Maker, estão explorando arquiteturas como uma app-chain SVM. Na prática, a maioria das equipes não opera o próprio hardware. Em vez disso, elas dependem de provedores de rollup como serviço (RaaS) que buscam preencher essa lacuna, como Caldera e Conduit.

Ainda não se sabe se as chains específicas de aplicações conseguirão gerar receita suficiente para serem lucrativas no longo prazo. Nesses casos, é importante entender o risco de contraparte e a estrutura de custos dos provedores de RaaS. Esses provedores normalmente cobram uma taxa fixa — muitas vezes entre US$ 5.000 e US$ 100.000, dependendo do tamanho da aplicação — e uma porcentagem dos lucros do sequenciador. A maioria dos provedores de RaaS utiliza padrões amplamente aceitos, como o OP Stack, para evitar o “lock-in”. Isso significa que, mesmo se o provedor de RaaS encerrar suas atividades, você ainda poderá operar o próprio hardware, desde que consiga superar a falha temporária de disponibilidade.

Como jogos são um caso de uso mais especializado, novas implementações e protocolos estão sendo desenvolvidos ativamente, como o World Engine da Argus. Em 5 de dezembro, o Dark Frontiers foi lançado como um shard de execução sobre a L2 EVM da Argus para jogos totalmente on-chain, ao contrário de outros jogos on-chain atuais que registram na blockchain apenas itens simples do jogo. Embora ainda seja cedo para avaliar, essa solução parece ficar em algum ponto entre os rollups específicos de aplicações e os rollups de uso geral.

Rollups de uso geral

Por serem ambientes isolados com menos capital econômico em risco, os rollups têm certo incentivo para experimentar com determinadas camadas da stack, como os níveis de execução e consenso, a fim de oferecer um produto diferenciado. No entanto, a maioria dos rollups usa versões prontas de VMs existentes, com exceção da Fuel. Isso acontece porque eles têm o incentivo de facilitar ao máximo o deploy de aplicações existentes em suas L2s. Esse cenário levou equipes que inovam nos níveis de execução e consenso a lançar suas próprias L1s, como a Monad.

Podemos ver mais experimentação na camada de execução em breve, já que o número de rollups supera em muito um equilíbrio razoável, especialmente entre aqueles que enfrentam dificuldades para atrair usuários e liquidez.

Estado atual dos rollups de uso geral

Rollups de uso geral como Arbitrum, Optimism e Base demonstraram fortes efeitos de rede e atraíram inúmeras aplicações existentes e novas para lançamentos em L2s, como GMX e friend.tech. A presença dos ativos e do estado nativos da Ethereum nessas L2s — que frequentemente usam Ethereum para denominar seu token de gas — garante que usuários e desenvolvedores tenham acesso a um ecossistema rico e maduro. Esse acesso é essencial para aplicações que buscam liquidez e integração com protocolos e ativos existentes baseados na Ethereum. Quanto à experiência do usuário, plataformas como a Coinbase integraram carteira nativa e suporte a pagamentos para a Base — onde operam o único sequenciador —, tornando a interação simples e intuitiva.

Ao considerar diferentes L2s, é importante avaliar ambientes de execução alternativos para o deploy, a liquidez e a própria infraestrutura da L2. Fatores como a estrutura de custos da disponibilidade de dados, possíveis mudanças futuras nas taxas da rede e a evolução do mercado de provedores de infraestrutura devem orientar o processo de decisão. Os desenvolvedores de aplicações precisam entender a estrutura de custos atual para os usuários e fazer projeções razoáveis para o futuro com base em diferentes fatores, especialmente o custo da disponibilidade de dados. Para desenvolvedores que consideram um deploy em L2, é crucial entender as nuances dos sistemas, com atenção especial ao ambiente de execução escolhido e às oportunidades alternativas de deploy.

Pesquisas inovadoras lideradas pela Ethereum Foundation, como os “rollups baseados” sequenciados pela L1, indicam que os rollups continuarão evoluindo em disponibilidade, descentralização e experiência do usuário. Sequenciadores descentralizados — ou pelo menos uma rotação entre vários sequenciadores para garantir a disponibilidade — ainda estão em fase de pesquisa, mas oferecem avanços promissores para aumentar a confiabilidade e reduzir o risco atual associado aos sequenciadores. Hoje, os usuários confiam que o sequenciador operado pela equipe principal da L2 irá ordenar as transações de maneira justa e não extrair MEV de forma maliciosa reordenando transações. Em caso de censura pelo sequenciador, os usuários também podem enviar transações diretamente à L1 por meio de inclusão forçada.

Por outro lado, os rollups atuais não têm alguns recursos essenciais que estão sendo desenvolvidos ativamente de acordo com seus roadmaps. Por exemplo, nenhum dos principais rollups otimistas oferece provas de falha sem permissão, e esses sistemas muitas vezes são controlados por contratos atualizáveis por meio de multisigs. Além disso, muitos rollups não oferecem mecanismos de saída para que os usuários retirem fundos quando há um sequenciador malicioso.

O estágio final dos rollups de uso geral

Um estágio final para rollups de uso geral com um sequenciador robusto — ou um conjunto de sequenciadores — é um resultado possível. Em um mundo no qual a Ethereum mantém sua posição como a chain com o estado mais interessante e os usuários continuam preferindo fortemente pontes de L1 para L2, uma ou mais L2s de rollup de uso geral podem oferecer vantagens significativas de execução e uma experiência de usuário muito melhor. 

Na prática, a L1 existiria apenas para oferecer as propriedades exigidas pelo rollup, eliminando para a L2 o risco de reorganização da L1 e permitindo que a L2 fosse otimizada para os aspectos importantes aos usuários finais: latência e atualização do estado com a maior eficiência possível, normalmente na forma de preços melhores. A Ethereum — a L1 escolhida — ainda teria um papel, pois o consenso social continuaria atribuindo valor ao estado da Ethereum por razões meméticas, como participantes com descentralização confiável, lançamento justo e outros fatores. A L2 existiria como uma entidade externa à L1.

Os rollups apresentarão os seguintes recursos e propriedades:

• Inovação sem permissão – qualquer pessoa pode criar e fazer deploy de novas aplicações
• Resistência à censura – por meio de inclusão forçada na L1
• Disponibilidade de dados – diretamente na L1 ou em uma camada de DA separada
• Validade – provas de falha ou provas zk
• Ambiente de execução paralelizado – as transações são processadas com extrema eficiência

Nesse estágio final, existem poucos rollups — talvez dois — com volume e uma base de usuários relevantes. Uma nova aplicação escolhe fazer deploy nesse rollup porque o custo de compartilhar o espaço de bloco — amortizado até ficar o mais próximo possível de zero — é compensado pelo amplo acesso aos usuários. As preferências demonstradas pelos usuários indicam que uma UX simples é uma prioridade elevada. Se algum dia chegarmos a esse cenário, o setor cripto terá efetivamente reinventado as finanças tradicionais com várias melhorias importantes: inovação sem permissão, resistência à censura, ausência de custódia e transparência. Apenas um pequeno grupo de participantes tem acesso de escrita aos mercados financeiros tradicionais. A NYSE e outras bolsas são mercados rigorosamente regulamentados e com acesso restrito, capazes de censurar indivíduos conforme determinam as leis e os regulamentos.

Nesse cenário, a latência e a colocalização com sequenciadores continuariam existindo, assim como ocorre nas finanças tradicionais com servidores de livros de ofertas. Atualmente, o acesso restrito determinado por questões políticas e pela dependência de trajetória define quais entidades têm o direito de manter infraestrutura junto aos servidores da NYSE. As décadas de experiência da Citadel na otimização de infraestrutura e algoritmos que oferecem melhores preços aos usuários finais continuariam relevantes em um ambiente sem permissão. Nesse estágio final dos rollups, indivíduos e equipes competiriam com todas as outras pessoas talentosas do mundo estritamente com base em desempenho, resultando em preços e experiências melhores para os usuários finais.

Embora tudo isso pareça bom na teoria, o estado atual das L2s apresenta uma realidade muito diferente. Além de os únicos sequenciadores serem operados pela equipe principal — criando um ponto único de falha de disponibilidade —, eles frequentemente controlam as ações mais importantes, seja o contrato da ponte ou as provas de falha com permissão. Embora muitas L2s tenham em seus roadmaps a descentralização e a remoção da multisig, essa ainda não é a realidade atual.

Onde as L1s fazem sentido

O conceito de estado compartilhado em blockchains de camada 1, como Solana e Ethereum, permite a composabilidade sem permissão. Isso significa que aplicações podem interagir entre si de forma segura e sem depender de confiança. Uma das utilidades desse recurso está em estratégias de marketing, como airdrops direcionados. Por exemplo, ao utilizar o estado compartilhado, um projeto pode identificar e recompensar comunidades específicas de NFT, permitindo mecanismos de recompensa altamente direcionados e eficazes. A Pyth, um oráculo multichain de dados, recentemente fez um airdrop de $PYTH na Solana para todas as pessoas que interagiram com seu protocolo em mais de 40 blockchains. Ao analisar padrões de propriedade e o engajamento da comunidade na blockchain, os projetos podem personalizar suas recompensas — como tokens exclusivos ou acesso a novos serviços — para incentivar e envolver segmentos específicos da comunidade blockchain, criando iniciativas de marketing mais relevantes e impactantes.

O estado compartilhado permite de forma única essas atribuições on-chain para recompensas e ações. A Jupiter, um agregador unificado de negociação que garante aos usuários os melhores preços possíveis, é um exemplo de aplicação que só pode existir em uma chain com estado compartilhado, como a Solana.

Em conjunto com DeFi, os pagamentos são um dos casos de uso mais importantes do setor cripto, permitindo que os usuários enviem qualquer quantia de valor sem intermediários extrativistas como a Western Union. Os pagamentos abrangem tanto transações entre pessoas, como no Venmo, quanto transações de empresas para consumidores, como em compras on-line. É importante que os pagamentos sejam tão baratos e rápidos que os usuários não precisem considerar os custos de gas ao enviar dinheiro. Na Solana, mais da metade das transferências de USDC é inferior a US$ 5, algo possível apenas em blockchains com custos de gas extremamente baixos, como a Solana.

Isso permite criar novos negócios, como a Tiplink, que possibilita enviar dinheiro usando uma URL sem precisar configurar uma carteira — você pode até se cadastrar com suas credenciais do Google. A Shopify integrou o Solana Pay para permitir que os clientes finalizem compras pagando em USDC na Solana. A Visa escolheu integrar a Solana para liquidar USDC para as adquirentes globais Worldpay e Nuvei. A Code usou nonces duráveis para criar um ambiente de execução pseudoassíncrono e desenvolver um sistema extremamente rápido de notificações de pagamento, além de uma experiência de usuário simples. Embora algumas pessoas chamem isso de L2, a solução não tem provas de falha e é otimizada exclusivamente para oferecer uma experiência melhor ao usuário final.

A Solana não tem L2s porque as transações já são muito baratas e o estado é separado e precificado nativamente dentro de cada bloco. Desde o início, a Solana foi otimizada para sincronizar o estado com a maior rapidez permitida pela física e aproximar o custo de uma transação do custo marginal de operação. Na Ethereum, as transações são muito mais caras, em parte devido à EVM single-threaded, e o estado só pode ser precificado separadamente quando outra instância da máquina virtual está em execução, que é o que as L2s fazem. A Solana e outras blockchains com VMs paralelas permitem mercados de taxas locais, nos quais diferentes partes do estado têm taxas distintas conforme o nível de disputa por uma parte específica. Um ponto de alta demanda localizado no estado pode ser gerenciado sem aumentar a disputa ou as taxas em toda a blockchain. Na prática, isso significa que a emissão de um NFT ou um airdrop gera poucas externalidades para uma aplicação separada. 

Ao contrário das L2s, o estágio final da Solana não está no roadmap: ele já existe. Embora a Solana seja mantida e aprimorada ativamente por meio de SIMDs, ela é um livro-razão de ativos funcional e comprovadamente neutro, que não exige confiança adicional em multisigs, alinhamento ou narrativas.

Qual é a melhor solução para mim?

Bem, isso depende do que você deseja otimizar. Como regra geral, um desenvolvedor de aplicações ou proprietário de negócio deve dedicar o mínimo de tempo necessário à manutenção da infraestrutura blockchain e o máximo possível à evolução do produto para criar a melhor experiência de usuário. A questão é: quanto tempo é necessário para você?

Ao escolher uma chain específica, é preciso estudar com cuidado os recursos primitivos disponíveis nela, como demonstra o caso de aplicações como a Drip, que já emitiu mais de 60 milhões de NFTs e tem 500 mil colecionadores.

O que você pretende otimizar acabará restringindo suas opções de chain. Com base no resumo acima sobre as diferentes L1s e L2s, estas são algumas dimensões a considerar:

1. Usuários on-chain
2. Uso on-chain (se você estiver otimizando para uma função on-chain específica, como negociação, deverá analisar as chains que oferecem um ambiente de taxas baixas, como Solana, Sui ou Optimism. Você também precisará entender as escolhas técnicas e as limitações relacionadas a tempos de bloco menores, blocos maiores e outros fatores.)
3. Tempo de execução
4. Liquidez on-chain
5. Grandes detentores e liquidez on-chain (por exemplo, o ecossistema EVM tende a ter mais liquidez devido à era anterior de lançamentos de tokens, mas isso está mudando rapidamente)
6. Acesso a comunidades on-chain específicas (artistas, traders etc.)
7. Disponibilidade de subsídios e capital de risco (ecossistemas mais novos têm mais capital para subsídios, mas menos capital de risco)
8. Complexidade técnica e sobrecarga de gerenciamento (por exemplo, a Code precisa de apenas dois engenheiros para operar sua aplicação na Solana, enquanto a dydx precisa de mais de 30 engenheiros e pesquisadores)
9. Programabilidade e soberania sobre as regras da chain (por exemplo, regras específicas de liquidação de negociações)
10. Acesso a participantes institucionais (por exemplo, Coinbase na Base e Visa e Shopify na Solana)
11. Composabilidade com outras aplicações do ecossistema (por exemplo, DeFi e aplicações de pagamento)

Fazer deploy em estruturas específicas de rollup pode ser uma boa opção para determinadas aplicações que entendam e aproveitem de forma única as propriedades mencionadas acima. Para a maioria das aplicações, a Solana oferece os recursos primitivos necessários para alcançar o sucesso. Suas decisões arquitetônicas únicas permitem que ela seja rápida, barata e eficiente, além de já estar em produção há muitos anos.

Conclusão

Entender e navegar pelo cenário das blockchains, especialmente ao escolher entre plataformas de camada 1 (L1) e camada 2 (L2), exige uma compreensão detalhada das concessões envolvidas. A escolha entre L1 e L2 vai além de uma decisão técnica: é uma estratégia comercial crucial que influencia a escalabilidade, a segurança e a viabilidade geral de um projeto. Refatorar uma base de código inteira também gera mais dívida técnica e reduz sua probabilidade de criar uma aplicação bem-sucedida.

É impossível exagerar a importância da experiência do usuário para a adoção da blockchain. Conforme a tecnologia amadurece, o foco deve se voltar cada vez mais à criação de interfaces intuitivas, integradas e fáceis de usar, capazes de superar a distância entre a complexa infraestrutura blockchain e o usuário final. Embora diferentes aplicações se beneficiem de diferentes níveis de flexibilidade, a maioria dos desenvolvedores deve escolher uma plataforma que permita dedicar o máximo de tempo possível à criação do melhor produto.

Agradecemos a Akshay, 0xIchigo e Jon Charbonneau pela revisão e pelos comentários.