Autor: Zeke, YBB Capital Fuente: medio Traducción: Shan Oba, Golden Finance
Prefacio
En la era de las cadenas de bloques modulares liderada por Ethereum, brindar servicios de seguridad mediante la integración de una capa de disponibilidad de datos (DA) ya no es un concepto nuevo. Actualmente, el concepto de seguridad compartida introducido mediante estacas proporciona una nueva dimensión al espacio modular. Aprovecha el potencial del “oro y plata digitales” para brindar seguridad a numerosos protocolos blockchain y cadenas públicas, desde Bitcoin o Ethereum. La historia es bastante ambiciosa, ya que no sólo desbloquea liquidez en activos por valor de billones de dólares, sino que también es un elemento clave en futuras soluciones de escalamiento. Por ejemplo, las recientes recaudaciones masivas de fondos de 70 millones de dólares para el protocolo de participación de Bitcoin Babylon y de 100 millones de dólares para el protocolo de renovación de participación de Ethereum EigenLayer ilustran el fuerte apoyo al espacio por parte de las principales empresas de capital de riesgo.
Sin embargo, estos acontecimientos también plantean serias preocupaciones. Si la modularidad es la solución definitiva para el escalamiento, y estos protocolos son un componente clave de esa solución, entonces probablemente tendrán grandes cantidades de BTC y ETH bloqueadas. Esto genera problemas de seguridad del propio protocolo. ¿Se convertirán las complejas capas formadas por numerosos protocolos LSD (Liquid Stake Derivatives) y LRT (Layer 2 Rollup Tokens) en el mayor cisne negro del futuro de la blockchain? ¿Es sólida su lógica empresarial? Dado que ya analizamos EigenLayer en un artículo anterior, la siguiente discusión se centrará principalmente en Babylon para abordar estos problemas.
Ampliar el consenso de seguridad
Bitcoin y Ethereum son sin duda las blockchains públicas más valiosas en la actualidad. La seguridad, la descentralización y el consenso de valores que han acumulado a lo largo de los años son las razones principales por las que siempre han estado en la cima del mundo blockchain. Se trata de cualidades raras que son difíciles de replicar con otras cadenas heterogéneas. La idea central de la modularidad es "alquilar" estas cualidades a quienes las necesitan. Dentro del enfoque modular actual, hay dos facciones principales:
La primera facción utiliza una capa 1 suficientemente segura (generalmente Ethereum) como las tres capas inferiores o parcialmente funcionales de Rollups. Esta solución tiene la mayor seguridad y legalidad y puede absorber los recursos del ecosistema de la cadena principal. Pero para rollups específicos (cadenas de aplicaciones, cadenas de cola larga, etc.), puede que no sea particularmente amigable en términos de rendimiento y costo.
El segundo grupo tiene como objetivo crear una existencia que esté cerca de la seguridad de Bitcoin y Ethereum pero que tenga un mejor rendimiento de costos, como Celestia. Celestia logra esto mediante el uso de una arquitectura funcional DA pura, requisitos mínimos de hardware de nodo y bajos costos de gas. Este enfoque simplificado tiene como objetivo crear una capa DA que coincida con la seguridad y la descentralización de Ethereum y al mismo tiempo ofrezca un rendimiento sólido en el menor tiempo posible. Las desventajas de este enfoque son que llevará algún tiempo lograr su seguridad y descentralización por completo, y carece de legitimidad cuando compite directamente con Ethereum, lo que genera el rechazo de la comunidad Ethereum.
El tercer tipo dentro de esta facción incluye las capas babilónica y característica. Aprovechan el concepto central de Prueba de participación (POS) para crear servicios de seguridad compartidos aprovechando el valor de los activos de Bitcoin o Ethereum. En comparación con los dos primeros, esta es una existencia más neutral. Su ventaja es que hereda legalidad y seguridad, al tiempo que aporta más valor práctico a los activos de la cadena principal y aporta mayor flexibilidad.
El potencial del oro digital
Independientemente de la lógica subyacente de cualquier mecanismo de consenso, la seguridad de una cadena de bloques depende en gran medida de los recursos que la respaldan. Las cadenas PoW requieren mucho hardware y electricidad, mientras que PoS depende del valor de los activos prometidos. El propio Bitcoin está respaldado por una red PoW extremadamente grande, lo que lo convierte en la existencia más segura en todo el espacio blockchain. Sin embargo, como cadena pública con un valor de mercado circulante de 1,39 billones de dólares y que representa la mitad del mercado blockchain, su utilidad de activos se limita principalmente a transferencias y pagos de gas.
Para la otra mitad del mundo blockchain, especialmente después de que Ethereum cambió a PoS después de la actualización de Shanghai, se puede decir que la mayoría de las cadenas públicas utilizan diferentes arquitecturas PoS de forma predeterminada para llegar a un consenso. Sin embargo, las nuevas cadenas heterogéneas a menudo no logran atraer grandes promesas de capital, lo que plantea dudas sobre su seguridad. En la era actual de la modularidad, las zonas Cosmos y varias soluciones de Capa 2 pueden utilizar varias capas DA para compensar, pero esto a menudo se produce a expensas de la autonomía. El uso de Ethereum o Celestia como capa DA tampoco suele ser práctico para la mayoría de los mecanismos PoS o cadenas de consorcio más antiguos. El valor de Babylon radica en llenar este vacío brindando protección para la cadena PoS mediante apuestas BTC. Así como los humanos usan el oro para respaldar el valor del papel moneda, Bitcoin está perfectamente preparado para desempeñar este papel en el mundo blockchain.
de 0 a 1
Desbloquear el “oro digital” siempre ha sido el objetivo más ambicioso pero más difícil de alcanzar en el campo blockchain. Desde las primeras cadenas laterales, Lightning Network y tokens puente hasta las Runes y BTC Layer 2 actuales, cada solución tiene sus fallas inherentes. Si Babylon pretende explotar la seguridad de Bitcoin, primero deben descartarse las soluciones centralizadas que introducen una suposición de confianza en terceros. Entre las opciones restantes, Rune y Lightning Network (limitadas por un progreso de desarrollo extremadamente lento) actualmente solo tienen la capacidad de emitir activos. Esto significa que Babylon necesita diseñar su propia "solución de escalamiento" para permitir el stake nativo de Bitcoin de 0 a 1.
Desglosando los elementos básicos actualmente disponibles en Bitcoin, existen esencialmente los siguientes: 1. Modelo UTXO, 2. Marca de tiempo, 3. Varios métodos de firma, 4. Códigos de operación básicos. Dada la limitada programabilidad y capacidad de transporte de datos de Bitcoin, la solución de Babylon se basa en principios minimalistas. En Bitcoin, solo es necesario completar las funciones básicas del contrato de participación, lo que significa que la participación, el recorte, las recompensas y la recuperación de BTC se manejan en la cadena principal. Una vez que se logra este 0 a 1, la zona Cosmos puede manejar requisitos más complejos. Sin embargo, aún queda una pregunta clave: ¿cómo registrar los datos de la cadena PoS en la cadena principal?
Replanteo remoto
UTXO (Unspent Transaction Outputs) es un modelo de transacción diseñado por Satoshi Nakamoto para Bitcoin. La idea central es muy simple: las transacciones son sólo la entrada y salida de fondos, por lo que todo el sistema comercial puede representarse en términos de entradas y salidas. Los UTXO representan la porción de los fondos que ingresaron pero que no se gastaron por completo y, por lo tanto, permanecen como resultados de transacciones no gastados (es decir, Bitcoins no pagados). Todo el libro de contabilidad de Bitcoin es esencialmente una colección de UTXO, que registra el estado de cada UTXO para gestionar la propiedad y circulación de Bitcoins. Cada transacción gasta un UTXO antiguo y genera un UTXO nuevo. Debido a su potencial de escalabilidad inherente, los UTXO son un punto de partida natural para muchas soluciones de escalamiento nativas. Por ejemplo,
Babylon también necesita utilizar UTXO para implementar el contrato de Stake (Babylon se llama Stake remoto y transmite de forma remota la seguridad de Bitcoin a la cadena PoS a través de la capa intermedia). La implementación del contrato se puede dividir en cuatro pasos, combinando inteligentemente los códigos de operación existentes:
Bloquear fondos
Los usuarios envían fondos a direcciones controladas por firmas múltiples. A través de OP_CTV (OP_CHECKTEMPLATEVERIFY, que permite la creación de plantillas de transacciones predefinidas, asegurando que las transacciones solo puedan ejecutarse de acuerdo con estructuras y condiciones específicas), el contrato puede especificar que estos fondos solo pueden usarse bajo ciertas condiciones. Una vez que los fondos están bloqueados, se genera un nuevo UTXO que indica que los fondos han sido apostados.
Verificación condicional
Los bloqueos de tiempo se pueden implementar llamando a OP_CSV (OP_CHECKSEQUENCEVERIFY, que permite establecer un bloqueo de tiempo relativo basado en el número de secuencia de la transacción, lo que indica que UTXO solo se puede gastar después de un cierto tiempo relativo o número de bloques). Combinado con OP_CTV, se puede lograr apostar, desestacar (permitir al apostador gastar el UTXO bloqueado después de que se cumpla el período de compromiso) y recortar (obligar a que el UTXO se gaste en la dirección bloqueada, haciéndolo inutilizable si el apostador se comporta maliciosamente). , similar a la dirección de un agujero negro).
actualización de estado
Cada vez que un usuario apuesta o retira fondos apostados, se crea y gasta una UTXO. Los nuevos resultados de transacciones generan nuevos UTXO y los UTXO antiguos se marcan como gastados. De esta manera, cada transacción y movimiento financiero se registra con precisión en la cadena de bloques, garantizando transparencia y seguridad.
Distribución de recompensas
El contrato calcula las recompensas en función del monto apostado y el período de apuesta y las distribuye generando nuevos UTXO. Estas recompensas se pueden desbloquear y gastar mediante condiciones escritas una vez que se cumplan ciertas condiciones.
Marca de tiempo
Después de establecer el contrato de Stake nativo, es natural considerar la cuestión de registrar eventos históricos de la cadena externa. En el libro blanco de Satoshi Nakamoto, la cadena de bloques de Bitcoin introdujo el concepto de marcas de tiempo respaldadas por PoW, proporcionando un orden cronológico irreversible de los eventos. En el caso de uso nativo de Bitcoin, estos eventos se refieren a varias transacciones realizadas en el libro mayor. Hoy en día, para mejorar la seguridad de otras cadenas PoS, Bitcoin también se puede utilizar para marcar la hora de eventos en cadenas de bloques externas. Cada vez que ocurre un evento de este tipo, se activa una transacción que se envía al minero, quien luego la inserta en el libro mayor de Bitcoin, agregando así una marca de tiempo al evento. Estas marcas de tiempo pueden resolver varios problemas de seguridad de blockchain. El concepto general de marcar la hora de los eventos en una cadena secundaria en una cadena principal se denomina "punto de control", y las transacciones utilizadas para marcar la hora se denominan transacciones de punto de control. Específicamente, las marcas de tiempo en la cadena de bloques de Bitcoin tienen las siguientes características importantes:
Formato de hora: una marca de tiempo registra la cantidad de segundos desde el 1 de enero de 1970 a las 00:00:00 UTC. Este formato se llama hora Unix o hora POSIX.
Propósito: El propósito principal de la marca de tiempo es marcar el tiempo de generación del bloque, ayudar a los nodos a determinar el orden de los bloques y ayudar al mecanismo de ajuste de dificultad de la red.
Marcas de tiempo y ajustes de dificultad: la red Bitcoin ajusta la dificultad de minería aproximadamente cada dos semanas, o cada 2016 bloques. Las marcas de tiempo juegan un papel crucial en este proceso, ya que la red ajusta la dificultad en función del tiempo total de generación de los últimos bloques de 2016 para garantizar que se generen nuevos bloques aproximadamente cada 10 minutos.
Verificación de validez: cuando un nodo recibe un nuevo bloque, verifica la marca de tiempo. La marca de tiempo del nuevo bloque debe ser mayor que el tiempo medio de los bloques anteriores y no debe exceder el tiempo de la red en más de 120 minutos (2 horas en el futuro).
El servidor de marca de tiempo es una nueva primitiva definida por Babylon, que puede distribuir marcas de tiempo de Bitcoin a través de puntos de control de Babylon en bloques PoS, garantizando la precisión y la no manipulación de las series de tiempo. Como capa superior de toda la arquitectura de Babylon, este servidor es la fuente principal de confianza.
La arquitectura de tres niveles de Babilonia
Como se muestra en la figura, la arquitectura general de Babylon se puede dividir en tres capas: Bitcoin (como servidor de marca de tiempo), Babylon (como Cosmos Zone como capa intermedia) y la cadena PoS como capa de demanda. Babylon se refiere a los dos últimos como el plano de control (la propia Babylon) y el plano de datos (varias cadenas de consumo de PoS).
Ahora que entendemos la implementación básica del protocolo sin confianza, profundicemos en cómo Babylon usa las zonas Cosmos para conectar los dos extremos. Según una explicación detallada del Tse Lab de la Universidad de Stanford sobre Babylon, Babylon puede recibir flujos de puntos de control de múltiples cadenas PoS y fusionar estos puntos de control para su publicación en Bitcoin. El tamaño de los puntos de control se puede minimizar mediante el uso de firmas agregadas de los validadores de Babylon, y la frecuencia de estos puntos de control se puede controlar permitiendo que los validadores de Babylon cambien solo una vez por época.
Los validadores de varias cadenas de PoS descargan bloques de Babylon para verificar si sus puntos de control de PoS están incluidos en los bloques de Babylon verificados por Bitcoin. Esto permite que la cadena PoS detecte discrepancias, como si un validador de Babylon creara un bloque no disponible validado por Bitcoin y mintiera sobre los puntos de control de PoS que contiene. Los principales componentes del acuerdo son los siguientes:
· Punto de control: Bitcoin sólo verifica el último bloque de la Era Babilónica. Un punto de control consta del hash de un bloque y una única firma BLS agregada, correspondiente a las firmas de la mayoría de dos tercios de los validadores que firman la finalidad del bloque. Babylon Checkpoint también incluye el Anno. A los bloques PoS se les pueden asignar marcas de tiempo de Bitcoin a través de los puntos de control de Babylon. Por ejemplo, los dos primeros bloques PoS están controlados por el bloque Babylon y luego por el bloque Bitcoin con marca de tiempo t_3. Por lo tanto, a estos bloques PoS se les asigna la marca de tiempo de Bitcoin t_3.
· Cadena PoS canónica: cuando una cadena PoS se bifurca, la cadena con una marca de tiempo anterior se considera la cadena PoS canónica. Si dos bifurcaciones tienen la misma marca de tiempo, el empate se romperá a favor del bloque PoS del punto de control anterior en Babylon.
· Reglas de retiro: Para retirar dinero, el verificador envía una solicitud de retiro a la cadena PoS. El bloque PoS que contiene la solicitud de retiro será verificado por Babylon y posteriormente por Bitcoin, que le asignará una marca de tiempo t_1. Los retiros se aprueban en la cadena PoS una vez que el bloque de Bitcoin con marca de tiempo t_1 alcanza la profundidad k. Si un validador que se retira intenta un ataque remoto, a los bloques de la cadena de ataque solo se les pueden asignar marcas de tiempo posteriores a t_1. Esto se debe a que una vez que el bloque de Bitcoin con marca de tiempo t_1 alcanza la profundidad k, no se puede revertir. Al observar el orden de estos puntos de control en Bitcoin, los clientes de PoS pueden distinguir entre cadenas canónicas y de ataque e ignorar estas últimas.
· Reglas de reducción: si los validadores no retiran su apuesta después de que se detecta un ataque, pueden ser eliminados por firmar dos veces bloques PoS conflictivos. Los validadores de PoS maliciosos saben que si esperan hasta que se apruebe una solicitud de retiro antes de lanzar un ataque remoto, no podrán engañar a los clientes que pueden consultar Bitcoin para identificar la cadena canónica. Por lo tanto, pueden bifurcar la cadena PoS mientras asignan marcas de tiempo de Bitcoin a bloques en la cadena PoS canónica. Estos validadores de PoS colaboraron con validadores de Babylon maliciosos y mineros de Bitcoin para bifurcar Babylon y Bitcoin, reemplazando el bloque de Bitcoin con la marca de tiempo t_2 por otro bloque con la marca de tiempo t_3. A los ojos de los clientes PoS posteriores, esto cambiará la cadena PoS canónica de la cadena superior a la cadena inferior. Aunque este fue un ataque de seguridad exitoso.
· La regla de suspensión del punto de control de PoS no está disponible: los validadores de PoS deben pausar su cadena de PoS cuando observan un punto de control de PoS no disponible en Babylon. Un punto de control de PoS no disponible se define como un hash firmado por dos tercios de los validadores de PoS que supuestamente corresponde a un bloque de PoS no observable. Si el validador de PoS no pausa la cadena de PoS cuando observa un punto de control no disponible, un atacante puede revelar una cadena de ataque que anteriormente no estaba disponible, cambiando así la cadena canónica en futuras vistas del cliente. Esto se debe al punto de control de la Cadena de las Sombras, que luego se reveló que ocurrió antes en Babilonia. Las reglas de pausa anteriores explican por qué requerimos que los hashes de bloque de PoS enviados como puntos de control estén firmados por el conjunto de validadores de PoS. Si estos puntos de control no están firmados, cualquier atacante puede enviar un hash arbitrario afirmando que es el hash de un punto de control de bloque PoS que no está disponible en Babylon. Luego, el validador PoS debe detenerse en el punto de control. Tenga en cuenta que crear una cadena PoS inutilizable es un desafío: requiere comprometer al menos dos tercios de los validadores PoS para firmar bloques PoS sin proporcionar datos a validadores honestos. Sin embargo, en el ataque hipotético anterior, un adversario malicioso detuvo la cadena PoS sin comprometer a ningún validador. Para evitar este tipo de ataques, requerimos que los puntos de control de PoS estén firmados por dos tercios de los validadores de PoS. Por lo tanto, no habrá puntos de control de PoS no disponibles en Babylon a menos que dos tercios de los validadores de PoS estén comprometidos, lo cual es extremadamente improbable debido al costo de comprometer los validadores de PoS, y no afectará a otras cadenas de PoS ni a Babylon. Requiere comprometer al menos dos tercios de los validadores de PoS para firmar un bloque de PoS sin proporcionar datos a validadores honestos. Sin embargo, en el ataque hipotético anterior, un adversario malicioso detuvo la cadena PoS sin comprometer a ningún validador. Para evitar este tipo de ataques, requerimos que los puntos de control de PoS estén firmados por dos tercios de los validadores de PoS. Por lo tanto, no habrá puntos de control de PoS no disponibles en Babylon a menos que dos tercios de los validadores de PoS estén comprometidos, lo cual es extremadamente improbable debido al costo de comprometer los validadores de PoS, y no afectará a otras cadenas de PoS ni a Babylon.Requiere comprometer al menos dos tercios de los validadores de PoS para firmar un bloque de PoS sin proporcionar datos a validadores honestos. Sin embargo, en el ataque hipotético anterior, un adversario malicioso detuvo la cadena PoS sin comprometer a ningún validador. Para evitar este tipo de ataques, requerimos que los puntos de control de PoS estén firmados por dos tercios de los validadores de PoS.
· La regla de pausa del punto de control de Babylon no está disponible: Tanto los validadores de PoS como los de Babylon deben pausar la cadena de bloques cuando observan un punto de control de Babylon que no está disponible en Bitcoin. Un punto de control de Babylon no disponible se define como un hash de las firmas BLS agregadas de dos tercios de los validadores de Babylon que supuestamente corresponde a un bloque de Babylon no observable. Si los validadores de Babylon no suspenden la cadena de bloques de Babylon, un atacante podría filtrar una cadena de Babylon que antes no estaba disponible, cambiando así la cadena canónica de Babylon en futuras vistas de los clientes. De manera similar, si el validador de PoS no pausa la cadena de PoS, un atacante puede revelar una cadena de ataque de PoS que anteriormente no estaba disponible y una cadena de Babylon que anteriormente no estaba disponible, cambiando así la cadena de PoS canónica en futuras vistas de clientes. Esto se debe a que la cadena profunda de Babylon, revelada más tarde, tenía marcas de tiempo anteriores en Bitcoin y contenía puntos de control de la cadena de ataque PoS revelada más tarde. De manera similar a las reglas para pausar en puntos de control PoS no disponibles, esta regla explica por qué requerimos que los hashes de bloque de Babylon enviados como puntos de control tengan firmas BLS agregadas, lo que demuestra las firmas de dos tercios de los validadores de Babylon. Si el punto de control de Babylon no está firmado, cualquier adversario puede enviar un hash arbitrario alegando que es el hash del punto de control del bloque Babylon que no está disponible en Bitcoin. Los validadores PoS y los validadores Babylon deben esperar un punto de control sin una cadena Babylon o PoS no disponible en su imagen previa. Crear una cadena Babylon no disponible requiere comprometer al menos dos tercios de los validadores de Babylon. Sin embargo, en el ataque hipotético anterior, el adversario detiene todas las cadenas del sistema sin afectar a ningún validador de Babylon o PoS. Para evitar tales ataques, requerimos que los puntos de control de Babylon estén atestiguados por firmas agregadas; por lo tanto, no habrá puntos de control de Babylon inutilizables a menos que dos tercios de los validadores estén comprometidos, lo cual, debido al costo de comprometer a los validadores de Babylon, esta posibilidad es extremadamente pequeña. Pero en casos extremos, afecta a todas las cadenas de PoS obligándolas a hacer una pausa.
Capa de características en BTC
Babylon es similar a Eigenlayer en términos de propósito, pero está lejos de ser una simple "bifurcación" de Eigenlayer. Dado que DA no se puede utilizar de forma nativa en la cadena principal de BTC, la existencia de Babylon es bastante importante. El protocolo no sólo aporta seguridad a las cadenas PoS externas, sino que también es fundamental para revitalizar el ecosistema BTC internamente.
Ejemplo
Babylon ofrece muchos casos de uso potenciales, algunos de los cuales ya se han implementado o pueden tener la oportunidad de implementarse en el futuro:
Acortar el período de participación y mejorar la seguridad: las cadenas de PoS generalmente requieren consenso social (acuerdo entre la comunidad, operadores de nodos y validadores) para evitar ataques remotos. Estos ataques implican reescribir el historial de blockchain para manipular registros de transacciones o controlar la cadena. Los ataques remotos son particularmente graves en los sistemas PoS porque, a diferencia de PoW, los sistemas PoS no requieren que los validadores consuman grandes cantidades de recursos informáticos. Un atacante puede reescribir la historia controlando las claves de los primeros apostadores. Para garantizar la estabilidad y seguridad del consenso de la red blockchain, generalmente se requiere un ciclo de compromiso más largo. Por ejemplo, Cosmos requiere un período de desvinculación de 21 días. Sin embargo, con Babylon, los eventos históricos de la cadena PoS se pueden incorporar a los servidores de marca de tiempo de BTC, utilizando BTC como fuente de confianza para reemplazar el consenso social. Esto puede reducir el tiempo de desvinculación a un día (equivalente a unos 100 bloques BTC). Además, la cadena PoS puede lograr doble seguridad mediante la apuesta de tokens nativos y la apuesta de BTC.
Interoperabilidad entre cadenas: a través del protocolo IBC, Babylon puede recibir datos de puntos de control de múltiples cadenas PoS, logrando así la interoperabilidad entre cadenas. Esta interoperabilidad permite una comunicación fluida y el intercambio de datos entre diferentes blockchains, aumentando así la eficiencia y funcionalidad generales del ecosistema blockchain.
Integrar el ecosistema BTC: la mayoría de los proyectos en el ecosistema BTC actual, incluidos Layer 2, LRT y DeFi, carecen de seguridad suficiente y, a menudo, dependen de suposiciones de confianza de terceros. Estos protocolos también almacenan grandes cantidades de BTC en sus direcciones. En el futuro, Babylon puede desarrollar algunas soluciones que sean altamente compatibles con estos proyectos, creando beneficios mutuos y eventualmente formando un ecosistema fuerte similar a Eigenlayer dentro de Ethereum.
Gestión de activos entre cadenas: el protocolo Babylon se puede utilizar para la gestión segura de activos entre cadenas. Al agregar marcas de tiempo a las transacciones entre cadenas, se garantiza la seguridad y transparencia de las transferencias de activos entre diferentes cadenas de bloques. Este mecanismo ayuda a prevenir gastos dobles y otros ataques entre cadenas.
Torre de Babel
La historia de la Torre de Babel se origina en Génesis 11:1-9 en la Biblia. Es una historia clásica de humanos que intentaron construir la Torre de Babel pero fueron frustrados por Dios. Esta historia simboliza la unidad humana y el propósito común. El protocolo Babylon tiene como objetivo construir una torre similar para varias cadenas de PoS, unificándolas bajo un mismo techo. En términos de narrativa, parece tan bueno como Eigenlayer, el defensor de Ethereum. Pero ¿cómo funciona en la práctica?
Hasta ahora, la red de prueba de Babylon ha proporcionado seguridad para 50 zonas de Cosmos a través del protocolo IBC. Además del ecosistema Cosmos, Babylon también integra varios protocolos LSD (derivados colateralizados líquidos), protocolos de interoperabilidad de cadena completa y protocolos del ecosistema Bitcoin. Sin embargo, cuando se trata de apostar, Babylon actualmente va por detrás de Eigenlayer, que puede reutilizar Stake y LSD dentro del ecosistema Ethereum. Pero a largo plazo, la gran cantidad de Bitcoin latente en carteras y protocolos aún no se ha despertado por completo, y esto es sólo la punta del iceberg de 1,3 billones de dólares. Babylon necesita formar una simbiosis benigna con todo el ecosistema BTC.
La única solución al dilema Ponzi
Como se mencionó anteriormente, tanto Eigenlayer como Babylon se están desarrollando rápidamente y las tendencias futuras indican que bloquearán una gran cantidad de activos centrales de blockchain. Incluso si los protocolos en sí son seguros, ¿las apuestas en múltiples niveles crearán una espiral de muerte para el ecosistema de apuestas, lo que conducirá a un colapso similar a otra subida de tipos de interés en Estados Unidos? Desde la transición de Ethereum a PoS y el surgimiento de Eigenlayer, la industria Stake actual ha experimentado una exuberancia irracional. Los proyectos a menudo atraen a usuarios con un alto TVL a través de enormes expectativas de lanzamiento aéreo y retornos escalonados. Un ETH puede pasar por apuestas nativas, LSD y LRT, con hasta cinco o seis pilas. Esta acumulación aumenta el riesgo, ya que los problemas en cualquier protocolo pueden afectar directamente a todos los protocolos involucrados, especialmente aquellos al final de la cadena de participación. ecosistema de bitcoins,
Sin embargo, vale la pena señalar que Eigenlayer y Babylon tratan fundamentalmente de dirigir el volante de las apuestas hacia una verdadera utilidad, creando una demanda real para compensar el riesgo. Entonces, si bien estos protocolos de “seguridad compartida” pueden exacerbar directa o indirectamente el mal comportamiento, también son la única manera de evitar retornos del esquema Ponzi de apuestas escalonadas. La pregunta más apremiante ahora es si la lógica empresarial de un protocolo de “seguridad compartida” es realmente viable.
Las necesidades reales son clave
En Web3, ya sea una cadena pública o un protocolo, la lógica subyacente a menudo implica hacer coincidir a compradores y vendedores para necesidades específicas. Al hacer esto, puede "ganar el mundo" porque la tecnología blockchain garantiza que el proceso de emparejamiento sea justo, auténtico y creíble. En teoría, los protocolos de seguridad compartidos podrían complementar el próspero ecosistema modular y de participación. Sin embargo, ¿la oferta superará con creces la demanda? Por el lado de la oferta, existen muchos proyectos y cadenas principales que pueden proporcionar seguridad modular. Desde el punto de vista de la demanda, es posible que las cadenas PoS establecidas no necesiten o no estén dispuestas a alquilar dichos valores por el bien de las apariencias, mientras que las nuevas cadenas PoS pueden tener dificultades para pagar los intereses generados por grandes cantidades de BTC y ETH. Dejemos que Eigenlayer y Babylon formen un circuito comercial cerrado, y los ingresos generados deben equilibrar los intereses generados por los tokens prometidos dentro del protocolo. Incluso si se logra este equilibrio y los ingresos superan con creces los pagos de intereses, aún podría provocar que estas nuevas cadenas y protocolos de PoS se agoten. Por lo tanto, será crucial cómo equilibrar el modelo económico, evitar las burbujas causadas por las expectativas de lanzamientos aéreos e impulsar la oferta y la demanda de manera saludable.
