Introducción

BOB es un L2 Híbrido único que está diseñado para combinar la seguridad de Bitcoin con la programabilidad de Ethereum. Las L2 híbridas heredan la seguridad de Bitcoin, como la red más segura y descentralizada. La seguridad de Bitcoin se utiliza para crear puentes de confianza minimizada con Bitcoin, Ethereum y otras L1. Como resultado, la L2 híbrida no dependerá de puentes de terceros para la interoperabilidad y resuelve el problema de la liquidez fragmentada de la multicadena BTC.

Al fusionar la seguridad y el capital de Bitcoin con la innovación y versatilidad DeFi de Ethereum, BOB situará a Bitcoin en el corazón de DeFi, desbloqueando nuevos casos de uso y billones en liquidez. Esto convertirá a BOB en el hogar ideal para Bitcoin DeFi: el lugar mejor y más seguro para obtener rendimiento de su Bitcoin.

En 2024, publicamos el libro blanco Hybrid L2, en el que presentamos la visión híbrida y el diseño de alto nivel para la L2 híbrida de BOB, así como la hoja de ruta en 3 fases para actualizar BOB de ETH L2 a L2 híbrida.

En este artículo, esbozamos cómo BOB alcanzará la Fase 2: Un rollup ETH con finalidad Bitcoin y un puente BTC alimentado por BitVM. Como parte de esta actualización, BOB alcanzará las siguientes cinco nuevas propiedades:

  1. Validez del estado mediante pruebas ZK: Los bloques BOB se verifican criptográficamente y son probadamente correctos para evitar fallos de seguridad. Esto hace que la secuenciación de transacciones sea fiable, permitiendo la descentralización del secuenciador, y mejora los tiempos de finalización.
  2. Finalidad a través de la estaca Bitcoin: BOB tiene una única cadena canónica a través de cualquier puente nativo, impuesta por la finalidad de Bitcoin a través de la apuesta de BTC. Si los Proveedores de Finalidad (PF) firman cadenas competidoras, su participación en BTC se reducirá drásticamente.
  3. Puente Bitcoin nativo vía BitVM: BOB tendrá un puente Bitcoin nativo basado en el diseño BitVM2 de coautoría.
  4. Retiradas rápidas: Utilizando pruebas de validez y FPs, las retiradas de BOB a Bitcoin y Ethereum tardarán como mucho unas horas.
  5. Disponibilidad híbrida de datos: Los usuarios de BOB pueden incluir transacciones en BOB enviando una transacción en Bitcoin mainnet. Esto permite realizar retiradas de vuelta a Bitcoin sin que el secuenciador pueda censurar las transacciones.

‍

Bloques de construcción de la Fase 2

En la Fase 1, BOB lanzó su mainnet como una OP Stack rollup en Ethereum, soportando activos BTC de Ethereum (wBTC, SolvBTC, LBTC, tBTC, ...). BOB seguirá utilizando blobs EIP-4844 de Ethereum como DA y soportará el puente a Ethereum a través de los contratos puente estándar de OP.

En la Fase 2, BOB introduce tres bloques de construcción para añadir validez de estado ("ZK rollup"), finalidad Bitcoin y un puente BTC nativo.

  1. Pruebas de validez: Utilizando SNARKs sobre propuestas de estado BOB, cualquier tercero, cliente ligero o cadena externa puede verificar criptográficamente que las propuestas de estado BOB se han creado correctamente. Las pruebas de validez se publican y verifican en Ethereum. Esto garantiza que el secuenciador de BOB no puede producir bloques no válidos y convierte a BOB en un rollup de validez (a veces denominado "rollup ZK"). Las pruebas de validez también forman la base de los puentes nativos tanto para Bitcoin (a través de BitVM) como para Ethereum.
  2. Proveedores de Finalidad (FPs) apostados en BTC: BOB introduce FPs apostados en BTC, impulsados por Babylon. Los FPs apuestan BTC en Bitcoin y firman las propuestas de estado de BOB. Si los PF firman más de una versión de la cadena BOB, su BTC es recortado en Bitcoin (las claves privadas se filtran, lea más aquí). El corte por equivocación introduce un alto coste económico por intentar bifurcar la cadena BOB, ofreciendo mayores garantías de finalidad. Esta propiedad desempeña un papel crítico en el diseño híbrido L2, ya que garantiza el funcionamiento coherente de los puentes nativos BTC y ETH. Mientras que un secuenciador corrupto no puede crear bloques BOB inválidos (debido a las pruebas de validez), podría crear dos versiones válidas pero conflictivas de la cadena BOB (por ejemplo, que contengan un doble gasto) e intentar crear inconsistencia a través de los puentes BTC y ETH. La finalidad BTC-staked evita esto imponiendo una única versión canónica de BOB, verificada tanto en Bitcoin como en Ethereum.
  3. BitVM: BitVM es un mecanismo para ejecutar programas arbitrarios en Bitcoin de una manera optimista: la ejecución ocurre fuera de la cadena pero en caso de fallos, las disputas se resuelven y aplican en la cadena. Utilizamos BitVM para crear un puente de confianza minimizada entre Bitcoin y BOB. Específicamente, creamos un puente cliente ligero bidireccional: BOB ya puede verificar los depósitos en Bitcoin, BitVM nos permite verificar las retiradas en BOB y asegurar el procesamiento correcto en la cadena principal de Bitcoin. De este modo, verificamos la prueba SNARK sobre el estado de BOB así como la finalidad de BTC utilizando el mecanismo a prueba de fraude de BitVM.

‍

El diseño del BOB Hybrid L2

Ahora utilizamos los tres componentes básicos para crear la primera L2 híbrida de la historia:

  1. Validez de Rollup y Bitcoin Finality: Combinando las Pruebas de Validez y los PFs apostados por BTC, el BOB Híbrido L2 permite la seguridad de las transacciones y una rápida finalidad asegurada por BTC. Los PF se comprometen a que el estado BOB sea válido presentando una prueba de validez y proporcionando firmas sobre las propuestas de estado BOB, ponderadas por su participación en BTC.
  2. Puente Bitcoin nativo: Aprovechando las Validity Proofs, BTC-Staked FPs y BitVM, BOB añade un puente Bitcoin nativo. En BitVM, los operadores reclaman BTC a las instancias de BitVM mediante una compleja combinación de varias pruebas de la operación del puente y la finalización del estado de BOB.
  3. Puente y liquidación nativos de Ethereum: Integrando los Validity Proofs y los FPs BTC-Staked, los proponentes de Ethereum nativo afirman que BOB es válido y finalizado por FPs para completar las retiradas de los usuarios a Ethereum.

Validez del rollup y finalidad de Bitcoin

El secuenciador BOB produce bloques cada 2 segundos. Después de que se haya creado un cierto número de bloques BOB, el estado de BOB se finaliza - similar a un punto de control. Para ello, el secuenciador BOB genera una prueba de validez SNARK de BOB, incluyendo todos los bloques producidos desde el último punto de control/prueba. Esta prueba verifica criptográficamente que todas las transacciones procesadas son válidas.

El secuenciador envía el hash de la propuesta de estado, la firma y la prueba de validez a los PF que han apostado BTC. Los FPs deben haber apostado BTC en Bitcoin para ser FPs BOB y recibir a cambio parte de los honorarios del secuenciador como recompensa por su apuesta. Consideramos que una propuesta de estado BOB es definitiva una vez que ha sido firmada por al menos ⅔ de los BTC apostados. Además, el compromiso firmado con el estado BOB se comprueba periódicamente en Bitcoin. Después de 100 bloques Bitcoin, el punto de control se considera finalizado.

Esta combinación de prueba de validez y finalidad de Bitcoin se utiliza después para verificar y ejecutar correctamente los depósitos y retiradas de los puentes nativos de Bitcoin y Ethereum.

‍

Puente Bitcoin nativo

En BitVM, los denominados operadores facilitan a los usuarios la entrada y salida de BTC en BOB. Los operadores y los usuarios crean una instancia BitVM para cada depósito en el que el usuario bloquea una cantidad de BTC, y recibe bobBTC en BOB. Cuando un usuario inicia una retirada, un operador primero le envía BTC desde su propio monedero (adelantando el BTC) y luego reclama el BTC del depósito BitVM. El operador sólo puede reclamar los BTC de BitVM si puede demostrar que (1) ha proporcionado BTC de su propio bolsillo a un usuario que realiza una retirada y (2) que la solicitud de retirada correspondiente (que quema bobBTC) ha finalizado. Este proceso es optimista: el operador inicia el proceso de reclamación de BTC (en forma de SNARK), declarando que ha procesado correctamente la solicitud de retirada, y puede ser impugnado por cualquier usuario observador durante una ventana de tiempo predefinida ("periodo de impugnación").

Si es retado, el operador y el retador verifican una pequeña parte del programa verificador SNARK sobre Bitcoin en Bitcoin script. Si el retador demuestra con éxito que el operador está haciendo trampas, el BTC permanece en la instancia BitVM, y el operador es eliminado del puente. Si el operador era honesto, recibe el BTC de la instancia BitVM, y el retador es eliminado.

‍

‍

Para BOB específicamente, el operador hace la siguiente afirmación para una instancia BitVM: Combinan la transacción Bitcoin de retirada (= la transacción PegOut) con la prueba de que el BTC puenteado en BOB se quemó en un bloque finalizado, es decir, un bloque BOB que forma parte de una propuesta de estado finalizado. También prueban que la transacción PegOut y la referencia del punto de control BOB (como parte del punto de control del estado BOB firmado por los creadores de BTC a Bitcoin) en Bitcoin están en la misma cadena.

Para obtener información más detallada sobre BitVM, las diferencias entre los posibles enfoques de diseño y las últimas actualizaciones de progreso, consulte nuestro Informe sobre BitVM.

‍

Puente y liquidación nativos de Ethereum

Hay dos tipos de rollups populares en Ethereum: Rollups optimistas y de validez. En los rollups optimistas, las propuestas de estado regulares pueden ser impugnadas durante un periodo de tiempo predefinido. Si una propuesta de estado no se impugna con éxito, se considera finalizada. En los rollups de validez, una propuesta de estado va acompañada de una prueba ZK que garantiza la validez del estado. La prueba se verifica en Ethereum y, si es válida, el estado se da por finalizado inmediatamente.

Como parte de la Fase 2, BOB se convertirá en un rollup de validez. Esto garantiza que el mismo estado finalizado utilizado para BitVM se utilice también para Ethereum. La prueba de validez de BOB es diferente a la de otros rollups de validez. Combina dos pruebas: (1) la validez del bloque BOB previniendo fallos de seguridad y (2) una prueba de que los FPs atestiguan la cadena canónica de BOB. La prueba sobre los FPs incluye la presencia ⅔ o más de FPs apostados en BTC, un punto de verificación de las firmas de los FPs en Bitcoin, y que el punto de verificación tiene al menos 100 confirmaciones en Bitcoin.

Podemos finalizar con frecuencia el estado de BOB en Ethereum enviando esta prueba de validez combinada. Esto, a su vez, reduce el tiempo de retirada a Ethereum del estándar actual de 7 días de un rollup optimista a tan solo unas horas, según el estándar para rollups de validez.

‍

Disponibilidad de datos híbridos

Por diseño, los usuarios pueden incluir una transacción en BOB enviando una transacción en Ethereum, protegiéndolos contra la censura del secuenciador. Combinado con pruebas de validez y liquidaciones en Ethereum abiertas a cualquiera, los usuarios pueden forzar la retirada de sus activos de vuelta a Ethereum en situaciones de emergencia.

Recientemente BOB introdujo el novedoso concepto de Disponibilidad Híbrida de Datos, donde Bitcoin se añade al pipeline de derivación de un rollup de ETH. De forma similar a cómo los usuarios pueden enviar transacciones arbitrarias junto a un depósito en el contrato OptimismPortal en Ethereum, permitimos a los usuarios enviar transacciones arbitrarias a BOB en Bitcoin. El principal caso de uso para esto es incluir transacciones de retirada en BOB a Bitcoin si el secuenciador debe estar fuera de línea o censurando usuarios en la L2.

En el post completo, explicamos cómo añadiendo Bitcoin al proceso de derivación se consigue la resistencia a la censura de Bitcoin para las transacciones L2.

‍

Perspectivas para la fase 3: seguridad total de Bitcoin

Si Bitcoin añade funcionalidad para verificar pruebas de validez de forma nativa en Bitcoin script, BOB puede establecerse directamente en Bitcoin con total seguridad Bitcoin. Esto representa el estado ideal de la Fase 3: seguridad completa de Bitcoin que es demostrable a través de un cliente ligero de Bitcoin a cualquier otra cadena. Significa que BOB liquida en Bitcoin y la finalización (de puentes) en otras cadenas se hace verificando Bitcoin. Es una suposición de confianza razonable: si Bitcoin falla, probablemente todas las demás cadenas fallarán también.

En ausencia de una bifurcación de Bitcoin que permita verificadores ZK en la cadena, BOB tendrá que aprovechar la verificación optimista a través de BitVM. Lograr rollups optimistas en Bitcoin sin suposiciones de confianza adicionales requiere utilizar la cadena principal de Bitcoin como capa de disponibilidad de datos. A día de hoy, los costes de DA de Bitcoin son onerosos(véase el informe Galaxy) y suponen un reto en términos económicos.

Como resultado, para completar la transición a la Fase 3, BOB debe alcanzar una escala suficiente en términos de usuarios activos, de manera que incurrir en tasas adicionales de disponibilidad de datos no incremente las tasas de transacción más allá de las de las L2 de Ethereum competidoras. Las capas de disponibilidad de datos alternativas pueden considerarse un compromiso entre coste y seguridad, ya que introducen supuestos de confianza adicionales a los de Bitcoin.

Es importante destacar que el uso de una capa DA alternativa con verificación BitVM para la finalidad del rollup no añade beneficios sobre el diseño de la Fase 2: se debe confiar en la seguridad (normalmente PoS) de la capa DA. Además, una construcción de este tipo requiere verificar una prueba de cliente ligera para el consenso (PoS alternativo) de la DA en BitVM, lo cual es una cuestión de investigación abierta.

En consecuencia, la fase 2 de BOB es la solución más segura y viable en la práctica para BTC DeFi en la actualidad, especialmente debido al hecho de que la participación en BTC se reduce drásticamente en caso de error.

‍

Conclusión

Presentamos el proyecto técnico para actualizar BOB a la primera L2 híbrida de la historia: un rollup de Ethereum con finalidad Bitcoin y puentes nativos de confianza minimizada para activos BTC y ETH.

En las próximas semanas empezaremos a desplegar la L2 híbrida en la red de pruebas y completaremos la actualización a la red principal una vez superadas las auditorías. Paralelamente, estamos ultimando una especificación técnica completa que incluirá pruebas de seguridad y se publicará en breve. El puente BitVM de BOB ya se ha puesto en marcha en la red de pruebas y pronto comenzará la incorporación de operadores.

‍