Prefácio

Na era da blockchain modular liderada por Ethereum, fornecer serviços de segurança por meio da integração da camada de Disponibilidade de Dados (DA) não é mais tempo um conceito novo. Atualmente, o conceito de segurança compartilhada introduzido pelo staking oferece uma nova dimensão ao espaço modular. Ele aproveita o potencial do "ouro e prata digitais" para fornecer segurança de Bitcoin ou Ethereum a vários protocolos blockchain e cadeias públicas. Essa narrativa é bastante grandiosa, pois não apenas desbloqueia a liquidez de ativos no valor de trilhões de dólares, mas também serve como um elemento-chave em futuras soluções de escala. Por exemplo, as recentes arrecadações maciças de US$ 70 milhões pela participação Bitcoin protocolo Babylon e US$ 100 milhões pela Ethereum retomada protocolo EigenLayer ilustram o forte endosso de principal empresas de capital de risco para esse setor.

No entanto, estes desenvolvimentos também suscitaram preocupações significativas. Se a modularidade for a solução definitiva para o dimensionamento, e esses protocolos forem componentes cruciais dessa solução, eles provavelmente bloquearão grandes quantidades de BTC e ETH. Isso coloca em xeque a segurança dos próprios protocolos. Será que a complexa camada formada por inúmeros protocolos LSD (Liquid Staking Derivados) e LRT (Camada 2 Rollup Tokens) se tornará o maior cisne negro no futuro do blockchain? Sua lógica comercial é sólida? Como já analisamos o EigenLayer em nossos artigos anteriores, a discussão a seguir se concentrará principalmente na Babilônia para abordar essas questões.

Estendendo a segurança Consenso

Bitcoin e Ethereum são inegavelmente os blockchains públicos mais valiosos da atualidade. Sua segurança, descentralização e consenso de valor, acumulados ao longo de muitos anos, são as principais razões pelas quais eles permanecem no auge do mundo blockchain. Essas são qualidades raras que outras cadeias heterogêneas têm dificuldade em replicar. A ideia central da modularidade é "alugar" essas qualidades para quem precisa. Na abordagem atual de modularidade, existem duas facções principais:

A primeira facção usa uma Camada 1 suficientemente segura (geralmente Ethereum) como as três camadas inferiores ou parte das camadas funcionais para Rollups. Esta solução oferece a mais alta segurança e legitimidade e pode absorver recursos do ecossistema da cadeia principal. No entanto, pode não ser particularmente amigável em termos de taxa de transferência e custo para Rollups específicos (cadeias de aplicativos, cadeias de cauda longo, etc.).

A segunda facção pretende criar uma existência próxima da segurança de Bitcoin e Ethereum mas com melhor desempenho de custo, como Celestia. O Celestia consegue isso usando uma arquitetura de função DA pura, minimizando os requisitos de hardware do nó e os baixos custos de gás. Essa abordagem simplificada busca criar uma camada de DA que corresponda à segurança e à descentralização do Ethereum, oferecendo um forte desempenho no menor tempo possível. A desvantagem dessa abordagem é que sua segurança e descentralização ainda precisam de algum tempo para serem totalmente desenvolvidas, e ela carece de legitimidade enquanto está em concorrência direta com Ethereum, principal à rejeição pela comunidade Ethereum.

Um terceiro tipo nesta facção inclui Babylon e EigenLayer. Eles utilizam o conceito central de Proof-of-Stake (POS), aproveitando o valor do ativo de Bitcoin ou Ethereum para criar serviços de segurança compartilhados. Em comparação com os dois primeiros tipos, esta é uma existência mais neutra. Sua vantagem está em herdar legitimidade e segurança, ao mesmo tempo em que fornece mais valor de utilidade aos ativos da cadeia principal e oferece maior flexibilidade.

Potencial do ouro digital

Independentemente da lógica subjacente de qualquer mecanismo de consenso, a segurança de um blockchain depende em grande parte dos recursos que o suportam. PoW cadeias exigem hardware e eletricidade enormes, enquanto PoS depende do valor dos ativos apostados. Bitcoin em si é apoiado por uma rede PoW extremamente grande, tornando-se a presença mais segura em todo o espaço blockchain. No entanto, como uma cadeia pública com um valor de mercado circulante de US$ 1,39 trilhão, respondendo por metade do mercado do blockchain, sua utilidade de ativos é principalmente limitada a transferências e pagamentos gás

Para a outra metade do mundo blockchain, especialmente depois que Ethereum fez a transição para PoS após a atualização de Xangai, pode-se dizer que a maioria das cadeias públicas usa arquiteturas de PoS diferentes para alcançar o consenso por padrão. No entanto, novas cadeias heterogêneas muitas vezes não conseguem atrair capital substancial, colocando em dúvida sua segurança. Na era modular atual, as zonas Cosmos e várias soluções de Camada 2 podem usar várias camadas de DA para compensar, mas isso geralmente vem ao custo da autonomia. Para a maioria dos mecanismos de PoS antigos ou cadeias de consórcio, usar Ethereum ou Celestia como uma camada DA também é geralmente impraticável. O valor da Babilônia está em preencher essa lacuna, usando BTC estaca para fornecer proteção para PoS cadeias. Assim como a humanidade usou o ouro para apoiar o valor do papel-moeda, BTC é bem adequado para desempenhar esse papel no mundo blockchain.

From 0 to 1

Liberar o "ouro digital" sempre foi a narrativa mais ambiciosa e difícil de alcançar no espaço blockchain. Desde os primeiros correntes laterais, Lightning Network e tokens embrulhados em ponte até as Runas e BTC Camada 2 atuais, cada solução tem suas falhas inerentes. Se o Babylon visa aproveitar a segurança do Bitcoin, soluções centralizadas que introduzem suposições de confiança de terceiros devem ser descartadas primeiro. Entre as opções restantes, Runes e Lightning Network (limitado pelo progresso de desenvolvimento extremamente lento) atualmente só têm a capacidade de emissão de ativos. Isso significa que a Babilônia precisa projetar seu próprio "solução de dimensionamento" para permitir que Bitcoin nativos estaquem de 0 a 1.

Decompondo os elementos básicos atualmente utilizáveis por Bitcoin, existem essencialmente os seguintes: 1. UTXO modelo, 2. Carimbos de data/hora, 3. Vários métodos de assinatura, 4. Opcodes básicos. Dada a limitada capacidade de programação e suporte de dados de Bitcoin, a solução da Babylon é baseada no princípio do minimalismo. Por Bitcoin, apenas as funções essenciais para contratos de staking precisam ser concluídas, o que significa BTC staking, cortando, recompensas e recuperação são todos tratados na cadeia principal. Uma vez que esse 0 para 1 é alcançado, demandas mais complexas podem ser tratadas pelo Cosmos zona. No entanto, uma questão crítica permanece: como registrar os dados da cadeia PoS na cadeia principal?

Remote Staking

UTXO (Unspent Transaction Outputs) é o modelo de transação projetado por Satoshi Nakamoto para Bitcoin. A ideia central é extremamente simples: as transações são apenas fundos que entram e saem, de modo que todo o sistema de transações pode ser expresso em termos de entradas e saídas. UTXO representa a parte dos fundos que entram, mas não são totalmente gastos, permanecendo assim como saídas de transação não gastas (ou seja, Bitcoin não pagas). Todo o livro-razão Bitcoin é essencialmente uma coleção de UTXOs, registrando o estado de cada UTXO para gerenciar Bitcoin propriedade e circulação. Toda transação gasta UTXOs antigas e gera novas. Devido ao seu potencial inerente de escalabilidade, UTXO tornou-se naturalmente o ponto de partida para muitas soluções de escalabilidade nativas. Por exemplo, utilizar UTXOs e multisig para criar mecanismos de penalidade e canais de estado para a Lightning Network, ou vincular UTXOs para implementar tokens semifungíveis (SFTs), como inscrições e runas, tudo decorre desse ponto de partida crucial.

A Babylon também precisa aproveitar UTXO para implementar contratos de staking (conhecidos como staking remoto pela Babylon, onde a segurança da Bitcoin é passada remotamente para cadeias de PoS através de uma camada intermediário). A implementação do contrato pode ser dividida em quatro etapas, combinando de forma inteligente os opcodes existentes:

Bloqueio de Fundos

Os usuários enviam fundos para um endereço controlado por multisig. Por meio do OP_CTV (OP_CHECKTEMPLATEVERIFY, que permite criar modelos de transação predefinidos garantindo que as transações só possam ser executadas de acordo com estruturas e condições específicas), o contrato pode especificar que esses fundos só podem ser gastos sob determinadas condições. Uma vez que os fundos são bloqueados, um novo UTXO é gerado, indicando que esses fundos foram apostados.

Verificação de condição

Ao chamar OP_CSV (OP_CHECKSEQUENCEVERIFY, que permite definir um bloqueio de tempo relativo com base no número de sequência da transação, indicando que o UTXO só pode ser gasto após um determinado tempo relativo ou número de blocos), os bloqueios de tempo podem ser implementados. Combinado com OP_CTV, isso pode alcançar staking, unstaking (permitindo que o staker passe o UTXO bloqueado após o período de staking ser cumprido) e cortando (forçando o gasto de UTXO para um endereço bloqueado se o staker agir maliciosamente, tornando-o não gastável, semelhante a um endereço de buraco negro).

Atualizações de estado

Sempre que os usuários staking ou retiram fundos apostados, isso envolve a criação e o gasto de UTXOs. Novas saídas de transação geram novos UTXOs e UTXOs antigos são marcados como gastos. Dessa forma, cada transação e movimentação de fundos é registrada com precisão no blockchain, garantindo transparência e segurança.

Distribuição de Recompensas

Com base no valor apostado e na duração da aposta, o contrato calcula as recompensas e as distribui gerando novas UTXOs. Essas recompensas podem ser desbloqueadas e gastas por meio de condições de script assim que critérios específicos forem atendidos.

Timestamps

Depois de estabelecer um contrato de staking nativo, é natural considerar a questão do registro de eventos históricos de cadeias externas. No white paper de Satoshi Nakamoto, o blockchain Bitcoin introduziu um conceito de carimbos de data/hora suportados por PoW, fornecendo uma ordem cronológica irreversível para eventos. No caso de uso nativo do Bitcoin, esses eventos se referem a várias transações executadas no livro-razão. Hoje, para aumentar a segurança de outras cadeias de PoS, Bitcoin também pode ser usado para eventos de carimbo de data/hora em blockchains externos. Cada vez que esse evento ocorre, ele dispara uma transação enviada aos mineradores, que a inserem no Bitcoin razão, adicionando assim um carimbo de data/hora ao evento. Esses carimbos de data/hora podem resolver vários problemas de segurança de blockchains. O conceito geral de adicionar carimbos de data/hora a eventos em cadeias filhas na cadeia pai é conhecido como "ponto de verificação", e as transações usadas para adicionar carimbos de data/hora são chamadas de transações de ponto de verificação. Especificamente, os carimbos de data/hora no blockchain Bitcoin têm as seguintes características importantes:

• Formato de hora: Os carimbos de data/hora registram o número de segundos desde 1º de janeiro de 1970, 00:00:00 UTC, um formato conhecido como hora Unix ou hora POSIX.
• Objetivo: O principal objetivo de um carimbo de data/hora é marcar o tempo de geração de blocos, ajudando os nós a determinar a ordem dos blocos e auxiliando no mecanismo de ajuste de dificuldade da rede.
• Carimbos de data/hora e ajuste de dificuldade: A rede Bitcoin ajusta a dificuldade de mineração aproximadamente a cada duas semanas, ou a cada blocos de 2016. Os carimbos de data/hora desempenham um papel crucial nesse processo, pois a rede ajusta a dificuldade com base no tempo total de geração dos blocos mais recentes de 2016 para garantir que novos blocos sejam gerados aproximadamente a cada 10 minutos.
• Verificação de validade: quando um nó recebe um novo bloco, ele verifica o carimbo de data/hora. O carimbo de data/hora de um novo bloco deve ser maior do que o tempo médio de vários blocos anteriores e não deve exceder o tempo de rede em mais de 120 minutos (2 horas no futuro).

O servidor de carimbo de data/hora é uma nova primitiva definida pelo Babylon, que pode alocar Bitcoin carimbos de data/hora através de pontos de verificação do Babylon em blocos PoS, garantindo a precisão e o imutabilidade da sequência de tempo. Este servidor atua como a camada superior em toda a arquitetura da Babylon, servindo como a principal fonte de confiança.

Arquitetura de três camadas da Babylon

Conforme ilustrado no diagrama, a arquitetura geral da Babylon pode ser dividida em três camadas: Bitcoin (servindo como o servidor de carimbo de data/hora), Babylon (uma Zona Cosmos atuando como a camada intermediário) e as cadeias PoS como a camada de demanda. Babylon refere-se aos dois últimos como o Plano de Controle (a própria Babilônia) e o Plano de Dados (várias cadeias de consumo PoS).

Tendo entendido a implementação básica sem confiança do protocolo, vamos nos aprofundar em como a própria Babilônia conecta as duas extremidades usando o Cosmos zona. De acordo com a explicação detalhada do Tse Lab de Stanford sobre Babylon, Babylon pode receber fluxos de pontos de verificação de várias cadeias de PoS e mesclar esses pontos de verificação para publicar em Bitcoin. Usando assinaturas agregadas do Babylon validadores, o tamanho do ponto de verificação pode ser minimizado, e a frequência desses pontos de verificação é controlada permitindo que o Babylon validadores mude apenas uma vez por época.

Validadores de várias cadeias de PoS baixam blocos Babylon para verificar se seus pontos de verificação PoS estão incluídos nos blocos Babylon verificados Bitcoin. Isso permite que as cadeias de PoS detectem discrepâncias, como se o Babylon validadores criar um bloco indisponível verificado por Bitcoin e mentir sobre os PoS pontos de verificação contidos nele. Os principais componentes do protocolo são os seguintes:

· Pontos de verificação: Apenas o último bloco de uma época da Babilônia é verificado por Bitcoin. Um ponto de verificação consiste na cerquilha do bloco e uma única assinatura BLS agregada, correspondendo às assinaturas da maioria de dois terços dos validadores que assinaram o bloco para fins definitivos. Os postos de controle da Babilônia também incluem o número da época. PoS blocos podem atribuir carimbos de data/hora Bitcoin por meio de pontos de verificação do Babylon. Por exemplo, os dois primeiros blocos PoS são marcados por blocos Babylon, que são então marcados por um bloco Bitcoin com carimbo de data/hora t_3. Consequentemente, esses blocos PoS recebem a Bitcoin t_3 de carimbo de data/hora.

· Cadeias PoS canônicas: Quando ocorre uma cadeia PoS garfo, a cadeia com o carimbo de data/hora anterior é considerada a cadeia PoS canônica. Se dois garfos tiverem o mesmo carimbo de data/hora, o empate é quebrado em favor do bloco PoS com um ponto de verificação anterior na Babilônia.

· Regras de retirada: Para retirar, validadores enviar uma solicitação de saque para a cadeia de PoS. O bloco de PoS contendo a solicitação de retirada é então marcado pelo Babylon e, posteriormente, por Bitcoin, atribuindo-lhe t_1 de carimbo de data/hora. Uma vez que o bloco Bitcoin com carimbo de data/hora t_1 atinge uma profundidade de k, a retirada é concedida na cadeia de PoS. Se um validador com stakes retirados tentar um ataque de longo alcance, os blocos na cadeia de ataque só poderão receber um carimbo de data/hora posterior a t_1. Isso ocorre porque uma vez que o bloco Bitcoin com carimbo de data/hora t_1 atinge uma profundidade de k, ele não pode ser revertido. Ao observar a ordem desses pontos de verificação em Bitcoin, PoS clientes podem distinguir a cadeia canônica da cadeia de ataque e ignorá-la.

· Regras de corte: Se validadores não retirarem suas apostas ao detectar um ataque, elas podem ser cortadas por terem assinado duas vezes blocos de PoS conflitantes. Os PoS validadores mal-intencionados sabem que, se esperarem até que sua solicitação de retirada seja aprovada para lançar um ataque de longo alcance, eles não podem enganar os clientes que podem consultar Bitcoin para identificar a cadeia canônica. Assim, eles podem garfo a cadeia PoS enquanto atribuem carimbos de data/hora Bitcoin blocos na cadeia de PoS canônica. Esses PoS validadores, em colaboração com validadores mal-intencionados da Babylon e mineradores de Bitcoin, garfo Babylon e Bitcoin substituir o bloco Bitcoin por t_2 de carimbo de data/hora por outro bloco com t_3 de carimbo de data/hora. Na visão subsequente de PoS clientes, isso mudaria a cadeia de PoS canônica da cadeia superior para a cadeia inferior. Embora este seja um ataque de segurança bem-sucedido, ele resulta na cortando das apostas dos PoS validadores maliciosos, porque eles assinaram blocos conflitantes com assinatura dupla sem retirar suas apostas.

· Indisponibilidade de PoS Checkpoint Pausing Rules: PoS validadores devem pausar sua cadeia de PoS ao observar um ponto de verificação de PoS indisponível no Babylon. Um ponto de verificação de PoS indisponível é definido como o cerquilha assinado por dois terços do PoS validadores, que supostamente corresponde a um bloco de PoS que não pode ser observado. Se PoS validadores não pausar a cadeia de PoS ao observar um ponto de verificação indisponível, um invasor poderá revelar uma cadeia de ataque anteriormente indisponível, alterando a cadeia canônica em exibições posteriores do cliente. Isso ocorre porque o ponto de verificação da cadeia de sombras revelado mais tarde aparece mais cedo na Babilônia. A regra de pausa acima explica por que exigimos que os hashes de bloco PoS enviados como pontos de verificação sejam assinados pelo conjunto de validadores PoS. Se esses pontos de verificação não estivessem assinados, qualquer invasor poderia enviar uma cerquilha arbitrária, alegando ser o cerquilha de um ponto de verificação de bloqueio de PoS indisponível no Babylon. PoS validadores então teria que fazer uma pausa no posto de controle. Observe que criar uma cadeia de PoS indisponível é um desafio: requer comprometer pelo menos dois terços do PoS validadores para aprovar o bloco de PoS sem fornecer dados a validadores honestos. No entanto, no ataque presumido acima, o adversário malicioso pausa a cadeia de PoS sem comprometer um único validador. Para evitar esses ataques, exigimos que PoS pontos de controle sejam assinados por dois terços dos PoS validadores. Consequentemente, não haverá pontos de controle de PoS indisponíveis na Babilônia, a menos que dois terços dos PoS validadores sejam comprometidos, o que é altamente improvável devido ao custo de comprometer a PoS validadores e não afeta outras cadeias de PoS ou a própria Babilônia.

· Indisponibilidade das Regras de Pausa do Ponto de Verificação da Babilônia: Tanto a PoS quanto a validadores da Babylon devem pausar o blockchain ao observar um ponto de verificação da Babylon indisponível no Bitcoin. Um ponto de verificação Babylon indisponível é definido como um cerquilha com uma assinatura BLS agregada de dois terços da validadores da Babilônia, que supostamente corresponde a um bloco da Babilônia que não pode ser observado. Se o Babylon validadores não pausar o blockchain Babylon, um invasor pode revelar uma cadeia Babylon anteriormente indisponível, alterando a cadeia Babylon canônica em visualizações posteriores do cliente. Da mesma forma, se PoS validadores não pausar a cadeia de PoS, o invasor poderá revelar uma cadeia de ataque PoS anteriormente indisponível e a cadeia Babylon anteriormente indisponível, alterando a cadeia de PoS canônica em exibições posteriores do cliente. Isso ocorre porque a cadeia profunda da Babilônia revelada mais tarde tem um carimbo de data/hora anterior em Bitcoin e inclui pontos de verificação da cadeia de ataque PoS revelada posteriormente. Semelhante à regra para pausar em pontos de verificação de PoS indisponíveis, essa regra explica por que exigimos que os hashes de bloco Babylon enviados como pontos de verificação tenham uma assinatura BLS agregada provando as assinaturas de dois terços dos validadores Babylon. Se os postos de controle da Babilônia não fossem assinados, qualquer adversário poderia enviar uma cerquilha arbitrária, alegando ser a cerquilha de um ponto de verificação de bloqueio da Babilônia indisponível em Bitcoin. PoS validadores e Babylon validadores teriam então que esperar por um ponto de controle que não tenha cadeias de Babylon ou PoS indisponíveis em sua pré-imagem. Criar uma cadeia Babylon indisponível requer comprometer pelo menos dois terços da validadores Babylon. No entanto, no ataque assumido acima, o adversário pausa todas as cadeias do sistema sem comprometer um único validador de Babilônia ou PoS. Para evitar tais ataques, exigimos que os postos de controle da Babilônia sejam comprovados por assinaturas agregadas; assim, não haverá pontos de controle da Babilônia indisponíveis a menos que dois terços dos validadores sejam comprometidos, o que é altamente improvável devido ao custo de comprometer a validadores da Babilônia. Mas, em casos extremos, afetará todas as cadeias de PoS, forçando-as a pausar.

Eigenlayer em BTC

Em termos de propósito, embora a Babilônia seja semelhante a Eigenlayer, ela está longe de ser uma simples "garfo" de Eigenlayer. Dada a incapacidade atual de usar nativamente DA na cadeia principal BTC, a presença da Babilônia é bastante significativa. Esse protocolo não só traz segurança para as cadeias PoS externas, mas também é crucial para revitalizar o ecossistema BTC internamente.

Casos de uso

O Babylon apresenta inúmeros casos de uso potenciais, alguns dos quais já foram realizados ou podem ter oportunidades de realização no futuro:

1. Reduzindo os períodos de Staking e aumentando a segurança: as cadeias de PoS normalmente exigem consenso social (consenso entre a comunidade, operadores de nós e validadores) para evitar ataques de alcance longo. Esses ataques envolvem reescrever o histórico do blockchain para manipular registros de transações ou controlar a cadeia. Os ataques de alcance Longo são particularmente graves em sistemas PoS porque, ao contrário de PoW, PoS sistemas não exigem validadores para consumir recursos computacionais significativos. Um invasor pode reescrever o histórico controlando as chaves dos primeiros interessados. Para garantir a estabilidade e a segurança do consenso da rede blockchain, longo períodos de staking são geralmente necessários. Por exemplo, o Cosmos requer um período de desvinculação de 21 dias. No entanto, com Babylon, PoS eventos históricos da cadeia podem ser incluídos no servidor de carimbo de data/hora BTC, usando BTC como fonte de confiança para substituir o consenso social. Isso pode reduzir o tempo de descolagem para apenas um dia (equivalente a aproximadamente 100 BTC blocos). Além disso, as cadeias de PoS podem ter segurança dupla por meio de staking de token nativo e BTC staking.

• Cross-Chain Interoperabilidade: Através do IBC protocolo, o Babylon pode receber dados de pontos de verificação de várias cadeias de PoS, permitindo cadeia cruzada interoperabilidade. Essa interoperabilidade permite a comunicação perfeita e o compartilhamento de dados entre diferentes blockchains, aumentando a eficiência geral e a funcionalidade do ecossistema blockchain.
• Integrando o ecossistema BTC: A maioria dos projetos dentro do ecossistema BTC atual, incluindo Camada 2, LRT e DeFi, carece de segurança suficiente e muitas vezes depende de suposições de confiança de terceiros. Esses protocolos também armazenam grandes quantidades de BTC em seus endereços. No futuro, a Babylon pode desenvolver algumas soluções altamente compatíveis com esses projetos, criando benefícios mútuos e, eventualmente, formando um ecossistema robusto semelhante ao Eigenlayer dentro Ethereum.
• Cross-Chain Asset Management: O Babylon protocolo pode ser usado para gerenciamento seguro de ativos cadeia cruzada. Ao adicionar carimbos de data/hora a transações cadeia cruzada, garante a segurança e a transparência das transferências de ativos entre diferentes blockchains. Esse mecanismo ajuda a evitar gastos duplos e outros ataques cadeia cruzada.

A Torre de Babel

A história da Torre de Babel vem da Bíblia, Gênesis 11:1-9, e é um conto clássico da tentativa da humanidade de construir uma torre para alcançar os céus, apenas para ser frustrada por Deus. Esta história simboliza a unidade humana e objetivos compartilhados. O Babylon protocolo visa construir uma torre semelhante para várias cadeias de PoS, unindo-as sob o mesmo teto. Em termos narrativos, não parece menos impressionante do que Eigenlayer, o defensor de Ethereum. Mas como isso se sustenta na prática?

A partir de agora, a testnet Babylon forneceu garantias de segurança para 50 zonas do Cosmos através do IBC protocolo. Além do ecossistema Cosmos, o Babylon se integrou a alguns protocolos LSD (Liquid Staking Derivados), protocolos de interoperabilidade omnichain e protocolos de ecossistema Bitcoin. No entanto, em termos de staking, a Babilônia atualmente fica atrás da Eigenlayer, que pode reutilizar estacas e LSD dentro do ecossistema Ethereum. No longo prazo, porém, a vasta quantidade de BTC adormecida em carteiras e protocolos ainda não foi totalmente despertada, representando apenas a ponta do iceberg de US$ 1,3 trilhão. A Babilônia precisa formar uma simbiose positiva com todo o ecossistema BTC.

A única solução para o dilema do Staking Ponzi

Como mencionado anteriormente, Eigenlayer e Babylon estão se desenvolvendo rapidamente, e as tendências futuras sugerem que eles bloquearão grandes quantidades de ativos blockchain principais. Mesmo que esses protocolos em si sejam seguros, várias camadas de staking podem criar uma espiral de morte para o ecossistema de stake, causando um crash semelhante a outro aumento da taxa de juros pelos EUA? O atual setor de staking tem experimentado de fato uma exuberância irracional desde a transição de Ethereum para PoS e o surgimento da Eigenlayer. Os projetos geralmente atraem usuários com alto televisão por meio de enormes expectativas de airdrop e retornos em camadas. Um ETH pode passar por staking nativo, LSD e LRT, empilhando até cinco ou seis camadas. Esse empilhamento aumenta o risco, pois um problema em qualquer protocolo pode impactar diretamente todos os protocolos envolvidos, principalmente aqueles no final da cadeia de stake. O ecossistema BTC, com suas inúmeras soluções centralizadas, enfrentaria riscos ainda maiores se adotasse esse modelo.

No entanto, é importante notar que Eigenlayer e Babylon são fundamentalmente sobre guiar o volante de estaca em direção à utilidade genuína, criando demanda real para compensar riscos. Portanto, embora esses protocolos de "segurança compartilhada" possam exacerbar indiretamente ou diretamente as más práticas, eles também representam a única maneira de escapar dos retornos semelhantes aos Ponzi do staking em camadas. A questão mais urgente agora é se a lógica comercial dos protocolos de "segurança compartilhada" é realmente viável.

Real Demand is Key

Na Web3, seja para cadeias públicas ou protocolos, a lógica subjacente geralmente envolve Coincidindo compradores e vendedores para uma demanda específica. Aqueles que fazem isso bem podem "ganhar o mundo", pois a tecnologia blockchain garante que o processo de Coincidindo seja justo, real e confiável. Teoricamente, os protocolos de segurança compartilhados podem complementar os ecossistemas modulares e de staking em expansão. No entanto, a oferta excederá em muito a demanda? Do lado da oferta, existem muitos projetos e cadeias principais capazes de proporcionar segurança modular. Do lado da demanda, as cadeias de PoS estabelecidas podem não precisar ou ser relutantes em alugar essa segurança por uma questão de rosto, enquanto as novas cadeias de PoS podem ter dificuldades para pagar os juros gerados por grandes quantidades de BTC e ETH. Para que Eigenlayer e Babylon formem um ciclo comercial fechado, a receita gerada deve equilibrar os juros gerados pelos tokens apostados dentro do protocolo. Mesmo que esse equilíbrio seja alcançado e a receita supere em muito a despesa com juros, isso ainda pode resultar no esvaziamento dessas novas cadeias de PoS e protocolos. Portanto, como equilibrar o modelo econômico, evitar bolhas alimentadas por expectativas de queda de ar e impulsionar de forma saudável tanto a oferta quanto a demanda será crucial.

Sobre o YBB

O YBB é um fundo web3 que se dedica a identificar projetos que definem a Web3 com a visão de criar um habitat online melhor para todos os residentes da internet. Fundada por um grupo de crentes em blockchain que têm participado ativamente nesta indústria desde 2013, a YBB está sempre disposta a ajudar projetos em estágio inicial a evoluir de 0 para 1.Valorizamos a inovação, a paixão autodirigida e os produtos orientados para o usuário, reconhecendo o potencial das criptos e das aplicações blockchain.

Sítio Web | Twi: @YBBCapital

Referências

1. Explicação detalhada de como Babylon beneficia o ecossistema do Cosmos com a segurança de Bitcoin: ChainCatcher Artigo
2. Compreensão profunda do Eigenlayer: Quebrando Ethereum da situação de "empilhamento"? Artigo HaoTianCryptoInsight
3. Conversa com o cofundador da Babylon, Fisher Yu: Como desbloquear a liquidez de 21 milhões de BTC através do staking? Artigo do ChainCatcher
4. Dívida triangular ou inflação moderada: Uma perspectiva alternativa sobre re-staking: Weixin Artigo
5. Uma olhada no que tenho visto em criptografia ultimamente: TheKnower Substack

Isenção de responsabilidade:

1. Este artigo foi reproduzido de [Medium]. Todos os direitos autorais pertencem ao autor original [YBB]. Se houver objeções a essa reimpressão, entre em contato com a equipe Gate Learn e eles lidarão com isso prontamente.

2. Isenção de responsabilidade: Os pontos de vista e opiniões expressos neste artigo são exclusivamente do autor e não constituem qualquer conselho de investimento.

3. As traduções do artigo para outros idiomas são feitas pela equipe do Gate Learn. A menos que mencionado, copiar, distribuir ou plagiar os artigos traduzidos é proibido.