1. Todos lo quieren, pocos pueden manejarlo

1.1 La Tierra de Oportunidades: Bitcoin

(Fuente: companiesmarketcap)

Bitcoin, creado en 2008 por un desarrollador anónimo, se ha convertido en un activo masivo, ocupando el séptimo lugar en capitalización de mercado entre todas las clases de activos. Ahora es reconocido no solo por instituciones financieras, sino incluso por el Presidente de los EE. UU. Actualmente, la capitalización de mercado de Bitcoin es similar a la de la plata. Teniendo en cuenta que la adopción de Bitcoin todavía es relativamente baja y que su capitalización de mercado es solo una décima parte de la del oro, su potencial de crecimiento futuro sigue siendo muy prometedor.

A pesar del crecimiento inmenso de Bitcoin como activo, todavía existe una limitación significativa: su nivel de utilización. Activos tradicionales como acciones y bonos pueden ser utilizados en una amplia gama de productos financieros, pero las aplicaciones financieras de Bitcoin siguen siendo muy limitadas, tanto técnicamente como prácticamente. Similar a los días de frontera del Oeste Americano, Bitcoin representa una tierra de oportunidad sin explotar.

1.2 Intentos de Utilizar BTC

Debido a su enorme capitalización de mercado, numerosas empresas y protocolos han buscado aprovechar Bitcoin para la creación de crédito adicional. Los principales intentos de utilizar BTC hasta ahora incluyen:

• Finanzas Centralizadas: Las instituciones financieras tradicionales ofrecen diversos productos financieros basados en Bitcoin. CME ofrece futuros y opciones de Bitcoin, Coinbase ofrece préstamos respaldados por BTC, y varias instituciones han lanzado ETFs basados en BTC para inversores.
• Puente de Custodia: Servicios como WBTC y cbBTC envuelven BTC de manera centralizada, permitiendo que se utilice en otras redes. Al depositar BTC con custodios como BitGo o Coinbase, los usuarios reciben una cantidad equivalente de WBTC o cbBTC emitida en la red de Ethereum.
• Bridging On-chain: Para eliminar la dependencia de custodios centralizados, varios protocolos han intentado enlazar de forma segura BTC con otras redes. Sin embargo, lograr un mecanismo de enlace de BTC completamente sin confianza sigue siendo altamente desafiante, ya que algún nivel de suposiciones de confianza es inevitable.
• Soluciones de escalabilidad: Los esfuerzos por utilizar BTC en cadenas laterales y soluciones de capa 2 de Bitcoin han aumentado recientemente. Sin embargo, estos enfoques aún implican suposiciones de confianza adicionales. El equipo de Taproot Wizards está trabajando en mitigar este problema utilizando OP_CAT.
• Stablecoins basadas en BTC: Protocolos como Yala y Avalon han surgido, emitiendo stablecoins respaldadas por BTC de manera similar a MakerDAO. Sin embargo, estas soluciones también enfrentan el problema fundamental de requerir suposiciones de confianza al conectar BTC.

Examinar estos intentos de utilizar BTC revela un desafío común: es difícil usar Bitcoin de manera nativa. Una de las mayores fortalezas de Bitcoin es su seguridad, pero si supuestos de confianza adicionales debilitan esta seguridad, crea una barrera de entrada significativa para los titulares de BTC. Esta es la razón principal por la que el nivel de utilización de Bitcoin sigue siendo relativamente bajo.

1.3 Babilonia: Utilización nativa de BTC

Este es donde @babylonlabs_iose centra. Babylon permite a los titulares de BTC apostar sus Bitcoin de forma nativa en la red de Bitcoin y participar en la validación de otros protocolos PoS, obteniendo recompensas adicionales.

Gracias a la ventaja de utilizar BTC sin suposiciones de confianza adicionales, Babilonia ha alcanzado rápidamente más de $5 mil millones en TVL. El TVL podría haber sido aún mayor si no hubiera límites de participación en BTC.

Pero espera, el lenguaje de scripting de Bitcoin no es Turing completo, lo que significa que no puede admitir fácilmente contratos inteligentes complejos. Entonces, ¿cómo logra Babilonia lograr esta funcionalidad? En este artículo, exploraremos los mecanismos específicos detrás de la operación de Babilonia.

2. Babilonia

Al igual que la construcción de la Torre de Babel, ¿podremos alguna vez alcanzar una verdadera utilización nativa de BTC?

2.1 Visión general de Babilonia

La misión de Babilonia es escalar Bitcoin para asegurar el mundo descentralizado. Si bien es ampliamente conocido como un protocolo de participación en BTC, Babilonia también ofrece servicios de marca de tiempo de Bitcoin, formando un conjunto de protocolos de intercambio de seguridad de BTC.

Babylon está compuesto por dos protocolos principales:

• Timestamping de Bitcoin: Esto permite a las cadenas de PoS hacer checkpoint de sus datos de bloque en la red de Bitcoin. Al hacerlo, las cadenas de PoS pueden mitigar ataques de largo alcance, reducir los períodos de desvinculación de participaciones, proteger transacciones críticas y beneficiarse de la resistencia a la censura de Bitcoin a nivel de red.
• Bitcoin Staking: Esto permite a los titulares de BTC congelar sus BTC de forma nativa en la red de Bitcoin y participar en la validación de otros protocolos de PoS, ganando recompensas adicionales en el proceso.

2.2 Arquitectura de Babilonia

(Fuente: Babilonia)

La arquitectura fundamental de Babilonia se ilustra en el diagrama anterior, con la Cadena de Babilonia, construida sobre el Cosmos SDK, en su núcleo. Además de la Cadena de Babilonia, varios programas periféricos facilitan el staking de BTC y la comunicación con Bitcoin y otras Zonas de Consumidores. Las Zonas de Consumidores se refieren a cadenas de PoS que registran puntos de control en la red de Bitcoin a través de Babilonia.

La cadena de Babilonia consta de varios módulos que realizan funciones esenciales dentro del ecosistema, incluida la gestión del conjunto de validadores, el seguimiento de los encabezados de bloque de Bitcoin, el envío de puntos de control a la red de Bitcoin y la gestión del conjunto activo de proveedores de finalidad relacionados con el staking de BTC. Para referencia, un proveedor de finalidad es similar a un operador de AVS en EigenLayer, lo que significa que participa en la validación de otros protocolos de PoS.

Además, Babylon ha implementado varios programas de apoyo para facilitar la comunicación fluida entre la red Bitcoin y la Cadena de Babylon:

• Vigilantes: Un conjunto de programas que actúa como un relé de datos entre Bitcoin y Babilonia.
• Monitores: Un conjunto de programas que garantiza la consistencia entre la Cadena de Babilonia y la red Bitcoin.

A través de este ecosistema, Babilonia permite a la industria cripto aprovechar la sólida seguridad y la profunda liquidez de Bitcoin. Ahora, exploremos en más detalle las dos características principales de Babilonia: el sellado de tiempo de Bitcoin y el staking de Bitcoin.

3. Cómo funciona el sellado de tiempo de Bitcoin

3.1 ¿Por qué es lenta la desvinculación de Stake?

Cualquiera que haya apostado fichas antes sabría que desbloquear normalmente requiere un período de espera de 1 a 2 semanas. Durante este tiempo, las fichas no se pueden utilizar ni generar intereses, lo que causa ineficiencias. Pero, ¿por qué se necesita un período de espera para desbloquear? ¿Por qué no permitir retiros instantáneos?

La razón más simple es la seguridad de la red. Si el desbloqueo fuera instantáneo, grandes cantidades de tokens podrían ser desbloqueados en respuesta a las fluctuaciones del mercado, debilitando significativamente la seguridad de la red. Sin embargo, más allá de la seguridad, hay otra razón fundamental: prevenir ataques de largo alcance.

3.2 Ataque de Largo Alcance

(Fuente: AP)

Un ataque de largo alcance se refiere a un ataque en el que los validadores maliciosos crean una nueva bifurcación a partir de bloques pasados, intentando reemplazar la cadena canónica actual. Si la cadena bifurcada maliciosa llega a ser tan larga o más larga que la cadena canónica, los nodos recién unidos en la red pueden confundirse sobre cuál es la cadena legítima, lo que puede generar problemas potenciales. Pero espera, ¿esto es siquiera posible?

En una red de PoW, un ataque de largo alcance es casi imposible. Para alcanzar la cadena canónica actual, los atacantes necesitarían recrear nuevos bloques del pasado superando la potencia informática de la red existente, lo cual es prácticamente inviable.

Del mismo modo, en una red PoS que funciona correctamente, este ataque también es imposible. Crear una nueva bifurcación requeriría que los validadores maliciosos firmaran múltiples bloques conflictivos, lo cual se considera doble firma, una violación del protocolo que resulta en penalizaciones de reducción.

Sin embargo, ¿qué pasaría si se permitiera desbloquear inmediatamente?

A diferencia de las redes PoW, las redes PoS no requieren una gran potencia computacional para generar bloques. Esto significa que si los validadores maliciosos deshacen su apuesta de los activos de la cadena existente y luego crean una nueva cadena bifurcada a partir de un bloque pasado donde sus claves de validador todavía eran válidas, podrían potencialmente ponerse al día con la cadena canónica actual. En este escenario, los nodos recién unidos a la red podrían tener dificultades para determinar cuál es la cadena legítima, lo que podría llevar a confusión y riesgos de seguridad.

(Fuente: Babilonia)

Si un ataque de largo alcance tiene éxito, los validadores maliciosos pueden aprovechar los mecanismos de puente para robar fondos. Por ejemplo, supongamos que un atacante malintencionado llamado John transfiere 1M de tokens RUG de la cadena RugPull a Osmosis y los intercambia por tokens OSMO. Esta transferencia ocurre a través de IBC, que funciona bloqueando los tokens RUG originales en la cadena RugPull mientras se acuña una cantidad equivalente de tokens RUG en la cadena de Osmosis.

(Fuente: Babilonia)

Si asumimos que John ejecuta con éxito un ataque a larga distancia en la cadena RugPull, puede omitir maliciosamente la transacción que bloqueó los tokens RUG para enviarlos a la cadena Osmosis en la nueva cadena bifurcada. Como resultado, John adquiriría efectivamente tokens OSMO de forma gratuita.

Para prevenir ataques de largo alcance, es necesario un período de desvinculación de apuesta de cierta duración. Los actores malintencionados no pueden ejecutar un ataque de largo alcance durante el período de desvinculación (si lo intentan, se enfrentarán a sanciones por recorte). Además, durante este período, los participantes de la red pueden llegar a un consenso social sobre qué cadena es la cadena canónica. Como resultado, incluso si ocurre un ataque de largo alcance más tarde, es poco probable que la cadena bifurcada maliciosa sea aceptada por la red.

3.3 Reduzcamos el tiempo de desvinculación de participación con la marca de tiempo de BTC

El período de desvinculación de la participación es un método efectivo para prevenir ataques de largo alcance, pero viene con algunas desventajas.

El primer problema es que depende del consenso social para contrarrestar los ataques. Si bien la comunicación fuera de la cadena entre los participantes durante un período lo suficientemente largo puede desempeñar un papel crucial, no es una solución infalible al 100%.

El segundo problema es que, como se mencionó anteriormente, un período de desbloqueo más largo afecta negativamente la experiencia del usuario y la liquidez.

Babilonia introduce una solución llamada Bitcoin Timestamping, que permite a las cadenas de PoS reducir significativamente los períodos de desbloqueo a solo unas pocas horas. Esto permite a las cadenas de PoS registrar datos de bloque de cadena canónicos en la red de Bitcoin.

Con la marca de tiempo, incluso si los validadores maliciosos intentan un ataque de largo alcance y afirman que su cadena bifurcada es la cadena canónica, su ataque no tendrá éxito, porque los datos originales de la cadena canónica ya están registrados de forma segura en la red de Bitcoin. Mientras la seguridad de Bitcoin permanezca intacta, el ataque está garantizado que fracasará. Dado que este enfoque elimina la necesidad de consenso social, permite una reducción drástica en el período de desvinculación requerido.

(Fuente: Babilonia)

Aquí, Bitcoin Timestamping se registra utilizando el OP_RETURN opcode en la red Bitcoin. OP_RETURN es una instrucción que permite almacenar hasta 80 bytes de datos arbitrarios en la red Bitcoin. A diferencia de las transacciones regulares de Bitcoin, OP_RETURN no se puede utilizar para transferencias de fondos y no genera UTXOs.

Una consideración clave es si todas las cadenas de PoS pueden crear directamente puntos de control en la red de Bitcoin. Los bloques de Bitcoin son pequeños en tamaño, tienen un tiempo de bloque de 10 minutos y OP_RETURN solo puede almacenar un máximo de 80 bytes de datos. Si numerosas cadenas de PoS enviaran transacciones de verificación de puntos de control con frecuencia, la red de Bitcoin no sería capaz de manejar la carga.

Para resolver este problema, Babilonia introduce la Cadena de Babilonia, que agrega puntos de control de múltiples cadenas PoS a través de IBC y luego envía un único punto de control agregado a la red de Bitcoin.

Un componente clave de este proceso es el Vigilante Relayer, una entidad responsable de leer puntos de control de un nodo de Babilonia, empaquetarlos en transacciones OP_RETURN y luego enviarlos a la red de Bitcoin. El sistema requiere al menos un Vigilante Relayer honesto y activo para funcionar correctamente.

(Fuente: Babilonia)

La marca de tiempo BTC se produce de la siguiente manera: las cadenas de PoS envían puntos de control que contienen información de bloques a la cadena de Babilonia. La cadena de Babilonia luego envía un punto de control de los bloques de Babilonia a la red Bitcoin en el bloque final de cada época.

(Fuente: Babilonia)

Incluso si ocurre un ataque de largo alcance, el punto de control de la cadena bifurcada maliciosa siempre tendrá una marca de tiempo posterior al punto de control de la cadena canónica. Esto significa que los participantes de la red pueden simplemente verificar el punto de control de la red Bitcoin para identificar fácilmente las bifurcaciones maliciosas. Dado que este enfoque elimina la necesidad de consenso social, el período de desvinculación de la participación puede reducirse de varias semanas a solo unas pocas horas.

3.4 Más que desvinculación de participación rápida

La marca de tiempo de Bitcoin de Babylon hace más que simplemente mejorar la UX y la eficiencia de liquidez al reducir los períodos de desbloqueo de las cadenas PoS, sino que también proporciona varios beneficios adicionales.

3.4.1 Lentitud en la Finalización de Transacciones Importantes

Al adoptar una finalidad lenta a través de Babilonia, las cadenas PoS pueden lograr un nivel de seguridad comparable al de Bitcoin. Cuando un bloque PoS que contiene una transacción específica se marca con una marca de tiempo en la red de Bitcoin y se confirma por seis bloques de Bitcoin, la transacción se vuelve irreversible, siempre y cuando la seguridad de Bitcoin permanezca intacta.

Este mecanismo es útil para procesar transacciones de alto valor, como compras de bienes raíces, donde la seguridad absoluta es necesaria. Además, para las nuevas zonas de Cosmos lanzadas, que pueden tener una seguridad más débil, implementar una finalidad lenta puede proporcionar una capa adicional de protección para el procesamiento seguro de transacciones.

3.4.2 Resistencia a la censura a nivel de Bitcoin

La marca de tiempo de Bitcoin también puede ayudar a restaurar la vivacidad en caso de un ataque de censura en una cadena de PoS. Para abordar esto, Babilonia introduce un concepto especial llamado modo de rollup.

En una cadena PoS tradicional, al menos dos tercios (2/3) de los validadores deben ser honestos para mantener la resistencia a la censura. Sin embargo, con el modo de rollup de Babilonia, solo la mitad (1/2) de los validadores deben ser honestos para lograr resistencia a la censura, mejorando significativamente la resistencia de la cadena contra los ataques.

(Fuente: Babilonia)

Si un usuario de la cadena PoS cree que una transacción específica está siendo censurada, puede enviar una queja de censura (la sección roja en el diagrama) a la cadena de Babilonia, iniciando el proceso de entrar en el modo de rollup. La queja de censura contiene el hash de la transacción censurada.

Si, después de seis confirmaciones de bloque Bitcoin, la transacción censurada sospechosa aún no ha sido incluida en la cadena de PoS, los validadores honestos enviarán sus opiniones sobre la cadena de PoS a Babilonia. Si, después de seis confirmaciones adicionales de bloque Bitcoin, no se detecta ningún punto de control relacionado con la transacción censurada en ningún bloque de Bitcoin, los validadores honestos y los usuarios entrarán en modo de rollup.

En el modo de rollup, cualquier validador puede proponer un paquete de transacciones de PoS, y si los validadores que poseen al menos la mitad (1/2) de la participación total firman el paquete, la transacción se finalizará en la red de Bitcoin, evitando efectivamente la censura.

4. Cómo funciona el staking de Bitcoin

4.1 Visión general del staking de Bitcoin

El sellado de tiempo de Bitcoin permite a las cadenas PoS aprovechar la seguridad de Bitcoin para reducir los períodos de desvinculación de la participación y mejorar la resistencia a la censura, pero esto solo utiliza parcialmente la seguridad de Bitcoin.

Más allá del sellado temporal de Bitcoin, Babilonia introduce el staking de Bitcoin, que implementa nativamente el staking de BTC utilizando el lenguaje de script de Bitcoin. Esto permite que otros protocolos de PoS se beneficien de la seguridad criptoeconómica de BTC apostado. El protocolo de staking está diseñado como un complemento modular, lo que lo hace fácilmente adaptable para varios protocolos de consenso de PoS.

Para los titulares de BTC, el Bitcoin Staking de Babilonia es una atractiva oportunidad de inversión, ya que pueden apostar BTC al nivel de seguridad de Bitcoin sin depender de entidades externas, al mismo tiempo que también obtienen recompensas de protocolos externos.

Definamos algunos términos clave:

• Los protocolos que aprovechan la seguridad criptoeconómica del BTC apostado a través de la Participación en Bitcoin de Babilonia se llaman BSNs (Bitcoin Secured Networks), análogos a @eigenlayerconcepto de AVS (Actively Validated Services) de ‘s.
• Las entidades que reciben BTC delegado de los validadores y participan en la validación de BSNs se llaman Proveedores de Finalidad, similar a los operadores AVS de EigenLayer.

Pero espera, a diferencia de Ethereum, la red de Bitcoin no es Turing completa, lo que dificulta la implementación de contratos de participación complejos. ¿Entonces, cómo logra Babilonia esto?

Vamos a explorar los detalles con un ejemplo del blog de Babilonia.

4.2 Cómo se Implementa el Contrato de Staking

4.2.1 Bloqueo

// Contrato V0: agregando una condición de bloqueo a la UTXO de apuesta de Alice

condición-1 (bloqueo): time_lock = 1000 & alice_public_key

Supongamos que Alice apuesta BTC y también actúa como Proveedor de Finalidad. Para implementar el staking de BTC, se requiere un mecanismo para bloquear BTC. Esto se logra configurando una de las condiciones de gasto de UTXO para que solo Alice (la propietaria de BTC) pueda retirar los fondos después de un cierto período de tiempo (time_lock = 1000) usando su alice_public_key.

4.2.2 Slashing

// Contrato V1: agregando slashing ingenuo

condición-1 (bloqueo): time_lock = 1000 & alice_public_key; OR

condición-2 (slashing): alice_eots_public_key

Uno de los componentes esenciales que se deben implementar en el staking es el slashing. Si ocurre una acción maliciosa, se puede aplicar un mecanismo de incentivos quemando los BTC apostados. Para lograr esto, se establece una segunda condición de gasto de UTXO para que se pueda producir el slashing si alguien tiene la clave EOTS de Alice.

Aquí, EOTS (Extractable One-Time Signature) es una firma implementada utilizando firmas Schnorr, que fue introducida después de la actualización Taproot de Bitcoin. En pocas palabras, es un algoritmo que asegura que si un actor malicioso firma dos bloques diferentes al mismo nivel usando la misma clave, su clave secreta se revela públicamente.

Al observar esto con más detalle, una firma Schnorr consta de una clave privada x, una clave pública P=xG y un nonce aleatorio k. El proceso de firma es el siguiente: se genera un nonce aleatorio k y se calcula el valor público R=kG a partir del nonce. Luego, se calcula un valor hash e a partir del mensaje M y R, y se calcula el valor de la firma s basado en el nonce y e, donde s = k + ex. La firma Schnorr final consta de (s, R).

La idea principal de EOTS es que si la misma clave se usa dos veces para firmar, la clave privada queda expuesta. Si Alice firma dos mensajes diferentes usando el mismo nonce k, entonces la primera firma es s1= k + e_1x y la segunda firma es s2= k + e_2x. Dado que s1, s2, e1, e2 son públicamente conocidos, cualquiera puede resolver la clave privada x de Alice usando la ecuación x=(s1 - s2)/(e1 - e2).

Usando este mecanismo, si Alice firma maliciosamente dos mensajes diferentes usando la misma clave EOTS durante el proceso de validación de BSN, cualquiera que detecte esto puede extraer la clave secreta EOTS de Alice. Una vez revelada la clave secreta EOTS, el atacante puede robar los BTC apostados de Alice o quemar los BTC apostados de Alice como penalización.

4.2.3 Aplicación de la Quema

// Contrato V2

condición-1 (bloqueo): time_lock = 1000 & alice_public_key; OR

condición-2 (slashing): alice_eots_public_key & covenant_committee_quorum

// Transacción de reducción V0

entradas:

• input-1: el UTXO de staking, gastado usando la condición-2 anterior

Salidas:

• output-1: valor = 0.99 Bitcoin, propietario = 0000...0000

// Pre-aprobación V0: aplicación de quemado

// El comité del pacto pre-firma la tx de reducción anterior como su preaprobación

Dado que previamente hemos discutido las condiciones bajo las cuales ocurre el corte, ahora examinemos cómo se aplica en realidad el corte. Aplicar el corte es crucial porque, si Alice participa en un comportamiento malicioso, podría intentar retirar su BTC antes de que alguien detecte la mala conducta, extraiga su clave secreta EOTS y queme su BTC.

Para evitar esto, el slashing debe implementarse de manera que transfiera de manera forzosa el BTC a una dirección predefinida de quemado (0000…0000). Para lograr esto, la segunda condición de gasto de UTXO incluye un Quórum del Comité del Pacto. El Comité del Pacto es responsable de verificar si el slashing es legítimo. Al incorporar un esquema de firma múltiple (M-de-N), el sistema asegura que Alice no pueda retirar unilateralmente su BTC a su propia billetera antes de que se ejecute el slashing.

La ventaja de este enfoque es que, siempre y cuando Alice se comporte honestamente, su firma EOTS nunca se expone, lo que significa que el Comité del Pacto no puede confiscar sus fondos. Por lo tanto, Alice no necesita confiar en el Comité del Pacto, ya que no pueden actuar en su contra a menos que ella participe en un comportamiento malicioso.

4.2.4 Delegación Segura

// Contrato V3: habilitando la delegación segura

condición-1 (bloqueo): time_lock = 1000 & alice_public_key; OR

condición-2 (slash): alice_public_key & validator_eots_public_key & covenant_committee_quorum

// Transacción de penalización V0

entradas:

• input-1: el UTXO de staking, gastado usando la condición-2 anterior

salidas:

• salida-1: valor = 0.99 Bitcoin, propietario = 0000...0000

// Preaprobación V1

// Alice pre-firma la transacción de reducción como su aprobación previa.

El comité del pacto pre-firma la transacción de reducción como su preaprobación.

Alice puede apostar BTC directamente y participar en validar otros protocolos de PoS como proveedor de finalidad. Sin embargo, la mayoría de los usuarios elegirán delegar su participación en BTC.

Para implementar esto, agregar la clave EOTS del validador a la segunda condición asegura que si el validador participa en un comportamiento malicioso, el BTC de Alice puede ser quemado. Sin embargo, el problema aquí es que si el validador colude con el comité del pacto, podrían robar el BTC de Alice, obligando a Alice a confiar en el validador.

Una solución simple a este problema es incluir también la clave pública de Alice en la segunda condición. De esta manera, quemar BTC también requeriría la firma de Alice, evitando el robo no autorizado de BTC.

Para lograr esto, Alice pre-firma una transacción que establece que "si ocurre un slashing, BTC debe ser enviado a una dirección de quemado." En este caso, si el validador actúa maliciosamente y su clave EOTS es expuesta, y si el comité de convenios ejecuta una firma múltiple, los BTC serán enviados a la dirección de quemado, haciendo cumplir el proceso de slashing.

4.2.5 Prevención de Ataques Maliciosos con la Aplicación de Castigos Atómicos

/ Contrato V3

Condición-1 (bloqueo): time_lock = 1000 y alice_public_key; O

condición-2 (slashing): alice_public_key & validator_eots_public_key & covenant_committee_quorum

// Slashing transaction V0

entradas:

• entrada-1: el UTXO de staking, gastado usando la condición-2 anterior

salidas:

• output-1: valor = 0.99 Bitcoin, propietario = 0000...0000

Aprobación previa V2: aplicación de la barra atómica cuando se delega

La preaprobación de Alice es una firma de adaptador de la transacción de reducción de recompensa

// se generó usando la clave pública EOTS del validador.

// El comité del pacto pre-firma la tx de recorte como su preaprobación.

¿Qué sucede si un validador malicioso se dirige solo a stakers específicos para hacer slashing? Para evitar esto, Babylon introduce las firmas de adaptador.

Alice cifra su firma utilizando la clave pública EOTS del validador como una firma de adaptador. Si el validador intenta penalizar solo a Alice, debe usar su clave privada EOTS. Debido a la naturaleza de las Firmas de Adaptador, esto resultaría en la exposición de la clave privada EOTS del validador, eliminando cualquier incentivo para que los validadores participen en un comportamiento malicioso.

4.2.6 Implementación de Penalización Parcial

// Contrato V3

condición-1 (bloqueo): time_lock = 1000 & alice_public_key; OR

condición-2 (slashing): alice_public_key & validator_eots_public_key & covenant_committee_quorum

Transacción de reducción V1: habilitar la reducción parcial

entradas:

• input-1: el UTXO de staking, gastado usando la condición-2 anterior

salidas:

• output-1: value = 0.09 Bitcoin, owner = 0.09 Bitcoin, propietario = 0000...0000

• output-2: valor = 0.9 Bitcoin,

condiciones:

• Condición-1: time_lock = 500 y alice_public_key

// Preaprobación V2

La aprobación previa de Alice es una firma del adaptador de la tx de corte

// se generó usando la clave pública EOTS del validador.

El comité del pacto pre-firma la transacción de recorte como su preaprobación.

¿Pero no crees que quemar todos los Bitcoin en caso de reducción es demasiado extremo? Para abordar esto, solo se puede quemar una parte de los Bitcoin (por ejemplo, quemar solo el 10% mientras se devuelve el 90% restante después de un cierto período). Esto se puede implementar dividiendo las salidas de la transacción de reducción en dos, como se describe arriba.

4.2.7 ¡Reinvertir más!

// Contrato V4: Habilitar el restakeo

condición-1 (bloqueo): time_lock = 1000 & alice_public_key; OR

condición-2 (corte): alice_public_key & cualquier firma de la lista[validator_eots_public_key] & covenant_committee_quorum

El BTC delegado de Alice puede participar en la validación de múltiples protocolos PoS, no solo uno solo. Si un validador participa en la validación de diferentes protocolos PoS utilizando la misma clave EOTS, cualquier fuga en un lugar podría afectar a los otros sistemas. Por lo tanto, los proveedores de finalidad de Babylon deben usar diferentes claves EOTS para diferentes sistemas PoS, y se introduce una lista de claves EOTS en la segunda condición.

4.3 Resumen

A diferencia de las redes PoS como Ethereum o Solana, la red de Bitcoin opera en PoW, por lo que el concepto de staking no existe inherentemente. Sin embargo, Babylon ha implementado las funciones de bloqueo, corte y delegación de BTC necesarias para apostar a través de las características de UTXO, el lenguaje de scripting de Bitcoin y varios algoritmos de firma. Esto permite a los titulares de BTC obtener ganancias adicionales de forma nativa utilizando BTC, sin necesidad de puentes o servicios de custodia.

5. Liberando el Potencial de BTC al Mundo Descentralizado

Aparte de la Lightning Network, ningún otro protocolo hereda completamente la seguridad de la red Bitcoin. Sin embargo, al igual que la red Bitcoin, la funcionalidad de la Lightning Network es bastante limitada y es demasiado valiosa para renunciar a la robusta seguridad y la enorme liquidez de Bitcoin.

Babylon ha permitido el uso de la seguridad de Bitcoin de dos formas diferentes a través del Estampado de Tiempo de Bitcoin y el Staking de Bitcoin. El primero utiliza Bitcoin como servidor de marca de tiempo para evitar reversiones de transacciones o bifurcaciones maliciosas, mientras que el último aprovecha la poderosa liquidez de BTC como seguridad cripto-económica, permitiendo a los titulares de BTC obtener ganancias adicionales de manera nativa.

Actualmente, aproximadamente 55,000 BTC están depositados en Babylon, lo cual está en línea con un límite de depósito establecido por Babylon. Alrededor del 3.9% del suministro total de ETH se vuelve a apostar en EigenLayer. Teniendo esto en cuenta, aunque los titulares de BTC pueden ser conservadores en cuanto a la utilización de BTC, el potencial de crecimiento de Babylon, con solo alrededor del 0.2% del suministro total de BTC actualmente en juego, merece ser considerado.

Renuncia:

1. Este artículo es una reimpresión de [100y.eth]. Todos los derechos de autor pertenecen al autor original [100y.eth]. Si hay objeciones a esta reimpresión, por favor póngase en contacto con el Gate Learn equipo, y lo manejarán con prontitud.
2. Descargo de responsabilidad: Las opiniones expresadas en este artículo son únicamente las del autor y no constituyen ningún consejo de inversión.
3. El equipo de Gate Learn realiza traducciones del artículo a otros idiomas. Queda prohibido copiar, distribuir o plagiar los artículos traducidos a menos que se mencione.