O parceiro da Multicoin Capital, Kyle Samani, discorre sobre 7 razões pelas quais os blockchains modulares estão supervalorizados.
Escrito por: Kyle Samani, sócio, Multicoin Capital
Compilado por: Luffy, Foresight News
Nos últimos dois anos, o debate sobre a escalabilidade da blockchain concentrou-se no tema central do “debate entre modularidade e integração”.
Observe que as discussões sobre criptomoedas geralmente combinam sistemas “únicos” e “integrados”. O debate técnico sobre sistemas integrados versus sistemas modulares já dura 40 anos. Essa conversa no espaço das criptomoedas deve ser enquadrada pelas mesmas lentes da história, e isso está longe de ser um debate novo.
Ao considerar a modularização versus a integração, a decisão de design mais importante que uma blockchain pode tomar é até que ponto a complexidade da pilha é exposta aos desenvolvedores de aplicativos. Os clientes da blockchain são os desenvolvedores de aplicativos, portanto, as decisões de design finais devem considerar sua perspectiva.
Hoje, a modularização é amplamente elogiada como a principal maneira de escalar blockchains. Neste artigo, questionarei essa suposição a partir de primeiros princípios, revelando os mitos culturais e os custos ocultos dos sistemas modularizados, e compartilharei as conclusões que cheguei ao refletir sobre esse debate nos últimos seis anos.
Sistemas modularizados aumentam a complexidade de desenvolvimento.
Até agora, o maior custo oculto dos sistemas modularizados é a complexidade adicional do processo de desenvolvimento.
Sistemas modularizados aumentam significativamente a complexidade que os desenvolvedores de aplicativos devem gerenciar, tanto em seu próprio contexto de aplicativo (complexidade técnica) quanto no contexto de interagir com outros aplicativos (complexidade social).
No contexto das criptomoedas, as blockchains modularizadas teoricamente permitem maior especialização, mas isso vem à custa de criar nova complexidade. Essa complexidade (essencialmente técnica e social) está sendo transferida para os desenvolvedores de aplicativos, tornando a construção de aplicativos mais difícil.
Por exemplo, considere o OP Stack. Até o momento, parece ser a estrutura modular mais popular. O OP Stack força os desenvolvedores a escolher entre adotar a Lei das Cadeias (o que traz muita complexidade social) ou bifurcar e gerenciar separadamente. Ambas as escolhas trazem uma enorme complexidade downstream para os construtores. Se você escolher bifurcar, obterá suporte técnico de outros participantes do ecossistema (CEX, pontos de entrada fiduciários, etc.) que precisam arcar com custos para se adequar aos novos padrões técnicos? Se você optar por seguir a Lei das Cadeias, quais regras e restrições serão impostas a você hoje e amanhã?
Fonte: Modelo OSI
Sistemas operacionais modernos (OS) são grandes sistemas complexos que contêm centenas de subsistemas. Sistemas operacionais modernos lidam com os níveis 2-6 mostrados na figura acima. Este é um exemplo típico de integração de componentes modularizados para gerenciar a complexidade da pilha exposta aos desenvolvedores de aplicativos. Os desenvolvedores de aplicativos não querem lidar com nada abaixo do nível 7, que é exatamente a razão pela qual os sistemas operacionais existem: os sistemas operacionais gerenciam a complexidade dos níveis abaixo, para que os desenvolvedores de aplicativos se concentrem no nível 7. Portanto, a modularização em si não deve ser o objetivo, mas sim um meio para alcançar um fim.
Todo sistema de software principal no mundo de hoje — back-end em nuvem, sistemas operacionais, mecanismos de banco de dados, motores de jogos, etc. — é altamente integrado, ao mesmo tempo que é composto por muitos subsistemas modularizados. Sistemas de software tendem a ser altamente integrados para maximizar o desempenho e minimizar a complexidade de desenvolvimento. O mesmo vale para blockchains.
A propósito, o Ethereum está reduzindo a complexidade que surgiu na era dos forks do Bitcoin de 2011-2014. Os apoiadores da modularização frequentemente enfatizam o modelo de interconexão de sistemas abertos (OSI), acreditando que a disponibilidade de dados (DA) e execução devem ser separadas; no entanto, esse argumento é amplamente mal interpretado. A compreensão correta dos problemas atuais leva a conclusões opostas: o OSI é um argumento para sistemas integrados, não para sistemas modularizados.
Cadeias modularizadas não podem executar código mais rápido.
Por design, a definição comum de "cadeia modular" é a separação da disponibilidade de dados (DA) e execução: um conjunto de nós é responsável pelo DA, enquanto outro conjunto (ou conjuntos) de nós é responsável pela execução. Os conjuntos de nós não precisam ter sobreposição, mas podem.
Na prática, separar DA e execução não aumentará essencialmente o desempenho de nenhum deles; ao contrário, em algum lugar do mundo, algum hardware deve executar o DA, e algum hardware deve implementar a execução. Separar essas funções não melhorará o desempenho de nenhuma delas. Embora a separação possa reduzir os custos de computação, isso só pode ser alcançado através da execução centralizada.
É importante reiterar: seja a arquitetura modular ou integrada, algum hardware em algum lugar deve fazer o trabalho, e separar o DA e a execução em hardware separado não acelerará nem aumentará a capacidade total do sistema de forma essencial.
Alguns acreditam que a modularização permite que múltiplos EVM operem em paralelo de forma Rollup, permitindo que a execução escale horizontalmente. Embora isso seja teoricamente correto, essa perspectiva realmente destaca as limitações do EVM como processador de thread única, e não o pressuposto fundamental de separar DA e execução no contexto da escalabilidade do throughput total do sistema.
A modularização por si só não melhora o throughput.
A modularização aumenta o custo das transações para os usuários.
Por definição, cada L1 e L2 é um livro de ativos independente com seu próprio estado. Esses fragmentos de estado separados podem se comunicar, embora a latência das transações seja maior e a situação que os desenvolvedores e usuários enfrentam seja mais complexa (por meio de pontes cross-chain como LayerZero e Wormhole).
Quanto mais livros de ativos, mais fragmentos do estado global existirão para todas as contas. Isso é assustador tanto para as cadeias quanto para os usuários que operam em várias cadeias. A fragmentação do estado pode trazer uma série de consequências:
Redução da liquidez, resultando em maior slippage;
Maior consumo total de gás (transações cross-chain exigem pelo menos duas transações em pelo menos dois livros de ativos);
Aumento da computação duplicada entre livros de ativos (reduzindo assim o throughput total do sistema): quando o preço do ETH-USDC varia na Binance ou Coinbase, surgem oportunidades de arbitragem em cada pool ETH-USDC em todos os livros de ativos (você pode facilmente imaginar um mundo onde sempre que o preço do ETH-USDC varia na Binance ou Coinbase, mais de 10 transações são geradas em vários livros de ativos. Manter a consistência de preços em um estado fragmentado é uma utilização extremamente ineficiente do espaço de bloco).
É importante reconhecer que criar mais livros de ativos aumentará significativamente os custos em todas essas dimensões, especialmente os custos relacionados ao DeFi.
A principal entrada para DeFi é o estado na cadeia (ou seja, quem possui quais ativos). Quando as equipes lançam cadeias de aplicativos/Rollup, elas naturalmente criam fragmentos de estado, o que é muito desfavorável para o DeFi, tanto para os desenvolvedores que gerenciam a complexidade dos aplicativos (pontes, carteiras, latência, MEV cross-chain, etc.) quanto para os usuários (slippage, latência na liquidação).
As melhores condições para DeFi são: ativos emitidos em um único livro de ativos e transacionados dentro de uma única máquina de estado. Quanto mais livros de ativos existirem, mais complexidade os desenvolvedores de aplicativos devem gerenciar, e maiores serão os custos que os usuários terão que suportar.
Rollups de aplicativos não criam novas oportunidades de lucro para os desenvolvedores.
Os apoiadores das cadeias de aplicativos/Rollup acreditam que os incentivos levarão os desenvolvedores de aplicativos a desenvolver Rollups, em vez de construir no L1 ou L2, para que os aplicativos possam capturar o valor do MEV por conta própria. No entanto, essa ideia é falha, pois operar um Rollup de aplicativo não é a única maneira de capturar o MEV de volta para os tokens da camada de aplicativo, e na maioria dos casos, não é a melhor maneira. Os tokens da camada de aplicativo podem simplesmente codificar a lógica para capturar o MEV de volta para seus próprios tokens em contratos inteligentes na cadeia genérica. Vamos considerar alguns exemplos:
Liquidação: se o Compound ou a Aave DAO quiser capturar uma parte do MEV fluindo para os liquidadores, eles podem simplesmente atualizar seus contratos para que uma parte das taxas que flui para os liquidadores seja paga para sua própria DAO, sem a necessidade de uma nova cadeia/Rollup.
Oráculos: tokens de oráculo podem capturar MEV fornecendo serviços de back running. Além de atualizações de preços, os oráculos podem agrupar qualquer transação em uma cadeia que garante que será executada imediatamente após uma atualização de preço. Portanto, os oráculos podem capturar MEV oferecendo serviços de back running para buscadores, construtores de blocos, etc.
Cunhar NFTs: a cunhagem de NFTs está saturada com robôs de revenda. A simples codificação da redistribuição de lucros em queda pode facilmente mitigar essa situação. Por exemplo, se alguém tentar revender seu NFT duas semanas após a cunhagem, 100% da receita será retornada ao emissor ou à DAO. Com o tempo, essa porcentagem pode mudar.
Capturar o MEV para tokens da camada de aplicativo não tem uma resposta universal. No entanto, com um pouco de reflexão, os desenvolvedores de aplicativos podem facilmente capturar o MEV de volta para seus próprios tokens na cadeia genérica. Lançar uma nova cadeia não é de forma alguma necessário, pois traria complexidade técnica e social adicional para os desenvolvedores e mais problemas de carteira e liquidez para os usuários.
Rollups de aplicativos não podem resolver o problema de congestionamento entre aplicativos.
Muitas pessoas acreditam que as cadeias de aplicativos/Rollup garantirão que os aplicativos não sejam afetados por picos de gás causados por atividades em outras cadeias (como a cunhagem popular de NFTs). Essa perspectiva é parcialmente correta, mas em sua maior parte está errada.
Esta é uma questão histórica, cuja causa raiz é a natureza de thread única do EVM, e não porque DA e execução não estão separados. Todos os L2 devem pagar taxas ao L1, e as taxas do L1 podem aumentar a qualquer momento. Durante o auge da memecoin no início deste ano, as taxas de transação na Arbitrum e na Optimism chegaram a ultrapassar 10 dólares. Recentemente, as taxas da Optimism também dispararam após o lançamento do Worldcoin.
A única solução para resolver os picos de custo é: 1) maximizar o DA do L1, 2) refinar o mercado de custos o máximo possível:
Se os recursos do L1 forem limitados, os picos de uso em cada L2 serão transmitidos para o L1, resultando em custos mais altos para todos os outros L2. Portanto, as cadeias de aplicativos/Rollup não podem escapar dos picos de gás.
A coexistência de múltiplos EVM L2 é apenas uma maneira rudimentar de tentar localizar o mercado de custos. É melhor do que colocar o mercado de custos em um único EVM L1, mas não resolve o problema central. Quando você reconhece que a solução é localizar o mercado de custos, o ponto lógico final é um mercado de custos por cada estado (e não um mercado de custos por cada L2).
Outras cadeias já chegaram a essa conclusão. Solana e Aptos naturalmente localizaram o mercado de custos. Isso exigiu anos de trabalho de engenharia em seus respectivos ambientes de execução. A maioria dos apoiadores da modularização subestima gravemente a importância e a dificuldade de construir um mercado de custos local.
Lançar múltiplas cadeias não desbloqueia ganhos reais de desempenho para os desenvolvedores. Quando aplicativos impulsionam um aumento no volume de transações, todos os custos das cadeias L2 são afetados.
A flexibilidade foi superestimada.
Os apoiadores das cadeias modularizadas acreditam que a arquitetura modular é mais flexível. Essa afirmação é obviamente verdadeira, mas realmente importa?
Nos últimos seis anos, tenho me esforçado para encontrar desenvolvedores de aplicativos que possam fornecer casos de uso significativos que uma L1 genérica não pode oferecer. Mas até agora, exceto por três casos de uso muito específicos, ninguém conseguiu esclarecer por que a flexibilidade é importante e como ela ajuda diretamente na escalabilidade. Os três casos de uso específicos em que considero a flexibilidade importante são:
Aplicativos que utilizam o estado "quente". O estado quente é o estado necessário para coordenar em tempo real certos conjuntos de operações, mas é apenas temporariamente enviado para a cadeia e não existe para sempre. Alguns exemplos de estado quente:
Ordens limitadas em DEX, como dYdX e Sei (muitas ordens limitadas acabam sendo canceladas).
Coordenação em tempo real e identificação do fluxo de ordens em dFlow (dFlow é um protocolo que facilita um mercado descentralizado de fluxo de ordens entre market makers e carteiras).
Oráculos como Pyth, que é um oráculo de baixa latência. O Pyth opera como uma cadeia SVM independente. O Pyth gera tantos dados que a equipe central do Pyth decidiu que era melhor enviar atualizações de preços de alta frequência para uma cadeia independente e depois usar o Wormhole para conectar os preços a outras cadeias conforme necessário.
Cadeias que modificam o consenso. Os melhores exemplos são Osmosis (onde todas as transações são criptografadas antes de serem enviadas aos validadores) e Thorchain (que prioriza transações dentro do bloco de acordo com as taxas pagas).
É necessário aproveitar de alguma forma a infraestrutura de esquemas de assinatura de limiar (TSS). Alguns exemplos nesse sentido são Sommelier, Thorchain, Osmosis, Wormhole e Web3Auth.
Todos os exemplos listados acima, exceto Pyth e Wormhole, foram construídos usando o Cosmos SDK e operam como cadeias independentes. Isso ilustra adequadamente a aplicabilidade e escalabilidade do Cosmos SDK para os três casos de uso: estado quente, modificação de consenso e sistemas de esquemas de assinatura de limiar (TSS).
No entanto, a maioria dos projetos nos três casos de uso mencionados acima não são aplicativos; são infraestrutura.
Pyth e dFlow não são aplicativos; são infraestrutura. Sommelier, Wormhole, Sei e Web3Auth não são aplicativos; são infraestrutura. Dentre eles, o único aplicativo voltado para o usuário é um tipo específico: DEX (dYdX, Osmosis, Thorchain).
Há seis anos, venho perguntando aos apoiadores do Cosmos e do Polkadot sobre os casos de uso trazidos pela flexibilidade que eles oferecem. Acredito que há dados suficientes para fazer algumas inferências:
Primeiro, exemplos de infraestrutura não devem existir como Rollup, pois geram muitos dados de baixo valor (como estado quente, onde o significado completo do estado quente é que os dados não são enviados de volta ao L1) ou porque executam algumas funções que são intencionalmente relacionadas a atualizações de estado no livro de ativos (como todos os casos de uso do TSS).
Em segundo lugar, o único aplicativo que vi ser capaz de se beneficiar de uma mudança no design do sistema central é a DEX. Como as DEX estão saturadas de MEV e as chains genéricas não podem competir com a latência das CEX. O consenso é a base da qualidade da execução das transações e do MEV, portanto, mudanças baseadas em consenso naturalmente trazem muitas oportunidades de inovação para as DEX. No entanto, como mencionado anteriormente, a principal entrada para DEXs à vista são os ativos que estão sendo negociados. As DEX competem por ativos, e assim competem por emissores de ativos. Dentro dessa estrutura, cadeias DEX independentes têm menos chances de sucesso, pois a prioridade dos emissores de ativos ao emitir ativos não é o MEV relacionado a DEX, mas sim a funcionalidade de contratos inteligentes genéricos e como incorporar essa funcionalidade nos respectivos aplicativos dos desenvolvedores.
No entanto, as DEX de derivativos não precisam competir por emissores de ativos; elas dependem principalmente de garantias como USDC e alimentações de oráculos de preços, e essencialmente devem bloquear os ativos dos usuários para garantir posições de derivativos. Portanto, em termos de cadeias DEX independentes, elas são mais propensas a se aplicar a DEXs focadas em derivativos como dYdX e Sei.
Consideramos os aplicativos de integração L1 genéricos que existem atualmente, incluindo: jogos, sistemas DeSoc (como Farcaster e Lens), protocolos DePIN (como Helium, Hivemapper, Render Network, DIMO e Daylight), Sound, exchanges de NFT, entre outros. Nenhum deles se beneficiou especialmente da flexibilidade trazida pela modificação de consenso; cada um de seus livros de ativos possui um conjunto bastante simples, evidente e comum de requisitos: baixas taxas, baixa latência, acesso a DEX à vista, acesso a stablecoins e acesso a canais fiduciários, como CEX.
Acredito que agora temos dados suficientes para afirmar até certo ponto que a grande maioria dos aplicativos voltados para o usuário possui os mesmos requisitos genéricos listados no parágrafo anterior. Embora certos aplicativos possam otimizar variáveis marginais por meio de funcionalidades personalizadas na pilha, os trade-offs trazidos por essas personalizações geralmente não valem a pena (mais pontes, menos suporte a carteiras, menos suporte a indexadores/consultores, redução de canais fiduciários, etc.).
Lançar novos livros de ativos é uma maneira de alcançar flexibilidade, mas raramente agrega valor, e quase sempre traz complexidade técnica e social, enquanto os benefícios para os desenvolvedores de aplicativos são mínimos.
A escalabilidade do DA não requer remarcar.
Você também ouvirá os apoiadores da modularização falarem sobre remarcar no contexto da escalabilidade. Este é o argumento mais especulativo apresentado pelos apoiadores das cadeias modularizadas, mas é digno de discussão.
Isso aponta de forma grosseira que, devido à remarcar (por exemplo, através de sistemas como EigenLayer), todo o ecossistema criptográfico pode remarcar ETH infinitas vezes, capacitando um número infinito de camadas de DA (por exemplo, EigenDA) e camadas de execução. Portanto, ao garantir a valorização do ETH, a escalabilidade é resolvida de várias maneiras.
Embora exista uma enorme incerteza entre o status quo e um futuro teórico, assumimos sem pensar que todas as suposições de camadas são válidas como anunciado.
Atualmente, a DA do Ethereum é de cerca de 83 KB/s. Com o lançamento do EIP-4844 mais tarde neste ano, essa taxa pode dobrar para cerca de 166 KB/s. O EigenDA pode adicionar mais 10 MB/s, mas requer um conjunto diferente de condições de suposições de segurança (nem todo ETH será remarcado para o EigenDA).
Em comparação, a DA atualmente oferecida pelo Solana é de cerca de 125 MB/s (32.000 shreds por bloco, cada shred com 1.280 bytes, 2,5 blocos por segundo). O Solana é muito mais eficiente do que o Ethereum e o EigenDA. Além disso, de acordo com a Lei de Nielsen, a DA do Solana se expande ao longo do tempo.
Existem muitas maneiras de escalar o DA através da remarcar e modularização, mas esses mecanismos não são necessários hoje e trazem complexidade técnica e social óbvia.
Construindo para desenvolvedores de aplicativos.
Após anos de reflexão, cheguei à conclusão de que a modularização em si não deve ser um objetivo.
As blockchains devem servir seus clientes (ou seja, desenvolvedores de aplicativos), portanto, a blockchain deve abstrair a complexidade do nível de infraestrutura para que os desenvolvedores possam se concentrar em construir aplicativos de classe mundial.
A modularização é ótima. Mas a chave para construir uma tecnologia vencedora é descobrir quais partes da pilha precisam ser integradas e quais partes devem ser deixadas para os outros. No momento, a integração de DA e execução das cadeias oferece essencialmente uma experiência mais simples para os usuários finais e desenvolvedores, e, em última análise, proporcionará uma base melhor para aplicativos de primeira linha.
Link do artigo original.
Este artigo foi republicado com autorização do Foresight News.
Este artigo do parceiro da instituição de capital de risco Multicoin: por que a modularização das blockchains foi superestimada, apareceu pela primeira vez na zona de moedas Sanguine Zombit.