Los usuarios de Bitcoin solo deben necesitar BTC en Bitcoin para forzar una retirada de sus BTC de BOB a Bitcoin. Estamos trabajando en una solución híbrida: utilizando Ethereum como DA por defecto y permitiendo a los usuarios incluir transacciones en BOB a través de una transacción especial en Bitcoin. Estamos emocionados de compartir nuestro trabajo en progreso en esta publicación del blog.

Demasiado largo; no lo leí

• Las L2 deberían tener la misma resistencia a la censura que las L1 en las que se basan
• En BOB, los usuarios ya pueden retirar forzosamente sus activos de BOB a Ethereum a través de una transacción de Ethereum
• Para su puente BitVM, BOB está trabajando en integrar Bitcoin como una forma para que los usuarios ejecuten transacciones en BOB
• Los usuarios de Bitcoin podrán retirar su BTC de BOB sin tener que enviar una transacción a BOB

Una de las propiedades fundamentales de las L2s es que su estado debe progresar incluso cuando el el secuenciador está desconectado. L2s logran esto leyendo y escribiendo su estado desde una capa de Disponibilidad de Datos (DA) que se puede actualizar de forma independiente a la L2 estando en línea. De esta manera, los usuarios pueden forzar la inclusión de sus transacciones incluso cuando el secuenciador está fuera de línea o el secuenciador no acepta sus transacciones directamente.

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

Esto no es lo suficientemente bueno para nosotros: los usuarios de Bitcoin solo deberían necesitar BTC en Bitcoin para forzar un retiro de su BTC de BOB de vuelta a Bitcoin. Estamos trabajando en una solución híbrida: por defecto a Ethereum como DA mientras permitimos a los usuarios forzar transacciones incluidas en BOB a través de una transacción especial en Bitcoin. Estamos emocionados de compartir nuestro trabajo en progreso en esta publicación de blog.

Antecedentes sobre DA y Derivación

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

Simplificado, en rollups (específicamente cadenas OP Stack), tenemos dos tipos de datos en el L1:

• Transacciones de depósitose realizan en el contrato 'OptimismPortal'. Estas son las transacciones que realizan los usuarios en Ethereum, generalmente 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 (o op-batcher para ser más precisos) desde las transacciones de L2. Estos incluyen todas las transacciones realizadas directamente por los usuarios en BOB y eventualmente se incluyen de nuevo en los blobs de Ethereum.

Bitcoin como capa DA

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

Sin embargo, en nuestro caso, BOB aún puede usar Ethereum como su capa DA "principal" donde publica todos sus datos de transacciones, pero agregar Bitcoin como una capa de respaldo altamente resistente a la censura si Ethereum DA no está disponible. Básicamente, Ethereum se convierte en la capa DA optimista mientras que Bitcoin se convierte en el costoso pero resistente a fallos último recurso.

Pipeline de Derivación Híbrida

La solución básica es agregar Bitcoin a BOB como parte del canal de derivación, de modo que BOB (y específicamente el "op-nodo") procese las entradas en este orden:

1. Transacciones forzadas de retiro de Bitcoin (nuevas agregadas específicamente para BOB)
2. Depósitos de Ethereum al contrato OptimismPortal (estándar OP Stack) de BOB
3. Lotes de Ethereum de op-batcher (estándar de pila OP)

Vamos a adentrarnos en una posible solución para codificar las transacciones de retiro forzado de Bitcoin en el canal de derivación de BOB. Ten en cuenta que esto aún está en investigación, por lo que podrían haber cambios.

Transacciones Forzadas de Retiro de Bitcoin

Necesitaremos tres partes para crear una transacción de retiro forzado:

1. Construir la transacción de retiro forzoso en Bitcoin.
2. Almacene la transacción de retiro forzado en Bitcoin dentro de los límites de tamaño de Bitcoin.
3. Manejar los costos de gas para la transacción de retiro forzado en Bitcoin.

1. Construir la transacción de retiro forzado

Una pila OPtransacción de depósitotiene la siguiente estructura:

• bytes32 sourceHash: el source-hash, que identifica de forma única el origen del depósito.
• dirección desde: La dirección de la cuenta del remitente.
• dirección a: La dirección de la cuenta del destinatario, o la dirección nula (de longitud cero) si la transacción depositada es una creación de contrato.
• uint256 mint: El valor ETH a crear en L2.
• valor uint256: El valor ETH a enviar a la cuenta del destinatario.
• uint64 gas: El límite de gas para la transacción L2.
• bool isSystemTx: Si es verdadero, la transacción no interactúa con el pool de gas de bloques L2.
• datos de bytes: El calldata.

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

Luego podemos almacenar una versión (comprimida) de la transacción de retiro forzado en Bitcoin que incluye todos los datos mencionados anteriormente.

2. Almacene la transacción de retiro forzado en Bitcoin

Como los datos para la transacción de retiro forzado son más grandes de lo que normalmente se debe almacenar en una salida OP_RETURN, es probable que usemos unTaprootsalida para almacenar los datos.

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

Serialización de datos: la transacción de retiro forzoso se serializa utilizando scripts Taproot dentro de una estructura "sobre". Estos son noops en la red de Bitcoin y se utilizan, por ejemplo, para los Ordinales también. Ajustamos la estructura para que se ajuste a nuestras necesidades.

No establecido
OP_FALSE OP_IF
OP_PUSH "bob"
OP_1
OP_PUSH "transacción"
OP_0
OP_PUSH $WITHDRAWAL_TRANSACTION_DATA
OP_ENDIF
Esquema de Compromiso/Revelación de Dos Fases:
Como con los Ordinales, los usuarios tendrán que enviar dos transacciones a Bitcoin:

• Transacción de compromiso: Crea una salida Taproot comprometiéndose con el 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 que los nodos completos y los secuenciadores de BOB incluyan la transacción de retiro.
• Transacción de Revelación: Gasta la salida de la transacción de compromiso, revelando la inscripción en la cadena, es decir, revelando la transacción de retiro del usuario para su inclusión en BOB.

3. Manejar los costos de gas para la transacción de retiro forzado

Este es el problema más abierto hasta ahora, con dos opciones actualmente bajo consideración:

• Establezca el gas en 0 para la transacción de retiro forzado en Bitcoin y deduzca los costos de gas del saldo de ETH del usuario en BOB. De esta manera, solo los usuarios que tengan ETH en BOB pueden forzar retiros. Sin embargo, esta no es una buena opción, ya que requeriría que los usuarios tengan ETH en BOB para forzar retiros, es decir, los usuarios que tengan BTC en Bitcoin no pueden forzar retiros.
• Los usuarios pagan gas en BTC en Bitcoin. La red BOB necesitaría tener una dirección en Bitcoin que pueda recibir BTC y efectivamente intercambiar el BTC recibido por el usuario a ETH en BOB para pagar los costos de gas de la parte L1 más los costos de ejecución. Esta opción es probable al usarpasarela BOBy estableciendo la dirección EVM de BOB DAO como el destinatario de BTC.

¡También estamos experimentando con más ideas, así que estad atentos para más actualizaciones!

Poniéndolo todo junto

Cualquiera puede determinar el estado de GATE solo con tener que verificar los datos en Bitcoin y Ethereum:

1. Lea todas las transacciones de retiro de Bitcoin. Estas se codifican como dos transacciones para cada retiro, es decir, una transacción de compromiso y una transacción de revelación. Esta es la adición que estamos haciendo a la Pila OP y donde mejoramos el canal de derivación.
2. Lea todas las transacciones realizadas al contrato OptimismPortal de BOB en Ethereum. Esto ya es parte del proceso de derivación estándar de la pila OP.
3. Lea 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 bloques de Ethereum. Esto ya forma parte del canal de derivación de la pila OP estándar.

Desafíos técnicos

Consistencia de datos: Si bien es importante garantizar la consistencia de datos entre las cadenas de Ethereum y Bitcoin, la mera presencia de datos de transacciones en ambas cadenas no garantiza su validez. Las transacciones deben representar transiciones de estado válidas de acuerdo con la función de transición de estado del rollup para considerarse legítimas. La solución requiere implementar lógica de validación dentro del op-node (u otras implementaciones de capas de consenso) que verifique primero 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 debe mejorarse para manejar datos de ambas cadenas, lo que podría hacer que la resolución de disputas sea más compleja. Para abordar esto, debemos tener en cuenta con precisión las posibles transacciones de Bitcoin y Ethereum como parte del puente de BitVM y el acuerdo de BOB en Ethereum.

Aumento del almacenamiento: Además, los nodos BOB en la red enfrentan requisitos de almacenamiento y ancho de banda aumentados ya que necesitan procesar y almacenar datos de Bitcoin y Ethereum. Sin embargo, podríamos mitigar esto al requerir que las transacciones de BOB realizadas en Bitcoin deban incluirse en bloques de Ethereum con una referencia a los últimos bloques de Bitcoin. De esta manera, los nodos solo necesitan sincronizar bloques recientes de Bitcoin.

Siguientes Pasos

Estamos emocionados de empujar el límite de los rollups híbridos que combinan la seguridad de Bitcoin con la innovación de Ethereum. En este problema concreto, nos interesa combinar la resistencia a la censura de las transacciones de Bitcoin con la pila de rollups de BOB. Actualizaremos esta publicación del blog con más información a medida que progresemos.

Descargo de responsabilidad:

1. Este artículo es reproducido de [BOB]. Todos los derechos de autor pertenecen al autor original [Dominik Harz]. Si hay objeciones a esta reimpresión, por favor contacte al Gate Learnequipo y lo resolverán rápidamente.
2. Aviso de responsabilidad: Las opiniones expresadas en este artículo son únicamente las del autor y no constituyen asesoramiento de inversión.
3. El equipo de gate Learn tradujo el artículo a otros idiomas. Está prohibido copiar, distribuir o plagiar los artículos traducidos a menos que se mencione.