Se ha probado con éxito un prototipo de puente BitVM entre BOB y Bitcoin, lo que marca un hito importante en nuestra misión Hybrid L2 de combinar lo mejor de Bitcoin y Ethereum.

El prototipo aprovecha la última versión de BitVM2 para facilitar un puente Bitcoin de confianza minimizada. Se ha desarrollado en estrecha colaboración con Fiamma,una empresa líder en el desarrollo de BitVM y de infraestructuras de conocimiento cero.

Esto sigue muy de cerca el anuncio de nuestra próxima integración con Babylon, que traerá la finalidad de Bitcoin a la red BOB a través del protocolo de apuestas Bitcoin de Babylon. Juntos, estos dos desarrollos permiten a BOB empezar a moverse hacia la Fase 2 de la hoja de ruta Hybrid L2.

BOB será la primera solución de capa 2 en heredar la seguridad de Bitcoin y desarrollar un prototipo de puente basado en BitVM.

Siga leyendo para saber más.

‍

¿Qué es BitVM?

BitVM es un mecanismo para ejecutar programas en Bitcoin de forma optimista. La ejecución ocurre fuera de la cadena, pero en caso de fallos, las disputas se resuelven y aplican en la cadena. Piense en optimismo, pero en Bitcoin. Los dos principales casos de uso son los rollups de Bitcoin y los puentes de confianza minimizada. En ambos, queremos permitir a los usuarios depositar y retirar BTC de una L2 sin confiar en un tercero.

Los puentes existentes suelen depender de entidades centralizadas -como Wrapped Bitcoin (wBTC) y Coinbase Wrapped Bitcoin (cbBTC)- o de redes semiconfiables como tBTC, donde la seguridad depende de la honestidad de la mayoría de los participantes. En cambio, los puentes BitVM2 introducen un modelo de seguridad superior: Los depósitos de BTC no pueden ser robados mientras haya un único nodo honesto y en línea en la red, y este nodo puede ser el propio depositante.

La versión más reciente y práctica es BitVM2. Consulte nuestro último documento para ver la especificación completa del protocolo.

El cofundador de BOB, Alexei Zamyatin, colaborador activo y coautor del diseño técnico de BitVM2, destacó la importancia del logro de hoy:

"La seguridad de Bitcoin y el puente BTC minimizado por la confianza es lo que diferencia a Bitcoin L2s de todas las demás cadenas. La seguridad de la red más robusta y descentralizada, unida a una forma de depositar y retirar BTC sin confiar en terceros. Hasta ahora, esto no ha sido posible, casi todos los puentes BTC son multisigs de confianza. Sólo ahora, por primera vez en la historia de Bitcoin, tenemos por fin un plano y un prototipo para conseguirlo en la práctica con BitVM2".

‍

Flujo del protocolo BitVM2

  1. Comprimir un programa en un verificador SNARK, implementado en Bitcoin Script. Usando el sistema de pruebas Groth16 obtenemos aproximadamente 1GB de tamaño.
  2. Dividir el verificador en trozos de sub-programa, máximo 4MB cada uno, para que cada uno pueda ser ejecutado en una transacción Bitcoin.
  3. El operador se compromete con el programa durante la configuración.
  4. Al intentar retirar fondos de BitVM2, el Operador puede ser desafiado por cualquiera, por ejemplo, si el desenvolvimiento (peg-out) no se completó correctamente.
  5. En caso de impugnación, el Operador deberá revelar todos los resultados del programa de intermediación.
  6. Si el Operador hace trampas, uno de los resultados del sub-programa reclamado será erróneo. Cualquiera puede refutar al Operador ejecutando ese subprograma específico en una transacción Bitcoin, demostrando que el Operador reclamó un cálculo falso.
  7. Listo. El Operador defectuoso es expulsado y no puede acceder a los fondos de BitVM debido a una transacción de gastos invalidada.

‍

Flujo del puente BitVM

El Puente BitVM hace uso de BitVM2 para implementar un puente ligero-cliente sobre Bitcoin. El L2 verifica Bitcoin, Bitcoin verifica el L2. La parte más interesante es el desenvolvimiento, también llamado peg-out, que ha sido durante mucho tiempo un reto para los protocolos Bitcoin DeFi.

  1. Los operadores pagan BTC al usuario que retira de sus propios fondos y luego reclaman los BTC a BitVM.
  2. BitVM comprueba que para una transacción un-wrap en el L2, hay un correcto peg-out en Bitcoin.
  3. Si todo es correcto, el Operador obtiene el reembolso del BTC.

‍

Con un funcionamiento correcto, el proceso de puenteo se completa en menos de una hora en cada sentido, lo que es mucho más rápido que los puentes L1 o L2 existentes de Ethereum a Bitcoin.

‍

Asociación estratégica con Fiamma

Para acelerar su implementación de BitVM2, BOB se asoció con Fiamma, el pionero detrás de los primeros productos que utilizan BitVM2, incluyendo el primer puente BitVM (Fiamma Bridge) y la primera capa de verificación de Bitcoin impulsada por BitVM (Fiamma Layer).

Esta colaboración fue decisiva para el éxito del prototipo de puente BitVM de BOB. Juntos, BOB y Fiamma desplegaron la infraestructura clave del puente y probaron una primera versión del software prover para verificar el consenso de BOB. Esto sigue a la inversión estratégica de BOB en Fiamma a principios de este mes, con su infraestructura y experiencia capaz de apoyar el rápido despliegue de BitVM en BOB, comenzando con este prototipo de puente BitVM.

Cyimon Chen, cofundador de Fiamma y principal colaborador de BitVM, se ha referido a este hito:

"Estamos encantados de anunciar nuestra colaboración con el equipo de BOB. Apreciamos profundamente las valiosas ideas de Alexei y su equipo durante nuestras conversaciones. Estamos deseando integrar el puente BitVM en BOB, convirtiéndolo en el primer Bitcoin de capa 2 con un puente de confianza minimizada. Esperamos que el prototipo de puente BitVM de BOB sea el primero de muchos anuncios impresionantes que resulten de nuestra asociación estratégica."

‍

Avanzar en la hoja de ruta L2 híbrida de BOB

A principios de esta semana, BOB anunció su integración prevista con Babylon, el principal protocolo de apuestas BTC, que establecerá BOB como una red segura Bitcoin y proporcionará finalidad Bitcoin a su blockchain.

El puente minimizado por la confianza y la finalidad de Bitcoin son componentes esenciales del diseño híbrido de BOB, que pretende combinar la seguridad y liquidez de Bitcoin con la innovación y versatilidad DeFi de Ethereum, estableciendo a BOB como el hogar de BTC DeFi.

Esta combinación permitirá:

  • Mayor seguridad: Las transacciones en BOB estarán ancladas a la seguridad de Bitcoin.
  • Transferencias de BTC sin problemas: Los usuarios podrán mover BTC entre Bitcoin y BOB sin necesidad de confiar en intermediarios.
  • Retiradas más rápidas: La finalidad Bitcoin acelerará los tiempos de retirada en el puente Ethereum nativo de BOB.

Para saber más sobre lo que esto significa, lea el documento Hybrid L2 Vision Paper de BOB.

‍

¿Y ahora qué?

Tras la entrega de este prototipo, BOB tiene previsto desplegar el puente BitVM en la red de pruebas de BOB a principios de 2025, a lo que seguirá el despliegue de la red principal tras el éxito de la auditoría y la integración de los socios.

Una vez que BOB haya completado su integración con Babylon y sea una Red Asegurada Bitcoin (BSN), el principal mecanismo de seguridad para el puente BitVM será la finalidad Bitcoin a través de la estaca BTC. Estamos trabajando activamente con Babylon para implementar esto.

Mientras tanto, mantente atento a nuestras redes sociales para estar informado sobre el lanzamiento del puente BitVM, y todos los demás emocionantes desarrollos que tenemos planeados.

Para los desarrolladores y cualquiera a quien le guste adentrarse en la tecnología, las siguientes secciones explican más de los desarrollos específicos que sustentan el prototipo de puente. También hay enlaces a las transacciones de prueba del prototipo.

‍

Detalles técnicos de BitVM Bridge

Prover especializado basado en zkVM

Integrando la infraestructura central de Fiamma, desarrollamos un primer prototipo de nuestro prover basado en zkVM para validar la construcción de bloques en BOB. En esta primera versión, dimos entrada a nuestro prover SNARK:

  • Transacciones Ethereum L1 que envían nuevas raíces de salida al contrato L2OutputOracle.
  • Las cabeceras de bloque L2 hasta este "punto de control" para un bloque de destino.
  • Recibos de ejecución del bloque L2 de destino.

Aquí nos aseguramos de que el proponente aprobado firmaba correctamente y de que la raíz de salida coincidía con el último bloque L2. También verificamos que todos los bloques que conducían al bloque objetivo estuvieran en el orden correcto. A continuación, dentro de los registros de transacciones del bloque de destino, confirmamos que había un "evento de grabación" específico que identificaba de forma exclusiva la instancia de BitVM creada durante la configuración inicial.

Contrato puente y retransmisión completa de Bitcoin SPV

La mayor parte de la lógica de nuestro contrato inteligente se define en un nuevo contrato "Bridge", que hace posible acuñar tokens ERC20 en BOB y permite a los operadores procesar solicitudes de peg-out.

Internamente, también hay un "relé completo" de Bitcoin SPV, que comprobamos para asegurarnos de que las transacciones de Bitcoin están incluidas.

Procesos de Peg-In y Peg-Out

Suponiendo que un usuario, Alice, quiere puentear BTC a BOB y luego retirarse, el protocolo de puenteo BitVM paso a paso se ejecuta como sigue. Nota: "peg-in" y "peg-out" se refieren al puenteo de entrada y salida, según las definiciones utilizadas en el código y en el documento de BitVM.

Peg-In:

  • Alice se coordina con el comité* para crear una nueva instancia BitVM y obtiene un ID único (fuera de la cadena).
  • Alice envía BTC a la dirección Bitcoin designada, haciendo referencia al ID.
  • El comité envía la tx de Bitcoin y la prueba de inclusión al contrato inteligente puente en BOB, que verifica (utilizando el relé SPV) que la transacción de depósito se incluyó en la cadena principal de Bitcoin con al menos 6 confirmaciones.
  • Si todo va bien, el contrato inteligente acuñará un token ERC20 de BTC envuelto para Alice en una proporción de 1:1 respecto al depósito de BTC. Alice puede utilizarlo en cualquiera de los protocolos DeFi de BOB, como cualquier otro token ERC20.

‍

* El llamado comité de "emulación del pacto" se utiliza para simular los op-codes del pacto que faltan en Bitcoin. Este comité es necesario para pre-firmar transacciones Bitcoin específicas que aseguren que el operador sólo puede gastar depósitos BTC de forma que puedan ser desafiados, previniendo así el robo. Específicamente, este es un comité m-de-m, donde m puede ser muy grande (100s de firmantes muestreados aleatoriamente). Mientras uno de estos firmantes sea honesto, la configuración es segura. La propia Alice puede participar en esta configuración. Este comité puede ser eventualmente reemplazado si Bitcoin añade un nuevo opcode como TXHASH u OP_CAT.

‍

Peg-Out:

  • Alice bloquea el BTC ERC20 envuelto en el contrato inteligente puente en BOB y espera a que un operador acepte la solicitud.
  • A continuación, uno de los operadores envía la cantidad de BTC correspondiente a la dirección de Alice en Bitcoin, y proporciona una prueba de inclusión al contrato inteligente puente en BOB después de que se hayan producido al menos 6 confirmaciones. El contrato inteligente emite un evento "burn".

Nota: el peg-out se completa a Alice en este punto. El operador "adelanta" los BTC de su propio saldo. En los pasos siguientes, el operador recupera esta cantidad de los depósitos de BitVM para completar el proceso. Esta lógica puede compararse a la de un puente de liquidez en Ethereum.

  • El secuenciador BOB produce un bloque que contiene el evento "burn", que luego se utiliza como entrada para el prover ZK descrito anteriormente.
  • El operador inicia una retirada de los depósitos de BitVM en Bitcoin. Ahora, en un plazo de 7 días, cualquiera puede verificar la exactitud del peg-out y, en caso de errores, impugnar al operador.
  • Opción 1: Todo es correcto. Si el operador ejecutó el peg-out correctamente (cantidad correcta, destinatario, dentro del tiempo requerido, ...), no serán impugnados y reclamar el BTC de los depósitos BitVM después de 7 días.
  • Opción 2: Error y desafío. Si el operador intentó hacer trampas (por ejemplo, no envió BTC a Alice pero está intentando reclamar de todas formas), será retado - siempre y cuando haya al menos 1 usuario honesto y conectado en la red. El operador es entonces obligado a publicar datos adicionales sobre la ejecución del verificador SNARK (transacción "Assert"), que permite a los retadores probar a la red Bitcoin que el operador está haciendo trampas (con 1 transacción más). Si el operador no publica la transacción Assert o efectivamente ha hecho trampas (es decir, el verificador SNARK no puede haberse ejecutado correctamente), su intento de retirada fallará y será eliminado del conjunto de operadores.

‍

Tenga en cuenta que en el caso de peg-out, tenemos flexibilidad para restar tasas en el contrato inteligente para que el operador pueda recuperar más al reclamar de la instancia BitVM.

‍

Prototipo de puente BitVM en acción

Para demostrar el prototipo de puente en acción, veamos algunos ejemplos de transacciones en Bitcoin signet.

En primer lugar, la transacción "peg-in", en la que el usuario bloquea su BTC:

‍

Camino Feliz

En el caso óptimo (cuando el operador es honesto), adelantan los BTC al usuario en pegout_tx y luego reclaman los fondos (sin impugnación) en happy_take_tx:

‍

Camino infeliz (con desafío exitoso)

Cuando un operador intenta reclamar el BTC sin una prueba ZK exitosa, un retador puede proporcionar un disprove_tx que demuestre a BitVM que el assert_tx no era válido:

‍

Camino infeliz (con desafío infructuoso)

Si un operador es cuestionado por una salida válida, proporciona un assert_tx que no puede ser refutado. A continuación, reclama los fondos en unhappy_take_tx:

‍

Próximas etapas de desarrollo

El prototipo actual aún tiene algunas limitaciones, ya que está en fase de desarrollo. Próximos pasos hacia una versión de prueba previa al lanzamiento:

‍

  • Añadir comprobaciones de finalidad de Bitcoin a través de Babylon, incluyendo un cliente ligero ZK para verificar correctamente esto en Bitcoin.
  • Integración con BOB Bridge y Stake para mejorar la UX, ocultando la complejidad a los usuarios.
  • Existen algunas limitaciones prácticas a la hora de publicar algunos compromisos en la cadena debido a restricciones de tamaño (por ejemplo, actualmente la transmisión de afirmaciones carece de compromisos de datos). Estamos estudiando esta cuestión con Fiamma.
  • Ajustar los aspectos económicos para garantizar que los operadores reciban una remuneración justa y estén incentivados para operar el puente BitVM.

‍