Quando se trata tanto de atenção quanto de inovação, nem todos os componentes da pilha modular são criados igualmente. Enquanto historicamente houve muitos projetos inovando nas camadas de disponibilidade de dados (DA) e sequenciamento, as camadas de execução e liquidação têm sido comparativamente mais negligenciadas como parte da pilha modular até mais recentemente.

O espaço sequenciador compartilhado não apenas tem muitos projetos competindo por participação de mercado — Espresso, Astria, Raio, Roma, e Madarapara citar alguns — mas também inclui fornecedores de RaaS comoCaldeiraeConduitque desenvolvem sequenciadores compartilhados para rollups que se baseiam neles. Esses provedores de RaaS são capazes de oferecer um compartilhamento de taxas mais favorável com seus rollups, uma vez que seu modelo de negócios subjacente não depende exclusivamente da receita de sequenciamento. Todos esses produtos existem ao lado dos muitos rollups que optam por executar seu próprio sequenciador e descentralizar ao longo do tempo para capturar as taxas que gera.

O mercado de sequenciamento é único em comparação com o espaço DA, que basicamente opera como um oligopólio composto porCelestia, Disponível, e EigenDA. Isso torna o mercado difícil para novos entrantes menores além dos três principais para perturbar com sucesso o espaço. Projetos geralmente utilizam a escolha "incumbente" - Ethereum - ou optam por uma das camadas DA estabelecidas, dependendo do tipo de pilha tecnológica e alinhamento que estão procurando. Embora usar uma camada DA seja uma economia de custos massiva, terceirizar a peça sequenciadora não é uma escolha tão óbvia (do ponto de vista de taxas, não de segurança) - principalmente devido ao custo de oportunidade de desistir das taxas geradas. Muitos também argumentam que a DA se tornará uma mercadoria, mas vimos no cripto que fortes barreiras de liquidez combinadas com tecnologia subjacente única (difícil de replicar) tornam muito mais difícil tornar uma camada na pilha uma mercadoria. Independentemente desses debates e dinâmicas, existem muitos produtos DA e sequenciadores em produção (em resumo, com parte da pilha modular, @maven11research/commoditise-your-complements">"there are several competitors for every single service.")

As camadas de execução e liquidação (e por extensão, agregação) - que acredito terem sido comparativamente pouco exploradas - estão começando a ser iteradas de novas maneiras que se alinham bem com o restante do conjunto modular.

Recapitulação sobre a relação entre a camada de execução e liquidação

A camada de execução e de liquidação estão intimamente integradas, onde a camada de liquidação pode servir como o local onde os resultados finais da execução do estado são definidos. A camada de liquidação também pode adicionar funcionalidades aprimoradas aos resultados da camada de execução, tornando a camada de execução mais robusta e segura. Na prática, isso pode significar muitas capacidades diferentes — por exemplo, a camada de liquidação pode atuar como um ambiente para a camada de execução resolver disputas de fraudes, verificar provas e fazer a ponte entre outras camadas de execução.

Também vale mencionar que existem equipes habilitando nativamente o desenvolvimento de ambientes de execução opinativos diretamente dentro de seu próprio protocolo — um exemplo disso é Repyh Labs, que está construindo um L1 chamado Delta. Isto é, por natureza, o design oposto da pilha modular, mas ainda fornece flexibilidade dentro de um ambiente unificado e vem com vantagens de compatibilidade técnica, uma vez que as equipes não precisam gastar tempo integrando manualmente cada parte da pilha modular. As desvantagens, é claro, são estar isolado de um sentido de liquidez, não poder escolher camadas modulares que melhor se adequem ao seu design e ser muito caro.

Outras equipes estão optando por construir L1s extremamente específicos para uma funcionalidade central ou aplicativo. Um exemplo éHyperliquid, que construiu um L1 projetado especificamente para seu aplicativo nativo principal, uma plataforma de negociação perpétua. Embora seus usuários precisem fazer a ponte a partir do Arbitrum, sua arquitetura principal não depende do Cosmos SDK ou de outros frameworks, para que possa ser personalizado de forma iterativa e hiperotimizadapara seu principal caso de uso.

Progresso da camada de execução

O antecessor deste (último ciclo, e ainda em certa medida) foram alt-L1s de propósito geral, onde basicamente a única característica que superava o Ethereum era a maior taxa de transferência. Isso significava que historicamente os projetos basicamente tinham que optar por construir sua própria alt L1 do zero se quisessem melhorias de desempenho substanciais — principalmente porque a tecnologia ainda não estava lá no próprio Eth. E historicamente, isso significava simplesmente incorporar mecanismos de eficiência nativamente no protocolo de propósito geral. Neste ciclo, essas melhorias de desempenho são alcançadas por meio de um design modular e principalmente estão na plataforma de contrato inteligente mais dominante que existe (Ethereum) — desta forma, tanto os projetos existentes quanto os novos podem aproveitar a nova infraestrutura de camada de execução sem sacrificar a liquidez, segurança e vantagens da comunidade do Ethereum.

Neste momento, também estamos vendo mais mistura e combinação de diferentes VMs (ambientes de execução) como parte de uma rede compartilhada, o que permite flexibilidade para os desenvolvedores, bem como uma melhor personalização na camada de execução.Camada N, por exemplo, permite que os desenvolvedores executem nós de rollup generalizados (por exemplo, SolanaVM, MoveVM, etc como ambientes de execução) e nós de rollup específicos do aplicativo (por exemplo, perps dex, orderbook dex) sobre sua máquina de estado compartilhada. Eles também estão trabalhando para permitir a capacidade de composição total e a liquidez compartilhada entre essas diferentes arquiteturas de VM, um problema de engenharia onchain historicamente difícil de fazer em escala. Cada aplicativo na Camada N pode passar mensagens de forma assíncrona um para o outro sem demora no lado do consenso, o que normalmente tem sido o problema de "sobrecarga de comunicações" da criptografia. Cada xVM também pode usar uma arquitetura de banco de dados diferente, seja ela RocksDB, LevelDB, ou um banco de dados (a)síncrono personalizado feito do zero. A peça de interoperabilidade funciona por meio de um “sistema de snapshot” (um algoritmo similar ao Algoritmo Chandy-Lamport) onde as cadeias podem fazer a transição de forma assíncrona para um novo bloco sem exigir que o sistema pause. Do lado da segurança, provas de fraude podem ser enviadas no caso de uma transição de estado incorreta. Com esse design, o objetivo deles é minimizar o tempo de execução enquanto maximizam o throughput geral da rede.

Camada N

Em linha com esses avanços na personalização, Movement Labsalavanca a linguagem Move — originalmente projetada pelo Facebook e usada em redes como Aptos e Sui — para sua VM / execução. Move tem vantagens estruturais em comparação com outros frameworks, principalmente segurança e flexibilidade / expressividade do desenvolvedor, historicamente dois dos principais problemas ao construir onchain usando o que existe hoje. Importante, os desenvolvedores também podem apenas escreva Solidity e implante no Movimento— para tornar isso possível, o Movement criou um tempo de execução EVM totalmente compatível com bytecode que também funciona com a pilha Move. Seu rollup, M2, aproveita a paralelização BlockSTM que permite uma taxa de transferência muito maior, mantendo a capacidade de acessar o fosso de liquidez do Ethereum (historicamente o BlockSTM tem sido usado exclusivamente em alt L1s como Aptos, que obviamente não possuem compatibilidade com o EVM).

MegaETHtambém está impulsionando o progresso no espaço da camada de execução, especialmente por meio de seu mecanismo de paralelização e BD em memória, onde o sequenciador pode armazenar todo o estado na memória. No lado arquitetural, eles aproveitam:

• Compilação de código nativo que permite que o L2 seja muito mais performático (se o contrato for mais intensivo em computação, os programas podem obter um aumento de velocidade massivo, se não for muito intensivo em computação, ainda há um aumento de velocidade de ~2x+).
• Produção de bloco relativamente centralizada, mas validação e verificação de bloco descentralizadas.
• Sincronização eficiente de estado, onde os nós completos não precisam reexecutar transações, mas precisam estar cientes do delta de estado para poderem aplicá-lo ao seu banco de dados local.
• Estrutura de atualização da árvore de Merkle (onde normalmente a atualização da árvore é intensiva em armazenamento), onde sua abordagem é uma nova estrutura de dados de trie que é eficiente em memória e disco. A computação em memória permite que eles comprimam o estado da cadeia na memória, para que, quando as transações forem executadas, elas não precisem ir para o disco, apenas para a memória.

Mais um design que tem sido explorado e iterado recentemente como parte do conjunto modular é a agregação de provas - definida como um comprovante que cria uma única prova sucinta de múltiplas provas sucintas. Primeiro, vamos analisar as camadas de agregação como um todo e suas tendências históricas e atuais em cripto.

Atribuindo valor às camadas de agregação

Historicamente, nos mercados não cripto, os agregadores têm ganhado uma participação de mercado menor do que as plataformas ou marketplaces:

CJ Gustafson

Embora eu não tenha certeza se isso vale para criptomoedas em todos os casos, é definitivamente verdadeiro para exchanges descentralizadas, bridges e protocolos de empréstimo.

Por exemplo, a capitalização de mercado combinada de 1inch e 0x (dois agregadores dex básicos) é de cerca de $1bb — uma pequena fração dos cerca de $7.6bb da Uniswap. Isso também vale para pontes: agregadores de pontes como Li.Fi e Socket/Bungee aparentemente têm uma participação de mercado menor em comparação com plataformas como Across. Enquanto o Socket suporta 15 pontes diferentes, eles realmente têm um volume de ponte semelhante ao Across (Socket — $2.2bb, Através —$1.7bb) e Across representa apenas uma pequena fração do volume em Socket/Bungee recentemente.

No espaço de empréstimos, Yearn Financefoi o primeiro do seu tipo como um protocolo agregador de rendimento de empréstimo descentralizado - seu limite de mercado é atualmente~$250mm. Em comparação, produtos de plataforma como Aave (~$1.4bb) e Composto (~$560mm) têm comandado uma avaliação mais alta e mais relevância ao longo do tempo.

Mercados tradicionais operam de forma semelhante. Por exemplo, ICE(Intercontinental Exchange) EUA e CME Groupcada um tem market caps de cerca de $75bb, enquanto os "agregadores" como Charles Schwab e Robinhood têm market caps de cerca de $132b e $15b, respectivamente. Dentro do Schwab, querotas através da ICE e CMEentre muitos outros locais, o volume proporcional que passa por eles não é proporcional a essa parcela de sua capitalização de mercado. A Robinhood tem aproximadamente Contratos de opções de 119mm por mês, enquanto os da ICE estão por perto ~35mm— e os contratos de opções nem sequer são uma parte central do modelo de negócios da Robinhood. Apesar disso, a ICE é avaliada ~5x mais do que a Robinhood nos mercados públicos. Assim, Schwab e Robinhood, que atuam como interfaces de agregação de nível de aplicativo para rotear o fluxo de pedidos dos clientes por meio de vários locais, não têm valorizações tão altas quanto a ICE e CME, apesar de seus volumes respectivos.

Nós, como consumidores, simplesmente atribuímos menos valor aos agregadores.

Isso pode não ser válido em criptomoeda se camadas de agregação estiverem incorporadas em um produto/plataforma/chain. Se os agregadores estiverem intimamente integrados diretamente na chain, obviamente essa é uma arquitetura diferente e estou curioso para ver como ela se desenrola. Um exemplo é AggLayer da Polygon, onde os desenvolvedores podem facilmente conectar seu L1 e L2 em uma rede que agrega provas e permite uma camada de liquidez unificada entre as cadeias que usam o CDK.

AggLayer

Este modelo funciona de forma semelhante a Camada de Interoperabilidade Nexus da Avail, que inclui um mecanismo de agregação de prova e leilão de sequenciador, tornando seu produto DA muito mais robusto. Como a AggLayer da Polygon, cada cadeia ou rollup que se integra ao Avail se torna interoperável dentro do ecossistema existente do Avail. Além disso, o Avail agrupa dados de transações ordenadas de várias plataformas blockchain e rollups, incluindo Ethereum, todos os rollups do Ethereum, cadeias Cosmos, rollups do Avail, rollups da Celestia e diferentes construções híbridas como Validiums, Optimiums e parachains da Polkadot, entre outros. Os desenvolvedores de qualquer ecossistema podem então construir sem permissão na camada DA do Avail enquanto usam o Avail Nexus, que pode ser usado para agregação de prova e mensagens entre ecossistemas.

Disponível Nexus

Nebraconcentra-se especificamente na agregação e liquidação de provas, onde podem agregar em diferentes sistemas de prova - por exemplo, agregando provas do sistema xyz e provas do sistema abc de tal forma que tenha agg_xyzabc (em oposição à agregação dentro de sistemas de prova de forma que tenha agg_xyz e agg_abc). Esta arquitetura utiliza UniPlonK, que padroniza o trabalho dos verificadores para famílias de circuitos, tornando a verificação de provas em diferentes circuitos PlonK muito mais eficiente e viável. Em sua essência, ele utiliza as próprias provas de conhecimento zero (SNARKs recursivos) para escalar a peça de verificação — tipicamente o gargalo nessas sistemas. Para os clientes, o acerto de 'última milha' é muito mais fácil porque a Nebra cuida de toda a agregação em lote e acerto, onde as equipes só precisam alterar uma chamada de contrato de API.

Astriaestá trabalhando em designs interessantes sobre como seu sequenciador compartilhado pode funcionar com agregação de provas também. Eles deixam o lado de execução para os rollups em si, que executam software de camada de execução sobre um determinado espaço de nomes de um sequenciador compartilhado — essencialmente apenas a 'API de execução' que é uma maneira do rollup aceitar dados da camada de sequenciamento. Eles também podem facilmente adicionar suporte para provas de validade aqui para garantir que um bloco não violou as regras da máquina de estado EVM.

Josh Bowen

Aqui, um produto como Astria funciona como o fluxo #1 → #2 (transações não ordenadas → bloco ordenado), e a camada de execução / nó de rollup é #2 → #3, enquanto um protocolo como Nebraserve como a última milha #3 → #4 (bloco executado → prova sucinta). Nebra (ou Camada Alinhada) poderia também ser um quinto passo teórico onde as provas são agregadas e então verificadas posteriormente. A Sovereign Labs está trabalhando em um conceito semelhante ao último passo também, onde a agregação de provas com base em pontes está no cerne de sua arquitetura.

Laboratórios Soberanos

No agregado, algumas camadas de aplicativos são começando a possuir a infraestrutura por baixo, em parte porque permanecer apenas como uma aplicação de alto nível pode ter problemas de incentivo e custos elevados de adoção de usuários se não controlarem a estrutura subjacente. Por outro lado, à medida que os custos de infraestrutura estão sendo constantemente reduzidos pela concorrência e avanços tecnológicos, o custo para que aplicações / appchains se integrem com componentes modulares está se tornando muito mais viável. Acredito que essa dinâmica é muito mais poderosa, pelo menos por enquanto.

Com todas essas inovações - camada de execução, camada de liquidação, agregação - mais eficiência, integrações mais fáceis, interoperabilidade mais forte e custos mais baixos são muito mais possíveis. Realmente, tudo isso está levando a aplicações melhores para os usuários e a uma melhor experiência de desenvolvedor para os construtores. Esta é uma combinação vencedora que leva a mais inovação - e a uma velocidade de inovação mais rápida - em geral, e estou ansioso para ver o que se desenrola.

Aviso Legal：

1. Este artigo é reproduzido de [GateBridget Harris]. Todos os direitos autorais pertencem ao autor original [BRIDGET HARRIS]. Se houver objeções a esta reimpressão, entre em contato com o Gate Learnequipe, e eles lidarão com isso prontamente.
2. Isenção de responsabilidade: As opiniões expressas neste artigo são exclusivamente do autor e não constituem qualquer conselho de investimento.
3. As traduções do artigo para outros idiomas são feitas pela equipe Gate Learn. A menos que mencionado, copiar, distribuir ou plagiar os artigos traduzidos é proibido.