Resumen: Los puentes ZK despliegan contratos inteligentes en la Cadena A para recibir y verificar directamente los encabezados de bloque y las pruebas de conocimiento cero correspondientes de la Cadena B, confirmando la validez de los mensajes entre cadenas. Este es el esquema de puente más seguro.

• Los puentes Optimistic/OP utilizan pruebas de fraude para desafiar mensajes intercadenas inválidos en la cadena. La presencia de solo un desafiante confiable puede garantizar la seguridad del fondo del puente intercadenas.
• Debido a limitaciones técnicas, la red principal de Bitcoin no puede implementar directamente puentes ZK pero puede lograr puentes optimistas a través de BitVM y pruebas de fraude. Equipos como Bitlayer y Citrea han adoptado el esquema de puente BitVM, introduciendo la pre-firma e incorporando conceptos de canal, permitiendo a los usuarios predefinir el proceso de manejo después de la ejecución del depósito, evitando que el puente entre cadenas malverse los depósitos de los usuarios.
• El puente BitVM opera esencialmente en un modelo de "prepago-reembolso", con nodos Operadores específicos que proporcionan fondos a los usuarios de retiro. Los Operadores pueden solicitar periódicamente reembolsos desde una dirección de depósito pública. Si un Operador presenta una solicitud de reembolso falsa, puede ser impugnado y reducido por cualquier persona.
• Si bien teóricamente seguro, el puente BitVM tiene problemas con la vivacidad/utilidad y no cumple con las necesidades específicas de los usuarios para la independencia de los fondos y la lucha contra el lavado de dinero (ya que básicamente utiliza un modelo de fondo común). Bitlayer aborda esto con una solución de puente OP-DLC. Esta solución, similar a DLC.link, introduce pruebas de fraude basadas en canales y DLC para evitar el mal uso del oráculo.
• Dada la dificultad de implementar BitVM y pruebas de fraude, primero se desplegarán los puentes de DLC como un sustituto temporal. Siempre y cuando se resuelvan los riesgos de confianza de los oráculos e integren oráculos de terceros más confiables y maduros, los puentes de DLC pueden convertirse en un esquema de verificación de retiro más seguro que los puentes de multi-firma en la etapa actual.

Introducción: Desde la fiebre de la inscripción del año pasado, el ecosistema Bitcoin ha entrado en un período de crecimiento rápido. En solo medio año, el número de proyectos bajo la bandera de BTC Layer2 ha alcanzado casi 100. Simplemente se ha convertido en un nuevo continente lleno de caos, donde las oportunidades y las estafas coexisten. No es exagerado decir que el ecosistema actual de Bitcoin ya es un “crisol multiétnico” de Ethereum, Cosmos y Celestia, CKB y el ecosistema nativo de Bitcoin. Junto con la falta de voces autoritativas, el ecosistema de Bitcoin es simplemente como el del siglo XIX. Al igual que los Estados Unidos, se ha convertido en un nuevo mundo que atrae fuerzas de todos los ámbitos de la vida. Si bien esto aporta prosperidad y vitalidad a toda la narrativa de Web3, también introduce enormes riesgos.

Muchos proyectos han comenzado a hacer publicidad sin siquiera lanzar soluciones técnicas, utilizando el nombre de la capa 2 nativa, afirmando que pueden heredar completamente la seguridad de la red principal de Bitcoin; algunos incluso utilizan técnicas de propaganda para crear conceptos, inventando un montón de nombres y términos extraños como líneas para promocionar su propia superioridad. Aunque el fanfarroneo ya es el estado actual del ecosistema de Bitcoin, todavía hay muchos KOLs principales que han hecho llamamientos objetivos.

No hace mucho, Monanaut, el fundador del navegador blockchain Mempool, criticó públicamente los problemas actuales del ecosistema Bitcoin. Señaló con dureza que si una Capa 2 de Bitcoin simplemente utiliza un puente de retiro de firma múltiple y no permite a los usuarios retirar activos en cualquier momento de forma confiable, tal proyecto no es una Capa 2 real. Curiosamente, Vitalik ha señalado anteriormente que la Capa 2 debería ser al menos más segura en términos de seguridad que los sistemas que se basan únicamente en firmas múltiples.

Se puede decir que Monanaut y Vitalik señalaron abiertamente los problemas técnicos de Bitcoin Capa 2: Muchos puentes de retiro de L2 son básicamente puentes de firma múltiple. Ya sea que varias instituciones conocidas tengan cada una una clave, o se utilice una firma descentralizada basada en POS, pero en cualquier caso, su modelo de seguridad se basa en la suposición de honestidad de la mayoría, es decir, se predetermina que la mayoría de los participantes en la firma múltiple no coludan para hacer el mal.

Este tipo de solución de puente de retiro que depende en gran medida de la garantía de crédito no es en absoluto una solución a largo plazo. La historia nos ha demostrado que los puentes de firmas múltiples tendrán diversos problemas tarde o temprano. Solo la confianza se minimiza o la custodia de activos tiende a ser completamente sin confianza. Solo de esta manera puede resistir la prueba del tiempo y de los hackers. Pero la situación actual del ecosistema de Bitcoin es que muchas partes del proyecto ni siquiera han lanzado un mapa técnico para el puente de retiro. No hay un diseño establecido de cómo el puente debería ser confiable o minimizado.

Pero esto no es todo el ecosistema de Bitcoin. Todavía hay algunos gerentes de proyecto que han expresado sus opiniones sobre las ideas de optimización del puente de retiro. en el texto, Analizaremos brevemente Bitlayer y el puente BitVM de Citrea, y presentaremos el puente OP-DLC propuesto por Bitlayer para abordar las deficiencias del puente BitVM, para que más personas puedan comprender los riesgos y las ideas de diseño de los puentes entre cadenas. Esto es crucial para la mayoría de los participantes en el ecosistema de Bitcoin.

Puente Optimista: Un esquema de verificación de puente basado en prueba de fraude

De hecho, la esencia del puente entre cadenas es muy simple, que es demostrar a la cadena B que cierto evento ocurrió en la cadena A. Por ejemplo, si cruzas activos de ETH a Polygon, necesitas el puente entre cadenas para ayudarte a demostrar que realmente has transferido activos a una dirección específica en la cadena ETH, y luego puedes recibir la misma cantidad de fondos en la cadena Polygon.

Los puentes tradicionales entre cadenas generalmente utilizan firmas multi-testigo. Designarán varios testigos bajo la cadena. Los testigos ejecutarán los nodos de cada cadena pública y supervisarán si alguien ha depositado fondos en la dirección de pago del puente entre cadenas.

El modelo de seguridad de este tipo de puente cruzado entre cadenas es básicamente el mismo que el de las carteras multi-firma. El modelo de confianza debe ser determinado de acuerdo con el método de configuración de multi-firma como M/N, pero al final básicamente sigue la suposición de mayoría honesta, lo que significa que la mayoría de los notarios no son maliciosos por defecto y la tasa de tolerancia a fallos es relativamente limitada. Muchos casos de robo de puentes cruzados a gran escala que han ocurrido antes básicamente todos ocurrieron en este tipo de puentes multi-firma, ya sea por robo o por hackers.

Por el contrario, el "Puente Optimista" basado en el protocolo de prueba de fraude y el "Puente ZK" basado en ZK son mucho más seguros. Tomando el Puente ZK como ejemplo, establecerá un contrato validador dedicado en la cadena de destino para verificar directamente el certificado de retiro en la cadena, eliminando la necesidad de depender de testigos fuera de la cadena.

Por ejemplo, un puente ZK que abarca ETH y Polygon desplegará un contrato verificador en Polygon, vamos a llamarlo Verificador por ahora. El nodo Relayer del Puente ZK reenviará el último encabezado de bloque de Ethereum y la Prueba ZK que demuestra la validez al Verificador, quien lo verificará. Esto es equivalente a tener el contrato Verificador sincronizado en la cadena de Polygon y verificar el último encabezado de bloque de Ethereum. La raíz de Merkle registrada en el encabezado de bloque está relacionada con el conjunto de transacciones contenidas en el bloque y puede usarse para verificar si una cierta transacción está incluida en el bloque.

Si el bloque de Ethereum con una altura de bloque de 101 contiene 10 declaraciones de transferencia entre cadenas de ETH a Polygon, Relayer generará una Prueba de Merkle relacionada con estas 10 transacciones y enviará la prueba al contrato Verifier en la cadena de Polygon:

El bloque No. 101 de Ethereum contiene 10 transacciones cruzadas de ETH a Polygon. Por supuesto, el puente ZK puede convertir la Prueba de Merkle en ZK y enviar directamente la Prueba de ZK al contrato Verificador. Durante todo este proceso, los usuarios solo necesitan confiar en que el contrato inteligente del puente cruzado no tiene lagunas, y que la tecnología de prueba de conocimiento cero en sí misma es segura y confiable. No es necesario introducir demasiadas suposiciones de confianza como en los puentes tradicionales de multi-firma.

Y el”Puente Optimista” es ligeramente diferente. Algunos puentes optimistas conservan configuraciones similares a los testigos, pero introducen pruebas de fraude y ventanas de desafío., después de que el testigo genera una firma múltiple para el mensaje entre cadenas, aunque se envíe a la cadena objetivo, su validez no será reconocida de inmediato. Debe pasar un período de ventana y nadie lo cuestiona antes de que se pueda considerar válido. Esto es en realidad algo similar a la idea de Optimistic Rollup. Por supuesto, el Puente Optimista tiene otros modelos de producto, pero en última instancia, la seguridad está garantizada por el protocolo de prueba de fraude.

La suposición de confianza del puente multifirma M/N es N-(M-1)/N. Hay que suponer que el número de personas malintencionadas en la red es como máximo M-1, y el número de personas honestas es como mínimo N-(M-1). La suposición de confianza del puente ZK es insignificante, mientras que la suposición de confianza del puente optimista basada en la prueba de fraude es 1/N, solo uno de los testigos N debe ser honesto y estar dispuesto a desafiar los mensajes de cadena cruzada no válidos enviados a la cadena de destino para garantizar la seguridad del puente.

En la actualidad, debido a limitaciones técnicas, solo se puede implementar el puente ZK en la dirección de depositar Bitcoin en la Capa 2. Si la dirección se invierte y se realizan retiros de la Capa 2 a la cadena Bitcoin, solo se admiten puentes de firma múltiple u optimistas, o modelos similares a canales. (El puente OP-DLC que se describirá a continuación se asemeja más a un canal). Para implementar un puente optimista en la cadena Bitcoin, se debe introducir una prueba de fraude, y BitVM ha creado buenas condiciones para la implementación de esta tecnología.

en artículos anteriores“Una interpretación minimalista de BitVM: Cómo verificar las pruebas de fraude en la cadena BTC”, hemos introducido brevemente, La esencia de la prueba de fraude de BitVM es descomponer las tareas de cálculo complejas realizadas fuera de la cadena en una gran cantidad de pasos simples, y luego seleccionar un cierto paso para ser verificado directamente en la cadena de Bitcoin.. Esta idea es similar a rollups optimistas de Ethereum como Arbitrum y Optimism.

(La documentación de BitVM2 menciona que una tarea de computación se dividirá en un gran número de pasos intermedios a través de firmas de Lamport, y luego cualquiera puede desafiar un paso intermedio)

Por supuesto, la declaración anterior sigue siendo relativamente oscura, pero creo que la mayoría de las personas ya han entendido el significado del certificado de fraude. En el artículo de hoy, debido a limitaciones generales de espacio, no pretendemos explicar los detalles de implementación técnica de BitVM y el protocolo de prueba de fraude, porque esto implica una serie de procesos de interacción complejos.

Presentaremos brevemente BitLayer, Citrea, BOB e incluso el puente nativo BitVM diseñado oficialmente por BitVM desde la perspectiva del diseño de productos y mecanismos, y cómo Bitlayer alivia el cuello de botella del puente BitVM a través del puente OP-DLC, para mostrarle cómo diseñar una solución de puente de retiro superior en la cadena Bitcoin.

(Diagrama esquemático de la solución de puente de Bitlayer)

Un breve análisis del principio del puente BitVM entre Bitlayer y Citrea

a continuación, utilizamos la solución de puente BitVM anunciada por Bitlayer, Citrea y Bob como material para ilustrar el proceso de funcionamiento general del puente BitVM.

En sus documentos oficiales y blogs técnicos, la parte del proyecto mencionada anteriormente explicó claramente las ideas de diseño del producto de BitVM Withdrawal Bridge (actualmente en la etapa teórica). Primero, cuando un usuario retira dinero a través del puente BitVM, necesita usar el contrato Bridge en Capa 2 para generar una declaración de retiro. Los siguientes parámetros clave están especificados en la declaración de retiro:

El número de BTC mapeados que el retirador necesita destruir en L2 (como 1 BTC);

La tarifa de gestión entre cadenas que el retirante tiene la intención de pagar (se asume que es de 0.01 BTC);

La dirección de retiro del retirante en L1: L1_receipt;

La cantidad retirada del retirante (es decir, 1 - 0.01 = 0.99BTC)

Después, la declaración de retiro anterior se incluirá en el bloque de Capa 2. El puente BitVM El nodo Relayer sincronizará el bloque de Capa 2, monitoreará la declaración de retiro contenida en él y la enviará al nodo Operador, que pagará al usuario que realiza el retiro.

Lo que debe tenerse en cuenta aquí es que El Operador primero paga a los usuarios en la cadena de Bitcoin de su propio bolsillo, es decir, “adelanta” fondos para el Puente BitVM y luego solicita compensación del fondo del Puente BitVM.

Al solicitar el reembolso, el Operador debe proporcionar pruebas de pago anticipado en la cadena de Bitcoin (es decir, demostrar que ha transferido dinero a la dirección especificada por el usuario de retiro en L1, y debe extraer el registro de transferencia específico contenido en el bloque de Bitcoin). Al mismo tiempo, el Operador también debe emitir una declaración de retiro generada por el retirante en Capa 2 (a través de Prueba de Merkle, se demuestra que la declaración de retiro emitida proviene del bloque L2 y no está fabricada de la nada). después, el Operador debe demostrar lo siguiente:

Los fondos avanzados por el Operador al tomador en nombre del puente BitVM son iguales a la cantidad solicitada por el tomador en el estado;

Cuando el Operador solicita un reembolso, la cantidad de reembolso no será superior a la cantidad de BTC mapeado destruido por el retirante en Capa 2;

El operador ha procesado efectivamente todas las declaraciones de retiro de L2-L1 en un período de tiempo, y cada declaración de retiro puede coincidir con el registro de transferencia de retiro en la cadena de Bitcoin;

Esta es esencialmente una sanción para el Operador por mentir sobre el monto anticipado o negarse a procesar la declaración de retiro (lo que puede resolver el problema de resistencia a la censura del puente de retiro). El Operador necesita comparar y verificar los campos clave del certificado de pago anticipado y la declaración de retiro fuera de la cadena para demostrar que la cantidad de BTC involucrada en ambos es igual.

Si el Operador del Puente de Retiro informa falsamente el monto por adelantado, significa que el Operador afirma que la prueba de pago en L1 coincide con el Estado de Retiro emitido por el retirador de L2, pero la situación real es que los dos no coinciden.

De esta manera, se demuestra que la ZKP de la Prueba de Pago = Declaración de Retiro debe estar equivocada. Tan pronto como se publique esta ZKP, el Retador puede señalar qué paso es incorrecto y desafiarlo a través del protocolo de prueba de fraude de BitVM2.

Lo que necesita ser enfatizado es que Bitlayer, Citrea, BOB, ZKBase, etc. han adoptado todos la última ruta BitVM2, que es la nueva versión de la solución BitVM. Esta solución ZKizará las tareas de computación fuera de la cadena, es decir, generará Pruebas ZK para el proceso de cálculo fuera de la cadena, luego verificará la Prueba, y luego convertirá el proceso de verificación de ZKP en Adaptado a la forma de BitVM para facilitar los desafíos posteriores.

Al mismo tiempo, mediante el uso de Lamport y pre-firma, el desafío interactivo de varias rondas de la BitVM original puede optimizarse en un desafío no interactivo de una sola ronda, lo que reduce en gran medida la dificultad del desafío.

El proceso de desafío de BitVM requiere el uso de algo llamado "compromiso", es decir, Compromiso. Explicaremos qué es un "compromiso". En general, alguien que publica un "compromiso" en la cadena de Bitcoin afirmará que ciertos datos almacenados fuera de la cadena/tareas de computación que ocurren fuera de la cadena son precisos, y la declaración relevante publicada en la cadena es un "compromiso".

Podemos entender aproximadamente el Compromiso como un hash de una gran cantidad de datos fuera de la cadena. El tamaño del Compromiso en sí suele ser muy pequeño, pero puede estar vinculado a una gran cantidad de datos fuera de la cadena a través de métodos como el Árbol de Merkle, y estos datos asociados fuera de la cadena no necesitan ser cargados en la cadena.

En la solución del puente BitVM de BitVM2 y Citrea y BitLayer, si alguien piensa que hay un problema con el compromiso emitido por el Operador del Puente de Retiro en la cadena, y que el compromiso está asociado con un proceso de verificación ZKP inválido, él o ella puede iniciar un desafío, y la autoridad de desafío es sin permisos. (El proceso de interacción en el interior es relativamente complicado y no se explicará aquí)

Dado que el Operador adelanta fondos para el fondo de la moneda BitVM para pagar la retirada, y luego solicita reembolso al fondo, al solicitarlo, el Operador debe emitir un Compromiso para demostrar que el dinero que transfiere a la retirada en L1 es igual a la retirada. El pagador declara en L2 que desea recibir el dinero. Si el Compromiso ha pasado la ventana de prueba de fraude y no ha sido impugnado, el Operador puede retirar la cantidad de reembolso que necesita.

Aquí queremos explicar cómo se mantiene el fondo público del puente BitVM, y esta es precisamente la parte más crítica del puente entre cadenas. Como todos sabemos, los fondos que el puente entre cadenas puede pagar al tomador provienen de los activos aportados por los depositantes u otros LP, y el dinero adelantado por el Operador finalmente se retirará del fondo público, por lo que depende únicamente de los fondos. Como resultado de la transferencia, la cantidad depositada por el depositante absorbida por el puente BitVM debería ser igual a la cantidad retirada por el retirador. Por lo tanto, cómo mantener los fondos de depósito es un tema muy importante.

En la mayoría de las soluciones de puenteado de Capa 2 de Bitcoin, los activos públicos a menudo se gestionan a través de multi-firma. Los depósitos de los usuarios se agregan en una cuenta de multi-firma. Cuando se necesita hacer un retiro, esta cuenta de multi-firma es responsable de realizar el pago. Obviamente, hay un gran riesgo de confianza en esta solución.

La pasarela Bitlayer y BitVM de Citrea adopta ideas similares a la Red Lightning y los canales. Antes de realizar un depósito, el usuario primero se comunicará con la Alianza BitVM y le pedirá a esta última que pre-firme para lograr los siguientes efectos:

Después de que el usuario transfiera el depósito a la dirección de recarga, el dinero se bloqueará directamente en una dirección de Taproot y solo podrá ser recolectado por el Operador del puente. Además, el Operador solo puede reclamar los fondos de la dirección de Taproot del depósito anterior solicitando reembolso después de adelantar los fondos de retiro al usuario. Después de que finalice el período de desafío, el Operador puede retirar una cierta cantidad de depósitos de usuario.

En la solución del puente BitVM, existe una Federación BitVM (Federación BitVM) formada por N miembros, quienes programan los depósitos de los usuarios. Sin embargo, estos N miembros no pueden apropiarse de los depósitos de los usuarios de forma privada, porque los usuarios requerirán que la Alianza BitVM firme previamente antes de transferir dinero a la dirección designada para garantizar que estos depósitos solo puedan ser reclamados legalmente por el Operador.

(Diagrama de la solución de puente optimista de BitVM2)

Para resumir a un alto nivel, BitVM Bridge adopta ideas similares a los canales y las redes de rayos, lo que permite a los usuarios “verificar por sí mismos” y evitar que la Alianza BitVM manipule el grupo de depósitos sin autorización a través de la pre-firma. El dinero en el grupo de depósitos solo se puede usar para reembolsar al Operador. Si un operador tergiversa el monto anticipado, cualquier persona puede presentar una prueba de fraude y desafiarlo.

Si la solución anterior se puede implementar, el puente BitVM se convertirá en uno de los puentes de retiro de Bitcoin más seguros: No hay problemas de seguridad con este puente, solo problemas de disponibilidad/vivacidad. Cuando los usuarios intentan depositar fondos en BitVM, pueden ser censurados o rechazados a cooperar por la Alianza BitVM, lo que resulta en la imposibilidad de depositar fondos con éxito. Sin embargo, esto no tiene nada que ver con la seguridad, sino que es un problema de vivacidad/disponibilidad.

Sin embargo, la implementación del puente BitVM es relativamente difícil. Además, no puede satisfacer las necesidades de algunos inversionistas grandes que tienen requisitos relativamente altos de transparencia de fondos: estas personas pueden estar involucradas en problemas de lavado de dinero y no desean mezclar sus propios fondos con los fondos de otras personas, pero el puente BitVM aceptará uniformemente el dinero de los depositantes, de cierta manera, es un fondo donde se mezcla una gran cantidad de dinero.

Para resolver el problema de actividad del puente BitVM mencionado anteriormente y proporcionar un canal de entrada y salida de fondos independiente y limpio para personas con necesidades específicas, el equipo de BitLayer ha añadido una solución adicional de puente entre cadenas llamada OP-DLC. Además del puente optimista de BitVM2, se utiliza un puente DLC similar a DLC.link. Proporcionar a los usuarios dos entradas y salidas, el puente BitVM y el puente OP-DLC, para reducir la dependencia en el puente BitVM e incluso en la Alianza BitVM.

(diagrama esquemático de DLC)

DLC: Contrato de Registro Cauteloso

DLC (Discreet Log Contracts) se llama contrato de registro discreto. Fue propuesto por la Iniciativa de Moneda Digital del MIT. Esta tecnología se utilizó por primera vez para implementar un contrato inteligente ligero en Bitcoin. No requiere que el contenido del contrato se cargue en la cadena. A través de métodos como la comunicación interactiva fuera de la cadena y la pre-firma, se implementan funciones de contrato inteligente que protegen la privacidad en la cadena de Bitcoin. A continuación, utilizamos un caso de apuestas para ilustrar el principio de funcionamiento de DLC.

Supongamos que Alice y Bob quieren apostar por el resultado del partido entre Real Madrid y Barcelona que se celebrará tres días después, y cada uno de ellos paga 1 btc. Si gana Real Madrid, Alice puede obtener 1.5 BTC y Bob solo puede recuperar 0.5 BTC, lo que equivale a que Alice gane 0.5 BTC y Bob pierda 0.5 BTC; si gana Barcelona, Alice solo puede recuperar 0.5 BTC y Bob puede llevarse 1.5 BTC. Si hay un empate, ambos jugadores recuperarán 1 BTC cada uno.

Si queremos hacer el proceso de apuestas anterior sin confianza, debemos encontrar formas de evitar que cualquier parte haga trampa. Si simplemente usamos firmas múltiples 2/2 o firmas múltiples 2/3, obviamente no es lo suficientemente confiable. DLC proporciona su propia solución a este problema (confiando en oráculos de terceros). Todo el flujo de trabajo se puede dividir aproximadamente en cuatro partes.

Tomando el ejemplo anterior de Alice y Bob, primero, ambas partes crean una transacción de fondos fuera de la cadena, que puede bloquear 1 BTC de cada uno en la dirección de multi-firma 2/2., si esta transacción de fondos tiene efecto, los 2 BTC en la dirección de multi-firma necesitan ser autorizados por ambas partes antes de que puedan ser gastados.

Por supuesto, esta transacción del Fondo aún no se ha subido a la cadena, sino que permanece local para los clientes de Alice y Bob fuera de la cadena. Todos saben cuáles serán las consecuencias después de que esta transacción entre en vigor. En la actualidad, las dos partes solo están realizando deducciones teóricas y luego alcanzando una serie de acuerdos basados en los resultados de las deducciones.

En la primera fase de la creación de DLC, lo que podemos determinar es que, Ambas partes bloquearán sus 1 BTC en una dirección multi-firma en el futuro.

En el segundo paso, ambas partes continúan deduciendo posibles eventos y resultados futuros: Por ejemplo, cuando se anuncian los resultados del partido de fútbol, puede haber múltiples posibilidades como Alice ganando y Bob perdiendo, Alice perdiendo y Bob ganando, un empate, etc. Esto llevará a diferentes resultados de distribución de los Bitcoins en la dirección de firma múltiple 2/2 mencionada anteriormente.

Diferentes resultados deben ser desencadenados por diferentes instrucciones comerciales. Estas "Instrucciones de transacción que pueden ser cargadas en la cadena en el futuro" se llaman CET, es decir, Transacción de Ejecución de Contrato. Alice y Bob deben deducir todos los CET de antemano y generar un conjunto de datos de transacción que contenga todos los CET.

Por ejemplo, Basándose en los posibles resultados de la apuesta entre Alice y Bob mencionada anteriormente, Alice crea los siguientes CETs:

CET1: Alice puede obtener 1.5 BTC de la dirección multi-firma, y Bob puede obtener 0.5 BTC;

CET2: Alice puede obtener 0.5 BTC de la dirección multi-firma, y Bob puede obtener 1.5 BTC;

CET3: Ambas partes pueden recibir 1 BTC cada uno.

Tomemos CET1 como ejemplo (Alice recibe 1.5 BTC, Bob recibe 0.5 BTC):

El significado de esta transacción es transferir 1.5 BTC a la dirección de firma múltiple a una dirección Taproot que se activa por los resultados de salida de Alice y la máquina oráculo, y transferir los otros 0.5 BTC a la dirección de Bob. Los eventos correspondientes en este momento son: Real Madrid gana, Alice gana 0.5 BTC y Bob pierde 0.5 BTC.

Sin duda, para gastar estos 1.5 BTC, Alice debe recibir la firma del resultado "Real Madrid gana" enviada por el oráculo. En otras palabras, solo cuando el oráculo emita el mensaje "Real Madrid gana" puede Alice transferir los 1.5 BTC. En cuanto a los contenidos de CET2 y CET3, podemos deducirlos de la misma manera y no entraremos en detalles aquí.

Cabe destacar que CET es esencialmente una transacción que debe cargarse en la cadena para que tenga efecto. ¿Qué sucederá si Alice transmite CET1 de antemano, o en el caso de "Barcelona gana", todavía coloca CET1 en la cadena que solo se puede activar con éxito después de que "Real Madrid gana"?

En el diagrama anterior, mencionamos que después de que se coloque CET1 en la cadena, los 2 BTC bloqueados en la dirección original de multi-firma serán transferidos, 0.5 BTC se transferirá a Bob y 1.5 BTC se transferirán a una dirección de Taproot. La máquina oráculo emite "Solo después de que gane el Real Madrid" puede Alice desbloquear los BTC bloqueados en la dirección de Taproot. Resultados como se muestra a continuación.

Al mismo tiempo, esta dirección de Taproot está sujeta a un bloqueo de tiempo. Si Alice no puede retirar con éxito 1.5 BTC dentro del período de ventana especificado por el bloqueo de tiempo, Bob tiene derecho a tomar el dinero directamente.

Por lo tanto, siempre y cuando el oráculo sea honesto, Alice no puede llevarse los 1.5 BTC. Cuando expire el período de bloqueo temporal, Bob puede llevarse los 1.5 BTC. Además de los 0.5 BTC transferidos directamente a Bob cuando CET1 se cargó en la cadena, todo el dinero finalmente pertenecerá a Bob.

Para Alice, sin importar si gana o pierde al final, lo más beneficioso que puede hacer es poner la cantidad correcta de CET en la cadena. Poner el CET inválido en la cadena hará que pierda más dinero.

De hecho, cuando se construyó el CET mencionado anteriormente, se mejoró la firma schnorr de Taproot, que se puede entender como el uso de la clave pública del oráculo + resultados del evento para construir direcciones independientes para diferentes resultados. Después de eso, solo cuando la máquina oráculo anuncie la firma correspondiente a un cierto resultado, se podrá gastar el BTC bloqueado en la dirección correspondiente al resultado.

Por supuesto, aquí hay una posibilidad adicional. ¿Qué pasa si Alicia sabe que ha perdido y simplemente no pone el CET1 que construyó en la cadena? Esto es fácil de resolver porque Bob puede construir un CET personalizado para el problema de 'Alicia pierde, Bob gana'. El efecto logrado por este CET es básicamente el mismo que el CET construido por Alicia, pero los detalles específicos son diferentes, aunque el resultado es el mismo.

Lo descrito anteriormente es el proceso de construcción de CET más crítico. El tercer paso de DLC es que Alice y Bob se comuniquen, verifiquen la transacción CET construida por la otra parte y pongan su propia firma en la CET. Después de que la verificación sea correcta, pueden confiar el uno en el otro e invertir cada uno 1 BTC, bloqueando las direcciones iniciales de multi-firma 2/2 mencionadas de Alice y Bob, y luego esperar a que una CET específica se cargue en la cadena para desencadenar el proceso posterior.

Finalmente, después de que la máquina oráculo anuncia los resultados y obtiene la firma de la máquina oráculo en los resultados, cualquiera de las partes puede colocar el CET correcto en la cadena y permitir que los 2 BTC bloqueados en la dirección de multi-firma sean redistribuidos. Si el perdedor coloca primero el CET incorrecto en la cadena, si colocas el CET correcto en la cadena, perderás todo tu dinero. Si colocas el CET correcto en la cadena, el perdedor puede recuperar 0.5 BTC.

Alguien puede preguntar, ¿Cómo es diferente el DLC de la firma múltiple regular 2/3? En primer lugar, si se firman más de 2/3, cualquier dos partes pueden coludir para robar todos los activos, y el DLC permite a los oponentes limitar todos los escenarios construyendo un CET establecido previamente. Incluso si el oráculo participa en la colusión, el daño causado suele ser limitado.

En segundo lugar, la firma múltiple requiere que todas las partes firmen transacciones específicas para ser cargadas en la cadena, mientras que en el entorno de DLC, el oráculo solo necesita firmar los resultados de eventos específicos. No necesita conocer el contenido de CET/transacciones que se cargarán en la cadena. Ni siquiera necesita saber que hay dos personas, Alice y Bob. Solo necesita actuar como un oráculo ordinario. Simplemente interactuar con el usuario normalmente como una máquina.

Podemos pensar que la esencia de DLC es transformar la confianza en participantes de firma múltiple en confianza en oráculos. Siempre y cuando la máquina oráculo no participe en malas acciones, se puede garantizar que el diseño del protocolo DLC es lo suficientemente confiable. Teóricamente, DLC puede utilizar un oráculo de tercera parte relativamente maduro y completo para evitar hacer el mal. DLC.link y BitLayer aprovechan esta característica de DLC para transferir el problema de confianza del puente al oráculo de tercera parte.

Además, el puente DLC de Bitlayer también admite nodos oráculo autoconstruidos, agregando una capa de prueba de fraude encima de esto. Cuando el oráculo autoconstruido coloca CET inválidos en la cadena, cualquiera puede desafiarlo. Con respecto al principio de su puente OP-DLC, lo describiremos brevemente a continuación.

Puente OP-DLC: Canal DLC + Prueba de Fraude

Explicamos el principio de funcionamiento del puente OP-DLC desde todo el proceso de depósito y retiro. Supongamos que Alice ahora deposita 1 BTC en L2 a través del puente OP-DLC, Según el mecanismo de transacción de dos pasos, el Sr. ALice genera una transacción de pre-fondo, como se muestra a continuación:

En realidad, primero transfiera 1 BTC a la dirección de Taproot controlada conjuntamente por Alice y los miembros de la Alianza BitVM, y luego inicie una serie de procesos para crear CET. Si un miembro de la Alianza del Puente BitVM se niega a cooperar con la solicitud de depósito de Alice, Alice puede retirar el dinero inmediatamente después de que expire el bloqueo de tiempo.

Si los miembros de la Alianza BitVM están dispuestos a cooperar con Alice, ambas partes pueden utilizar la comunicación fuera de la cadena para generar primero una transacción formal de depósito de Fondos (aún no en la cadena), así como todos los CET en el escenario de retiro. Después de que se complete la generación y verificación de los CET, ambas partes pueden enviar la transacción de Fondos a la cadena.

En los datos de Testigo/Firma de la transacción del Fondo, Alice especificará su dirección de pago en Capa 2; Después de que la transacción del Fondo se cargue en la cadena, Alice puede enviar los datos de la transacción del fondo mencionada al contrato puente en Capa 2 para demostrar que ha completado la acción de depósito en la cadena de Bitcoin y es elegible para que el contrato puente L2 libere Tokens a la dirección de pago designada.

Después de que se desencadena la transacción del Fondo, el depósito queda realmente bloqueado en la dirección de multi-firma Taproot controlada conjuntamente por Alice y los miembros de la alianza BitVM. Sin embargo, cabe señalar que la multi-firma solo puede desbloquear el BTC bloqueado por la dirección a través de CET, y la Alianza BitVM no puede transferir el dinero sin motivo alguno.

A continuación, analicemos los CET construidos con antelación por Alice y la Alianza BitVM. Estos CET se utilizan para cumplir con posibles escenarios de retiros futuros. Por ejemplo, Alice puede haber depositado 1 BTC, pero solo retiró 0.3 BTC durante su primer retiro, y los 0.7 BTC restantes fueron entregados al fondo público de la Alianza BitVM. Para controlar, pero si deseas retirar dinero, solo puedes hacerlo a través del puente BitVM mencionado anteriormente;

O simplemente use estos 0.7 BTC para iniciar un nuevo depósito de prefinanciación. Como un activo recién agregado al puente DLC, puede repetir el proceso de transacción de fondos y construcción de CET mencionado anteriormente.

El proceso anterior no es difícil de entender. De hecho, el depositante Alice y la alianza bitVM actúan como contrapartes entre sí, crean CET para eventos de retiro de diferentes cantidades, y luego permiten que el oráculo lea la declaración de retiro iniciada por Alice en Capa 2 para determinar qué transacción desea activar Alice. Uno CET (cuánto dinero desea retirar).

El riesgo aquí es que la máquina oráculo pueda coludir con la Alianza BitVM. Por ejemplo, Alice declara que quiere retirar 0.5 BTC, pero la máquina oráculo falsifica el estado de retiro, lo que lleva finalmente a "Alice retira 0.1 BTC y la Alianza BitVM recibe 0.9 BTC." Error CET en la cadena.

Hay varias soluciones a este problema. La primera es utilizar un oráculo de terceros con un diseño relativamente completo. Prevenir tal colusión (es extremadamente difícil para la Alianza BitVM coludirse con oráculos en este momento), o permitir que el oráculo realice staking. El oráculo necesita publicar regularmente Commitment en la cadena de Bitcoin, declarando que ha gestionado la solicitud de retiro del retirador de manera honesta. Cualquiera puede desafiar el Commitment a través del protocolo de prueba de fraude de BitVM. Si el desafío tiene éxito, el oráculo malicioso será penalizado.

Bajo el diseño del puente OP-DLC, los usuarios siempre pueden "participar" en sus propios activos para evitar que los activos sean malversados por la Alianza BitVM. Además, este diseño tipo canal brinda más autonomía a los usuarios, y tampoco es necesario mezclar sus propios fondos con los fondos de otras personas. Es más como una solución de depósito y retiro entre pares.

Además, dado que tomará algún tiempo para que la solución BitVM se implemente, antes de que se implemente, el puente DLC será un modelo de procesamiento de puente más confiable en comparación con la simple solución de multifuirma. Esta solución también se puede utilizar como dos principales entradas de depósito y retiro utilizadas en paralelo con el puente BitVM. Si una de ellas falla, el usuario puede utilizar la otra entrada, lo que también es un buen método de tolerancia a fallos.

Resumir

La solución de puente BitLayer y BitVM de Citrea es esencialmente un modelo de "pago anticipado-reembolso", hay un nodo de Operador dedicado para transferir dinero a los usuarios de retiro, y el Operador puede solicitar regularmente reembolsos a la dirección de depósito público. Si un operador realiza una solicitud de reembolso falsa, puede ser impugnado y reducido por cualquier persona.

La solución de BitVM2 presenta la pre-firma y combina la idea de un canal para permitir a los usuarios limitar el proceso de procesamiento posterior al depósito antes de realizar un depósito formal, y no dar a los funcionarios del puente entre cadenas la oportunidad de malversar los depósitos de los usuarios.

En teoría, no hay problemas de seguridad con este puente, pero hay problemas de vivacidad/disponibilidad, y no puede satisfacer las necesidades de usuarios específicos para la independencia de fondos y la lucha contra el lavado de dinero (esencialmente, es un modelo de fondo común), y también es muy difícil de implementar.

Con este fin, Bitlayer ha añadido una solución de puente llamada OP-DLC, que es similar a DLC.link e introduce una prueba de fraude sobre la base de canales y DLC para evitar que la máquina oráculo del puente DLC haga maldades.

Sin embargo, dado que BitVM es demasiado difícil de implementar, primero se implementará el puente DLC y se convertirá en un reemplazo temporal, siempre y cuando se resuelva el riesgo de confianza de la máquina oráculo y se integre una máquina oráculo de terceros más confiable y madura, el puente DLC puede convertirse en una solución más segura para la verificación de retiros que el puente de multisig en esta etapa.

Descargo de responsabilidad：

1. Este artículo es reimpreso de [极客web3]. Todos los derechos de autor pertenecen al autor original [Faust & Nickqiao]. Si hay objeciones a esta reimpresión, por favor contacte al Gate Learnequipo, y lo resolverán rápidamente.
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. Las traducciones del artículo a otros idiomas son realizadas por el equipo Gate Learn. A menos que se mencione, está prohibido copiar, distribuir o plagiar los artículos traducidos.