Prólogo

En la era de la blockchain modular liderada por Ethereum, la prestación de servicios de seguridad a través de la integración de la capa de disponibilidad de datos (DA) no es más largo un concepto novedoso. Actualmente, el concepto de seguridad compartida introducido por el staking ofrece una nueva dimensión al espacio modular. Aprovecha el potencial del "oro y plata digital" para proporcionar seguridad desde Bitcoin o Ethereum a numerosos protocolos blockchain y cadenas públicas. Esta narrativa es bastante grandiosa, ya que no solo desbloquea la liquidez de activos por valor de billones de dólares, sino que también sirve como un elemento clave en futuras soluciones de escalado. Por ejemplo, las recientes recaudaciones masivas de fondos de $ 70 millones por el protocolo de participación de Bitcoin Babylon y $ 100 millones por el protocolo de reparticipación de Ethereum EigenLayer ilustran el fuerte respaldo de las firmas de capital de riesgo líderes para este sector.

Sin embargo, estos acontecimientos también han suscitado importantes preocupaciones. Si la modularidad es la solución definitiva para el escalado, y estos protocolos son componentes cruciales de esta solución, es probable que bloqueen cantidades masivas de BTC y ETH. Esto pone en tela de juicio la seguridad de los propios protocolos. ¿Se convertirá la compleja estratificación formada por numerosos protocolos LSD (Liquid Staking Derivados) y LRT (Capa 2 Rollup Tokens) en el mayor cisne negro del futuro de la cadena de bloques? ¿Es sólida su lógica comercial? Dado que ya hemos analizado EigenLayer en nuestros artículos anteriores, la siguiente discusión se centrará principalmente en Babylon para abordar estos problemas.

Extendiendo la seguridad Consenso

Bitcoin y Ethereum son, sin lugar a dudas, las cadenas de bloques públicas más valiosas en la actualidad. Su seguridad, descentralización y consenso de valores, acumulados a lo largo de muchos años, son las principales razones por las que siguen estando en la cúspide del mundo de la cadena de bloques. Estas son cualidades raras que otras cadenas heterogéneas encuentran difíciles de replicar. La idea central de la modularidad es "alquilar" estas cualidades a los necesitados. En el enfoque actual de modularidad, hay dos facciones principales:

La primera facción utiliza una capa 1 suficientemente segura (generalmente Ethereum) como las tres capas inferiores o parte de las capas funcionales para Rollups. Esta solución ofrece la mayor seguridad y legitimidad y puede absorber recursos del ecosistema de la cadena principal. Sin embargo, puede no ser particularmente amigable en términos de rendimiento y costo para Rollups específicos (cadenas de aplicación, cadenas de cola larga, etc.).

La segunda facción tiene como objetivo crear una existencia que esté cerca de la seguridad de Bitcoin y Ethereum pero con un mejor rendimiento de costos, como Celestia. Celestia logra esto mediante el uso de una arquitectura de función DA pura, minimizando los requisitos de hardware del nodo y los bajos costos de gas. Este enfoque simplificado busca crear una capa DA que coincida con la seguridad y la descentralización de Ethereum, al tiempo que ofrece un rendimiento sólido en el menor tiempo posible. La desventaja de este enfoque es que su seguridad y descentralización aún necesitan algún tiempo para desarrollarse por completo, y carece de legitimidad mientras está en competencia directa con Ethereum, líder al rechazo de la comunidad Ethereum.

Un tercer tipo en esta facción incluye a Babylon y EigenLayer. Utilizan el concepto central de Proof-of-Stake (POS) aprovechando el valor de los activos de Bitcoin o Ethereum para crear servicios de seguridad compartidos. En comparación con los dos primeros tipos, esta es una existencia más neutral. Su ventaja radica en heredar legitimidad y seguridad, al tiempo que proporciona más valor de utilidad a los activos de la cadena principal y ofrece una mayor flexibilidad.

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 hardware y electricidad masivos, mientras que PoS se basa en el valor de los activos apostados. Bitcoin en sí está respaldado por una red PoW extremadamente grande, lo que la convierte en la presencia más segura en todo el espacio blockchain. Sin embargo, como una cadena pública con un valor de mercado circulante de $ 1.39 billones, que representa la mitad del mercado de la cadena de bloques, 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 hiciera la transición 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 para lograr el consenso por defecto. Sin embargo, las nuevas cadenas heterogéneas a menudo no pueden atraer una participación sustancial de capital, lo que pone en duda su seguridad. En la era modular actual, las zonas Cosmos y varias soluciones de capa 2 pueden usar varias capas DA para compensar, pero esto a menudo se produce a costa de la autonomía. Para la mayoría de los mecanismos PoS antiguos o cadenas de consorcio, el uso de Ethereum o Celestia como capa DA también es generalmente poco práctico. El valor de Babylon radica en llenar este vacío mediante el uso de staking de BTC para proporcionar protección para las cadenas PoS. Así como la humanidad usó oro para respaldar el valor del papel moneda, BTC es adecuado para desempeñar este papel en el mundo blockchain.

De 0 a 1

Dar rienda suelta al "oro digital" siempre ha sido la narrativa más ambiciosa pero difícil de lograr en el espacio blockchain. Desde los primeros sidechains, Lightning Network y los tokens envueltos en puente hasta las runas y BTC Capa 2 actuales, cada solución tiene sus defectos inherentes. Si Babylon tiene como objetivo aprovechar la seguridad de Bitcoin, primero se deben descartar las soluciones centralizadas que introducen suposiciones de confianza de terceros. Entre las opciones restantes, Runes y Lightning Network (limitadas por un progreso de desarrollo extremadamente lento) actualmente solo tienen la capacidad de emisión de activos. Esto significa que Babylon necesita diseñar su propia "solución de escalado" para permitir el staking nativo de Bitcoin de 0 a 1.

Desglosando los elementos básicos actualmente utilizables por Bitcoin, son esencialmente los siguientes: 1. Modelo UTXO, 2. Marcas de tiempo, 3. Varios métodos de firma, 4. Códigos de operación básicos. Dada la limitada capacidad de programación y almacenamiento de datos de Bitcoin, la solución de Babylon se basa en el principio del minimalismo. En Bitcoin, solo se deben completar las funciones esenciales para los contratos de participación, lo que significa que el staking, el slashing, las recompensas y la recuperación de BTC se manejan en la cadena principal. Una vez que se logra este 0 a 1, las demandas más complejas pueden ser manejadas por la zona Cosmos. Sin embargo, sigue habiendo un problema crítico: ¿cómo registrar los datos de la cadena PoS en la cadena principal?

Remote Staking

UTXO (Unspent Transaction Outputs) es el modelo de transacción diseñado por Satoshi Nakamoto para Bitcoin. La idea central es extremadamente simple: las transacciones son simplemente fondos que entran y salen, por lo que todo el sistema de transacciones puede expresarse en términos de entradas y salidas. UTXO representa la parte de los fondos que ingresan pero no se gastan en su totalidad, por lo que permanecen como salidas de transacciones no gastadas (es decir, Bitcoin no pagado). Todo el libro mayor de Bitcoin es esencialmente una colección de UTXO, que registra el estado de cada UTXO para administrar la propiedad y la circulación de Bitcoin. Cada transacción gasta UTXO antiguos y genera otros nuevos. Debido a su potencial inherente de escalabilidad, UTXO se ha convertido naturalmente en el punto de partida para muchas soluciones de escalado nativas. Por ejemplo, el uso de UTXO y multisig para crear mecanismos de penalización y canales de estado para la Lightning Network, o la vinculación de UTXO para implementar tokens semifungibles (SFT) como inscripciones y runas, se derivan de este punto de partida crucial.

Babylon también necesita aprovechar UTXO para implementar contratos de staking (denominado staking remoto por Babylon, donde la seguridad de Bitcoin se transfiere de forma remota a las cadenas PoS a través de una capa intermediaria). La implementación del contrato se puede dividir en cuatro pasos, combinando inteligentemente los códigos de operación existentes:

Bloqueo de fondos

Los usuarios envían fondos a una dirección controlada por multisig. A través de OP_CTV (OP_CHECKTEMPLATEVERIFY, que permite crear plantillas de transacciones predefinidas que garantizan que las transacciones solo se puedan ejecutar de acuerdo con estructuras y condiciones específicas), el contrato puede especificar que estos fondos solo se pueden gastar bajo ciertas condiciones. Una vez que los fondos están bloqueados, se genera un nuevo UTXO, lo que indica que estos fondos han sido apostados.

Verificación de la condición

Al llamar 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 el UTXO solo se puede gastar después de un cierto tiempo relativo o número de bloques), se pueden implementar bloqueos de tiempo. Combinado con OP_CTV, esto puede lograr staking, unstaking (permitiendo que el staker gaste el UTXO bloqueado después de que se cumpla el período de staking) y slashing (forzando el gasto de UTXO a una dirección bloqueada si el staker actúa maliciosamente, haciéndolo no gastable, similar a una dirección de agujero negro).

Actualizaciones de estado

Cada vez que los usuarios hacen staking o retiran fondos apostados, implica crear y gastar UTXO. Las salidas de transacciones nuevas generan nuevos UTXO y los UTXO antiguos se marcan como gastados. De esta manera, cada transacción y movimiento de fondos se registra con precisión en la cadena de bloques, lo que garantiza la transparencia y la seguridad.

Distribución de recompensas

En función de la cantidad apostada y la duración de la apuesta, el contrato calcula las recompensas y las distribuye generando nuevos UTXO. Estas recompensas se pueden desbloquear y gastar a través de las condiciones del script una vez que se cumplen criterios específicos.

Timestamps

Después de establecer un contrato de staking nativo, es natural considerar el tema de registrar eventos históricos de cadenas externas. En el libro blanco de Satoshi Nakamoto, la cadena de bloques de Bitcoin introdujo un concepto de marcas de tiempo compatibles con PoW, proporcionando un orden cronológico irreversible para los eventos. En el caso de uso nativo de Bitcoin, estos eventos se refieren a varias transacciones ejecutadas en el libro mayor. Hoy en día, para mejorar la seguridad de otras cadenas PoS, Bitcoin también se puede usar para marcar el tiempo de eventos en cadenas de bloques externas. Cada vez que ocurre un evento de este tipo, desencadena una transacción enviada a los mineros, que luego la insertan en el libro mayor de Bitcoin, agregando así una marca de tiempo al evento. Estas marcas de tiempo pueden abordar varios problemas de seguridad de las cadenas de bloques. El concepto general de agregar marcas de tiempo a eventos en cadenas hijas en la cadena principal se conoce como "puntos de control", y las transacciones utilizadas para agregar marcas de tiempo se denominan transacciones de puntos de control. Específicamente, las marcas de tiempo en la cadena de bloques de Bitcoin tienen las siguientes características importantes:

• Formato de hora: Las marcas de tiempo registran el número de segundos desde el 1 de enero de 1970, 00:00:00 UTC, un formato conocido como hora Unix o hora POSIX.
• Propósito: El propósito principal de una marca de tiempo es marcar el tiempo de generación de bloques, ayudando a los nodos a determinar el orden de bloques y ayudando en el mecanismo de ajuste de dificultad de la red.
• Marcas de tiempo y ajuste de dificultad: La red Bitcoin ajusta la dificultad de minería aproximadamente cada dos semanas, o cada bloques de 2016. 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 bloques más recientes de 2016 para garantizar que se generen nuevos bloques aproximadamente cada 10 minutos.
• Comprobación de validez: Cuando un nodo recibe un nuevo bloque, verifica la marca de tiempo. La marca de tiempo de un nuevo bloque debe ser mayor que el tiempo medio de varios bloques anteriores y no debe exceder el tiempo de 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 asignar marcas de tiempo de Bitcoin a través de puntos de control de Babylon en bloques PoS, asegurando la precisión e inmutabilidad de la secuencia de tiempo. Este servidor actúa como la capa superior en toda la arquitectura de Babylon, sirviendo como la principal fuente de confianza.

Arquitectura de tres capas de Babilonia

Como se ilustra en el diagrama, la arquitectura general de Babilonia se puede dividir en tres capas: Bitcoin (que sirve como servidor de marca de tiempo), Babilonia (una Zona Cosmos que actúa como capa intermediario) y las cadenas PoS como capa de demanda. Babylon se refiere a los dos últimos como el Plano de Control (la propia Babilonia) y el Plano de Datos (varias cadenas de consumidores PoS).

Habiendo entendido la implementación básica sin confianza del protocolo, profundicemos en cómo Babilonia conecta los dos extremos usando la zona del Cosmos. Según la explicación detallada del Tse Lab de Stanford en Babylon, Babylon puede recibir flujos de puntos de control de múltiples cadenas PoS y fusionar estos puntos de control para publicar en Bitcoin. Mediante el uso de firmas agregadas de validadores de Babylon, el tamaño del punto de control se puede minimizar, y la frecuencia de estos puntos de control se controla permitiendo que los validadores de Babylon cambien solo una vez por época.

Los validadores de varias cadenas 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 las cadenas PoS detecten discrepancias, como si los validadores de Babylon crean un bloque no disponible verificado por Bitcoin y mienten sobre los puntos de control PoS contenidos en él. Los principales componentes del protocolo son los siguientes:

· Puntos de control: Solo el último bloque de una época de Babilonia es verificado por Bitcoin. Un punto de control consiste en el hash del bloque y una sola firma BLS agregada, correspondiente a las firmas de la mayoría de dos tercios de los validadores que firmaron el bloque para la finalidad. Los puestos de control de Babilonia también incluyen el número de época. Los bloques PoS pueden asignar marcas de tiempo de Bitcoin a través de los puntos de control de Babylon. Por ejemplo, los dos primeros bloques de PoS son puntos de control por bloques de Babylon, que a su vez son puntos de control por un bloque Bitcoin con t_3 de marca de tiempo. En consecuencia, a estos bloques de PoS se les asigna el t_3 de marca de tiempo Bitcoin.

· Cadenas PoS canónicas: Cuando se produce una fork de cadena PoS, la cadena con la marca de tiempo anterior se considera la cadena PoS canónica. Si dos bifurcaciones tienen la misma marca de tiempo, el empate se rompe a favor del bloque PoS con un punto de control anterior en Babylon.

· Reglas de retiro: Para retirar, los validadores envían una solicitud de retiro a la cadena PoS. El bloque de PoS que contiene la solicitud de retiro es luego punto de control por Babylon y, posteriormente, por Bitcoin, asignándole una marca de tiempo t_1. Una vez que el bloque Bitcoin con marca de tiempo t_1 alcanza una profundidad de k, el retiro se otorga en la cadena PoS. Si un validador con apuestas retiradas intenta un ataque de largo alcance, a los bloques de la cadena de ataque solo se les puede asignar una marca de tiempo posterior a t_1. Esto se debe a que una vez que el bloque Bitcoin con marca de tiempo t_1 alcanza una profundidad de k, no se puede revertir. Al observar el orden de estos puntos de control en Bitcoin, los clientes PoS pueden distinguir la cadena canónica de la cadena de ataque e ignorar esta última.

· Reglas de corte: Si los validadores no retiran sus apuestas al detectar un ataque, pueden ser cortados por tener bloques PoS conflictivos de doble firma. Los PoS validadores malintencionados saben que si esperan hasta después de que se apruebe su solicitud de retiro para lanzar un ataque de largo alcance, no pueden engañar a los clientes que pueden consultar Bitcoin para identificar la cadena canónica. Por lo tanto, pueden fork la cadena de PoS mientras asignan marcas de tiempo Bitcoin a los bloques de la cadena de PoS canónica. Estos PoS validadores, en colaboración con validadores maliciosos de Babylon y mineros Bitcoin, fork Babylon y Bitcoin reemplazar el bloque Bitcoin con t_2 de marca de tiempo con otro bloque con t_3 de marca de tiempo. En la vista posterior de los clientes PoS, esto cambiaría la cadena PoS canónica de la cadena superior a la cadena inferior. Aunque se trata de un ataque de seguridad exitoso, da lugar a la slashing de las participaciones de los PoS validadores maliciosos porque tienen bloques conflictivos con doble firma sin retirar sus participaciones.

· Reglas de pausa de PoS punto de control: PoS validadores deben pausar su cadena de PoS al observar un punto de control PoS no disponible en Babilonia. Un punto de control de PoS no disponible se define como el hash firmado por dos tercios del PoS validadores, que supuestamente corresponde a un bloque PoS que no se puede observar. Si no PoS validadores pausa la cadena de PoS al observar un punto de control no disponible, un atacante puede revelar una cadena de ataque que no estaba disponible anteriormente, cambiando la cadena canónica en vistas de cliente posteriores. Esto se debe a que el punto de control de la cadena de sombras revelada más tarde aparece antes en Babilonia. La regla de pausa anterior explica por qué requerimos que los hashes de bloque PoS enviados como puntos de control estén firmados por el conjunto de validadores PoS. Si estos puntos de control no estuvieran firmados, cualquier atacante podría enviar un hash arbitrario, afirmando que es el hash de un punto de control de bloque PoS no disponible en Babylon. PoS validadores tendría que detenerse en el puesto de control. Tenga en cuenta que crear una cadena de PoS no disponible es un desafío: requiere comprometer al menos dos tercios de la PoS validadores para firmar el bloque PoS sin proporcionar datos a validadores honestos. Sin embargo, en el ataque asumido anteriormente, el adversario malicioso pausa la cadena PoS sin comprometer un solo validador. Para evitar este tipo de ataques, exigimos que PoS puntos de control estén firmados por dos tercios de los PoS validadores. En consecuencia, no habrá puntos de control de PoS no disponibles en Babilonia a menos que dos tercios de la PoS validadores se vean comprometidos, lo cual es muy poco probable debido al costo de comprometer PoS validadores y no afecta a otras cadenas de PoS ni a la propia Babilonia.

· Reglas de pausa del punto de control de Babylon: Tanto los validadores de PoS como los de Babylon deben pausar la cadena de bloques al observar un punto de control de Babylon no disponible en Bitcoin. Un punto de control de Babylon no disponible se define como un hash con una firma BLS agregada de dos tercios de los validadores de Babylon, que supuestamente corresponde a un bloque de Babylon que no se puede observar. Si los validadores de Babylon no pausan la cadena de bloques de Babylon, un atacante puede revelar una cadena de Babylon previamente no disponible, cambiando la cadena canónica de Babylon en vistas posteriores del cliente. Del mismo modo, si no PoS validadores pausa la cadena de PoS, el atacante puede revelar una cadena de ataque PoS que no estaba disponible anteriormente y la cadena Babylon que no estaba disponible anteriormente, cambiando la cadena de PoS canónica en vistas de cliente posteriores. Esto se debe a que la profunda cadena de Babilonia revelada más tarde tiene una marca de tiempo anterior en Bitcoin e incluye puntos de control de la cadena de ataque PoS revelada más tarde. Similar a la regla 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 una firma BLS agregada que demuestre las firmas de dos tercios de los validadores de Babylon. Si los puntos de control de Babylon no estuvieran firmados, cualquier adversario podría enviar un hash arbitrario, afirmando que es el hash de un punto de control de bloque de Babylon no disponible en Bitcoin. PoS validadores y Babylon validadores tendrían que esperar a un puesto de control que no tuviera cadenas de Babylon o PoS no disponibles en su preimagen. Crear una cadena de Babylon no disponible requiere comprometer al menos dos tercios de los validadores de Babylon. Sin embargo, en el ataque asumido anteriormente, el adversario pausa todas las cadenas del sistema sin comprometer un solo validador Babylon o PoS. Para evitar este tipo de ataques, requerimos que los puntos de control de Babylon se demuestren mediante firmas agregadas; por lo tanto, no habrá puntos de control de Babylon no disponibles a menos que dos tercios de los validadores estén comprometidos, lo cual es muy poco probable debido al costo de comprometer a los validadores de Babylon. Pero en casos extremos, afectará a todas las cadenas PoS al obligarlas a pausar.

Capa propia en BTC

En términos de propósito, aunque Babylon es similar a Eigenlayer, está lejos de ser un simple "fork" de Eigenlayer. Dada la incapacidad actual de usar DA de forma nativa en la cadena principal de BTC, la presencia de Babilonia es bastante significativa. Este protocolo no solo brinda seguridad a las cadenas PoS externas, sino que también es crucial para revitalizar el ecosistema BTC internamente.

Casos de uso

Babylon presenta numerosos casos de uso potenciales, algunos de los cuales ya se han realizado o pueden tener oportunidades de realizarse en el futuro:

1. Reducción de los períodos de staking y mejora de la seguridad: Las cadenas PoS generalmente requieren consenso social (consenso entre la comunidad, los operadores de nodos y los validadores) para evitar ataques de largo alcance. Estos ataques implican reescribir el historial de la cadena de bloques para manipular los registros de transacciones o controlar la cadena. Los ataques de largo alcance son particularmente graves en los sistemas PoS porque, a diferencia de PoW, los sistemas PoS no requieren validadores para consumir recursos computacionales significativos. Un atacante puede reescribir el historial controlando las claves de los primeros stakers. Para garantizar la estabilidad y seguridad del consenso de la red blockchain, generalmente son necesarios períodos de participación largos. 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 incluir en el servidor 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 solo un día (equivalente a aproximadamente 100 bloques de BTC). Además, las cadenas PoS pueden tener doble seguridad a través del staking de tokens nativos y el staking de BTC.

• Interoperabilidad entre cadenas: A través del protocolo IBC, Babylon puede recibir datos de puntos de control de múltiples cadenas PoS, lo que permite cross-chain interoperabilidad. Esta interoperabilidad permite una comunicación fluida y el intercambio de datos entre diferentes cadenas de bloques, lo que mejora la eficiencia y la funcionalidad generales del ecosistema de cadenas de bloques.
• Integración del ecosistema BTC: La mayoría de los proyectos dentro del ecosistema BTC actual, incluidos Capa 2, LRT y DeFi, carecen de suficiente seguridad 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 podría desarrollar algunas soluciones altamente compatibles con estos proyectos, creando beneficios mutuos y eventualmente formando un ecosistema robusto 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 cross-chain. Al agregar marcas de tiempo a las transacciones cross-chain, garantiza la seguridad y transparencia de las transferencias de activos entre diferentes blockchains. Este mecanismo ayuda a prevenir el doble gasto y otros ataques cross-chain.

La Torre de Babel

La historia de la Torre de Babel proviene de la Biblia, Génesis 11:1-9, y es un relato clásico del intento de la humanidad de construir una torre para alcanzar los cielos, solo para ser frustrado por Dios. Esta historia simboliza la unidad humana y los objetivos compartidos. El protocolo de Babylon tiene como objetivo construir una torre similar para varias cadenas PoS, uniéndolas bajo un mismo techo. En términos de narrativa, no parece menos impresionante que Eigenlayer, el defensor de Ethereum. Pero, ¿cómo se mantiene en la práctica?

A partir de ahora, la red de prueba de Babylon ha proporcionado garantías de seguridad a 50 zonas Cosmos a través del protocolo IBC. Más allá del ecosistema Cosmos, Babylon se ha integrado con algunos protocolos LSD (Liquid Staking Derivados), protocolos de interoperabilidad omnicadena y protocolos de ecosistema Bitcoin. Sin embargo, en términos de staking, Babylon actualmente está detrás de Eigenlayer, que puede reutilizar staking y LSD dentro del ecosistema Ethereum. Sin embargo, en la larga carrera, la gran cantidad de BTC que se encuentra inactiva en billeteras y protocolos aún no se ha despertado por completo, lo que representa solo la punta del iceberg de $ 1.3 billones. Babylon necesita formar una simbiosis positiva con todo el ecosistema BTC.

La única solución al dilema del Staking Ponzi

Como se mencionó anteriormente, Eigenlayer y Babylon se están desarrollando rápidamente, y las tendencias futuras sugieren que bloquearán cantidades masivas de activos centrales de blockchain. Incluso si estos protocolos en sí mismos son seguros, ¿podrían las múltiples capas de staking crear una espiral de muerte para el ecosistema de staking, causando un desplome similar a otro aumento de las tasas de interés por parte de los EE. UU.? El sector actual de staking ha experimentado una exuberancia irracional desde la transición de Ethereum a PoS y la aparición de Eigenlayer. Los proyectos a menudo atraen a los usuarios con un alto TVL a través de expectativas masivas de airdrop y retornos en capas. Un ETH puede pasar por staking nativo, LSD y LRT, apilando hasta cinco o seis capas. Este apilamiento aumenta el riesgo, ya que un problema en cualquier protocolo puede afectar directamente a todos los protocolos involucrados, especialmente aquellos al final de la cadena de participación. El ecosistema BTC, con sus numerosas soluciones centralizadas, enfrentaría riesgos aún mayores si adopta este modelo.

Sin embargo, es importante tener en cuenta que Eigenlayer y Babylon tratan fundamentalmente de guiar el volante de replanteo hacia una utilidad genuina, creando una demanda real para compensar los riesgos. Por lo tanto, si bien estos protocolos de "seguridad compartida" pueden exacerbar directa o indirectamente las malas prácticas, también representan la única forma de escapar de los rendimientos similares a los de Ponzi del staking en capas. La cuestión más apremiante ahora es si la lógica comercial de los protocolos de "seguridad compartida" es realmente viable.

La demanda real es clave

En Web3, ya sea para cadenas públicas o protocolos, la lógica subyacente suele implicar coincidencia compradores y vendedores para una demanda concreta. Aquellos que hacen esto bien pueden "ganar el mundo", ya que la tecnología blockchain garantiza que el proceso de coincidencia sea justo, real y confiable. En teoría, los protocolos de seguridad compartidos pueden complementar el auge de los ecosistemas modulares y de staking. Sin embargo, ¿la oferta superará con creces la demanda? Por el lado de la oferta, hay muchos proyectos y cadenas principales capaces de proporcionar seguridad modular. Por el lado de la demanda, las cadenas PoS establecidas pueden no necesitar o ser reacias a alquilar dicha seguridad por el bien de la cara, mientras que las nuevas cadenas PoS pueden tener dificultades para pagar los intereses generados por grandes cantidades de BTC y ETH. Para que Eigenlayer y Babylon formen un circuito comercial cerrado, los ingresos generados deben equilibrar el interés generado por los tokens apostados dentro del protocolo. Incluso si se logra este equilibrio y los ingresos superan con creces el gasto por intereses, aún podría resultar en que estas nuevas cadenas y protocolos PoS se agoten. Por lo tanto, será crucial cómo equilibrar el modelo económico, evitar las burbujas alimentadas por las expectativas de lanzamientos aéreos e impulsar de manera saludable tanto la oferta como la demanda.

Acerca de YBB

YBB es un fondo web3 que se dedica a identificar proyectos que definan Web3 con la visión de crear un mejor hábitat en línea para todos los residentes de Internet. Fundada por un grupo de creyentes de blockchain que han participado activamente en esta industria desde 2013, YBB siempre está dispuesta a ayudar a los proyectos en etapa inicial a evolucionar de 0 a 1.Valoramos la innovación, la pasión autodidacta y los productos orientados al usuario, al tiempo que reconocemos el potencial de las criptomonedas y las aplicaciones de blockchain.

Sitio web | Twi: @YBBCapital

Referencias

1. Explicación detallada de cómo Babylon beneficia al ecosistema de Cosmos con la seguridad de Bitcoin: ChainCatcher Artículo
2. Comprensión profunda de Eigenlayer: ¿Salir Ethereum de la situación de "apilamiento"? HaoTianCryptoInsight Artículo
3. Conversación con el cofundador de Babylon, Fisher Yu: ¿Cómo desbloquear la liquidez de 21 millones de BTC a través del staking? ChainCatcher Artículo
4. Deuda triangular o inflación leve: una perspectiva alternativa sobre el replanteamiento: Weixin Artículo
5. Un vistazo a lo que he estado viendo en las criptomonedas últimamente: TheKnower Substack

Disclaimer:

1. Este artículo es una reimpresión de [Medium]. Todos los derechos de autor pertenecen al autor original [YBB]. Si hay objeciones a esta reimpresión, póngase en contacto con el equipo de Gate Learn, y ellos se encargarán de ello con prontitud.

2. Descargo de responsabilidad: Los puntos de vista y opiniones expresados en este artículo son únicamente los del autor y no constituyen ningún consejo de inversión.

3. Las traducciones del artículo a otros idiomas son realizadas por el equipo de Gate Learn. A menos que se mencione, está prohibido copiar, distribuir o plagiar los artículos traducidos.