Desvendando Babilônia: Como liberar o valor de segurança do Bitcoin?

Autor: Pesquisador da YBB Capital Zeke

Introdução

No era uma novidade fornecer serviços de segurança através da conexão com a camada de disponibilidade de dados (DA) na era da modularização liderada pelo Ethereum. No entanto, o conceito de compartilhamento de segurança trazido pelo Staking traz uma nova dimensão para a pista de modularização, ou seja, o uso do potencial do “ouro digital e prata” para fornecer segurança a vários protocolos e blockchains do Bitcoin ou Ethereum. Em termos narrativos, é bastante grandioso. Não só libera a liquidez de trilhões de dólares de valor de mercado, mas também é a chave para o caminho futuro de escalabilidade. Tomemos como exemplo os recentes protocolos de stake do Bitcoin, Babylon, e de re-staking do Ethereum, EigenLayer, que arrecadaram respectivamente US$ 70 milhões e US$ 100 milhões em financiamento. Não é difícil ver que os principais VC estão muito confiantes nesta pista.

Mas as dúvidas que se seguem também são bastante longo, se a modularização é o fim da expansão, e os dois como membros-chave dela inevitavelmente bloquearão a BTC e a ETH do céu, então vale a pena examinar a segurança da própria protocolo? Será que o louco “matryoshka” formado com o longo LSD e LRT protocolo se tornará o maior cisne negro no futuro Blockchain? A lógica de negócio é razoável? Uma vez que já analisamos o EigenLayer em artigos anteriores, a discussão a seguir se concentrará na questão do apelo através da Babilônia.

Estender o consenso de segurança

O desenvolvimento mais valioso no mundo da blockchain até hoje certamente será o Bitcoin e o Ethereum, com sua segurança, descentralização e consenso de valor acumulados ao longo dos anos, todos esses são os núcleos chave que garantem que ambos permaneçam no topo das blockchains públicas ano após ano. Eles também possuem características escassas que são mais difíceis de replicar nas outras blockchains heterogêneas, e a essência do pensamento modular é ‘alugar’ essas características para os demandantes. No estágio atual do pensamento modular, existem principalmente duas facções:

• A primeira opção é ter uma camada 1 suficientemente segura (geralmente o Ethereum) como a camada inferior ou camada funcional parcial para Rollups. Esse cenário oferece a maior segurança, autenticidade e também pode aproveitar os recursos do ecossistema da cadeia principal. No entanto, em termos de throughput e custo, não é particularmente amigável para Rollups específicos (como cadeias de aplicativos, cadeias de cauda longa, etc.).
• A segunda opção é criar uma entidade com segurança semelhante ao Bitcoin e Ethereum, mas com melhor desempenho e custo. Por exemplo, o Celestia, que é conhecido por sua arquitetura de funcionalidade pura da DA, reduz ao máximo os requisitos de hardware dos nós e os custos de gás. Esta abordagem simplifica o processo com o objetivo de criar uma camada DA com segurança e descentralização comparáveis ao Ethereum e com alto desempenho em tempo mínimo. A desvantagem desse plano é que a segurança e a descentralização ainda precisam ser aprimoradas com o tempo, e ele não é reconhecido como uma solução oficial, além de ser considerado uma competição direta com o Ethereum, sendo excluído pela comunidade Ethereum.

E outra categoria dentro desta facção é Babylon e Eigenlayer, que utilizam a ideia central da PoS (Prova de Staking) para criar serviços de segurança compartilhada usando o valor dos ativos do Bitcoin ou Ethereum. Comparado com os dois anteriores, ele é uma existência mais neutra. Sua vantagem está em herdar a legitimidade e segurança, ao mesmo tempo em que confere mais valor de uso aos ativos da cadeia principal e é mais flexível.

O Potencial do Ouro Digital

Independentemente da lógica subjacente de qualquer mecanismo de consenso, a segurança da blockchain depende em grande medida do suporte de recursos. A cadeia PoW requer grande quantidade de hardware e energia, enquanto a PoS depende do valor dos ativos em stake. O próprio Bitcoin é suportado por uma rede de poder de computação PoW extremamente poderosa, o que o torna a entidade mais segura em toda a blockchain. No entanto, como uma cadeia pública com uma capitalização de mercado circulante de US $1,39 trilhão e que ocupa metade da indústria blockchain, seus ativos têm apenas duas aplicações principais: transferência e pagamento de taxas de gás.

Para a outra metade do mundo da blockchain, especialmente depois da atualização do Ethereum para PoS, a maioria das blockchains públicas usa PoS com diferentes arquiteturas como padrão para atingir o consenso. No entanto, a segurança das novas blockchains heterogêneas é questionável, pois elas não conseguem atrair grandes apostas de capital. Na era atual de modularidade, embora a Cosmos zone e várias camadas 2 possam ser usadas para compensar com várias camadas de aplicativos descentralizados, elas também perdem autonomia. Para a maioria das antigas blockchains POS ou blockchains de consórcio, é praticamente impossível usar o Ethereum ou Celestia como aplicativos descentralizados, mas o valor do Babylon é justamente preencher essa lacuna e usar BTC como garantia para as blockchains PoS. Assim como o ouro foi usado no passado para apoiar o valor do papel-moeda, o BTC é realmente adequado para desempenhar esse papel no mundo das blockchains.

De 0 a 1

Libertar o “ouro digital” tem sido uma narrativa ambiciosa e difícil de alcançar no mundo das criptomoedas, desde os primeiros dias das cadeias laterais, da Rede de Iluminação e das tokens embalados até as soluções atuais como o Rune e o BTC Layer2. Pode-se dizer que todos esses esquemas têm suas próprias limitações. Se Babylon quiser garantir a segurança do Bitcoin, a primeira coisa a ser eliminada é qualquer solução centralizada que introduza a suposição de confiança de terceiros. Das soluções restantes, Rune e Rede de Iluminação (que têm um desenvolvimento extremamente lento) atualmente têm apenas a capacidade de emitir ativos, o que significa que Babylon precisa projetar seu próprio “esquema de escala” para permitir a estaca nativa do Bitcoin de 0 a 1.

Desmontar alguns dos elementos básicos atualmente disponíveis do Bitcoin revela que eles são basicamente os seguintes: 1. Modelo UTXO, 2. carimbo de data/hora, 3. vários métodos de assinatura, 4. códigos de operação básicos. A solução proposta pelo Babylon considera a fraca capacidade de programação e suporte de dados do Bitcoin. Seguindo o princípio da minimização, apenas as funções necessárias para contratos de stake no Bitcoin são realizadas na cadeia principal, ou seja, o stake, corte, recompensa, recuperação, etc., tudo é feito na cadeia principal. Após implementar esse conceito do zero, as partes com requisitos mais complexos serão tratadas pelas zonas do Cosmos. No entanto, há ainda um problema fundamental aqui, como registrar os dados da cadeia PoS na cadeia principal?

Stake Remoto

UTXO (Saída de transação não gasta Model) é um modelo de transação projetado pela Satoshi Nakamoto para Bitcoin, e sua ideia central é extremamente simples. A negociação nada mais é do que a entrada e saída de fundos, então todo o sistema de negociação só precisa ser expresso na forma de entrada e saída. O chamado UTXO é quando os fundos entram, mas os fundos gastos não são tão longo, e a parte restante é o Saída de transação não gasta (ou seja, o Bitcoin que não foi pago). E todo o livro razão de Bitcoin é na verdade uma coleção de UTXOs, registrando o estado de cada UTXO, gerenciando a propriedade e circulação de Bitcoin, cada transação gasta o UTXO antigo e gera um novo. Devido aos seus atributos, ele tem uma certa possibilidade de escalabilidade potencial, e naturalmente se tornou o ponto de partida do esquema de expansão nativo de Xu longo. Por exemplo, usando UTXOs e assinaturas longo para criar uma Rede de iluminação do mecanismo de penalidade e canal estatal, ou vinculando UTXOs para implementar o Token Fungível inscrição e runas de SFT (tokens semifungíveis). É com base neste ponto de partida crítico que pode tornar-se uma realidade.

E Babylon também precisa usar UTXO para implementar contratos de stake (chamados de stake remoto pelo Babylon, ou seja, a segurança do BTC é transmitida para a cadeia PoS por uma camada intermediária). Ao mesmo tempo, combina de forma inteligente os códigos de operação existentes na abordagem, e os passos específicos para implementar o contrato podem ser divididos em quatro etapas:

• Fundos bloqueados

O utilizador envia fundos para um endereço controlado por multi-assinatura. Através do OP_CTV (OP_CHECKTEMPLATEVERIFY, permite a criação de modelos de transação predefinidos, garantindo que a transação só possa ser executada de acordo com uma estrutura e condições específicas), o contrato pode especificar que os fundos só podem ser gastos quando certas condições são cumpridas. Após os fundos serem bloqueados, é gerado um novo UTXO, representando que estes fundos foram staked;

• Verificação de Condições

Chamar OP_CSV (OP_CHECKSEQUENCEVERIFY permite que você defina um bloqueio de tempo relativo, com base no número de série da transação, o que significa que UTXO só pode ser gasto após um determinado tempo relativo ou Bloco) para garantir que os fundos não possam ser retirados dentro de um determinado período de tempo. Combinado com o OP_CTV mencionado acima, é possível alcançar stake, stake (se o tempo stake for satisfeito, o stake pode gastar o UTXO bloqueado), corte (Cortar, quando o stake é mau, o UTXO será gasto à força para o Endereço bloqueado e limitado ao estado de não gasto, semelhante ao Queimar Endereço);

• Atualização de status

Sempre que um usuário faz uma aposta ou retira fundos da aposta, a criação e gasto de UTXOs estão envolvidos. Novas saídas de transação geram novos UTXOs, enquanto os antigos UTXOs são marcados como gastos. Dessa forma, cada transação e fluxo de fundos são registrados com precisão na cadeia de blocos, garantindo transparência e segurança;

• Distribuição de renda

Com base no valor e no tempo de staking, o contrato calculará as recompensas a serem recebidas e as distribuirá gerando novos UTXOs. Essas recompensas podem ser desbloqueadas e gastas após o cumprimento de condições específicas do script.

data/hora

Com a introdução do contrato de participação nativo, naturalmente surge a questão do registro de eventos históricos de cadeias externas. No White Paper de Satoshi Nakamoto, a blockchain do Bitcoin introduziu o conceito de carimbo de data/hora suportado por PoW, que fornece uma ordem de tempo irreversível para os eventos. Nos casos de uso nativos do Bitcoin, esses eventos referem-se a várias transações executadas no livro-razão. Hoje em dia, para reforçar a segurança de outras blockchains PoS, o Bitcoin também pode ser usado para marcar eventos em cadeias externas com carimbos de data/hora. Cada vez que um evento desse tipo ocorre, uma transação é acionada e enviada aos mineiros, que a inserem no livro-razão do Bitcoin, adicionando um carimbo de data/hora ao evento. Esses carimbos de data/hora podem ser usados para resolver várias questões de segurança das blockchains. O conceito geral de adicionar carimbos de data/hora a eventos em uma sidechain na mainchain é chamado de “checkpointing”, enquanto as transações usadas para adicionar carimbos de data/hora são chamadas de “checkpoint transactions”. Mais especificamente, os carimbos de data/hora na blockchain do Bitcoin têm as seguintes características importantes:

1. Formato de tempo: O registro de carimbo de data/hora é o número de segundos decorridos desde 00:00:00 UTC em 1 de janeiro de 1970. Esse formato é conhecido como carimbo de data/hora Unix ou POSIX.
2. Função: A principal função do carimbo de data/hora é identificar o tempo de geração do bloco, ajudando os nós a determinar a ordem dos blocos, bem como auxiliar no mecanismo de ajuste da dificuldade da rede;
3. data/hora e Dificuldade de redireccionamento: A rede Bitcoin ajusta a dificuldade a cada 2016 blocos (aproximadamente a cada duas semanas). O data/hora desempenha um papel fundamental nesse processo, pois a rede ajusta a dificuldade de mineração com base no tempo total de geração dos últimos 2016 blocos, para que a velocidade de geração dos novos blocos seja próxima de um bloco a cada 10 minutos.
4. 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 a mediana do tempo de vários blocos anteriores e não pode exceder 120 minutos do tempo de rede (ou seja, 2 horas no futuro).

O servidor de carimbos de tempo é uma nova primitiva definida pelo Babylon, que permite que os carimbos de tempo do Bitcoin sejam alocados através de checkpoints do Babylon em blocos PoS, garantindo a precisão da sequência temporal e prevenindo adulterações. Este servidor é a fonte principal de confiança em toda a arquitetura do Babylon.

A arquitetura de três camadas do Babylon

Como mostrado na figura acima, a arquitetura geral do Babylon pode ser dividida em três camadas: Bitcoin (como servidor de carimbo de data/hora), Babylon (uma zona Cosmos) como camada intermediária e camada de demanda da cadeia PoS. Babylon chama os dois últimos de Control Plane (plano de controle, ou seja, o próprio Babylon) e Data Plane (plano de demanda de dados, ou seja, várias cadeias de consumo PoS).

Após compreender a implementação básica do protocolo sem confiança, vamos ver como o próprio Babylon utiliza a zona Cosmos para conectar as duas extremidades. De acordo com a explicação detalhada do Babylon pelo Tse Lab de Stanford, Babylon pode receber fluxos de checkpoints de várias cadeias PoS e publicá-los no Bitcoin após mesclá-los. Ao usar a assinatura agregada de validadores de Babylon, é possível minimizar o tamanho dos checkpoints e controlar a frequência desses checkpoints permitindo que os validadores de Babylon mudem apenas uma vez a cada Epoch.

Os validadores de cada cadeia PoS baixam o bloco Babilônia e observam se o seu ponto de verificação PoS está incluído no bloco Babilônia verificado pelo Bitcoin. Isso permite que a cadeia PoS detecte discrepâncias, por exemplo, se os validadores de Babilônia criarem um bloco inválido verificado pelo Bitcoin e mentirem sobre o ponto de verificação PoS contido no bloco inválido. Os principais componentes que constituem o protocolo são os seguintes:

• Pontos de Verificação: Apenas o último bloco da época de Babilônia é verificado pelo Bitcoin. O ponto de verificação consiste no hash do bloco e em uma assinatura BLS agregada única, que corresponde à assinatura do conjunto final de validadores 2/3 que assinaram o bloco para a determinação final. O ponto de verificação de Babilônia também inclui o número da época. Os blocos PoS podem receber o carimbo de data/hora do bloco Bitcoin através do ponto de verificação de Babilônia. Por exemplo, os dois primeiros blocos PoS são verificados pelo bloco de Babilônia, que por sua vez é verificado pelo bloco Bitcoin com carimbo de data/hora t_3. Portanto, esses blocos PoS recebem o carimbo de data/hora do Bitcoin t_3.

• Norma da cadeia PoS: Quando ocorre uma bifurcação na cadeia PoS, a cadeia com o carimbo de data/hora mais antigo é considerada a norma da cadeia PoS. Se duas bifurcações tiverem o mesmo carimbo de data/hora, o empate é quebrado a favor do bloco PoS com o checkpoint mais antigo em Babylon.

• Regras de saque: Para fazer um saque, os validadores enviam uma solicitação de saque à cadeia PoS. O bloco PoS que contém a solicitação de saque é verificado pela Babylon e, em seguida, pelo Bitcoin, e recebe um carimbo de data/hora t_1. Assim que o bloco Bitcoin com carimbo de data/hora t_1 atingir uma profundidade k, o saque é concedido na cadeia PoS. Nesse momento, se um validador que já retirou a participação em stake realizar um ataque de longo alcance, os blocos da cadeia de ataque só poderão receber um carimbo de data/hora do Bitcoin posterior a t_1. Isso ocorre porque, uma vez que o bloco Bitcoin com carimbo de data/hora t_1 atingir uma profundidade k, ele não pode ser revertido. Em seguida, observando a ordem desses pontos de verificação no Bitcoin, o cliente PoS pode distinguir a cadeia canônica da cadeia de ataque e, em seguida, ignorar a cadeia de ataque.

• Regras de confisco: Se um validador não retira sua participação ao detectar um ataque, pode haver confisco de validadores que possuem blocos de PoS com conflitos de assinatura dupla. Os validadores maliciosos de PoS sabem que, se esperarem até que a solicitação de saque seja aprovada antes de realizar um ataque de segurança de longo alcance, eles não serão capazes de enganar o cliente, que pode verificar o Bitcoin para identificar a cadeia canônica. Portanto, eles podem bifurcar a cadeia de PoS ao atribuir os carimbos de data e hora do Bitcoin aos blocos na cadeia canônica de PoS. Esses validadores de PoS colaboram com os maliciosos validadores de Babylon e os mineradores de Bitcoin para bifurcar o Babylon e o Bitcoin, substituindo o bloco de Bitcoin com o carimbo de data e hora t_2 por outro bloco com o carimbo de data e hora t_3. Para os clientes de PoS subsequentes, isso mudará a cadeia canônica de PoS de cima para baixo. Embora seja um ataque de segurança bem-sucedido, ele resultará no confisco dos juros dos validadores maliciosos de PoS, pois eles têm blocos com conflitos de assinatura dupla, mas ainda não resgataram sua participação.

• Regra de parada de ponto de verificação PoS indisponível: os validadores PoS devem suspender sua cadeia PoS quando observarem um ponto de verificação PoS indisponível em Babylon. Aqui, um ponto de verificação PoS indisponível é um hash assinado por 2/3 dos validadores PoS, pressupondo corresponder a um bloco PoS indisponível. Se os validadores PoS não suspenderem a cadeia PoS ao observar o ponto de verificação indisponível, um atacante poderá revelar uma cadeia de ataque anteriormente indisponível e alterar a cadeia de especificação em visualizações de clientes posteriores. Isso ocorre porque os pontos de verificação da cadeia de sombra exibidos posteriormente aparecem no início de Babylon. A regra de suspensão acima revela por que exigimos que o hash do bloco PoS enviado como ponto de verificação seja assinado pelo conjunto de validadores PoS. Se esses pontos de verificação não forem assinados, qualquer atacante pode enviar qualquer hash e afirmar que é o hash do ponto de verificação do bloco PoS indisponível em Babylon. Em seguida, os validadores PoS terão que suspender o ponto de verificação. Note que a criação de cadeias PoS indisponíveis é difícil: requer a quebra de pelo menos 2/3 dos validadores PoS para que eles completem os blocos PoS com assinatura, mas não forneçam dados aos validadores honestos. No entanto, no ataque pressuposto acima, o adversário malicioso interrompeu a cadeia PoS sem atacar nenhum validador. Para evitar esse tipo de ataque, exigimos que os pontos de verificação PoS sejam verificados por 2/3 dos validadores PoS. Portanto, apenas se 2/3 dos validadores PoS estiverem realmente sob controle do atacante, Babylon terá pontos de verificação PoS indisponíveis. Devido ao custo de quebrar validadores PoS, esse tipo de ataque é extremamente improvável e não afetará outras cadeias PoS ou o próprio Babylon.
• Regras de pausa do ponto de verificação Babylon não disponível: Os validadores PoS e Babylon devem pausar a blockchain quando observarem o ponto de verificação Babylon não disponível no Bitcoin. Aqui, o ponto de verificação Babylon não disponível é o hash da assinatura BLS agregada dos 2/3 validadores de Babylon, que se presume corresponder a um bloco Babylon não observável. Se os validadores de Babylon não pararem a blockchain de Babylon, um atacante pode revelar uma cadeia de Babylon previamente não disponível, alterando assim a cadeia de Babylon normativa na visão do cliente posteriormente. Da mesma forma, se os validadores PoS não pararem a cadeia PoS, um atacante pode revelar uma cadeia de ataque PoS previamente não disponível e uma cadeia de Babylon previamente não disponível, alterando assim a cadeia PoS normativa na visão do cliente posteriormente. Isso ocorre porque a cadeia de Babylon escura revelada posteriormente tem um carimbo de data/hora mais antigo no Bitcoin e contém o ponto de verificação da cadeia de ataque PoS revelada posteriormente. Assim como as regras de pausa do ponto de verificação PoS não disponível, as regras acima revelam por que exigimos que o hash do bloco de Babylon enviado como ponto de verificação venha com uma assinatura BLS agregada para provar a assinatura dos 2/3 validadores de Babylon. Se o ponto de verificação de Babylon não tiver uma assinatura, qualquer oponente pode enviar qualquer hash e afirmar que é o ponto de verificação do bloco Babylon não disponível no Bitcoin. Em seguida, os validadores PoS e Babylon teriam que esperar por um ponto de verificação sem nenhuma cadeia de Babylon ou PoS indisponível em seu domínio! Criar uma cadeia de Babylon não disponível requer a quebra de pelo menos 2/3 dos validadores de Babylon. No entanto, no ataque hipotético acima, o atacante parou todas as cadeias do sistema sem sequer quebrar um único validador de Babylon ou PoS. Para evitar esse tipo de ataque, exigimos que o ponto de verificação de Babylon seja comprovado por meio de uma assinatura agregada; portanto, só haverá um ponto de verificação de Babylon não disponível se realmente houver 2/3 validadores danificados. Devido ao custo de danificar os validadores de Babylon, esse tipo de ataque de disponibilidade de dados é altamente improvável. No entanto, em circunstâncias extremas, ele pode afetar todas as cadeias PoS ao forçá-las a parar.

Eigenlayer em BTC

Do ponto de vista do objetivo, Babylon, embora semelhante ao Eigenlayer, não é de forma alguma um simples fork do “Eigenlayer”. A existência de Babylon é muito significativa, uma vez que a DA na cadeia principal do BTC não pode ser usada nativamente. Além de trazer segurança para as cadeias externas de PoS, este protocolo também é particularmente importante para revitalizar o ecossistema do BTC internamente.

Caso de uso

Existem muitos casos de uso possíveis em Babylon, aqui estão alguns casos já implementados ou com potencial para implementação no futuro:

1. Reduzir o período de stake e aumentar a segurança: As cadeias PoS geralmente requerem consenso social (consenso entre comunidades, operadores de nós e validadores) para evitar ataques de longo alcance, que é uma forma de ataque em que o histórico do blockchain é reescrito para alterar registros de transações ou controlar a cadeia. Esse tipo de ataque é especialmente grave em sistemas PoS, pois, ao contrário do PoW, os validadores que participam do consenso não precisam de muitos recursos computacionais, permitindo que um atacante controle as chaves de stake iniciais para reescrever o histórico. Portanto, para garantir a estabilidade e segurança do consenso da rede blockchain, um longo período de stake é necessário. Por exemplo, o período de unstake no Cosmos é de 21 dias. No entanto, com o Babylon, eventos históricos da cadeia PoS podem ser adicionados ao servidor de carimbos de tempo do BTC, substituindo o consenso social por uma fonte confiável no BTC. Isso permite que o período de unstake seja reduzido para apenas 1 dia (aproximadamente 100 blocos do BTC). Além disso, a cadeia PoS pode ter a garantia de stake nativo e stake em BTC nesse momento.

2. Interação entre cadeias: Através do protocolo IBC, Babylon pode coletar dados de pontos de verificação de vários links PoS, alcançando a interação entre cadeias. Essa interoperabilidade permite comunicação e compartilhamento de dados perfeitos entre diferentes blockchains, melhorando a eficiência e funcionalidade do ecossistema blockchain como um todo;

3. Integração do ecossistema BTC: A maioria dos projetos no atual ecossistema BTC ainda não possui segurança suficiente, seja em relação à Layer2, LRT ou DeFi, a maioria ainda depende de suposições de confiança de terceiros. E esses protocolos contêm uma grande quantidade de BTC em seus endereços, talvez no futuro possam colidir com o Babylon e criar soluções complementares, nutrindo-se mutuamente e, no final, formando um ecossistema poderoso como o Eigenlayer no Ethereum.

4. Gestão de Ativos Cross-Chain: O protocolo Babylon pode ser usado para gerenciar de forma segura ativos cross-chain. Ao adicionar carimbos de data/hora às transações cross-chain, garante-se a segurança e transparência na transferência de ativos entre diferentes blockchains. Esse mecanismo ajuda a prevenir gastos duplos e outros ataques cross-chain.

Torre de Babel

A história da Torre de Babel vem do capítulo 11: 1-9 do livro de Gênesis, na Bíblia, é uma história clássica sobre a tentativa da humanidade de construir uma torre que alcançasse o céu, mas foi impedida por Deus. Seu significado simboliza a unidade e o objetivo comum da humanidade. É também um potencial significado do Protocolo Babilônia, um projeto que visa construir uma torre de Babel para várias cadeias de PoS e unificá-las. Em termos de narrativa, parece não ser inferior ao Eigenlayer, o defensor do Ethereum, mas qual é a situação real?

Até o momento, a rede de teste Babylon já garantiu a segurança de 50 zonas Cosmos através do protocolo IBC. Além do Cosmos, o Babylon também colaborou com alguns protocolos de Liquidez e stake, protocolos de interoperabilidade de blockchain e ecossistemas de Bitcoin para integração. Por outro lado, em termos de stake, em comparação com Eigenlayer, Babylon ainda está um pouco aquém na reutilização de stake e Liquidez no ecossistema Ethereum. No entanto, a longo prazo, o BTC adormecido em várias carteiras e protocolos ainda não foi totalmente despertado, então isso é apenas a ponta do iceberg de 13 trilhões de dólares. Atualmente, o Babylon ainda precisa formar uma complementaridade ativa com todo o ecossistema BTC.

A única solução para o jogo de bonecas russas da Pond’s

Como mencionado no prefácio, Eigenlayer e Babylon estão crescendo em suas asas e, a partir da tendência atual, eles bloquearão uma enorme quantidade de Blockchain ativos principais no futuro. Mesmo que não haja nenhum problema com a segurança dessas duas protocolo em si, será que a boneca matryoshka longo empurrará toda a ecologia stake para uma espiral de morte e causará uma queda cair nada menos do que o nível de outro aumento da taxa de juros nos Estados Unidos? A atual pista de estacas viveu, de facto, um longo período de prosperidade irracional após os curtos períodos de Ethereum para PoS e Eigenlayer. Em ordem de obter uma maior TVL, a festa do projeto muitas vezes joga fora um grande número de expectativas de airdrop e renda sobreposta de boneca de nidificação para tentar os usuários, e um ETH pode até mesmo nidificar bonecos 5 ou 6 vezes de stake nativos para LSD para LRT. Isso naturalmente leva a um grande número de problemas de risco com o empilhamento do boneco de nidificação, e um problema com apenas um dos protocolo afeta diretamente todos os protocolo envolvidos no boneco de nidificação (especialmente o stake protocolo na extremidade da cauda da estrutura do boneco de nidificação). Há um grande número de soluções centralizadas no ecossistema BTC, e se você aprender a desenhar um furo, o risco de copiar esse conjunto só será maior. Mas, para ser claro, Eigenlayer e Babylon estão guiando o volante stake em direção ao valor real de utilidade, e ambos estão essencialmente criando oferta e demanda reais para compensar esse risco. Portanto, embora a existência da “segurança compartilhada” protocolo direta ou indiretamente promova o agravamento de maus hábitos, é a única solução para stake bonecos de nidificação se livrar dos benefícios de Ponzi. Agora, a questão mais importante é: a lógica de negócios da “segurança compartilhada” protocolo realmente válida?

A verdadeira oferta e demanda é a chave

Na Web3, quer seja uma cadeia pública ou um protocolo, a lógica subjacente muitas vezes assenta na “correspondência” entre compradores e vendedores para atender a determinadas necessidades. Aqueles que fazem a correspondência corretamente podem obter o “mundo”, e a blockchain em si apenas garante que esta correspondência seja justa, real e confiável. Teoricamente, os protocolos de segurança compartilhada podem complementar bem o próspero atual sistema de stake e ecossistema modular. No entanto, ao ponderar cuidadosamente, será que esta oferta excederá em muito a procura? Em primeiro lugar, do lado da oferta, existem muitos projetos que oferecem segurança modular e cadeias principais. Por outro lado, as antigas cadeias PoS de renome podem não precisar ou talvez, por questões de prestígio, não queiram alugar este tipo de segurança, e as novas cadeias PoS serão capazes de pagar os juros maciços gerados por BTC e ETH? Para que a lógica comercial do Eigenlayer e do Babylon forme um ciclo fechado, pelo menos é necessário que os lucros a serem obtidos estejam equilibrados com os juros gerados pelo token de stake dentro do protocolo. E mesmo que este equilíbrio seja alcançado, ou até mesmo que os lucros superem em muito as despesas com juros, ainda haverá a questão da drenagem de valor das novas cadeias PoS e protocolos. Portanto, ponderar o equilíbrio no modelo econômico, sem cair na bolha do desenvolvimento baseado em expectativas de airdrop, e promover de forma mais saudável a interação entre oferta e procura, é crucial.

Referências

1.万字详解 Babylon 如何让 Cosmos 生态受益于BTC的安全性：

2. Compreender profundamente a Eigenlayer: Permitindo que o Ethereum quebre a situação de “boneca russa”? :_source=publication-search

3. Conversa com Babylon Co-fundador Fisher Yu: Como desbloquear a liquidez de 21 milhões de BTC por meio de staking?

4.三角债 or 温和通胀：再质押的另类视角：_WzndAZXRjnEgD2hcew

5. Um olhar sobre o que tenho visto ultimamente no mundo das criptomoedas: