Prefácio

Na era da blockchain modular liderada pela Ethereum, fornecer serviços de segurança através da integração da camada de Disponibilidade de Dados (DA) não é mais longo um conceito novo. Atualmente, o conceito de segurança partilhada introduzido pelo staking oferece uma nova dimensão ao espaço modular. Ele aproveita o potencial do "ouro e prata digital" para fornecer segurança de Bitcoin ou Ethereum a inúmeros protocolos de blockchain e cadeias públicas. Essa narrativa é bastante grandiosa, pois não só 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 angariações maciças de 70 milhões de dólares pela Bitcoin aposta protocolo Babylon e de 100 milhões de dólares pela Ethereum protocolo EigenLayer ilustram o forte apoio das empresas de capital de risco principal para este sector.

No entanto, estes desenvolvimentos também suscitaram preocupações significativas. Se a modularidade for a solução definitiva para dimensionamento, e esses protocolos forem componentes cruciais dessa solução, é provável que bloqueiem grandes quantidades de BTC e ETH. Isto põe em causa a segurança dos próprios protocolos. Será que as camadas complexas formadas por inúmeros protocolos LSD (Liquid Estaca Derivados) e LRT (Camada 2 Rollup Tokens) se tornarão o maior cisne negro no futuro do blockchain? A 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 hoje. 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. Estas são qualidades raras que outras cadeias heterogéneas têm dificuldade em replicar. A ideia central da modularidade é "alugar" essas qualidades a quem precisa. Na atual abordagem de modularidade, existem duas fações principais:

A primeira façã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 rendimento e custo para Rollups específicos (cadeias de aplicativos, cadeias de cauda longo, etc.).

A segunda fação visa criar uma existência próxima da segurança de Bitcoin e Ethereum mas com melhor desempenho de custo, como a Celestia. Celestia consegue isso usando uma arquitetura de função DA pura, minimizando os requisitos de hardware do nó e baixos custos de gás. Esta abordagem simplificada procura 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 desta abordagem é que a sua segurança e descentralização ainda precisam de algum tempo para serem plenamente desenvolvidas, e carece de legitimidade enquanto está em concorrência direta com Ethereum, principal à rejeição pela comunidade Ethereum.

Um terceiro tipo nesta fação inclui Babylon e EigenLayer. Eles utilizam o conceito central de Proof-of-Stake (POS), aproveitando o valor patrimonial 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 maciços, enquanto PoS depende do valor dos ativos envolvidos. Bitcoin 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, representando metade do mercado do blockchain, sua utilidade de ativos é limitada principalmente 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, as novas cadeias heterogéneas não conseguem, muitas vezes, atrair capitais substanciais, pondo em causa a 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 muitas vezes tem o custo da autonomia. Para a maioria dos mecanismos de PoS antigos ou cadeias de consórcio, usar Ethereum ou Celestia como uma camada de 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 é adequado para desempenhar esse papel no mundo blockchain.

De 0 a 1

Liberar o "ouro digital" sempre foi a narrativa mais ambiciosa e difícil de alcançar no espaço blockchain. Desde os primeiros cadeias 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 pretende aproveitar a segurança de Bitcoin, soluções centralizadas que introduzam 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 ativos. Isso significa que a Babilônia precisa projetar seu próprio "solução de escalonamento" para permitir que a Bitcoin nativa estaque de 0 a 1.

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

Remote Estaca

UTXO (Unspent Transaction Outputs) é o modelo de transação projetado pela 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 resultados de transações não gastos (ou seja, Bitcoin não pagos). 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. Cada 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 escalonamento 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.

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

Bloqueio de Fundos

Os usuários enviam fundos para um endereço controlado por multisig. Através 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 certas 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 corte (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 stake ou retiram fundos apostados, isso envolve a criação e o gasto de UTXOs. Novas saídas de transação geram novas UTXOs, e UTXOs antigas são marcadas como gastas. 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 através 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 de Bitcoin, esses eventos referem-se 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 marcar a data e hora de eventos em blockchains externas. Cada vez que tal evento ocorre, ele dispara uma transação enviada aos mineradores, que a inserem no Bitcoin livro-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 registam 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 neste 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 mediano 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 por Babylon, que pode alocar Bitcoin carimbos de data/hora através de pontos de verificação Babylon em blocos PoS, garantindo a precisão e imutabilidade da sequência de tempo. Este servidor atua como a camada superior em toda a arquitetura do Babylon, servindo como a principal fonte de confiança.

Arquitetura de três camadas da Babilônia

Como ilustrado no diagrama, a arquitetura geral da Babilônia pode ser dividida em três camadas: Bitcoin (servindo como o servidor de carimbo de data/hora), Babilônia (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 e sem confiança do protocolo, vamos mergulhar 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 on Babylon de Stanford, 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 PoS cadeias detetem discrepâncias, como se 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 hash do bloco e uma única assinatura BLS agregada, correspondendo às assinaturas da maioria de dois terços dos validadores que assinaram o bloco para finalização. Os postos de controle da Babilônia também incluem o número da época. PoS blocos podem atribuir Bitcoin carimbos de data/hora através dos pontos de verificação do Babylon. Por exemplo, os dois primeiros blocos de PoS são verificados por blocos Babylon, que são então verificados por um bloco Bitcoin com t_3 de carimbo de data/hora. Consequentemente, esses blocos de PoS recebem o Bitcoin t_3 de carimbo de data/hora.

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

· Regras de levantamento: Para levantar, validadores enviar um pedido de levantamento para a cadeia de PoS. O bloco de PoS contendo o pedido de retirada é então verificado pelo Babylon e, posteriormente, pelo Bitcoin, atribuindo-lhe o carimbo de data/hora t_1. Uma vez que o bloco de Bitcoin com t_1 de carimbo de data/hora atinge uma profundidade de k, a retirada é concedida na cadeia de PoS. Se um validador com stakes retiradas tentar um ataque de longo alcance, os blocos na cadeia de ataque só poderão receber um carimbo de data/hora depois de t_1. Isso ocorre porque uma vez que o bloco de Bitcoin com t_1 de carimbo de data/hora 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 ignorar esta última.

· Regras de corte: Se validadores não retirarem suas apostas ao detetar um ataque, elas podem ser cortadas por terem blocos de PoS conflitantes assinados duplamente. Os PoS validadores mal-intencionados sabem que, se esperarem até que seu pedido de retirada seja aprovado 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 forquilha a cadeia de PoS enquanto atribuem Bitcoin carimbos de data/hora a blocos na cadeia de PoS canônica. Esses PoS validadores, em colaboração com validadores e Bitcoin mineiros mal-intencionados da Babilônia, forquilha Babylon e Bitcoin para substituir o bloco Bitcoin com carimbo de data/hora t_2 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, resulta na corte das apostas dos PoS validadores mal-intencionados porque eles têm blocos conflitantes assinados duas vezes sem retirar suas participações.

· Indisponibilidade de PoS Checkpoint Regras de Pausa: PoS validadores devem pausar sua cadeia de PoS ao observar um ponto de verificação de PoS indisponível na Babilônia. Um ponto de verificação de PoS indisponível é definido como o hash assinado por dois terços dos 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 indisponível anteriormente, 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 de PoS enviados como pontos de verificação sejam assinados pelo conjunto de validadores de PoS. Se esses pontos de verificação não estivessem assinados, qualquer invasor poderia enviar uma hash arbitrária, alegando ser a hash de um ponto de verificação de bloqueio de PoS indisponível na Babilônia. PoS validadores teria então 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 dos PoS validadores para assinar o bloco de PoS sem fornecer dados a validadores honestos. No entanto, no ataque assumido acima, o adversário malicioso pausa a cadeia de PoS sem comprometer um único validador. Para evitar tais ataques, exigimos que PoS postos 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 da PoS validadores sejam comprometidos, o que é altamente improvável devido ao custo de comprometer PoS validadores e não afeta outras cadeias de PoS ou a própria Babilônia.

· Indisponibilidade das Regras de Pausa do Babylon Checkpoint: Tanto o PoS quanto o Babylon validadores devem pausar o blockchain ao observar um ponto de verificação do Babylon indisponível no Bitcoin. Um ponto de verificação da Babilônia indisponível é definido como um hash 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 Babylon validadores não pausar o blockchain Babylon, um invasor pode revelar uma cadeia Babylon anteriormente indisponível, alterando a cadeia canônica Babylon em visualizações de clientes posteriores. Da mesma forma, se PoS validadores não pausar a cadeia de PoS, o invasor pode revelar uma cadeia de ataque de PoS anteriormente indisponível e a cadeia Babylon anteriormente indisponível, alterando a cadeia de PoS canônica em visualizações posteriores do cliente. Isso ocorre porque a cadeia profunda da Babilônia revelada mais tarde tem um carimbo de data/hora anterior no Bitcoin e inclui pontos de controle da cadeia de ataque PoS revelada mais tarde. 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 comprovando as assinaturas de dois terços do Babylon validadores. Se os postos de controle da Babilônia não estivessem assinados, qualquer adversário poderia enviar uma hash arbitrária, alegando ser a hash de um ponto de controle de bloco da Babilônia indisponível na Bitcoin. PoS validadores e Babylon validadores teriam então que esperar por um posto de controle que não tem Babilônia indisponível ou PoS cadeias em sua pré-imagem. Criar uma cadeia Babilônia indisponível requer comprometer pelo menos dois terços da validadores Babilônia. No entanto, no ataque assumido acima, o adversário pausa todas as cadeias do sistema sem comprometer um único Babilônia ou PoS validador. Para evitar tais ataques, exigimos que os postos de controle da Babilônia sejam comprovados por assinaturas agregadas; assim, não haverá postos de controle indisponíveis na Babilônia, a menos que dois terços da validadores estejam comprometidos, o que é altamente improvável devido ao custo de comprometer a Babilônia validadores. Mas, em casos extremos, afetará todas as PoS cadeias, forçando-as a fazer uma pausa.

Eigenlayer em BTC

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

Casos de uso

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

1. Reduzir os períodos de Estaca e melhorar a segurança: PoS cadeias normalmente exigem consenso social (consenso entre a comunidade, operadores de nós e validadores) para evitar ataques de longo alcance. Esses ataques envolvem reescrever o histórico do blockchain para manipular registros de transações ou controlar a cadeia. Os ataques de Longo alcance são particularmente graves em sistemas PoS porque, ao contrário PoW, os sistemas PoS 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, Cosmos requer um período de desvinculação de 21 dias. No entanto, com Babilônia, PoS eventos históricos em cadeia podem ser incluídos no servidor de carimbo de data/hora BTC, usando BTC como uma 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 staking BTC

• Interoperabilidade de cadeia cruzada: Através do protocolo IBC, 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 contínua e o compartilhamento de dados entre diferentes blockchains, melhorando a eficiência geral e a funcionalidade do ecossistema blockchain.
• Integração do 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 pressupostos de confiança de terceiros. Esses protocolos também armazenam grandes quantidades de BTC em seus endereços. No futuro, 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 o gerenciamento seguro de cadeia cruzada ativos. Ao adicionar carimbos de data/hora às cadeia cruzada transações, garante a segurança e a transparência das transferências de ativos entre diferentes blockchains. Este 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 os objetivos partilhados. 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 da Ethereum. Mas como se sustenta na prática?

A partir de agora, o testnet Babylon forneceu garantias de segurança para 50 zonas Cosmos através do IBC protocolo. Além do ecossistema Cosmos, Babylon integrou-se com alguns protocolos LSD (Liquid Estaca Derivados), protocolos de interoperabilidade omnichain e protocolos de ecossistema Bitcoin. No entanto, em termos de staking, a Babilônia atualmente está atrasada em relação ao Eigenlayer, que pode reutilizar estaca e LSD dentro do ecossistema Ethereum. No longo prazo, porém, a grande 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. Babilônia precisa formar uma simbiose positiva com todo o ecossistema BTC.

A única solução para o dilema Ponzi Estaca

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 de blockchain principais. Mesmo que esses protocolos em si sejam seguros, várias camadas de staking poderiam 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 apostas tem experimentado uma exuberância irracional desde a transição de Ethereum para a PoS e o surgimento da Eigenlayer. Os projetos geralmente atraem usuários com alto TVL através de enormes expectativas de airdrop e retornos em camadas. Um ETH pode passar por staking, LSD e LRT nativos, empilhando até cinco ou seis camadas. Esse empilhamento aumenta o risco, pois um problema em qualquer protocolo pode impactar diretamente todos os protocolos envolvidos, especialmente 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 orientar o volante de estaca em direção à utilidade genuína, criando demanda real para compensar os 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 ao Ponzi do staking em camadas. A questão mais premente agora é se a lógica comercial dos protocolos de "segurança compartilhada" é realmente viável.

A demanda real é a chave

Na Web3, seja para cadeias públicas ou protocolos, a lógica subjacente geralmente envolve compradores e vendedores correspondência para uma demanda específica. Aqueles que fazem isso bem podem "ganhar o mundo", já que a tecnologia blockchain garante que o processo de correspondência 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, será que a oferta excederá em muito a procura? Do lado da oferta, existem muitos projetos e cadeias principais capazes de fornecer segurança modular. Do lado da procura, as cadeias de PoS estabelecidas podem não precisar ou estar relutantes em alugar essa garantia por uma questão de face, enquanto as novas cadeias de PoS podem ter dificuldade em pagar os juros gerados por grandes quantidades de BTC e ETH. Para que Eigenlayer e Babylon formem um circuito comercial fechado, a receita gerada deve equilibrar o interesse gerado pelos tokens apostados dentro do protocolo. Mesmo que esse equilíbrio seja alcançado e a receita exceda em muito as despesas com juros, ainda assim poderá resultar no esgotamento dessas novas cadeias de PoS e protocolos. Portanto, como equilibrar o modelo econômico, evitar bolhas alimentadas por expectativas de airdrop 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 melhor habitat online 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 autoguiada e produtos orientados ao usuário, reconhecendo o potencial das criptos e aplicações blockchain.

Website | Twi: @YBBCapital

Referências

1. Explicação detalhada de como Babylon beneficia o ecossistema Cosmos com a segurança de Bitcoin: ChainCatcher Artigo
2. Compreensão aprofundada 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 ChainCatcher
4. Dívida triangular ou inflação moderada: Uma perspetiva alternativa sobre re-staking: Weixin Artigo
5. Um olhar para o que eu tenho visto em cripto ultimamente: TheKnower Substack

Declaração de exoneração de responsabilidade:

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

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.