Desglose de Babylon: ¿Cómo liberar el valor de seguridad de Bitcoin?

Autor: YBB Capital Investigador Zeke

Prefacio

En la era modular liderada por Ethereum, brindar servicios de seguridad a través de la capa de DA (disponibilidad de datos) ya no es algo nuevo. La idea de compartir seguridad que trae el Staking (apuesta) en la actualidad proporciona un nuevo dimensionamiento modular, es decir, aprovechar el potencial del ‘oro y la plata digital’ para brindar seguridad a numerosos protocolos y blockchains provenientes de Bitcoin o Ethereum. Desde un punto de vista narrativo, se podría decir que es bastante grandioso. No solo libera la liquidez de miles de millones de dólares en capitalización de mercado, sino que también es clave para el futuro camino de escalabilidad. Tomemos como ejemplo los recientes protocolos de apuesta de Bitcoin Babylon y el protocolo de ReStaking de Ethereum EigenLayer, que obtuvieron financiamiento masivo de 70 millones de dólares y 100 millones de dólares respectivamente. No es difícil ver que los principales inversores de capital de riesgo están muy interesados en esta área.

Pero con la duda viene también una gran cantidad de críticas. Si la modularidad es el final de la escalabilidad, ambos serán clave para bloquear grandes cantidades de BTC y ETH. ¿Vale la pena cuestionar la seguridad del protocolo en sí? ¿El loco ‘juego de muñecas rusas’ formado por muchos protocolos LSD y LRT será el mayor cisne negro en el futuro de la cadena de bloques? ¿Es lógico desde un punto de vista comercial? Dado que hemos analizado EigenLayer en artículos anteriores, en este artículo nos centraremos principalmente en Babylon para discutir los problemas mencionados anteriormente.

Extender el consenso de seguridad

El desarrollo más valioso en el mundo de la cadena de bloques debe ser Bitcoin y Ethereum. La seguridad, la descentralización y el consenso de valor que se han acumulado durante muchos años son los núcleos clave que aseguran que ambas puedan permanecer en la cima de la cadena pública durante muchos años. También es una característica escasa que es difícil de replicar en otras cadenas heterogéneas y la idea central del pensamiento modular es alquilar estas características a los demandantes. En la fase actual del pensamiento modular, se divide principalmente en dos facciones:

• La primera opción es utilizar una capa 1 (generalmente Ethereum) lo suficientemente segura como capa inferior o capa de funciones parciales para Rollups. Este enfoque ofrece la máxima seguridad, legitimidad y capacidad para incorporar recursos del ecosistema de la cadena principal. Sin embargo, para Rollups específicos (como cadenas de aplicaciones, cadenas de cola larga, etc.), la capacidad de rendimiento y los costos no son particularmente amigables.
• La segunda opción es crear otra entidad con seguridad similar a la de Bitcoin y Ethereum, pero con un mejor rendimiento y coste, como Celestia, que utiliza una arquitectura pura de funciones DA, reduce al máximo los requisitos de hardware de los nodos y tiene un bajo coste de gas. Este enfoque simplifica el proceso para crear una capa DA que sea tan segura y descentralizada como Ethereum, pero con un rendimiento más potente en el menor tiempo posible. La desventaja de esta solución es que la seguridad y la descentralización necesitan más tiempo para mejorar, y carece de legitimidad y compite directamente con Ethereum, lo que la ha llevado a ser rechazada por la comunidad de Ethereum.

Y otra clase en esta facción es Babylon y Eigenlayer, que a través de la idea central de PoS (Prueba de participación), utilizan el valor de los activos de Bitcoin o Ethereum para crear servicios de seguridad compartidos. En comparación con los dos anteriores, es una presencia más neutral. Su ventaja radica en heredar la ortodoxia y la seguridad, al tiempo que otorga más valor de utilidad a los activos de la cadena principal, y es más flexible.

El potencial del oro digital

Independientemente de la lógica subyacente de cualquier mecanismo de consenso, la seguridad de la cadena de bloques depende en gran medida de cuántos recursos la respaldan. Las cadenas de trabajo (PoW) requieren una gran cantidad de hardware y energía, mientras que las cadenas de participación (PoS) dependen del valor de los activos en juego. Bitcoin en sí mismo está respaldado por una red de potencia computacional muy poderosa de PoW, lo que lo convierte en la entidad más segura de toda la cadena de bloques. Sin embargo, como una cadena pública que tiene una capitalización de mercado de 1.39 billones de dólares, su utilidad se limita principalmente a las transacciones y al pago de comisiones de gas.

Sin embargo, para la otra mitad del mundo de la cadena de bloques, especialmente después de la actualización de Ethereum Shanghai para convertirse en PoS, se puede decir que la mayoría de las cadenas públicas utilizan por defecto diferentes arquitecturas de PoS para lograr consenso. Sin embargo, debido a que las nuevas cadenas heterogéneas en sí mismas no pueden atraer grandes apuestas de capital, su seguridad plantea muchas dudas. En la actual era modular, aunque las zonas de Cosmos y varias capas 2 pueden usar varias capas de DA para compensar, también pierden autonomía. Para la mayoría de las antiguas cadenas públicas o cadenas de consorcio con mecanismos POS, es prácticamente imposible utilizar Ethereum o Celestia como DA, y el valor de Babylon radica precisamente en cubrir esta brecha, permitiendo que BTC se apueste para proteger las cadenas PoS. Al igual que en el pasado, los seres humanos usaban el oro para respaldar el valor del papel moneda, BTC es realmente adecuado para desempeñar este papel en el mundo de la cadena de bloques.

De cero a uno

La liberación del “oro digital” ha sido siempre la narrativa más ambiciosa y difícil de lograr en la cadena de bloques. Desde las primeras soluciones de sidechain, Lighting Network, envoltura de tokens y ahora los sistemas de runas y capa 2 de BTC, se puede decir que todas estas soluciones tienen ciertas deficiencias inherentes. Si Babylon quiere mantener la seguridad de Bitcoin, naturalmente debe descartar primero las soluciones centralizadas que implican la introducción de terceros de confianza. De las soluciones restantes, las capacidades actuales de runas y Lighting Network (limitadas por el lento progreso del desarrollo) se limitan principalmente a la emisión de activos. Esto significa que Babylon necesita diseñar su propio “plan de escalado” para permitir la participación nativa de Bitcoin de 0 a 1.

Desglosar algunos de los elementos básicos disponibles en Bitcoin en realidad se reduce a: 1. El modelo UTXO, 2. Marca de tiempo, 3. Varios métodos de firma, 4. Códigos de operación básicos. La solución propuesta por Babylon se basa en la limitada capacidad de programación y carga de datos de Bitcoin. Siguiendo el principio de minimización, solo se requiere realizar las funciones necesarias para contratos de participación en Bitcoin, es decir, el staking de BTC, el slashing, las recompensas, la recuperación, etc., se realizan en la cadena principal. Una vez que se haya completado esta transición del 0 al 1, las partes con requisitos más complejos serán manejadas por la zona Cosmos. Sin embargo, aquí todavía existe un problema crucial: ¿cómo se registra los datos de la cadena PoS en la cadena principal?

Stake remoto (Remote Staking)

UTXO (modelo de salida de transacción no gastada, Unspent Transaction Outputs) es un modelo de transacción diseñado por Satoshi Nakamoto para Bitcoin, cuya idea principal es muy simple. Las transacciones son simplemente la entrada y salida de fondos, por lo que todo el sistema de transacciones se puede expresar en dos formas: entrada (Input) y salida (Output). UTXO se refiere a los fondos que entran, pero no se gastan en su totalidad, lo que queda es la salida de transacción no gastada (es decir, Bitcoin no pagado). El libro mayor de Bitcoin en realidad es una colección de UTXO, gestionando la propiedad y circulación de Bitcoin registrando el estado de cada UTXO. Cada vez que se realiza una transacción, se gastará un UTXO antiguo y se generará uno nuevo. Debido a sus propiedades que tienen cierta posibilidad de ser escalables, naturalmente se convierte en el punto de partida para muchas ideas de soluciones nativas de escalabilidad. Por ejemplo, el uso de UTXO y firmas múltiples para crear mecanismos de multas y el estado del canal en la red Lightning, o vincular UTXO para implementar inscripciones y runas de tokens semi-fungibles (SFT). Todo se basa en este punto de partida clave para hacerlo realidad.

Y Babylon naturalmente también requiere UTXO para implementar contratos de stake (Babylon se refiere a stake remoto, es decir, la seguridad de BTC se transfiere a la cadena PoS a través de una capa intermedia remota), al mismo tiempo, en términos de pensamiento, combina hábilmente los códigos de operación existentes. De hecho, los pasos concretos para implementar el contrato se pueden descomponer en las siguientes cuatro etapas:

• Bloquear fondos

El usuario envía fondos a una dirección controlada por firma múltiple. A través de OP_CTV (OP_CHECKTEMPLATEVERIFY, que permite crear plantillas de transacciones predefinidas para garantizar que las transacciones solo se puedan ejecutar según una estructura y condiciones específicas), el contrato puede especificar que los fondos solo se pueden gastar cuando se cumplan ciertas condiciones. Después de bloquear los fondos, se genera una nueva UTXO que representa que estos fondos han sido stakeados;

• Verificación de condiciones

Llamar a OP_CSV (OP_CHECKSEQUENCEVERIFY le permite establecer un bloqueo de tiempo relativo, basado en el número de serie de la transacción, lo que significa que UTXO solo se puede gastar después de un cierto tiempo relativo o Bloquear) para garantizar que los fondos no se puedan retirar dentro de un cierto período de tiempo. Combinado con el OP_CTV mencionado anteriormente, es posible lograr stake, stake (si se cumple el tiempo stake, el stake puede gastar el UTXO bloqueado), slashing (Cortar, cuando el stake es malo, el UTXO se gastará a la fuerza en el DIRECCIÓN bloqueado y se limitará al estado de no gasto, similar a Dirección de quema);

• Actualización de estado

Cada vez que un usuario realiza una apuesta o retira fondos apostados, implica la creación y el gasto de UTXO. Las nuevas salidas de transacciones generarán nuevos UTXO, mientras que los antiguos UTXO se marcarán como gastados. De esta manera, cada transacción y flujo de fondos se registran con precisión en la cadena de bloques, garantizando transparencia y seguridad;

• Distribución de ingresos

Según la cantidad y el tiempo de la apuesta, el contrato calculará las recompensas ganadas y las asignará mediante la generación de nuevas UTXO. Estas recompensas se pueden desbloquear y gastar mediante condiciones de script después de cumplir ciertos requisitos.

Marca de tiempo

Después de tener un contrato de stake nativo, es natural pensar en el problema del registro de eventos históricos de cadenas externas. En la White Paper de Satoshi Nakamoto, Bitcoin Cadena de bloques introdujo un concepto de Marca de tiempo impulsado por PoW, un mecanismo que proporciona una cronología irreversible de los acontecimientos. En el caso de uso nativo de Bitcoin, estos eventos se refieren a las diversas transacciones realizadas 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, se activa una transacción enviada al minero, el minero luego se inserta en el libro mayor de Bitcoin, agregando una marca de tiempo al evento. Estas marcas de tiempo se pueden utilizar para abordar diversos problemas de seguridad de la cadena de bloques. El concepto general de eventos de marca de tiempo en una cadena hija en la cadena principal on-chain se denomina “punto de control”, mientras que las transacciones utilizadas para agregar marcas de tiempo se denominan transacciones de punto de control. En concreto, el Marca de tiempo del Bitcoin Cadena de bloques tiene las siguientes características importantes:

1. Formato de tiempo: El sello de tiempo registra la cantidad de segundos desde el 1 de enero de 1970 00:00:00 UTC, este formato se conoce como sello de tiempo de Unix o tiempo POSIX;
2. Función: La función principal del sello de tiempo es identificar 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;
3. Marca de tiempo y ajuste de dificultad: La red de Bitcoin realiza un ajuste de dificultad cada 2016 bloques (aproximadamente cada dos semanas). La marca de tiempo juega un papel crucial en este proceso, ya que la red ajusta la dificultad de minería en función del tiempo total de generación de los últimos 2016 bloques, para que la velocidad de generación de nuevos bloques se acerque a uno cada 10 minutos;
4. Validación: Cuando un nodo recibe un nuevo bloque, verifica el sello temporal. El sello temporal de un nuevo bloque debe ser mayor que la mediana de los sellos temporales de varios bloques anteriores y no puede exceder los 120 minutos de tiempo de red (es decir, 2 horas en el futuro).

El servidor de marcas de tiempo es un nuevo lenguaje original definido por Babylon, que asigna marcas de tiempo de Bitcoin a través de los puntos de control de Babylon en bloques de PoS para garantizar la precisión de la secuencia temporal y prevenir la manipulación. Este servidor es la fuente central de confianza en toda la arquitectura de Babylon.

La arquitectura de tres capas de Babylon

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 una zona de Cosmos), como capa intermedia, y la capa de demanda de cadena PoS. Babylon se refiere a los últimos dos como Control Plane (plano de control, es decir, Babylon en sí mismo) y Data Plane (plano de demanda de datos, es decir, varias cadenas de consumo de PoS).

Una vez entendida la forma básica en que el protocolo va sin confianza, veamos cómo Babylon utiliza Cosmos zone para conectar ambos extremos. Según la explicación detallada de Babylon por parte del Laboratorio Tse de Stanford “1”, Babylon puede recibir flujos de puntos de control de múltiples cadenas PoS y fusionar estos puntos de control para publicarlos en Bitcoin. Mediante la firma agregada de los validadores de Babylon, se puede minimizar el tamaño de los puntos de control y controlar la frecuencia de estos puntos de control al permitir que los validadores de Babylon cambien solo una vez en cada Epoch (época).

Los validadores de cada cadena PoS descargan bloques de Babylon y observan si su punto de control PoS está incluido en el bloque de Babylon verificado por Bitcoin. Esto permite a la cadena PoS detectar diferencias, por ejemplo, si los validadores de Babylon crean un bloque no válido verificado por Bitcoin y mienten sobre el punto de control PoS incluido en el bloque no válido. Los principales componentes que conforman el protocolo son los siguientes:

• Punto de control: Solo se verifica el último bloque de la época de Babilonia en Bitcoin. El punto de control está compuesto por el hash del bloque y una firma BLS agregada única correspondiente a la firma del conjunto de validadores de 2/3 que firmaron el bloque para su confirmación final. El punto de control de Babilonia también incluye el número de época. Los bloques de PoS pueden asignar la marca de tiempo del bloque de Bitcoin mediante el punto de control de Babilonia. Por ejemplo, los dos primeros bloques de PoS tienen el punto de control establecido en el bloque de Babilonia, y el bloque de Babilonia tiene el punto de control establecido en el bloque de Bitcoin con la marca de tiempo t_3. Por lo tanto, estos bloques de PoS se les asigna la marca de tiempo de Bitcoin t_3.

• Norma de la cadena PoS: Cuando hay un fork en la cadena PoS, se considera como la cadena PoS normativa aquella con el sello de tiempo más temprano. Si dos forks tienen el mismo sello de tiempo, se rompe el empate a favor de los bloques PoS con el checkpoint más temprano en Babylon.

• Reglas de retiro: Para realizar un retiro, el validador envía una solicitud de retiro a la cadena PoS. El bloque PoS que contiene la solicitud de retiro es verificado por Babylon y luego por Bitcoin, y se asigna una marca de tiempo t_1. Una vez que la profundidad del bloque de Bitcoin con marca de tiempo t_1 alcanza k, se otorga el retiro en la cadena PoS. En este momento, si los validadores que han extraído el stake realizan un ataque a larga distancia, los bloques en la cadena de ataque solo pueden tener una marca de tiempo de Bitcoin posterior a t_1. Esto se debe a que una vez que el bloque de Bitcoin con marca de tiempo t_1 alcanza una profundidad de k, no se puede retroceder. Luego, observando el orden de estos puntos de verificación en Bitcoin, el cliente de PoS puede distinguir entre la cadena canónica y la cadena de ataque, y luego puede ignorar la cadena de ataque.

• Reglas de confiscación: si un validador no retira su participación después de detectar un ataque, se puede confiscar a los validadores que tengan bloques de prueba de participación (PoS) con conflictos de firma doble. Los validadores maliciosos de PoS saben que si esperan a que se apruebe una solicitud de retiro antes de llevar a cabo un ataque de seguridad a largo plazo, no podrán engañar al cliente y el cliente podrá ver el Bitcoin para identificar la cadena correcta. Por lo tanto, es posible que bifurquen la cadena de PoS al asignar un sello de tiempo de Bitcoin en los bloques de la cadena de PoS correcta. Estos validadores de PoS colaboran con el validador malicioso de Babylon y los mineros de Bitcoin para bifurcar Babylon y Bitcoin y reemplazar un bloque de Bitcoin con un sello de tiempo t_3 en lugar de un sello de tiempo t_2. A los clientes de PoS posteriores les parecerá que la cadena de PoS correcta ha cambiado de la parte superior a la inferior. Aunque es un ataque de seguridad exitoso, conduce a la confiscación de los derechos de participación de los validadores maliciosos de PoS, ya que tienen bloques con conflictos de firma doble pero aún no han retirado su participación.

• Regla de detención de puntos de control PoS no disponibles: los validadores de PoS deben detener su cadena PoS cuando observan un punto de control PoS no disponible en Babylon. Aquí, un punto de control PoS no disponible es un hash firmado por 2/3 de los validadores de PoS, que se supone que corresponde a un bloque PoS no observable. Si los validadores de PoS no detienen la cadena PoS al observar un punto de control no disponible, un atacante puede revelar una cadena de ataque anteriormente no disponible y cambiar la cadena canónica en vistas de clientes posteriores. Esto se debe a que los puntos de control de la cadena de sombra que se muestran más tarde aparecen en las primeras etapas de Babylon. La regla de detención anterior revela por qué requerimos que los hash de bloques PoS enviados como puntos de control estén firmados por un conjunto de validadores de PoS. Si estos puntos de control no están firmados, cualquier atacante puede enviar cualquier hash y afirmar que es el hash del punto de control del bloque PoS no disponible en Babylon. Luego, los validadores de PoS tendrán que detener el punto de control. Tenga en cuenta que crear una cadena PoS no disponible es difícil: se requiere que al menos 2/3 de los validadores de PoS sean atacados para que completen el bloque PoS con una firma, pero no proporcionen datos a los validadores honestos. Sin embargo, en el ataque hipotético anterior, el oponente malintencionado detuvo la cadena PoS sin atacar a ningún validador. Para evitar este tipo de ataques, requerimos que los puntos de control PoS sean validados por 2/3 de los validadores de PoS. Por lo tanto, solo hay puntos de control PoS no disponibles en Babylon si el atacante controla efectivamente 2/3 de los validadores de PoS. Debido al costo de atacar a los validadores de PoS, este tipo de ataque es extremadamente improbable y no afectará otras cadenas PoS ni a Babylon en sí mismo.
• Reglas de pausa de los puntos de control no disponibles de Babylon: los validadores de PoS y Babylon deben pausar la cadena de bloques cuando observen puntos de control de Babylon no disponibles en Bitcoin. Aquí, un punto de control de Babylon no disponible es un hash de la firma BLS agregada con 2/3 de los validadores de Babylon, que se supone que corresponde a un bloque de Babylon que no se puede observar. Si los validadores de Babylon no detienen la cadena de bloques de Babylon, un atacante puede revelar una cadena de Babylon previamente no disponible, lo que cambiaría la cadena de Babylon especificada en la vista del cliente posterior. De manera similar, si los validadores de PoS no detienen la cadena de PoS, un atacante puede revelar una cadena de ataque de PoS previamente no disponible y una cadena de Babylon previamente no disponible, lo que especificaría la cadena de PoS en la vista del cliente posterior. Esto se debe a que la cadena de Babylon oscura revelada posteriormente tiene una marca de tiempo anterior en Bitcoin y contiene un punto de control de la cadena de ataque de PoS revelada posteriormente. Al igual que con las reglas de pausa del punto de control de PoS no disponible, las reglas anteriores revelan por qué requerimos que el hash del bloque de Babylon enviado como punto de control esté firmado con una firma BLS agregada para demostrar la firma de los 2/3 de los validadores de Babylon. Si el punto de control de Babylon no tiene firma, cualquier adversario puede enviar cualquier hash y afirmar que es el hash del punto de control del bloque de Babylon no disponible en Bitcoin. Luego, tanto los validadores de PoS como los validadores de Babylon tendrían que esperar un punto de control sin ninguna cadena de Babylon o PoS no disponible en su preimagen. Crear una cadena de Babylon no disponible requiere comprometer al menos 2/3 de los validadores de Babylon. Sin embargo, en el ataque supuesto anteriormente, el atacante detuvo todas las cadenas en el sistema sin comprometer ningún validador individual de Babylon o PoS. Para evitar este tipo de ataque, requerimos que los puntos de control de Babylon estén probados con una firma agregada, por lo que solo hay puntos de control de Babylon no disponibles cuando hay daño a los 2/3 de los validadores. Dado el costo de comprometer los validadores de Babylon, este ataque de disponibilidad de datos es extremadamente improbable. Pero en casos extremos, afectaría a todas las cadenas de PoS al forzarlas a detenerse.

Eigenlayer en BTC

Aunque Babilonia no es diferente de Eigenlayer en términos de propósito, Babylon no es de ninguna manera una simple fork de “Eigenlayer”. En la situación actual en la que BTC cadena principal DA no se puede usar de forma nativa, la existencia de Babilonia tiene mucho sentido. Además de aportar seguridad a la cadena PoS externa, este protocolo también es particularmente importante para la revitalización del ecosistema BTC.

Caso de uso

Hay muchos casos de uso posibles en Babylon, a continuación se muestran algunos casos de uso que ya se han implementado o que pueden implementarse en el futuro:

1. Reducir el período de stake y aumentar la seguridad: Las cadenas PoS suelen requerir consenso social (entre la comunidad, operadores de nodos y validadores) para prevenir ataques a larga distancia, que consisten en atacar la cadena reescribiendo su historia para cambiar registros de transacciones o tomar control de la cadena. Este tipo de ataque es especialmente grave en sistemas PoS, ya que a diferencia de PoW, los validadores que participan en el consenso no necesitan consumir una gran cantidad de recursos computacionales, por lo que un atacante puede reescribir la historia controlando las claves de los primeros stakers. Entonces, para garantizar la estabilidad y seguridad del consenso de la red de la cadena de bloques, un período de stake prolongado es esencial, como el período de desbloqueo de Cosmos que requiere 21 días. Sin embargo, a través de Babylon, los eventos históricos de la cadena PoS se pueden agregar al servidor de marcas de tiempo de BTC, lo que permite utilizar BTC como fuente de confianza en lugar del consenso social. Así, el período de desbloqueo se puede reducir a solo 1 día (es decir, después de aproximadamente 100 bloques de BTC). Además, la cadena PoS puede tener una doble protección de stake nativa de token y de BTC en este momento.

2. Interacción cross-chain: a través del Protocolo de comunicación entre Blockchains (IBC), Babylon puede obtener datos de checkpoint de varios PoS chains, logrando así una interacción cross-chain. Esta interoperabilidad permite una comunicación sin fisuras y un intercambio de datos entre diferentes blockchains, mejorando la eficiencia y funcionalidad del ecosistema blockchain en general;

3. Integración en el ecosistema de BTC: La mayoría de los proyectos en el ecosistema actual de BTC aún no tienen suficiente seguridad, ya sea en Layer2, LRT o DeFi, en su mayoría dependen de suposiciones de confianza de terceros. Estas direcciones de protocolos también albergan una gran cantidad de BTC, y en el futuro tal vez puedan colisionar con Babylon para encontrar soluciones complementarias y alimentarse mutuamente, formando finalmente un ecosistema poderoso similar a Eigenlayer en Ethereum.

4. Gestión de activos cross-chain: El protocolo de Babylon se puede utilizar para gestionar de forma segura los activos cross-chain. Al agregar marcas de tiempo a las transacciones cross-chain, se garantiza la seguridad y transparencia de los activos al transferirse entre diferentes blockchains. Este mecanismo ayuda a prevenir el doble gasto y otros ataques cross-chain.

Torre de Babel

La historia de la Torre de Babel proviene de Génesis 11:1-9 en la Biblia, es una historia clásica sobre el intento de los humanos de construir una torre que llegue hasta el cielo, pero que finalmente es detenida por Dios. Su significado simboliza la unidad y los objetivos comunes de la humanidad. También es un posible significado oculto del Protocolo Babylon, un proyecto que tiene como objetivo construir una torre de Babel para varias cadenas de PoS y unirlas. En términos narrativos, parece no ser inferior al defensor de Ethereum, Eigenlayer, pero ¿cuál es la situación real?

Hasta ahora, la red de prueba de Babylon ha proporcionado seguridad a 50 zonas de Cosmos a través del protocolo IBC. Además de Cosmos, Babylon también ha colaborado con algunos protocolos de liquidez y stake, protocolos de interoperabilidad completa de la cadena y protocolos de la ecología de Bitcoin para su integración. Por otro lado, en términos de stake, Babylon aún se queda atrás en comparación con Eigenlayer en cuanto a la reutilización de stake y LSD en la ecología de Ethereum. Sin embargo, a largo plazo, el BTC dormido en muchas billeteras y protocolos aún no ha sido completamente despertado, por lo que solo estamos viendo la punta del iceberg de los 13 billones de dólares. En este momento, Babylon todavía necesita formar una complementariedad positiva con toda la ecología de BTC.

La única solución de los muñecas rusas de Pampers

Como se mencionó anteriormente, Eigenlayer y Babylon están creciendo rápidamente, y según la tendencia actual, ambos protocolos bloquearán una gran cantidad de activos principales de blockchain en el futuro. Aunque la seguridad de estos dos protocolos en sí no es un problema, ¿la complejidad de las trampas múltiples llevará a la espiral descendente de todo el ecosistema de stake y causará una caída comparable a la subida de tasas de interés en Estados Unidos? La pista de stake actualmente ha experimentado un período de prosperidad irracional y prolongada después de la transición de Ethereum a PoS y la aparición de Eigenlayer. Para obtener un TVL más alto, los proyectos a menudo lanzan numerosas expectativas de airdrop y beneficios de trampas para atraer a los usuarios. Un ETH puede ser atrapado en stake nativo, luego en LSD, luego en LRT, e incluso puede ser atrapado 5 o 6 veces. Naturalmente, esto generará muchos problemas de riesgo debido a la complejidad de las trampas. Si uno de los protocolos tiene un problema, afectará directamente a todos los protocolos en las trampas (especialmente los protocolos de stake que están en la parte final de la estructura de trampas). Además, el ecosistema de BTC tiene muchas soluciones centralizadas, y copiar estas soluciones conlleva aún más riesgos. Sin embargo, es importante destacar que Eigenlayer y Babylon están guiando la rueda de stake hacia un valor real y práctico, y ambos están creando una oferta y demanda real para contrarrestar este riesgo. Por lo tanto, aunque la existencia del protocolo de ‘seguridad compartida’ indirecta o directamente promueve el aumento de prácticas deshonestas, es la única solución para escapar de los beneficios colaterales de las trampas de stake. El problema principal ahora es si la lógica comercial del protocolo de ‘seguridad compartida’ es verdaderamente sólida.

La verdadera oferta y demanda es clave

En Web3, ya sea una cadena pública o un protocolo, su lógica subyacente a menudo se basa en la “coincidencia” de compradores y vendedores con ciertas necesidades. El casamentero correcto puede obtener el “mundo”, y la cadena de bloques en sí solo hace que este emparejamiento sea justo, real y creíble. Teóricamente, los protocolos de seguridad compartidos pueden complementar el próspero ecosistema modular y de estaca actual. Pero si lo piensas bien, ¿esta oferta superará con creces la demanda? largo cadena principal Por otro lado, es posible que la antigua cadena de PoS no necesite o no alquile dicha garantía en aras de la apariencia, y ya sea que la nueva cadena de PoS pueda pagar por el Interés generado por el BTC y el ETH, la lógica comercial de Eigenlayer y Babylon debe formar un circuito cerrado, y al menos los ingresos que deben obtenerse deben equilibrarse con los Interés generados por el stake Token en el protocolo. E incluso si se puede lograr este equilibrio, e incluso los beneficios superan con creces el gasto de interés, en este caso, habrá una chupasangre de nuevos PoS y protocolos. Por lo tanto, cómo sopesar el modelo económico, no caer en la caída en la burbuja del desarrollo esperado de Airdrop, e impulsar de manera más saludable los lados de la oferta y la demanda será la máxima prioridad.

Referencia

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

2. Comprensión profunda de Eigenlayer: ¿dejar que Ethereum rompa la situación de la “muñeca anidada”? :_source=búsqueda-publicación

3. Conversación con Babylon co-fundador Fisher Yu: ¿Cómo desbloquear la liquidez de 21 millones de BTC a través del stake?

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

5. Un vistazo a lo que he estado viendo en cripto últimamente: