tl;dr

  • Las L2 deben tener la misma resistencia a la censura que las L1 en las que se basan
  • En BOB, los usuarios ya pueden forzar la retirada de sus activos de BOB a Ethereum a través de una transacción Ethereum
  • Para su puente BitVM, BOB está trabajando en la integración de Bitcoin como forma de que los usuarios puedan realizar transacciones en BOB
  • Los usuarios de Bitcoin podrán retirar sus BTC de BOB sin tener que enviar una transacción a BOB.

‍

Una de las principales propiedades de los L2 es que su estado debe progresar incluso cuando el secuenciador está desconectado. Los L2 consiguen esto leyendo y escribiendo su estado desde una capa de Disponibilidad de Datos (DA) que puede actualizarse independientemente de que el L2 esté en línea. De este modo, los usuarios pueden forzar la inclusión de sus transacciones incluso cuando el secuenciador está desconectado, o el secuenciador no acepta directamente sus transacciones.

Para el puente BitVM de BOB, esto plantea un problema interesante. BOB utiliza actualmente blobs EIP-4844 de Ethereum como capa DA. Los usuarios de Ethereum pueden realizar fácilmente retiradas a Bitcoin a través del puente BitVM. Sin embargo, esto requiere que los usuarios tengan ETH en Ethereum.

Esto no es suficiente para nosotros: Los usuarios de Bitcoin sólo deberían necesitar BTC en Bitcoin para forzar una retirada de sus BTC de BOB de vuelta a Bitcoin. Estamos trabajando en una solución híbrida: utilizar Ethereum como DA por defecto y permitir a los usuarios forzar la inclusión de transacciones en BOB a través de una transacción especial en Bitcoin. Estamos muy contentos de compartir nuestro trabajo en progreso en esta entrada del blog.

‍

Antecedentes de la DA y la derivación

El proceso de derivación es bastante importante para los L2: todo el estado L2 de BOB debe construirse a partir del L1 y la capa DA. Permite a las L2 disfrutar de la misma resistencia a la censura que la capa DA, en nuestro caso, Ethereum.

Simplificando, en los rollups (concretamente en las cadenas OP Stack), tenemos dos tipos de datos en el L1:

  • Operaciones de depósito hechas al contrato "OptimismPortal". Estas son las transacciones que son hechas por usuarios en Ethereum típicamente para depositar sus activos en BOB. Estas transacciones de depósito también se pueden utilizar para ejecutar otras transacciones en BOB.
  • Lotes enviados por el secuenciador (u op-batcher para ser más precisos) de transacciones L2. Estos incluyen todas las transacciones realizadas directamente por los usuarios en BOB y finalmente se incluyen de nuevo en los blobs de Ethereum.

‍

Bitcoin como capa DA

Si queremos Bitcoin como capa DA, ¿por qué no cambiar completamente a usar Bitcoin completamente como capa DA? La respuesta es principalmente el coste. Bitcoin tiene muy poco almacenamiento disponible (unos 4MB aproximadamente cada 10 minutos), y por lo tanto, el coste de almacenamiento es alto.

Sin embargo, en nuestro caso, BOB puede seguir utilizando Ethereum como su capa DA "principal", donde publica todos sus datos de transacciones, pero añadir Bitcoin como capa de reserva altamente resistente a la censura si Ethereum DA no está disponible. Esencialmente, Ethereum se convierte en la capa DA optimista, mientras que Bitcoin se convierte en el último recurso, caro pero tolerante a fallos.

‍

Proceso de derivación híbrido

La solución básica es añadir Bitcoin a BOB como parte del proceso de derivación, de forma que BOB (y específicamente el "op-node") procese las entradas en este orden:

  1. Transacciones de retirada forzosa de Bitcoin (recién añadido específicamente para BOB)
  2. Depósitos de Ethereum en el contrato OptimismPortal de BOB (estándar OP Stack)
  3. Lotes Ethereum de op-batcher (OP Stack estándar)

Pasemos a una posible solución para codificar las transacciones de retirada forzada de Bitcoin en el proceso de derivación de BOB. Tenga en cuenta que esto todavía está siendo investigado, por lo que los cambios son posibles.

‍

Transacciones de retirada forzosa de Bitcoin

Necesitaremos tres partes para crear una transacción de retirada forzosa:

  1. Construir la transacción de retirada forzosa en Bitcoin.
  2. Almacene la transacción de retirada forzosa en Bitcoin dentro de los límites de tamaño de Bitcoin.
  3. Gestionar los costes de gas para la transacción de retirada forzosa en Bitcoin.

‍

1. Construir la transacción de retirada forzosa

Una transacción de depósito de pila OP tiene la siguiente estructura:

  • bytes32 sourceHash: el source-hash, identifica unívocamente el origen del depósito.
  • dirección de: La dirección de la cuenta del remitente.
  • dirección a: La dirección de la cuenta del destinatario, o la dirección nula (longitud cero) si la operación depositada es una creación de contrato.
  • uint256 menta: El valor de ETH a acuñar en L2.
  • Valor uint256: El valor de ETH que se enviará a la cuenta del destinatario.
  • uint64 gas: El límite de gas para la transacción L2.
  • bool isSystemTx: Si es true, la transacción no interactúa con el pool de gas de bloques L2.
  • bytes de datos: Los datos de llamada.

Una transacción de retirada forzada requiere incluir la transacción de retirada codificada en el campo de datos de la transacción de depósito. Esto se hace creando la transacción en BOB que activa la retirada de BOB a Bitcoin y funcionaría exactamente igual que si la transacción se enviara desde Ethereum.

Entonces podemos almacenar una versión (comprimida) de la transacción de retirada forzosa en Bitcoin que incluya todos los datos anteriores.

‍

2. Almacenar la transacción de retirada forzada en Bitcoin

Dado que los datos de la transacción de retirada forzosa son mayores de lo que normalmente debería almacenarse en una salida OP_RETURN, probablemente utilizaremos una salida Taproot para almacenar los datos.

Mientras que es fácil identificar una transacción de depósito (que puede incluir una retirada) en Ethereum debido a que se envía al contrato OptimismPortal de BOB, no es tan fácil identificar una transacción de retirada forzada en Bitcoin.

Serialización de datos: La transacción de retirada forzosa se serializa utilizando scripts Taproot dentro de una estructura "sobre". Estos noops existen en la red Bitcoin y se utilizan, por ejemplo, también para Ordinales. Ajustamos la estructura para adaptarla a nuestras necesidades.

Sin configurar

OP_FALSE OP_IF

 OP_PUSH "bob"

 OP_1

 OP_PUSH "transacción"

 OP_0

 OP_PUSH $DATOS_TRANSACCION_RETIRADA

OP_ENDIF

Esquema Commit/Reveal en dos fases:

Al igual que con Ordinals, los usuarios tendrán que enviar dos transacciones a Bitcoin:

  • Transacción de compromiso: Crea una salida Taproot comprometiendo al script que contiene el contenido de la inscripción. Esta transacción aún no revela los datos y necesitaremos la segunda transacción para nodos completos BOB y secuenciadores para incluir la transacción de retirada.
  • Revelar transacción: Gasta la salida de la transacción de confirmación, revelando la inscripción en la cadena, es decir, revelando la transacción de retirada del usuario para su inclusión en BOB.

‍

3. Gestionar los costes de gas de la operación de retirada forzosa

Este es el problema más abierto hasta ahora, con dos opciones actualmente en estudio:

  • Establecer gas a 0 para la transacción de retirada forzada en Bitcoin y deducir los costes de gas del saldo de ETH del usuario en BOB. De esta manera, sólo los usuarios que tienen ETH en BOB pueden forzar retiradas. Sin embargo, esta no es una buena opción ya que requeriría que los usuarios tuvieran ETH en BOB para forzar retiradas, es decir, los usuarios que tienen BTC en Bitcoin no pueden forzar retiradas.
  • El gas es pagado por los usuarios en BTC en Bitcoin. La red BOB necesitaría tener una dirección en Bitcoin que pueda recibir BTC e intercambiaría efectivamente el BTC recibido por el usuario a ETH en BOB para pagar la parte L1 de los costes de gas más los costes de ejecución. Esta opción es probable utilizando BOB Gateway y estableciendo la dirección EVM del DAO de BOB como destinatario de BTC.

También estamos experimentando con más ideas, así que permanezca atento a las novedades.

‍

Puesta en común

Cualquiera puede determinar el estado de BOB con sólo comprobar los datos sobre Bitcoin y Ethereum:

  1. Lea todas las transacciones de retirada de Bitcoin. Éstas se codifican como dos transacciones por cada retirada, es decir, una transacción de confirmación y otra de revelación. Esta es la adición que estamos haciendo a la Pila OP y donde mejoramos la tubería de derivación.
  2. Leer todas las transacciones realizadas al contrato OptimismPortal de BOB en Ethereum. Esto ya forma parte del proceso de derivación estándar de OP Stack.
  3. Lee todas las transacciones realizadas directamente en BOB e integradas como parte de lotes en Ethereum. Es importante destacar que los nodos completos no leen directamente del secuenciador para recibir transacciones confirmadas, sino que leen de los blobs de Ethereum. Esto ya forma parte de la canalización de derivación estándar de OP Stack.

‍

Retos técnicos

Consistencia de datos: Aunque garantizar la coherencia de los datos entre las cadenas de Ethereum y Bitcoin es importante, la mera presencia de datos de transacciones en ambas cadenas no garantiza la validez. Las transacciones deben representar transiciones de estado válidas según la función de transición de estado del rollup para ser consideradas legítimas. La solución requiere implementar una lógica de validación dentro de op-node (u otras implementaciones de la capa de consenso) que primero verifique si una transacción resulta en un cambio de estado válido antes de aceptarla.

Pruebas de fraude y validez: El sistema de prueba de fraude tanto para BitVM como para Ethereum necesita ser mejorado para manejar datos de ambas cadenas, lo que podría hacer más compleja la resolución de disputas. Para solucionar esto, necesitamos contabilizar con precisión las posibles transacciones de Bitcoin y Ethereum como parte del puente de BitVM y la liquidación de BOB en Ethereum.

Aumento del almacenamiento: Además, los nodos BOB de la red se enfrentan a un aumento de los requisitos de almacenamiento y ancho de banda, ya que necesitan procesar y almacenar datos de Bitcoin y Ethereum. Sin embargo, podríamos mitigar esto exigiendo que las transacciones BOB realizadas en Bitcoin se incluyan en los blobs de Ethereum con una referencia a los últimos bloques de Bitcoin. De esta forma, los nodos sólo necesitan sincronizar los bloques Bitcoin recientes.

‍

Próximos pasos

Estamos entusiasmados por ampliar la frontera de los rollups híbridos combinando la seguridad de Bitcoin con la innovación de Ethereum. En este problema concreto, estamos interesados en tener la resistencia a la censura de las transacciones de Bitcoin combinada con la pila de rollups de BOB. Actualizaremos esta entrada de blog con más información a medida que avancemos.

‍