Autor: Zeke, pesquisador da YBB Capital
Prefácio
Na era modular liderada pela Ethereum, fornecer serviços de segurança conectando a camada DA (disponibilidade de dados) não é novidade. O atual conceito de segurança compartilhada trazido pelo Staking fornece uma nova dimensão à trilha modular, ou seja, usando o potencial do “ouro e prata digital” para fornecer muitos protocolos de blockchain e cadeias públicas com os benefícios do Bitcoin ou da segurança do Ethereum. . Narrativamente falando, é bastante grandioso. Não só liberta biliões de liquidez em valor de mercado, como também é a chave para a expansão futura. Veja o recente protocolo de staking de Bitcoin Babylon e o protocolo de re-pledge (ReStake) EigenLayer do Ethereum, que receberam respectivamente um enorme financiamento de US$ 70 milhões e US$ 100 milhões como exemplos. Não é difícil perceber que o chefe VC reconhece muito essa faixa.
No entanto, também há muitas dúvidas que surgem com ela. Se a modularização é o objetivo final da expansão da capacidade, e os dois, como membros-chave, inevitavelmente bloquearão uma enorme quantidade de BTC e ETH, então é a segurança do próprio protocolo. vale a pena examinar? Será que a louca "matryoshka" formada com muitos protocolos LSD e LRT se tornará o maior cisne negro no futuro blockchain? Sua lógica de negócios é razoável? Como analisamos o EigenLayer em artigos anteriores, o artigo a seguir discutirá principalmente as questões de apelação por meio do Babylon.
Estenda o consenso de segurança
As cadeias públicas mais valiosas até agora no desenvolvimento do mundo blockchain devem ser Bitcoin e Ethereum. Sua segurança, descentralização e consenso de valor acumulados ao longo de muitos anos garantem que eles possam permanecer no topo da montanha da cadeia pública durante todo o ano. essencial. É também a característica escassa que é mais difícil de copiar por outras cadeias heterogéneas, e o núcleo da ideia modular é “alugar” estas características aos que são procurados. No estágio atual do pensamento modular, existem principalmente duas facções:
A primeira é que a Camada 1 (geralmente Ethereum) com segurança suficiente é usada como as três camadas inferiores ou parte das camadas funcionais dos Rollups. Esta solução tem a mais alta segurança e legitimidade, e também pode absorver recursos no ecossistema da cadeia principal. Mas para Rollups específicos (cadeias de aplicação, cadeias de cauda longa, etc.), o rendimento e o custo não são particularmente amigáveis;
A segunda é recriar uma existência próxima da segurança do Bitcoin e Ethereum e com melhor desempenho de custo. Por exemplo, o conhecido Celestia usa uma arquitetura funcional DA pura, minimiza os requisitos de hardware do nó, reduz os custos de gás, etc., e simplifica as complexidades para criar uma camada DA que seja tão segura, descentralizada e poderosa quanto o Ethereum no menor tempo possível. A desvantagem desta solução é que levará algum tempo para completar a segurança e descentralização, e carece de legitimidade e constitui uma relação competitiva óbvia com Ethereum, por isso é rejeitada pela comunidade Ethereum.
Outra categoria nesta facção é Babylon e Eigenlayer, que usam a ideia central do POS (Proof-of-Stake) para criar serviços de segurança compartilhados, emprestando o valor do ativo Bitcoin ou Ethereum. Comparada com as duas primeiras, é uma existência mais neutra. A sua vantagem é que, ao mesmo tempo que herda legitimidade e segurança, também confere aos activos da cadeia principal mais valor de utilização e é mais flexível.
O potencial do ouro digital
Independentemente da lógica subjacente do mecanismo de consenso, a segurança da blockchain depende em grande parte de quantos recursos ela possui para apoiá-la. A cadeia PoW requer muito hardware e eletricidade, enquanto o PoS depende do valor dos ativos prometidos. O próprio Bitcoin é suportado por uma rede de poder de computação PoW extremamente grande, que pode ser considerada a existência mais segura em todo o blockchain. No entanto, sendo uma cadeia pública com um valor de mercado circulante de 1,39 biliões de dólares e responsável por metade da blockchain, os seus ativos são utilizados apenas em dois cenários principais de utilização: transferência e pagamento de gás.
Para a outra metade da indústria de blockchain, especialmente desde que o Ethereum Shanghai atualizou para PoS, pode-se dizer que a maioria das cadeias públicas usa PoS de diferentes arquiteturas por padrão para completar o consenso. No entanto, uma vez que a nova cadeia heterogénea em si não pode atrair muitos compromissos de capital, a sua segurança é altamente questionável. Na era modular atual, embora a zona Cosmos e várias camadas 2 também possam usar várias camadas DA para compensar, elas também perdem sua autonomia. Para a maioria das antigas cadeias públicas ou cadeias de aliança com mecanismos POS, é basicamente impossível usar Ethereum ou Celestia para atuar como DA. O valor da Babylon é preencher essa lacuna, comprometendo-se a fornecer proteção à cadeia PoS. Assim como os humanos usaram ouro para sustentar o valor das notas no passado, o BTC é de fato adequado para desempenhar esse papel no mundo blockchain.
de 0 a 1
Liberar “ouro digital” sempre foi a narrativa mais grandiosa e difícil no blockchain, desde as primeiras cadeias laterais, Lightning Network e tokens embrulhados em ponte até as runas de hoje e o BTC Layer2, pode-se dizer que não importa o tipo de solução. existe, certas falhas inerentes. Se a Babylon quiser implementar a segurança do Bitcoin, a solução centralizada que introduz a suposição de confiança de terceiros será naturalmente eliminada primeiro. Entre os planos restantes, Rune e Lightning Network (limitados por um progresso de desenvolvimento extremamente lento) atualmente só têm a capacidade de emitir ativos, o que significa que a Babylon precisa projetar outro “plano de expansão” para permitir que o Bitcoin seja penhorado nativamente de 0 a 1. .
A divisão de alguns dos elementos básicos atualmente disponíveis no Bitcoin são, na verdade, os seguintes: 1. Modelo UTXO, 2. Carimbo de data e hora, 3. Métodos de assinatura múltipla, 4. Códigos de operação básicos. A solução dada pela Babylon é baseada na fraca programabilidade e capacidade de transporte de dados do Bitcoin. Aderindo ao princípio da minimização, apenas as funções necessárias do contrato de penhor são concluídas no Bitcoin, o que significa que o penhor BTC, o confisco, as recompensas, a retirada, etc. Depois de realizar este 0 a 1, os requisitos complexos são então entregues à zona Cosmos para processamento. Mas ainda há uma questão chave aqui: como registrar os dados da cadeia PoS na cadeia principal?
Piquetagem Remota
UTXO (Unspent Transaction Outputs) é um modelo de transação desenvolvido por Satoshi Nakamoto para Bitcoin. Sua ideia central é extremamente simples. A negociação nada mais é do que a entrada e saída de fundos, portanto todo o sistema de negociação só precisa ser expresso em duas formas: entrada (Input) e saída (Output). O chamado UTXO significa que quando os fundos entram, mas os fundos gastos não são tantos, a parte restante é a saída da transação não gasta (ou seja, o Bitcoin não pago). Todo o livro-razão do Bitcoin é na verdade uma coleção de UTXOs. Ao registrar o status de cada UTXO, a propriedade e a circulação de Bitcoins são gerenciadas. Cada transação consome UTXOs antigos e gera novos UTXOs. Como seus atributos possuem certa escalabilidade potencial, tornou-se naturalmente o ponto de partida para muitas soluções de expansão nativa. Por exemplo, a Lightning Network usa UTXO e assinaturas múltiplas para criar um mecanismo de penalidade e canal de status, ou vincula UTXO para realizar inscrições e runas de SFT (tokens semifungíveis). É tudo baseado neste ponto de partida fundamental que pode se tornar realidade.
Naturalmente, Babylon também precisa usar UTXO para implementar o contrato de penhor (Babylon é chamado de penhor remoto, ou seja, a segurança do BTC é transmitida remotamente para a cadeia PoS através da camada intermediária, ao mesmo tempo, combina habilmente o existente). códigos de operação com ideias para implementar o contrato As etapas específicas podem ser divididas nas quatro etapas a seguir:
Bloquear fundos
Os usuários enviam fundos para um endereço controlado por uma assinatura múltipla. Através do OP_CTV (OP_CHECKTEMPLATEVERIFY, que permite a criação de modelos de transações predefinidos, garantindo que as transações só podem ser executadas de acordo com estruturas e condições específicas), o contrato pode especificar que esses fundos só podem ser gastos quando determinadas condições forem atendidas. Após o bloqueio dos fundos, é gerado um novo UTXO, indicando que os fundos foram penhorados;
Verificação condicional
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 UTXO só pode ser gasto após um determinado tempo relativo ou número de blocos) pode obter bloqueio de tempo, garantindo que os fundos não possam ser sacados dentro de um determinado período de tempo. Combinado com o OP_CTV reclamado acima, o staking e o unstaking podem ser realizados (quando o tempo de promessa for cumprido, o promitente pode gastar o UTXO bloqueado) e o slashing (se o promitente fizer o mal, ele será forçado a gastar). UTXO para um endereço bloqueado e restrito a um estado não gastável, semelhante a um endereço de buraco negro);
atualização de status
Sempre que um usuário aposta ou retira fundos apostados, o UTXO é criado e gasto. Novas saídas de transação geram novos UTXOs e UTXOs antigos são marcados como gastos. Desta forma, cada transação e fluxo de capital é registrado com precisão na blockchain, garantindo transparência e segurança;
distribuição de receitas
Com base no valor e no prazo do penhor, o contrato calculará a recompensa devida e a distribuirá gerando novo UTXO. Essas recompensas podem ser desbloqueadas e gastas por meio de condições programadas ao atender a determinadas condições.
Carimbo de data e hora
Com o contrato de penhor nativo em vigor, é natural pensar na questão do registro de acontecimentos históricos na cadeia externa. No white paper de Satoshi Nakamoto, o blockchain Bitcoin introduziu o conceito de carimbos de data/hora alimentado por PoW, um mecanismo que fornece uma ordem cronológica irreversível de eventos. No cenário de uso nativo do Bitcoin, esses eventos referem-se a diversas transações realizadas no livro-razão. Hoje, para aumentar a segurança de outras cadeias PoS, o Bitcoin também pode ser usado para registrar eventos em blockchains externos. Cada vez que tal evento ocorre, ele aciona uma transação que é enviada ao minerador, que então a insere no livro-razão do Bitcoin, registrando assim a data e hora do evento. Esses carimbos de data/hora podem ser usados para resolver vários problemas de segurança do blockchain. O conceito geral de eventos de carimbo de data/hora em uma cadeia filha em uma cadeia pai é chamado de checkpoint, e as transações usadas para carimbá-los são chamadas de transações de ponto de verificação. Especificamente, o carimbo de data/hora na blockchain Bitcoin tem as seguintes características importantes:
Formato de hora: O carimbo de data/hora registra o número de segundos desde 00:00:00 UTC de 1º de janeiro de 1970. Esse formato é chamado de carimbo de data/hora Unix ou hora POSIX;
Função: A principal função do timestamp é identificar o tempo de geração dos blocos, ajudar os nós a determinar a ordem dos blocos e auxiliar o mecanismo de ajuste de dificuldade da rede;
Carimbos de data e hora e ajustes de dificuldade: A rede Bitcoin realiza ajustes de dificuldade a cada bloco de 2016 (aproximadamente a cada duas semanas). Os timestamps desempenham um papel fundamental neste processo, pois a rede ajusta a dificuldade de mineração com base no tempo total de geração dos últimos blocos de 2016, para que novos blocos sejam gerados a uma taxa próxima de um 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 que o tempo médio de vários blocos anteriores e não pode exceder 120 minutos de tempo de rede (ou seja, 2 horas no futuro).
Timestamp Server é uma nova primitiva definida pela Babylon que distribui carimbos de data/hora Bitcoin através de pontos de verificação da Babylon por meio de blocos PoS, garantindo a precisão das séries temporais e evitando adulterações. Este servidor é a camada superior de toda a arquitetura do Babylon e é a principal fonte de requisitos de confiança.
A arquitetura de três níveis da Babilônia
Conforme 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 do Cosmos), como camada intermediária, e a camada de demanda da cadeia PoS. Babylon chama os dois últimos respectivamente de Plano de Controle (plano de controle, ou seja, o próprio Babylon) e Plano de Dados (plano de demanda de dados, ou seja, várias cadeias de consumo de PoS).
Depois de compreender a implementação básica da falta de confiança do protocolo, vamos ver como o próprio Babylon usa a zona Cosmos para conectar as duas extremidades. De acordo com a explicação detalhada do Stanford Tse Lab sobre Babylon [1], o Babylon pode receber fluxos de pontos de verificação de múltiplas cadeias PoS, mesclar esses pontos de verificação e publicá-los no Bitcoin. O tamanho dos pontos de verificação é minimizado usando assinaturas agregadas dos validadores do Babylon, e a frequência desses pontos de verificação é controlada permitindo que os validadores do Babylon mudem apenas uma vez por época.
Os validadores de cada cadeia PoS baixam o bloco Babylon e observam se seu ponto de verificação PoS está incluído no bloco Babylon verificado pelo Bitcoin. Isso permite que a cadeia PoS detecte discrepâncias, por exemplo, se um validador Babylon criar um bloco indisponível que é verificado pelo Bitcoin e mentir sobre o ponto de verificação PoS contido no bloco indisponível. Os principais componentes que compõem o acordo são os seguintes:
Ponto de verificação: apenas o último bloco da Época da Babilônia é verificado pelo Bitcoin. O ponto de verificação consiste no hash do bloco e em uma única assinatura BLS agregada correspondente às assinaturas dos 2/3 conjuntos de validadores que assinaram o bloco para finalização. Os pontos de verificação da Babilônia também contêm números de época. Os blocos PoS podem receber carimbos de data e hora de blocos Bitcoin por meio de pontos de verificação Babylon. Por exemplo, os dois primeiros blocos PoS são verificados pelo bloco Babylon, 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 Bitcoin t_3.
Cadeia PoS canônica: quando ocorre uma bifurcação na cadeia PoS, a cadeia com um carimbo de data/hora anterior é considerada a cadeia PoS canônica. Se duas bifurcações tiverem o mesmo carimbo de data/hora, o empate será desfeito em favor do bloco PoS com o ponto de verificação anterior em Babylon.
Regras de saque: Para sacar dinheiro, o validador envia uma solicitação de saque à rede PoS. O bloco PoS contendo a solicitação de retirada é verificado pelo Babylon e depois pelo Bitcoin e recebe um carimbo de data/hora t_1. As retiradas são concedidas na cadeia PoS quando a profundidade do bloco Bitcoin com carimbo de data/hora t_1 se torna k. Neste ponto, se um validador que retirou sua aposta realizar um ataque de longo alcance, o bloco na cadeia de ataque só poderá receber um carimbo de data/hora Bitcoin posterior a t_1. Isso ocorre porque uma vez que o bloco Bitcoin com carimbo de data/hora t_1 atinge profundidade k, ele não pode ser revertido. Então, observando a ordem desses pontos de verificação no Bitcoin, o cliente PoS pode distinguir entre a cadeia canônica e a cadeia de ataque e, posteriormente, ignorar a cadeia de ataque.
Regra de corte: Validadores com blocos PoS conflitantes com assinatura dupla podem ser cortados se não retirarem sua aposta quando um ataque for detectado. Validadores de PoS maliciosos sabem que se esperarem até que uma solicitação de saque seja aprovada antes de conduzir um ataque de segurança de longo alcance, não serão capazes de confundir os clientes, que podem olhar para o Bitcoin para identificar a cadeia canônica. Portanto, eles podem bifurcar a cadeia PoS ao atribuir carimbos de data/hora Bitcoin a blocos na cadeia PoS canônica. Esses validadores PoS colaboraram com validadores maliciosos do Babylon, bem como com mineradores de Bitcoin, para bifurcar o Babylon e o Bitcoin e substituir o bloco Bitcoin com carimbo de data e hora t_2 por outro bloco com carimbo de data e hora t_3. Isso mudará a cadeia PoS canônica da cadeia superior para a cadeia inferior aos olhos dos clientes PoS posteriores. Embora este tenha sido um ataque de segurança bem-sucedido, resultou na redução da participação do validador PoS malicioso porque eles tinham um bloco conflitante com assinatura dupla, mas ainda não haviam retirado sua participação.
Regras de interrupção para pontos de verificação de PoS indisponíveis: os validadores de PoS devem pausar sua cadeia de PoS ao observar um ponto de verificação de PoS indisponível no Babylon. Aqui, um ponto de verificação PoS indisponível é um hash assinado por 2/3 dos validadores PoS, que se presume corresponder a um bloco PoS não observável. Se o validador PoS não parar a cadeia PoS ao observar um ponto de verificação indisponível, um invasor poderá revelar a cadeia de ataque anteriormente indisponível e alterar a cadeia canônica em visualizações posteriores do cliente. Isso ocorre porque o ponto de verificação da cadeia sombria mostrada mais tarde ocorre no início da Babilônia. A regra de pausa acima revela 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 forem assinados, qualquer invasor poderá enviar um hash arbitrário e alegar que é o hash de um ponto de verificação de bloco PoS que não está disponível no Babylon. Os validadores PoS terão então que pausar o ponto de verificação. Observe que criar uma cadeia PoS inutilizável é difícil: requer a quebra de pelo menos 2/3 dos validadores PoS para que eles completem o bloco PoS com assinaturas, mas não forneçam dados para validadores honestos. No entanto, no ataque hipotético acima, o adversário malicioso interrompeu a cadeia PoS sem atacar um único validador. Para evitar tais ataques, exigimos que os pontos de verificação de PoS sejam verificados por 2/3 dos validadores de PoS. Portanto, Babylon terá pontos de verificação de PoS indisponíveis somente se 2/3 dos validadores de PoS forem de fato controlados por invasores. Devido ao custo de comprometer os validadores de PoS, este ataque é extremamente improvável e não afetará outras cadeias de PoS ou a própria Babylon.
Regras de pausa para pontos de verificação Babylon indisponíveis: os validadores PoS e Babylon devem pausar o blockchain ao observar um ponto de verificação Babylon indisponível no Bitcoin. Aqui, o ponto de verificação Babylon indisponível é um hash das assinaturas BLS agregadas com 2/3 validadores Babylon, o que presumivelmente corresponde a um bloco Babylon não observável. Se um validador Babylon não parar a blockchain Babylon, um invasor pode revelar uma cadeia Babylon anteriormente indisponível, alterando assim a cadeia canônica do Babylon na visão de clientes posteriores. Da mesma forma, se o validador PoS não parar a cadeia PoS, o invasor poderá revelar a cadeia de ataque PoS anteriormente indisponível, bem como a cadeia Babylon anteriormente indisponível, canonizando assim a cadeia PoS na visão dos clientes atrasados. Isso ocorre porque a cadeia escura da Babylon, revelada posteriormente, tem um carimbo de data/hora anterior no Bitcoin e contém pontos de verificação da cadeia de ataque PoS revelada posteriormente. Assim como as regras de suspensão para pontos de verificação PoS indisponíveis, as regras acima revelam por que exigimos que os hashes de bloco Babylon enviados como pontos de verificação sejam acompanhados por uma assinatura BLS agregada que comprove as assinaturas de 2/3 dos validadores Babylon. Se um ponto de verificação do Babylon não estiver assinado, qualquer adversário pode enviar um hash arbitrário e alegar que é o hash de um ponto de verificação do bloco Babylon que não está disponível no Bitcoin. Os validadores PoS e os validadores Babylon terão então que esperar por um ponto de verificação que não tenha nenhuma cadeia Babylon ou PoS indisponível em suas pré-imagens! Criar uma cadeia Babylon inutilizável requer quebrar pelo menos 2/3 dos validadores Babylon. No entanto, no ataque hipotético acima, o invasor interrompeu todas as cadeias do sistema sem sequer comprometer um único validador Babylon ou PoS. Para evitar tais ataques, exigimos que os pontos de verificação do Babylon sejam atestados por assinaturas agregadas, de modo que só haverá pontos de verificação do Babylon inutilizáveis se 2/3 dos validadores estiverem realmente comprometidos; Devido ao custo de comprometer os validadores Babylon, este ataque à disponibilidade de dados é extremamente improvável. Mas, em casos extremos, afeta todas as cadeias PoS, forçando-as a parar.
Camada própria em BTC
Embora Babylon não seja diferente de Eigenlayer em termos de propósito, Babylon não é de forma alguma uma simples bifurcação de "Eigenlayer". A existência do Babylon é muito significativa quando a atual cadeia principal do BTC DA não pode ser usada nativamente. Além de trazer segurança às cadeias PoS externas, este protocolo também é particularmente importante para a revitalização do ecossistema BTC.
Exemplo
Existem muitos casos de uso possíveis no Babylon. Aqui estão alguns casos de uso que foram implementados ou têm a oportunidade de serem implementados no futuro:
1. Encurtar o ciclo de piquetagem e aumentar a segurança: As cadeias PoS geralmente exigem consenso social (consenso entre comunidades, operadores de nós e validadores) para evitar ataques de longo alcance. o blockchain. Métodos de ataque que adulteram registros de transações ou cadeias de controle. Este ataque é particularmente sério em sistemas PoS porque, ao contrário do PoW, os validadores que participam do consenso em sistemas PoS não precisam consumir muitos recursos computacionais, e os invasores podem reescrever o histórico controlando as chaves dos primeiros stakers. Portanto, para garantir a estabilidade do consenso e a segurança da rede blockchain, é basicamente necessário um longo ciclo de penhor. Por exemplo, o ciclo de descomprometimento do Cosmos requer 21 dias. Mas através do Babylon, os eventos históricos da cadeia PoS podem ser adicionados ao servidor de carimbo de data/hora do BTC, usando assim o BTC como uma fonte de confiança para substituir o consenso social, de modo que o tempo de desempacotamento possa ser reduzido para apenas 1 dia (ou seja, após o BTC rodar cerca de 100 blocos). E a cadeia PoS pode ter garantias duplas de penhor de token nativo e penhor de BTC neste momento;
2. Interoperabilidade entre cadeias: Através do protocolo IBC, Babylon é capaz de receber dados de pontos de verificação de múltiplas cadeias PoS para alcançar a interoperabilidade entre cadeias. Essa interoperabilidade permite comunicação e compartilhamento de dados contínuos entre diferentes blockchains, melhorando a eficiência geral e a funcionalidade do ecossistema blockchain;
3. Integrar o ecossistema BTC: A maioria dos projetos no atual ecossistema BTC não possui segurança forte o suficiente, seja Camada 2, LRT ou DeFi, a maioria deles ainda depende da suposição de confiança de terceiros. E há um grande número de BTC armazenados nos endereços desses protocolos. No futuro, eles poderão colidir com o Babylon para encontrar algumas boas soluções correspondentes, alimentar-se mutuamente e, eventualmente, formar um ecossistema tão poderoso quanto. Autocamada em Ethereum;
4. Gerenciamento de ativos entre cadeias: O protocolo Babylon pode ser usado para gerenciar com segurança ativos entre cadeias. Garanta segurança e transparência quando os ativos são transferidos entre diferentes blockchains, adicionando carimbos de data/hora às transações entre cadeias. Esse mecanismo ajuda a evitar gastos duplos e outros ataques entre cadeias.
Torre de babel
A história da Torre de Babel vem da Bíblia, Gênesis Capítulo 11, versículos 1-9. É uma história clássica sobre a tentativa da humanidade de construir uma torre de Babel, mas que acabou sendo interrompida por Deus. Sua moral simboliza a unidade e o comum. objetivo da humanidade. Este é também o significado subjacente do protocolo Babylon. O projeto visa construir uma Torre da Babilônia para muitas cadeias PoS e uni-las. Narrativamente falando, não parece ser inferior ao Eigenlayer, o defensor do Ethereum, mas qual é a situação real?
Até agora, a rede de testes Babylon forneceu garantias de segurança para 50 zonas Cosmos através do protocolo IBC. Além do Cosmos, a Babylon também alcançou cooperação e integração com alguns protocolos LSD (piquetagem de liquidez), protocolos de interoperabilidade de cadeia completa e protocolos ecológicos Bitcoin. Por outro lado, em termos de staking, Babylon ainda é ligeiramente inferior ao Eigenlayer na sua capacidade de reutilizar promessas e LSD dentro do ecossistema Ethereum. Mas, no longo prazo, o BTC adormecido em muitas carteiras e protocolos não foi totalmente despertado, então esta é apenas a ponta do iceberg de US$ 1,3 trilhão. A atual Babilônia ainda precisa complementar ativamente todo o ecossistema BTC.
A única solução para as bonecas de Pond
Conforme mencionado no prefácio, Eigenlayer e Babylon estão se tornando cada vez mais maduros, a julgar pela tendência atual, os dois irão bloquear uma enorme quantidade de ativos essenciais de blockchain no futuro. Mesmo que não haja problemas com a segurança dos dois protocolos em si, será que múltiplas bonecas matryoshka empurrarão todo o ecossistema de staking para uma espiral mortal e causarão um declínio que não será inferior ao nível de outro aumento das taxas de juro nos EUA? A atual trajetória de piquetagem realmente passou por um longo período de prosperidade irracional após a transição do Ethereum para o PoS e o surgimento do Eigenlayer. Para obter TVL mais alto, as partes do projeto geralmente oferecem uma grande quantidade de lançamentos aéreos esperados e bonecos de nidificação para seduzir os usuários. Um ETH pode até ser aninhado 5 ou 6 vezes do penhor nativo ao LSD para o LRT. Naturalmente, isso causará muitos problemas de risco à medida que as bonecas matryoshka forem empilhadas. Enquanto houver um problema com um dos protocolos, isso afetará diretamente todos os acordos participantes das bonecas matryoshka (especialmente o acordo de penhor no final de). a estrutura da boneca matryoshka). Existem muitas soluções centralizadas no ecossistema BTC. Se você seguir o mesmo padrão, o risco de copiá-lo só será maior. Mas o que precisa de ficar claro é que a Eigenlayer e a Babylon estão a guiar o volante em direcção a um valor prático real. Estão essencialmente a criar oferta e procura reais para compensar este risco. Portanto, embora a existência do acordo de “segurança partilhada” promova indirecta ou directamente a intensificação de tendências pouco saudáveis, é a única solução para apostar bonecas matryoshka para evitar os retornos de Pond. A questão mais importante agora é: será que a lógica empresarial do acordo de “segurança partilhada” está realmente estabelecida?
A oferta e a procura reais são fundamentais
Na Web3, seja uma cadeia pública ou um protocolo, sua lógica subjacente geralmente se baseia na “combinação” de compradores e vendedores com determinadas necessidades. Quem fizer a combinação certa pode ganhar “o mundo”, e o próprio blockchain apenas torna essa combinação justa, verdadeira e confiável. Protocolos de segurança compartilhados podem, teoricamente, complementar o atual ecossistema próspero de piquetagem e modular. Mas se pensarmos bem, será que esta oferta excederá em muito a procura? Em primeiro lugar, do lado da oferta, existem alguns projetos e cadeias principais que podem fornecer segurança modular. Por outro lado, as antigas cadeias PoS podem não precisar ou não alugarão tal segurança devido à face, e as novas cadeias PoS. cadeias E se eles podem pagar os juros gerados pela enorme quantidade de BTC e ETH, a lógica de negócios da Eigenlayer e da Babylon deve formar um circuito fechado, e pelo menos a renda obtida deve ser equilibrada com os juros gerados pelo staking de Tokens no acordo . E mesmo que esse equilíbrio possa ser alcançado, e mesmo que a receita supere em muito o pagamento de juros, neste caso haverá sugação de sangue para novos PoS e protocolos. Portanto, como ponderar o modelo económico, para não cair numa bolha que depende das expectativas de lançamento aéreo para o desenvolvimento, e para impulsionar tanto a oferta como a procura de uma forma mais saudável será a principal prioridade.
referências
1. Dez mil palavras de explicação detalhada de como a Babilônia permite que o ecossistema Cosmos se beneficie da segurança do Bitcoin: https://www.chaincatcher.com/article/2079486
2. Conheça o Eigenlayer em profundidade: Ethereum pode quebrar a situação da “boneca matryoshka”? ：https://haotiancryptoinsight.substack.com/p/eigenlayer?utm_source=publication-search
3. Diálogo com Babylon Lianchuang Fisher Yu: Como desbloquear a liquidez de 21 milhões de BTC por meio de piquetagem? : https://www.chaincatcher.com/article/2120653
4. Dívida triangular ou inflação moderada: uma perspectiva alternativa sobre a rehipoteca: https://mp.weixin.qq.com/s/dMc_WzndAZXRjnEgD2hcew
5.Uma olhada no que tenho visto em criptografia ultimamente: https://theknower.substack.com/p/a-look-at-what-ive-been-seeing-in
