Recentemente, tem sido notada uma tendência onde um número crescente de dApps estão a anunciar o lançamento dos seus próprios rollups. Além disso, há um aumento no número de rollups genéricos que estão prestes a entrar em funcionamento.

Os rollups genéricos abordam os problemas de escalabilidade do Ethereum à medida que enfrenta volumes crescentes de transações e crescimento de dApps. Estas soluções de camada 2 processam mais transações fora da cadeia, posteriormente assegurando-as na cadeia principal, equilibrando escalabilidade com segurança. A sua versatilidade suporta vários dApps, eliminando a necessidade de soluções de escalabilidade únicas para cada aplicação.

Os rollups específicos da aplicação são soluções personalizadas que abordam as necessidades únicas de aplicações individuais. Eles oferecem velocidade aprimorada otimizando o processamento de transações para casos de uso específicos. Em termos de custos, podem fornecer uma alternativa mais eficiente às soluções genéricas, especialmente durante a congestão da rede. Sua característica marcante é a flexibilidade. Ao contrário das soluções de Camada 2 de uso geral que são rígidas e mais limitadas pelo design enraizado do EVM, os rollups específicos da aplicação podem ser personalizados, tornando-os ideais para aplicações como jogos que requerem precompilações específicas. Além disso, eles permitem que as dApps capturem melhor valor, oferecendo mais controle sobre a economia de tokens e fluxos de receita.

Com o consenso a formar-se em torno da proliferação de rollups, olhando um ano para o futuro onde múltiplos rollups dominam o mercado, a necessidade de uma infraestrutura robusta torna-se fundamental. Esta infraestrutura servirá como o “betão armado” de um mundo multi-rollup.

Este artigo abordará quatro pilares fundamentais que moldarão o futuro do ecossistema multi-rollup:

1. Segurança como Fundação: A Camada de Segurança é a base da confiança no mundo descentralizado. Nesta seção, exploramos o papel vital que desempenha na garantia da integridade das transações da Camada 2, identificando pressupostos de confiança e abordando possíveis armadilhas de segurança.
2. Equilibrar a Personalização e a Interoperabilidade : Alcançar uma interoperabilidade perfeita entre diversos rollups é fundamental para um mundo de blockchain modular. Nesta seção, abordamos os problemas de interoperabilidade trazidos por uma estrutura modular e discutimos soluções atuais para enfrentar a fragmentação e promover um ecossistema coeso.
3. Análise de custos: Reduzir custos é crucial para a adoção mais ampla e viabilidade de rollups, pois diminui as barreiras econômicas em comparação com a utilização de contratos inteligentes. A eficiência de custos em rollups é alcançada principalmente através da exploração das economias de escala, agregando-se a outros rollups para partilhar taxas, e adotando a divisão do trabalho ao delegar certas tarefas a prestadores de serviços externos.
4. Segurança Compartilhada: Uma camada de segurança compartilhada é essencial, pois alivia o processo intensivo de tempo e recursos de inicialização de segurança para novos protocolos ou camadas modulares, garantindo uma segurança robusta comparável a plataformas estabelecidas como o Ethereum. Inúmeras soluções como Eigenlayer, Babylon, ICS da Cosmos e Mesh Security surgiram, mostrando uma variedade de aplicações

Juntas, estas quatro camadas fornecerão um plano abrangente para a infraestrutura necessária para apoiar um mundo blockchain modular próspero e coeso.

Segurança Como Fundamento

No cerne de qualquer sistema descentralizado reside a confiança e a segurança. A sua ausência mina a própria promessa de um ecossistema sem confiança. É por isso que a camada de segurança é primordial; sem ela, os utilizadores e o TVL estão em risco. A queda do Plasma e das Sidechains oferece uma história de advertência. Uma vez visto como o salvador da escalabilidade da Ethereum, os seus problemas, como o 'problema de disponibilidade de dados', erodiram a confiança e levaram à sua popularidade decrescente. É por isso que a camada de segurança se torna parte I deste artigo.

Para entender as complexidades dos rollups e suas vulnerabilidades potenciais, é essencial dissecar o ciclo de vida de uma transação de Camada 2. Usando os rollups de contratos inteligentes como referência, vamos aprofundar em cada fase e identificar as suposições de confiança e possíveis armadilhas de segurança:

1. Submissão de Tx através de RPC:
   1. Pressuposto de Confiança: O endpoint RPC é confiável e seguro. Os usuários e dapps estão agora confiando nos provedores de rpc, por exemplo, alchemy, infura, etc.
   2. Preocupação com a segurança: Os utilizadores podem ser censurados pelos fornecedores de RPC, por exemplo, a infura e a alchemy bloqueando pedidos de RPC para tornardo cashOs fornecedores de RPC podem enfrentar ataques DDOS, por exemplo ankr sendo comprometido viaDNS hijack.
   3. Soluções: Os fornecedores de RPC, como a Infura, estão a seguir ativamente um roadmap descentralizado. Além disso, os utilizadores têm a opção de escolher soluções descentralizadas como a Rede Pocket.
2. Sequenciador Ordena o Tx, Fornece Compromissos Suaves: estado inseguro
   1. Pressuposição de Confiança: Os utilizadores esperam que os sequenciadores ordenem as transações de forma justa e forneçam compromissos suaves genuínos.
   2. Preocupação com a segurança: O sistema deve resistir à censura, garantindo que todas as transações sejam processadas sem viés. É crucial que o sistema permaneça continuamente operacional e seria melhor proteger-se contra sequenciadores que obtêm MEV ruim às custas do usuário final.
   3. Soluções:
      1. CR e vivacidade:
         1. classificação atual das soluções com base no CR e no nível de atividade (baixo para alto): sequenciador único —— POA —— sequenciadores POS sem permissão —— sequenciadores compartilhados —— rollups baseados (sequenciados por l1)
            1. Note que o POA com autoridades limitadas sem suporte para transações forçadas pode ter menos CR do que um sequenciador centralizado com transações forçadas habilitadas.
            2. No que diz respeito à vivacidade, outra métrica crucial a considerar é a falha do proponente, que ocorre quando um proponente fica offline. Em tais casos, é essencial garantir que os utilizadores possam ainda levantar os seus fundos.
               1. Mesmo que os sequenciadores estejam a censurar ou recusem-se a funcionar, alguns rollups permitem que os utilizadores enviem as suas txs diretamente para L1s por si mesmos, ou seja, a saída de emergência ( liveness para txs forçadas depende da implementação específica ). O problema é que pode ser demasiado caro para os utilizadores com fundos limitados fazerem isso, e os utilizadores podem esperar CR e liveness em tempo real.
               2. Certas soluções de rollup, como Arbitrum e Fuel, oferecem a capacidade para qualquer pessoa se tornar um proponente após um certo atraso, ou seja, auto propôr-se.
               3. Verifique este indicador para cada rollup: https://l2beat.com/scaling/risk
         2. Mais detalhes sobre outras soluções diferentes podem ser consultados no meu tópico anterior: https://twitter.com/yuxiao_deng/status/1666086091336880128
      2. Proteção MEV:
         1. Diferentes soluções de privacidade podem ajudar a proteger os utilizadores de serem antecipados ou encurralados, uma vez que a informação da transação está oculta (também ajuda com CR). Métodos relacionados para ocultar a informação da transação incluem FCFS com uma mempool privada (o que arbitrum e optimism estão a implementar neste momento), a solução TEE da SUAVE, encriptação de limiar (shutter network a trabalhar nisso), etc. Quanto mais sofisticada for a solução, menos complicados podem ser os cálculos das transações.

MEV Roast | Piscinas de Memória Criptografadas - Justin Drake (Fundação Ethereum) - YouTube

1. Note que o que queremos é proteção mev, não eliminação mev.Investigação por @tarunchitraresume duas direções principais para reduzir o MEV: reduzir a flexibilidade do minerador para reordenar transações, impondo regras de ordenação e introduzir um mercado competitivo para o direito de reordenar, adicionar e/ou censurar transações. No entanto, o artigo conclui que nem a ordenação justa nem mecanismos econômicos isolados podem mitigar eficazmente o MEV para todas as funções de pagamento. Existem limites inferiores sobre como você não pode remover o MEV além de um certo ponto.
2. O sequenciador executa e publica o lote de transações e raízes de estado para a camada DA quando for economicamente viável; estado seguro
   1. Pressuposto de confiança: Os produtores de bloco publicam o bloco inteiro na camada DA para que outros possam baixá-los e validá-los.
   2. Preocupação com a segurança: Se parte dos dados não estiver disponível, o bloco pode conter transações maliciosas que estão a ser ocultadas pelo produtor do bloco. Mesmo que o bloco contenha transações não maliciosas, ocultá-las pode comprometer a segurança do sistema. É muito importante que os sequenciadores tenham os dados das tx disponíveis, uma vez que o rollup precisa de conhecer o estado da rede e os saldos das contas.
   3. Soluções:
   4. A publicação na Ethereum agora é a solução mais segura, mas mais cara (seria 90% mais barata após a protodankshadring, mas mesmo um aumento de 10x na capacidade pode ainda não ser suficiente para os rollups): as transações dos rollups são descarregadas e divulgadas por todos os nós da Ethereum. Como a Ethereum tem um grande número de nós a replicar e a verificar os dados das transações, é altamente improvável que os dados desapareçam ou fiquem completamente indisponíveis.
      1. Após a danksharding, os nós do ethereum não irão baixar todos os dados da tx, mas apenas partes dos dados usando o DAS e KZG (similar à solução da avail mencionada abaixo)
      2. Sob o conceito modular, pode ser mais eficiente para rollups enviar dados de tx para uma camada DA que é apenas responsável por DA (O desempenho teórico do Ethereum pode ser ligeiramente inferior porque, além do DA, ainda mantém a execução do L1, veja a comparação de desempenho entre eigenDA e Ethereum abaixo).

1. As soluções modulares atuais de DA apresentam compromissos entre segurança e desempenho. É desafiador comparar a segurança do DA usando apenas uma dimensão:
   1. Avail e Celestia utilizam DAS para garantir a disponibilidade dos dados; desde que haja amostragem suficiente, os dados estão seguros. Os LCs podem amostrar e obter uma garantia alta de DA, uma vez que a indisponibilidade de dados seria facilmente detetada e recuperada por porções muito pequenas de LCs. Isto não seria possível sem DAS. A descentralização da camada de DA, ou seja, o número de nós na rede determina o nível de segurança e também a distribuição da participação. EigenDA não usa DAS, mas utiliza um mecanismo de prova de custódia para impedir que os restakers sejam preguiçosos, ou seja, os operadores de DA têm de calcular rotineiramente uma função que só pode ser concluída se tiverem descarregado todos os dados necessários e são penalizados se não atestarem corretamente os blobs (não é necessário armazenar após a realização da prova).
   2. Garantir que o processo de duplicação de dados, ou seja, codificação de apagamento, seja preciso. EigenDA, Ethereum após 4844 e Avail usam compromissos kzg para garantir precisão, mas esses são computacionalmente intensivos. Celestia emprega prova de fraude. Os nós leves devem esperar por um intervalo breve antes de poderem confirmar que um bloco foi codificado corretamente, finalizando-o do seu ponto de vista. (*Celestia poderia potencialmente mudar para provas de validade se for uma opção de compensação melhor)
   3. Segurança econômica da camada DA (riscos de reorganização e colusão): depende do valor apostado na camada DA, =2/3 do valor apostado no Avail e Celestia
   4. Repassar a atestação DA da camada DA para o Ethereum. Se os dados forem enviados para outra camada DA enquanto o contrato de liquidação ainda estiver no Ethereum, então precisamos de um contrato de ponte para validar que o DA está disponível na camada DA para a liquidação final.
      1. O blobstream da Celestia verifica as assinaturas na atestação DA da Celestia. A atestação é uma raiz de Merkle dos dados L2 assinados pelos validadores da Celestia atestando o fato de que os dados estão disponíveis na Celestia. Este recurso está disponível em testnetagora mesmo.
      2. Avail utiliza uma abordagem otimista para verificar a atestação da DA. Uma vez que a atestação é enviada para o contrato de ponte no Ethereum, um período de espera começa durante o qual a atestação é considerada válida, a menos que contestada.
      3. Succinct está a trabalhar com Avail e Celestia numa ponte de atestação de dados baseada em zk-SNARK, o que torna o progresso da atestação mais seguro e barato ao simplesmente verificar a prova zk.
      4. Para EigenDA, o dispersor divide e envia tarefas para os nós EigenDA e depois agrega assinaturas deles e retransmite dados para o Ethereum
2. Liquidação Final: estado finalizado
   1. Pressuposto de Confiança 1:
      1. Os nós completos do Rollup (um nó que pode calcular totalmente o estado sem depender de outras provas) podem finalizar o primeiro bloco de rollup válido em sua altura assim que é publicado na cadeia principal, pois possuem os dados necessários e recursos computacionais para verificar rapidamente a validade do bloco. No entanto, isso não é o caso para outras partes terceiras como clientes leves, que dependem de provas de validade, provas de fraude ou protocolos de resolução de disputas para verificar o estado de forma confiável sem precisar executar uma réplica completa da cadeia eles mesmos.
   2. Preocupação de segurança 1:
      1. Para ZK Rollups, l1 verifica o zkp e apenas aceita raízes de estado corretas. A dificuldade reside principalmente no custo e processo de geração do zkp.
      2. Por outro lado, os Rollups otimistas dependem da premissa de que pelo menos uma parte honesta irá prontamente submeter a prova de fraude para contestar quaisquer transações maliciosas. No entanto, a maioria dos sistemas de comprovação de fraude atuais ainda não são sem permissão, e a submissão de provas de fraude depende apenas de alguns validadores.
   3. Soluções 1:
      1. Prova de fraude sem permissão possibilitada pelo protocolo BOLD da Arbitrum. A principal razão pela qual a prova de fraude é atualmente permitida é a preocupação com os ataques de atraso:
         1. Durante o período de desafio, qualquer stakeholder que não seja o proponente pode lançar um desafio. O proponente é então obrigado a defender sua afirmação contra cada desafiante individualmente, um de cada vez. No final de cada desafio, a parte que perder renuncia à sua participação.
         2. Num ataque de atraso, uma parte maliciosa (ou grupo de partes) pode impedir ou atrasar a confirmação dos resultados de volta à cadeia L1, fazendo desafios e perdendo deliberadamente a disputa e as apostas)
         3. O protocolo de desafio 𝐁𝐎𝐋𝐃 aborda isso garantindo limites superiores fixos nos tempos de confirmação para liquidação de Rollups otimistas, garantindo que uma única parte honesta no mundo possa vencer qualquer número de reivindicações maliciosas.
      2. A cadeia de testemunhas pode atuar como uma torre de vigia para novas rollups otimistas para garantir que pelo menos uma parte honesta desafiará um estado inválido:
         1. Para rollups estabelecidos como Arbitrum e Optimism, existem incentivos intrínsecos suficientes para vários fornecedores terceirizados, como exploradores, serviços semelhantes ao Infura, e sua fundação, para monitorar o estado da cadeia e enviar provas de fraude quando necessário. No entanto, novos rollups ou appchains podem não ter esse nível de segurança.
         2. A Witness Chain utiliza um mecanismo de incentivo único, o "Proof of Diligence," que garante que as torres de vigia (validadores) estejam consistentemente motivadas a monitorizar e verificar transações, garantindo que o estado submetido à cadeia principal esteja correto. Este mecanismo garante que cada torre de vigia realize a sua devida diligência, uma vez que as recompensas que recebem são específicas e independentes para cada nó. Em outras palavras, se uma torre de vigia descobrir uma recompensa, não pode partilhar o pagamento de incentivo exato com outras torres de vigia, garantindo que cada nó conduza a sua verificação independente. Além disso, a Witness Chain oferece flexibilidade ao permitir que os rollups especifiquem requisitos personalizados, como o número de torres de vigia e a sua distribuição geográfica alimentada pelo "proof of location" - o seu serviço independente. Esta flexibilidade garante um equilíbrio entre segurança e eficiência.
            *A rede Watchtower também está a emergir como uma nova camada na própria pilha rollup, fornecendo segurança agrupada à execução utilizada por outras aplicações relacionadas - como a segurança rollup em si, protocolos de interoperabilidade, serviço de notificação e rede de guardiões, etc. Mais detalhes serão lançados no futuro.
   4. Pressuposto de Confiança 2:
      1. O processo inteiro de liquidação para rollups de contratos inteligentes é escrito em contrato inteligente na L1. O contrato inteligente na camada DA é assumido como logicamente preciso, sem bugs e sem atualizações maliciosas.
   5. Preocupação de segurança 2: As pontes e atualizações de contratos inteligentes rollups são controladas por carteiras multi-sig. A ponte tem a capacidade de roubar fundos arbitrariamente dos usuários através de uma atualização maliciosa.
   6. Soluções 2:
      1. A ideia mais popular hoje em dia é adicionar atrasos de tempo que permitem aos utilizadores sair se discordarem de uma atualização planeada. No entanto, esta solução requer que os utilizadores monitorem continuamente todas as cadeias em que têm tokens, no caso de precisarem de sair.
      2. A Camada Beacon da Altlayer pode atuar como uma camada social para atualizações de todos os rollups consagrados a ela. Sequenciadores que se registam para operar um rollup juntamente com os validadores do rollup da Camada Beacon podem bifurcar socialmente o rollup, independentemente de a ponte consagrada no Ethereum ser atualizada ou não.
      3. Rollups consagrados a longo prazo: o rollup consagrado tem sido o objetivo final do roteiro do Ethereum há vários anos. Exceto pela consagração da ponte/verificador de prova de fraude em L1, o contrato de liquidação também está consagrado.
         1. A Ethereum PSE está a trabalhar nesse sentido

Quanto aos rollups soberanos, a principal diferença é que o estado da cadeia é liquidado pelos nós completos de rollup em vez do contrato inteligente consagrado no L1. Uma comparação mais detalhada pode ser consultada https://www.cryptofrens.info/p/settlement-layers-ethereum-rollups

É importante notar que mais segurança não equivale a melhor desempenho. Tipicamente, à medida que as medidas de segurança aumentam, há um compromisso com a escalabilidade. Portanto, é essencial encontrar um equilíbrio entre os dois. Em conclusão, os rollups oferecem a flexibilidade de selecionar diferentes níveis de pressupostos de segurança com base em preferências individuais. Esta adaptabilidade é uma das características notáveis do mundo modular, permitindo uma abordagem personalizada para atender a necessidades específicas, mantendo a integridade do sistema.

Equilibrar a Personalização e a Interoperabilidade

É um adágio bem conhecido no mundo modular: “Modularismo, não maximalismo.” Se os rollups não puderem interoperar de forma segura e eficiente, então modularismo ≠ maximalismo mas = fragmentação. É crucial descobrir como lidar com a interoperabilidade entre diferentes rollups.

Vamos primeiro revisitar como as cadeias monolíticas alcançam a interoperabilidade. Em termos mais simples, alcançam operações entre cadeias verificando o consenso ou estado da outra cadeia. Existem várias abordagens disponíveis no mercado, e as diferenças residem em quem é responsável pela verificação (entidades oficiais, mecanismos de multi-assinatura, redes descentralizadas, etc.) e como a correção da verificação é assegurada (através de partes externas, garantias econômicas, mecanismos optimistas, zk-proofs, etc.). Para uma análise mais profunda sobre este tópico, confira as minhas peças de ponte favoritas: Pensamentos sobre Interoperabilidade.

Com o aumento da modularização, a questão da interoperabilidade tornou-se mais intrincada:

1. Problema de fragmentação:
   1. A proliferação de rollups é esperada para ultrapassar significativamente o número de L1s, pois é muito mais fácil aterrar um l2 do que um l1. Isso poderia levar a uma rede altamente fragmentada?
   2. Embora as blockchains monolíticas ofereçam um consenso e estado consistentes para verificação direta, qual será o processo de verificação para blockchains modulares que têm três (ou possivelmente quatro) componentes distintos (DA, execução, liquidação e sequenciamento)?
      1. DA e a camada de liquidação tornam-se a principal fonte de verdade. A verificação de execução já está disponível, uma vez que os rollups fornecem inerentemente provas de execução. A sequenciação ocorre antes da publicação no DA.
2. Problema extensível:
   1. À medida que novas rollups são introduzidas, surge a questão: podemos oferecer prontamente serviços de ponte para acomodá-las? Mesmo que a construção de uma rollup seja sem permissão, você pode precisar gastar 10 semanas convencendo outras pessoas a adicionar uma. Os serviços de ponte atuais atendem predominantemente a rollups e tokens mainstream. Com o potencial influxo de várias rollups, há uma preocupação sobre se esses serviços podem avaliar e lançar eficientemente soluções correspondentes para apoiar essas rollups emergentes sem comprometer a segurança e funcionalidade.
3. Problema de experiência do utilizador:
   1. O ajuste final dos rollups otimistas demora sete dias, muito mais do que outros L1s. O desafio é abordar o tempo de espera de sete dias para as pontes oficiais dos rollups otimistas. A submissão de zkp também tem um atraso, já que os rollups normalmente aguardam para acumular um grande lote de transações antes de apresentar a prova para economizar custos de verificação. Rollups populares como StarkEx geralmente postam provas no L1 apenas uma vez a cada poucas horas.
   2. Os dados de tx do Rollups submetidos à camada DA/settlement terão um atraso de tempo para poupar custos (1-3 minutos para rollups otimistas e algumas horas para rollups zk, como mencionado acima. Isso precisa ser abstraído dos usuários que têm necessidades de finalidade mais rápida e segura.

A boa notícia é que estão a surgir soluções para estes desafios:

1. Problema de fragmentação:
   1. Embora haja uma proliferação de rollups no ecossistema, é digno de nota que a maioria dos rollups de contratos inteligentes compartilham atualmente uma camada de liquidação comum, nomeadamente a Ethereum. As principais distinções entre estes rollups residem nas suas camadas de execução e sequenciação. Para alcançar a interoperabilidade, simplesmente precisam de verificar mutuamente o estado final da camada de liquidação partilhada. No entanto, o cenário torna-se ligeiramente mais intrincado para rollups soberanos. A sua interoperabilidade é algo desafiante devido às diferentes camadas de liquidação. Uma abordagem para lidar com isto é estabelecer um mecanismo de liquidação Peer-to-Peer (P2P), onde cada cadeia incorpora diretamente um cliente leve da outra, facilitando a verificação mútua. Alternativamente, estes rollups soberanos podem primeiro ligar-se a um hub de liquidação centralizado, que então serve como um conduto para se conectar com outras cadeias. Esta abordagem centrada no hub simplifica o processo e garante uma interconexão mais coesa entre diversos rollups (semelhante ao estado da interoperabilidade do cosmos).

1. Além do Ethereum servir como um dos hubs de liquidação, outros hubs de liquidação potenciais incluem Arbitrum, zkSync e StarkNet, que atuam como hubs de liquidação para L3s construídos sobre eles. A camada de interoperabilidade do Polygon 2.0 também funciona como um hub central para rollups zk construídos em cima dela.
2. Em conclusão, embora o número de rollups e suas variações esteja a expandir, a quantidade de hubs de liquidação permanece limitada. Isso simplifica efetivamente a topologia, reduzindo o problema de fragmentação para apenas alguns hubs-chave. Embora haja mais rollups do que altl1s, as interações entre rollups são menos complicadas do que as interações entre l1, pois os rollups geralmente se enquadram na mesma zona de confiança/segurança.
3. Como os diferentes centros de liquidação interagem entre si pode referir-se à forma como as cadeias monolíticas atuais interagem entre si, como mencionado no início.

Além disso, no esforço de eliminar a fragmentação do lado do utilizador, certas Camadas 2, como ZKSync, integraram Abstração de Conta nativa para facilitar uma experiência sem costuras entre rollups.

1. Problema extensível
   1. Hyperlane(fornecer segurança modular para cadeias modulares) e Catalyst(Liquidez sem permissão entre cadeias) nascem para resolver o problema de interoperabilidade com permissão.
      1. A essência da Hyperlane é criar uma camada de segurança padronizada que pode ser aplicada em várias cadeias, tornando-as intrinsecamente interoperáveis.
      2. O Catalyst foi concebido para oferecer liquidez sem permissão para cadeias modulares. Age como uma ponte, permitindo que qualquer nova cadeia se conecte à liquidez e troque com hubs principais como Ethereum e Cosmos de forma transparente.
   2. Os fornecedores do SDK/RAAS Rollup oferecem serviços de ponte nativos dentro do seu ecossistema
      1. Agora, os novos rollups são lançados principalmente através de SDKs de rollup existentes ou serviços RAAS, por isso são inerentemente interoperáveis com outros rollups que utilizam os mesmos serviços. Por exemplo, para infraestruturas construídas com o OP Stack, o nível fundamental é um padrão de ponte partilhado, que permite a movimentação sem problemas de ativos em tudo o que partilha a base de código do OP Stack. Para rollups lançados através do altlayer, todos estão consagrados à camada beacon, que atua como o hub de liquidação e garante a interoperabilidade segura. Para rollups lançados através de sovereign labs ou zksync, são interoperáveis entre si 'out of the box' com base na agregação de provas (explicarei mais tarde).

Problema UE:

1. Antes de mergulhar nesta parte, vamos primeiro reconhecer diferentes níveis de compromissos e o seu atraso temporal:

1. Algumas partes estão confortáveis com compromissos suaves de estágio 1 por l2, por exemplo, exchanges como Binance apenas esperam por um certo número de blocos Layer2 para considerar transações como confirmadas, sem a necessidade de esperar pelo processamento em lote a ser submetido ao Layer12. Alguns provedores de pontes como o protocolo hop pegariam tantos blocos na cadeia de envio e determinariam a finalidade com base no consenso L1 (estágio 2)3. Para pontes com minimização de confiança e para que os usuários retirem os fundos de l2-l1 usando a ponte oficial, pode demorar muito (várias horas e 7 dias)

1. Reduzir o Estágio 2 ou o Estágio 3 ofereceria vantagens significativas, proporcionando uma garantia mais forte num período de tempo mais curto para uma experiência do utilizador mais segura e rápida. Além disso, alcançar uma ponte com minimização de confiança sempre foi um objetivo desejado, especialmente à luz dos frequentes incidentes de segurança com pontes.
2. Reduzir o tempo final de liquidação (7 dias para rollups otimistas e várias horas para rollups zk), ou seja, encurtar a fase 3
   1. Rollups Híbridos (Prova de Fraude + ZK): Esta abordagem combina as vantagens das provas ZK e dos rollups otimistas. Embora a geração e verificação de provas possam ser intensivas em recursos, apenas são executadas quando uma transição de estado é contestada. Em vez de enviar uma prova ZK para cada lote de transações, a prova é calculada e enviada apenas quando um estado proposto é contestado, semelhante a um rollup otimista. Isso permite um período de contestação mais curto, uma vez que a prova de fraude pode ser gerada em um único passo e o custo das provas ZK é evitado na maioria dos cenários.
      1. De destacar que os agrupamentos SVM da Eclipse e da LayerN utilizam risc0 para gerar a prova de fraude zk. O OP Stack concedeu suporte a Risc0 e Mina para o desenvolvimento da prova de fraude zk. Além disso, Fuel introduziu recentemente um método híbrido semelhante que suporta vários provadores.
   2. Após a postagem de dados na camada DA, faça alguma verificação extra da correção da execução para aumentar o nível de confiança - requisitos elevados, o mesmo que um nó completo
      1. Quando o sequenciador agrupa as txs nas camadas DA dos rollups otimistas, garante a ordenação canônica e DA para as txs x-rollup. Portanto, a única coisa que precisa ser confirmada é a execução: S1 == STF(S0, B1). Claro, você pode simplesmente executar um nó completo (requisitos elevados) para verificar a tx, mas o que realmente queremos é reduzir a latência para clientes leves. Redes de provadores como @SuccinctLabse@RiscZeropode confirmar o estado pós-execução fornecendo provas de estado sucintas. Isso fornece uma confirmação robusta para dapps e usuários.
      2. Altlayer tem uma camada de farol entre os rollups e L1. Os sequenciadores da camada de farol são responsáveis por sequenciar, executar e gerar a prova de validade (POV). POV permite que os verificadores verifiquem uma transição de estado para um rollup mais tarde sem ter acesso ao estado inteiro. Com verificadores descentralizados realizando verificações periódicas, alcançamos uma finalidade de transação altamente robusta. Não é necessário esperar 7 dias, pois os verificadores já concluíram as verificações necessárias. Como resultado, as mensagens entre cadeias tornaram-se mais rápidas e seguras.
      3. EigenSettle garante verificação através de mecanismos econômicos. Os nós Opt-in EigenLayer com apostas realizam o cálculo para garantir a validade do estado e usam seu colateral para respaldar seus compromissos. Qualquer montante inferior ao valor da aposta que esses operadores tenham publicado pode ser tratado como liquidado com segurança e permite interoperabilidade respaldada economicamente.
   3. Verificação instantânea com ZK Rollups:
      1. A Sovereign Labs e a Polygon 2.0 empregam uma abordagem inovadora para atingir a finalidade rápida contornando a camada de resolução. Em vez de esperar para enviar a prova para o Ethereum, podemos instantaneamente disseminar as provas zk geradas através de uma rede peer-to-peer e realizar operações entre cadeias com base nos zkps propagados. Mais tarde, podemos utilizar a recursão para consolidá-los num lote de provas e submetê-lo à Camada 1 quando se tornar economicamente viável.
         1. No entanto, ainda não está totalmente resolvido, ainda precisamos confiar na agregação correta do zkp. O Agregador do Polygon 2.0 pode ser operado de forma descentralizada, envolvendo validadores do Polygon do pool de validadores compartilhado, melhorando assim a vitalidade da rede e a resistência à censura. No entanto, o uso deste método também levará a um tempo de finalização mais curto, uma vez que a agregação de zkps de várias cadeias é certamente mais rápida do que esperar por zkps suficientes em uma única cadeia.
      2. Os hiper-cadeias da Zksync utilizam o método de camadas para agregar zkp e alcançar uma finalidade mais curta. Em contraste com a resolução em L1, as hiper-cadeias podem resolver suas provas em L2 (tornar-se um l3). Esta abordagem facilita a comunicação rápida, uma vez que o ambiente econômico em L2 possibilita uma verificação rápida e economicamente viável.
         1. Para aumentar ainda mais a escalabilidade, podemos substituir o L2 settlement por um programa mínimo necessário para operar o L3 com mensagens. Este conceito foi substanciado através de provas especializadas que permitem a agregação.
3. Abordar o atraso na publicação para a camada DA (alguns métodos também podem ser aplicados para reduzir o período de liquidação), ou seja, encurtar a fase 2
   1. Camada de Sequenciamento Compartilhada: Se os rollups compartilharem uma camada de sequenciamento (por exemplo, através de um serviço de sequenciador compartilhado ou usando o mesmo conjunto de camadas de sequenciamento), eles podem obter uma confirmação suave do sequenciador. Isso, combinado com um mecanismo econômico, garante a integridade do estado final. Combinações possíveis incluem:
      1. O sequenciador e construtor partilhado sem estado faz uma promessa de execução através do staking proposto pela Espresso; Esta abordagem é mais adequada para rollups com a estrutura PBS, assumindo que o construtor de blocos já tem os direitos necessários para partes dos blocos. Uma vez que o construtor tem estado e serve como o papel de execução subjacente para os sequenciadores partilhados, é natural que faça promessas adicionais.
      2. Sequenciação de validade compartilhada proposta pela pesquisa Umbra: sequenciador compartilhado stateful + prova de fraude para garantir bom comportamento. Os sequenciadores aceitam pedidos entre cadeias. Para evitar comportamentos desonestos por parte dos sequenciadores, é usado um mecanismo de prova de fraude compartilhado, envolvendo ligeiras alterações ao mecanismo de prova de fraude original. Durante o período de desafio, os desafiantes também verificariam a execução correta das ações atômicas. Isso pode envolver a verificação das raízes dos contratos de ponte em diferentes rollups ou examinar a prova de Merkle fornecida pelos sequenciadores. Os sequenciadores desonestos são penalizados.
   2. Intervenção de Terceiros: Entidades externas como Hop, Connext e Across podem intervir para mitigar riscos. Eles validam mensagens e disponibilizam o capital para as atividades financeiras entre cadeias dos utilizadores, reduzindo eficazmente o período de espera. Por exemplo, o Boost (GMP Express) é uma funcionalidade especial do Axelar e Squid que reduz o tempo de transação entre cadeias para 5-30 segundos para trocas abaixo do valor de $20.000 USD.
   3. Infraestrutura de intenção para a ponte como uma forma específica de intervenção de terceiros: Esta infraestrutura renovada pode abranger mais terceiros para intervir e resolver as intenções entre domínios cruzados para os utilizadores.
      1. Através de uma arquitetura focada na intenção (eliminando atritos e complexidades dos utilizadores ao envolver atores sofisticados como MMs e construtores), os utilizadores transmitem o seu objetivo ou resultado pretendido sem detalhar as transações precisas necessárias para o concretizar. Indivíduos com uma tolerância elevada ao risco podem intervir, disponibilizar o capital necessário e cobrar taxas mais elevadas.
      2. É mais seguro porque os fundos dos utilizadores só seriam libertados quando o resultado for válido. Pode ser mais rápido e flexível porque mais partes (solucionadores) estão envolvidas no processo de resolução sem permissão e competindo para fornecer um resultado melhor aos utilizadores.
      3. UniswapX, SUAVE dos flashbots e essencial estão todos a trabalhar nesta direção. Mais sobre intenções: \
         nft://10/0x9351de088B597BA0dd2c1188f6054f1388e83578/?showBuying=true&showMeta=true
      4. O aspecto desafiante desta solução centra-se no oráculo de liquidação. Vamos pegar no UniswapX como exemplo. Para facilitar trocas entre cadeias, dependemos de um oráculo de liquidação para determinar quando libertar fundos para os resolutores. Se o oráculo de liquidação optar pela ponte nativa (que é lenta), ou se for utilizada uma ponte de terceiros (levantando preocupações de confiança), ou mesmo se for uma ponte de Cliente Leve (ainda não pronta para uso), essencialmente encontramo-nos no mesmo ciclo que antes. Portanto, o UniswapX também oferece “Trocas rápidas entre cadeias” semelhantes a uma ponte otimista.
      5. Simultaneamente, a eficácia da resolução de intenções depende da competição entre os solvers. Uma vez que os solvers precisam reequilibrar o seu inventário entre diferentes cadeias, isso pode potencialmente levar a problemas de solvers centralizados, limitando o pleno potencial das intenções.

Para resumir, pode-se observar que existem três formas de abordar os problemas do UE:

1. Usa a magia do zk :
   1. O desafio principal reside no desempenho da tecnologia zk, abrangendo tanto o tempo necessário para a geração quanto os custos associados. Além disso, ao lidar com blockchains modulares altamente personalizáveis, surge a questão: possuímos um sistema de prova zk capaz de acomodar a miríade de diferenças?
2. Use um esquema de corte econômico para garantir :
   1. A principal desvantagem desta abordagem é o atraso temporal inerente ao método descentralizado (por exemplo, no caso do EigenSettle, temos de esperar que o limite seja atingido). Além disso, a abordagem centralizada oferece compromissos limitados (como exemplificado pela sequência partilhada), dependendo de construtores/sequenciadores para assumir compromissos, que podem ser restritos e carecer de extensibilidade.
3. Confie em um terceiro :
   1. Embora confiar numa terceira parte possa introduzir riscos adicionais, já que os utilizadores devem ter fé na ponte, as trocas entre domínios habilitadas para intenções representam uma forma um tanto mais “descentralizada” de interligação de terceiros. No entanto, esta abordagem ainda enfrenta a latência do oráculo, problemas de confiança e possíveis atrasos temporais, já que é necessário aguardar que alguém aceite a sua intenção.

É interessante que a modularização também introduza novas possibilidades para experiências de interoperabilidade:

1. Velocidade aprimorada com componentes modulares: Ao se dividir em módulos mais finos, os usuários podem obter confirmações mais rápidas a partir do nível layer2 (que pode já ser seguro o suficiente para usuários comuns)
2. Sequenciador partilhado para transações atómicas: O conceito de um sequenciador partilhado poderia potencialmente permitir uma nova forma de transações atómicas, como empréstimos relâmpago. Mais detalhes em : https://twitter.com/sanjaypshah/status/1686759738996912128

Soluções de interoperabilidade modular estão a crescer rapidamente e, atualmente, existem várias abordagens, cada uma com as suas próprias forças e fraquezas. Talvez a solução final ainda esteja um pouco distante, mas é encorajador ver tantas pessoas a esforçarem-se para criar um mundo modular mais seguro e conectado antes da explosão do rollup.

Análise de custos

Um dos fatores que contribui para o número limitado de rollups existentes é a consideração econômica associada ao seu lançamento, em comparação com a utilização de contratos inteligentes. Operar via contratos inteligentes adota um modelo de custo mais variável, onde a despesa principal é a taxa de gás, enquanto o lançamento e manutenção de um rollup incorrem em custos fixos e variáveis. Essa dinâmica de custo sugere que aplicações com um volume substancial de transações ou taxas de transação relativamente altas estão melhor posicionadas para aproveitar os rollups, pois têm uma maior capacidade de amortizar os custos fixos envolvidos. Consequentemente, iniciativas destinadas a reduzir o custo associado aos rollups—tanto fixos quanto variáveis—são fundamentais. Aprofundar os componentes de custo dos rollups, conforme elucidado por Neel e Yaoqi durante sua palestra na ETHCC, fornece uma imagem mais clara:

Ao empregar um modelo financeiro, como a análise do Fluxo de Caixa Descontado (DCF), pode ser fundamental para avaliar a viabilidade de lançar um rollup para uma aplicação. A fórmula:

DCF(Receitas - Despesas)>Investimento Inicial

serve como base para determinar se o rendimento operacional ultrapassa o investimento inicial, tornando assim o lançamento de um rollup uma decisão financeiramente sólida. Protocolos que conseguem reduzir os custos operacionais enquanto aumentam a receita são fundamentais para incentivar a adoção crescente de rollups. Vamos explorar um por um:

1. Taxa de Desenvolvimento e Implantação Inicial
   1. A configuração inicial, apesar da disponibilidade de SDKs de código aberto como Opstack e Rollkit, ainda exige uma quantidade significativa de tempo e capital humano para instalação e depuração. As necessidades de personalização, por exemplo, a integração de uma VM em um SDK, aumentam ainda mais os recursos necessários para alinhar a VM com as várias interfaces que cada SDK fornece.
   2. Serviços RAAS como AltLayer e Caldera podem aliviar significativamente essas complexidades e esforços, encapsulando os benefícios econômicos da divisão do trabalho.
2. Taxa/Receita Recorrente
   1. Receitas (++++)
      1. Taxas de utilizador
         1. = Taxa de Envio de Dados L1 + Taxa do Operador L2 + Taxa de Congestionamento L2
         2. Embora algumas taxas de utilizador possam ser compensadas por despesas, analisar e esforçar-se para reduzir esses custos é vital, pois os rollups podem tornar-se insustentáveis se as taxas de utilizador forem proibitivamente altas para os utilizadores. (Explorado na secção de despesas)
      2. Valor Extraível pelo Minerador (MEV) capturado
         1. Principalmente relacionado com o valor da transação originário da cadeia, isto pode ser impulsionado quer ao melhorar a eficiência de extração de MEV ou aumentar o MEV entre domínios.
         2. Ao fazer parceria com buscadores estabelecidos, empregar um leilão PBS para fomentar a competição ou aproveitar a construção de blocos da SUAVE como serviço são estratégias viáveis para otimizar a eficiência de captura de MEV.
         3. Para capturar mais MEV entre cadeias, é benéfico utilizar uma camada de sequenciador compartilhada ou SUAVE (mempool compartilhado e construção de bloco compartilhada) pois estas se conectam a vários domínios.
            1. De acordo comPesquisas recentespor Akaki, os sequenciadores partilhados são valiosos para os caçadores de arbitragem que procuram aproveitar oportunidades de arbitragem em diferentes cadeias, pois garantem a vitória em corridas simultâneas em todas as cadeias.
            2. SUAVE serve como uma camada de agregação de fluxo de pedidos multi-domínio, auxiliando o construtor/pesquisador a explorar o MEV entre domínios.
   2. Despesas （- - - -)
      1. Taxa de operação da camada 2 (L2)
         1. Ordenação: Pode ser complicado comparar soluções de encomenda centralizadas e descentralizadas. A concorrência em soluções mais descentralizadas, como a Prova de Eficiência, pode ajudar a diminuir os custos, mantendo a margem mínima do operador e também incentivando a publicação de lotes com a maior frequência possível. Por outro lado, as soluções centralizadas normalmente envolvem menos partes, o que pode simplificar o processo, mas pode não se beneficiar da mesma dinâmica de redução de custos.
         2. Execução: Aqui é onde os nós completos usam VMs/EVMs para executar as alterações no estado de um rollup dadas novas transações de usuário.
            1. A eficiência pode ser reforçada por meio de VMs alt otimizadas, como o Fuel e a Solana VM do Eclipse, que permitem a execução paralela. No entanto, desviar-se da compatibilidade com EVM pode introduzir atrito para desenvolvedores e usuários finais, juntamente com possíveis problemas de segurança. A compatibilidade da Stylus da Arbitrum com EVM e WASM (que é mais eficiente do que EVM) é louvável.
         3. Prova
            1. Mercado Prover
               1. Teoricamente, a utilização de um mercado especializado de provadores como Risc0, =nil e marlin, em vez de criar uma rede de provadores centralizada ou descentralizada proprietária, pode resultar em economia de custos por várias razões:
                  1. Pode haver um nível mais elevado de participação num mercado de provadores dedicado, o que por sua vez promove uma maior concorrência, levando, em última análise, a preços mais baixos.
                  2. Os provadores podem otimizar o uso de hardware e ser reaproveitados quando uma aplicação específica não requer a geração imediata de prova, reduzindo os custos de operação e fornecendo um serviço mais barato.
                  3. Naturalmente, existem desvantagens, incluindo a potencial captura de menos utilidade de token e a dependência do desempenho de uma parte externa. Além disso, os zk rollups distintos podem impor pré-requisitos de hardware variados para o processo de geração de prova. Essa variabilidade poderia representar um desafio para os provadores que buscam expandir suas operações de prova.
                  4. mais sobre o mercado da Gate e a rede da Gate: https://figmentcapital.medium.com/mercados-de-prova-decisórios-descentralizados-e-infraestrutura-zk-f4cce2c58596
      2. Camada 1 (L1) publicação de dados
         1. Optar por uma camada de Disponibilidade de Dados (DA) mais económica, para além do Ethereum ou mesmo utilizando a solução DAC, pode reduzir significativamente os custos, embora ao custo potencial de uma segurança reduzida (explorada mais a fundo na camada de segurança). Para jogos e redes sociais, que geralmente têm um valor baixo mas uma largura de banda alta, a escalabilidade pode ser um fator mais importante do que a segurança para eles.
         2. Empregar Ethereum como a camada DA permite alavancar protodansharing e dansharding para alcançar eficiência de custos. Além disso, dado que a taxa de lançamento de blob é definida por bloco, independentemente da utilização do blob pelo rollup, existe uma necessidade de equilíbrio entre custo e atraso: enquanto um rollup idealmente lançaria um blob completo, uma baixa taxa de chegada de transação levando à ocupação total de um espaço de blob resulta em custos de atraso excessivos.
            1. Soluções potenciais: custo conjunto de publicação de blob para rollups pequenos;
      3. Taxa de liquidação L1
         1. Para rollups otimistas, o custo de liquidação é relativamente baixo. Depois do bedrock, o Optimism apenas paga ~5$ por dia para o ethereum;
         2. Para liquidação zk, é relativamente caro para verificação zkp
            1. agregação de provas zk
               1. Dependendo do sistema de prova subjacente, um rollup no Ethereum pode gastar de 300k a 5m de gás para validar uma única prova. Mas como os tamanhos das provas crescem muito lentamente (ou não crescem de todo) com o número de transações, os rollups podem reduzir seu custo por transação esperando para acumular um grande lote de transações antes de enviar uma prova.
               2. Laboratórios soberanos, a camada de interoperabilidade do polígono 2.0, como mencionado anteriormente, agrega provas de múltiplos rollups, cada rollup pode então verificar o estado de múltiplos rollups ao mesmo tempo, economizando nos custos de verificação. A estrutura de camadas do Zksync, combinada com a agregação de provas, reduz ainda mais os custos de verificação.
               3. No entanto, este método é mais eficaz quando dois domínios utilizam o mesmo ZKVM ou um esquema de provador compartilhado (as hipercadeias do zksync usam o mesmo zkEVM com circuitos zkp totalmente idênticos); caso contrário, pode resultar em desempenho comprometido.
                  1. Os laboratórios NEBRA trazem economia de escala e composabilidade de verificação de prova na Ethereum. NEBRA UPA (Universal Proof Aggregator) agrega universalmente provas heterogêneas para que o custo de verificação possa ser amortizado. A UPA pode ser usada para compor provas de diferentes fontes para permitir novos casos de uso.

Em resumo, os principais métodos para economizar nos custos de rollup incluem:

1. Co-agregando com outros rollups para compartilhar taxas ou aproveitar economias de escala:
   1. É de salientar que essa agregação também é potencialmente crucial para alcançar a interoperabilidade. Como anteriormente destacado, o uso de uma camada ou estrutura congruente em diversos rollups simplifica a interação entre eles, garantindo uma troca de informações sem problemas. Essa estratégia consolidada promove uma infraestrutura de Camada 2 mais integrada e unificada.
2. Delegar certas tarefas a prestadores de serviços externos, capitalizando o princípio da divisão do trabalho.

À medida que surgem mais rollups (o que significa que pode colaborar com partes adicionais para dividir as taxas) e mais prestadores de serviços de rollup oferecem serviços mais refinados (fornecendo uma seleção mais ampla de prestadores upstream maduros), antecipamos que as despesas associadas à criação de um rollup diminuirão.

Segurança Compartilhada

Se você pretende alcançar um nível equivalente de segurança (tanto economicamente quanto em termos de descentralização) como a cadeia de origem, basta implantar um contrato inteligente ou um pacote cumulativo de contratos inteligentes. Se o aproveitamento de uma parte da segurança fornecida pela cadeia de origem for suficiente para melhorar o desempenho, existem atualmente várias soluções de segurança compartilhadas à sua disposição.

As soluções de segurança compartilhadas facilitam muito o processo de inicialização de segurança da maioria dos protocolos ou camadas modulares que precisam de segurança inicial. Isso é muito significativo para um futuro mundo modular, pois imaginamos mais infra/protocolos surgindo para facilitar a funcionalidade de um mundo modular e mais partes de um rollup se tornarem modulares, exceto DA, execução, liquidação e sequenciamento. Se um rollup usa uma determinada camada modular (como DA) ou um serviço cuja segurança não está no mesmo nível do Ethereum, então a segurança geral de toda a cadeia modular pode ser comprometida. Precisamos de segurança partilhada para permitir uma economia de serviços SAAS descentralizada e fiável.

Eigenlayer, ICS da Babylon e Cosmos e a segurança em rede da Osmosis desempenham um papel fundamental ao oferecer confiança descentralizada como um serviço a outras entidades infraestruturais.

1. Eigenlayer permite aos validadores de Ethereum reutilizar seu $ETH para proteger outras aplicações construídas na rede.
2. ICS da Cosmos permite ao Cosmos Hub ("cadeia fornecedora") emprestar a sua segurança a outras blockchains ("cadeias consumidoras") em troca de taxas.
3. Segurança Mesh, trazida por osmose, permite que os delegantes de tokens (não validadores) voltem a apostar os seus tokens apostados numa cadeia parceira dentro do ecossistema. Isso permite um fluxo de segurança bidirecional ou multilateral, pois diferentes appchains podem combinar seus mcaps para melhorar a segurança geral.
4. Babylon permite aos detentores de BTC apostar o seu BTC dentro da rede BTC e fornecer segurança a outras cadeias POS otimizando o uso da linguagem de script Bitcoin e utilizando um mecanismo criptográfico avançado

O ICS e o Mesh Security, ambos parte integrante do ecossistema Cosmos, visam principalmente facilitar o empréstimo de segurança entre cadeias. Essas soluções atendem predominantemente às necessidades de segurança das cadeias de aplicativos Cosmos, permitindo que elas aproveitem a segurança de outras cadeias dentro do ecossistema. Especificamente, o cosmos hub ICS oferece para cadeias cosmos que não querem inicializar conjuntos de validadores (segurança replicada), enquanto a segurança de malha exige que cada cadeia tenha seu próprio conjunto de validadores, mas permite uma opcionalidade muito maior para a governança da cadeia.

Por outro lado, Babylon apresenta uma abordagem única, desbloqueando o potencial latente dos ativos ociosos dos detentores de BTC sem mover o BTC para fora de sua cadeia nativa. Ao otimizar o uso da linguagem de script do Bitcoin e integrar mecanismos criptográficos avançados, Babylon fornece segurança adicional aos mecanismos de consenso de outras cadeias com ótimas funcionalidades como períodos de desvinculação mais rápidos. Validadores em outras cadeias POS com BTC podem bloquear seu BTC na rede Bitcoin e assinar blocos POS com chaves privadas de BTC. Desempenhos inválidos como assinaturas duplas vazariam a chave privada do btc do validador e queimariam seu BTC na rede bitcoin. O staking de BTC seria lançado no 2º testnet da Babylon.

Enquanto Babylon navega pelas restrições da falta de suporte a contratos inteligentes do Bitcoin, operadores Eigenlayer na plataforma Ethereum Turing-complete, Não só o Eigenlayer oferece segurança econômica para novos rollups e cadeias, mas seu ambiente no Ethereum também permite uma gama mais diversificada de AVS. De acordo com o artigo da eigenlayer sobre confiança programável,a camada de segurança eigenlayer pode realmente ser dividida em 3 tipos:

1. Confiança económica: Confiança dos validadores que assumem compromissos e apoiam as suas promessas com interesses financeiros. Este modelo de confiança garante a consistência independentemente do número de partes envolvidas. Deve haver condições objetivas de corte que possam ser submetidas e verificadas onchain e geralmente é pesada para restakers.
2. Confiança descentralizada: confiança advinda de uma rede descentralizada operada por operadores independentes e geograficamente isolados. Este aspecto enfatiza o valor intrínseco da descentralização e permite casos de uso que não são objetivamente comprováveis, uma vez que a descentralização aumenta a dificuldade de colusão. Para utilizar a confiança descentralizada, geralmente é leve.
3. Confiança de inclusão Ethereum: confie que os validadores Ethereum construirão e incluirão seus blocos conforme prometido, juntamente com o software de consenso que estão executando. Isso pode ser especificamente comprometido por validadores ethereum (não restakers LST). Eles executam sidecars de software para executar computação extra e receber recompensas extras.

Então agora que estamos claros com os materiais de segurança, o que podemos esperar?

1. ICS e segurança em malha reduzem as barreiras de segurança para as appchains cosmos como neutron, stride e axelar.
2. Eigenlayer pode encaixar em muitas soluções que foram mencionadas antes:
   1. segurança rollup: rede de retransmissão; torre de vigilância, sequenciamento, proteção mev, eigenDA
   2. interoperação rollup: eigensettle; pontes
   3. análise de custos: rede prover
   4. mais para explorar, confirahttps://www.blog.eigenlayer.xyz/eigenlayer-universe-15-unicorn-ideas/
3. Babilônia está executando testnet para aumentar o nível de segurança de outras cadeias de proof of stake. Sua primeira testnet fornece serviço de carimbo de data/hora para adicionar segurança adicional às atividades defi de alto valor de várias cadeias cosmos como akash, osmosis, juno, etc.

A ideia central por trás dessas soluções de segurança compartilhada é aumentar a eficiência de capital de ativos apostados ou ilíquidos, introduzindo responsabilidades adicionais. No entanto, é essencial estar vigilante em relação aos riscos adicionais ao buscar retornos mais altos:

1. A maior complexidade introduz mais incertezas. Os validadores ficam expostos a condições adicionais de penalização que podem não ter treino suficiente, o que pode ser perigoso.
   1. Eigenlayer tem como objetivo resolver este problema ao propor a implementação de um comitê de veto. Este comitê serve como uma entidade mutuamente confiável entre os stakers, operadores e desenvolvedores AVS. No caso de um bug de software dentro do AVS, os stakers e operadores não enfrentarão penalidades, pois o comitê de veto pode lançar um voto de veto. Embora esta abordagem possa não ser inerentemente escalável e possa ser subjetiva se os AVSs não estiverem estritamente alinhados com os casos de uso baseados em ações atribuíveis de forma confiável, ainda pode servir como um meio valioso para iniciar uma estratégia de mitigação de riscos durante as fases iniciais.
2. Maior complexidade também traz encargos adicionais. Pode ser avassalador para validadores menos experientes determinar com qual serviço compartilhar a segurança. Além disso, o período de configuração inicial pode envolver um risco maior de erros. Adicionalmente, devem existir mecanismos para permitir que validadores e stakers “menos experientes em tecnologia” se beneficiem de rendimentos mais elevados, desde que estejam dispostos a aceitar riscos relativamente elevados, sem serem limitados pelas suas capacidades operacionais.
   1. A Rio Network e a Renzo estão a trabalhar em conjunto para abordar eficazmente este desafio para a Eigenlayer, oferecendo uma abordagem estruturada para selecionar cuidadosamente operadores de nó sofisticados e serviços AVS para possíveis reposições, elevando os níveis de segurança e reduzindo as barreiras de entrada para os participantes.

Além disso, à medida que a Eigenlayer ganha uma adoção mais ampla, poderia potencialmente abrir novos horizontes no domínio da Financeirização da Segurança. Isso poderia facilitar a valoração da segurança compartilhada e das várias aplicações construídas sobre ela.

1. Uma limitação apresentada à EigenLayer está na sua capacidade de escalar a alocação de capital para o seu sistema, superando oportunidades de rendimento em DeFi para os mesmos ativos que suporta (LSTs). A EigenLayer valoriza a segurança e isso abre portas para muitos primitivos subvalorizarem esse valor e proporcionarem a capacidade para os restakers tanto restakear como participar no ecossistema DeFi mais amplo.
   1. O Protocolo Ion é um produto que tenta fazer isso para ampliar o alcance que a restaking pode ter. Ion está construindo uma plataforma de empréstimos independente de preço, projetada para apoiar especificamente ativos apostados e re-apostados usando infraestrutura ZK para submeter ao risco de redução de nível inferior presente nesses ativos (sistemas de prova de estado ZK + ZKML). Isso poderia iniciar o início do nascimento de muitos novos primitivos DeFi construídos sobre o valor subjacente de segurança que a EigenLayer mercantiliza, possibilitando ainda mais a capacidade de restaking para escalar em todo o ecossistema.

Ao estarmos no limiar de transformações significativas, é crucial abraçar os princípios da segurança, interoperabilidade e eficácia em termos de custos. Estes pilares não só irão orientar o desenvolvimento de soluções blockchain mais escaláveis e eficientes, como também abrirão caminho para um mundo digital mais interligado e acessível. Abraçar estas mudanças com visão e adaptabilidade certamente conduzirá a avanços inovadores no ecossistema blockchain.

Aviso Legal：

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