1. Introducción

El Contrato de Log Discreto (DLC) es un marco de ejecución de contratos basado en un Oráculo, propuesto por Tadge Dryja del Instituto de Tecnología de Massachusetts en 2018. DLC permite a dos partes ejecutar pagos condicionales basados en condiciones predefinidas. Las partes determinan posibles resultados, los firman previamente y utilizan estas prefirmas para ejecutar pagos cuando el Oráculo aprueba el resultado. Por lo tanto, DLC permite nuevas aplicaciones financieras descentralizadas al tiempo que garantiza la seguridad de los depósitos de Bitcoin.

En comparación con la Red Lightning, DLC tiene las siguientes ventajas significativas:

• Privacidad: DLC ofrece una mejor protección de la privacidad que la Red Lightning. Los detalles del contrato solo se comparten entre las partes involucradas y no se almacenan en la cadena de bloques. En contraste, las transacciones de la Red Lightning se enrutan a través de canales y nodos públicos, lo que hace que su información sea pública y transparente.
• Complejidad y flexibilidad de los contratos financieros: DLC puede crear y ejecutar directamente contratos financieros complejos en la red Bitcoin, como derivados, seguros y apuestas, mientras que la Red Lightning se utiliza principalmente para pagos rápidos de pequeño valor y no puede admitir aplicaciones complejas.
• Riesgo contraparte reducido: Los fondos de DLC están bloqueados en contratos multi-firma y solo se liberan cuando se produce el resultado de un evento predefinido, reduciendo el riesgo de que alguna de las partes no cumpla con el contrato. Aunque la Red Lightning reduce la necesidad de confianza, todavía conlleva ciertos riesgos de contraparte en la gestión de canales y provisión de liquidez.
• No es necesario gestionar canales de pago: las operaciones de DLC no requieren la creación o mantenimiento de canales de pago, que son fundamentales para la Red Lightning y implican una gestión compleja y intensiva en recursos.
• Escalabilidad para casos de uso específicos: Si bien la Red Lightning aumenta en cierta medida la capacidad de transacción de Bitcoin, DLC ofrece una mejor escalabilidad para contratos complejos en Bitcoin.

Aunque los DLCs tienen ventajas significativas en el ecosistema de Bitcoin, todavía existen algunos riesgos y problemas, como:

• Riesgo clave: Existe el riesgo de fuga o pérdida de las claves privadas de Oracle y los nonces comprometidos, lo que conlleva la pérdida de activos del usuario.
• Riesgo de confianza centralizada: la centralización en los Oracles puede llevar fácilmente a ataques de denegación de servicio.
• Problema de derivación descentralizada de claves: Si el Oráculo es descentralizado, los nodos del Oráculo solo poseen partes de la clave privada. Sin embargo, los nodos del Oráculo descentralizados no pueden usar directamente BIP32 para la derivación de claves basada en estas partes de la clave privada.
• Riesgo de colusión: Si los nodos de Oracle coluden entre sí o con una parte, el problema de confianza con los Oracles permanece sin resolver. Se necesita un mecanismo de monitoreo confiable para minimizar la confianza en los Oracles.
• Problema de Cambio de Denominación Fija: Las firmas condicionales requieren un conjunto determinístico y enumerable de eventos antes de construir el contrato para construir la transacción. Por lo tanto, el uso de DLC para la reasignación de activos tiene una restricción de cantidad mínima, lo que conduce al problema de cambio de denominación fija.

Para abordar estos problemas, este documento propone varias soluciones e ideas de optimización para mitigar los riesgos y problemas asociados con los DLC, mejorando así la seguridad del ecosistema de Bitcoin.

2. Principio de DLC

Alice y Bob entran en un acuerdo de apuestas sobre si el valor hash del bloque (n+k) es impar o par. Si es impar, Alice gana el juego y puede retirar los activos dentro del tiempo t; si es par, Bob gana el juego y puede retirar los activos dentro del tiempo t. Utilizando DLC, la información del bloque (n+k) se transmite a través de un Oráculo para construir una firma condicional, asegurando que el ganador correcto reciba todos los activos.

Inicialización: El generador de la curva elíptica es G, y su orden es q.

Generación de claves: El Oráculo, Alice y Bob generan independientemente sus propias claves privadas y públicas.

• La clave privada del Oráculo es z, y su clave pública es Z, satisfaciendo Z=z⋅G;
• La clave privada de Alice es x, y su clave pública es X, satisfaciendo X=x⋅G;
• La clave privada de Bob es y, y su clave pública es Y, satisfaciendo Y=y⋅G.

Transacción de financiamiento: Alice y Bob crean juntos una transacción de financiamiento, bloqueando 1 BTC cada uno en una salida multi-firma 2-de-2 (una clave pública X pertenece a Alice y la otra Y a Bob).

Transacciones de Ejecución de Contratos (CET): Alice y Bob crean dos CET para gastar la transacción de financiación.

El Oráculo calcula el compromiso

y luego calcula S y S′

y transmite (R, S, S′).

Alice y Bob calculan cada uno la nueva clave pública correspondiente

Liquidación: Después de que aparezca el (n+k)-ésimo bloque, el Oráculo genera el valor correspondiente s o s′ basado en el valor hash de ese bloque.

• Si el valor hash del bloque (n+k) es impar, el Oráculo calcula y transmite

• Si el valor hash del bloque (n+k) es par, el Oráculo calcula y transmite

Retiro: Tanto Alice como Bob pueden retirar los activos basados en el s o s' transmitidos por el Oracle.

• Si el Oráculo transmite s, Alice puede calcular la nueva clave privada sk^{Alice} y retirar los 2 BTC bloqueados

• Si el Oráculo transmite s′, Bob puede calcular la nueva clave privada sk^{Bob} y retirar los 2 BTC bloqueados

Análisis: La nueva clave privada sk^{Alice} calculada por Alice y la nueva clave pública PK^{Alice} satisfacen la relación de logaritmo discreto

Por lo tanto, la retirada de Alice será exitosa.

De manera similar, la nueva clave privada sk^{Bob} calculada por Bob y la nueva clave pública PK^{Bob} satisfacen la relación del logaritmo discreto

Por lo tanto, la retirada de Bob será exitosa.

Además, si el Oráculo transmite s, es útil para Alice, pero no para Bob porque Bob no puede calcular la nueva clave privada correspondiente sk^{Bob}. Del mismo modo, si el Oráculo transmite s′, es útil para Bob, pero no para Alice, porque Alice no puede calcular la nueva clave privada correspondiente sk^{Alice}. Por último, la descripción anterior omite el bloqueo temporal. Se debe agregar un bloqueo temporal para permitir que una de las partes calcule la nueva clave privada y retire dentro del tiempo t. De lo contrario, si excede el tiempo t, la otra parte puede usar la clave privada original para retirar los activos.

3. Optimizaciones de DLC

3.1 Gestión de claves

En el protocolo DLC, la clave privada del Oráculo y el nonce comprometido son cruciales. La filtración o pérdida de la clave privada del Oráculo y el nonce comprometido puede llevar a los siguientes cuatro problemas de seguridad:

(1) Oracle Pierde Clave Privada z

Si el Oracle pierde su clave privada, el DLC no puede liquidarse, lo que hace necesario ejecutar un contrato de reembolso de DLC. Por lo tanto, el protocolo DLC incluye una transacción de reembolso para prevenir las consecuencias de que el Oracle pierda su clave privada.

(2) Fuga de la clave privada de Oracle z

Si la clave privada del Oráculo se filtra, todos los DLC basados en esa clave privada enfrentan el riesgo de liquidación fraudulenta. Un atacante que roba la clave privada puede firmar cualquier mensaje deseado, obteniendo control completo sobre los resultados de todos los contratos futuros. Además, el atacante no se limita a emitir un solo mensaje firmado, sino que también puede publicar mensajes conflictivos, como firmar que el valor hash del (n+k)-ésimo bloque es tanto impar como par.

(3) Fuga o Reutilización de Nonce k de Oracle

Si el Oráculo filtra el nonce k, entonces en la fase de liquidación, independientemente de si el Oráculo transmite s o s′, un atacante puede calcular la clave privada z del Oráculo de la siguiente manera:

Si el Oráculo reutiliza el nonce k, entonces después de dos liquidaciones, un atacante puede resolver el sistema de ecuaciones basado en las firmas de transmisión del Oráculo para deducir la clave privada z del Oráculo en uno de los cuatro escenarios posibles,

caso 1:

caso 2:

caso 3:

caso 4:

(4) Oracle Pierde Nonce k

Si el Oráculo pierde el nonce k, el DLC correspondiente no puede liquidarse, lo que hace necesario ejecutar un contrato de reembolso de DLC.

Por lo tanto, para mejorar la seguridad de la clave privada del Oráculo, es recomendable utilizar BIP32 para derivar claves secundarias o nietas para firmar. Además, para aumentar la seguridad del nonce, el valor hash k:=hash(z, counter) debe utilizarse como el nonce k, para evitar la repetición o pérdida del nonce.

3.2 Oráculo descentralizado

En DLC, el papel del Oráculo es crucial ya que proporciona datos externos clave que determinan el resultado del contrato. Para mejorar la seguridad de estos contratos, se requieren Oráculos descentralizados. A diferencia de los Oráculos centralizados, los Oráculos descentralizados distribuyen la responsabilidad de proporcionar datos precisos e inalterables entre múltiples nodos independientes, reduciendo el riesgo asociado con un único punto de falla y disminuyendo la probabilidad de manipulación o ataques dirigidos. Con un Oráculo descentralizado, los DLC pueden lograr un mayor grado de confianza y fiabilidad, asegurando que la ejecución del contrato dependa completamente de la objetividad de las condiciones predeterminadas.

Las firmas de umbral de Schnorr se pueden utilizar para implementar Oráculos descentralizados. Las firmas de umbral de Schnorr ofrecen las siguientes ventajas:

• Seguridad mejorada: Al distribuir la gestión de claves, las firmas de umbral reducen el riesgo de puntos únicos de fallo. Incluso si las claves de algunos participantes se ven comprometidas o atacadas, el sistema completo sigue siendo seguro siempre que la violación no supere un umbral predefinido.
• Control Distribuido: Las firmas de umbral permiten el control distribuido sobre la gestión de claves, eliminando una entidad única que posea todos los poderes de firma, reduciendo así los riesgos asociados con la concentración de poder.
• Disponibilidad mejorada: las firmas pueden completarse siempre y cuando un cierto número de nodos de Oracle estén de acuerdo, aumentando la flexibilidad y disponibilidad del sistema. Incluso si algunos nodos no están disponibles, la fiabilidad general del sistema no se ve afectada.
• Flexibilidad y escalabilidad: El protocolo de firma de umbral puede establecer diferentes umbrales según sea necesario para cumplir con varios requisitos de seguridad y escenarios. Además, es adecuado para redes a gran escala, ofreciendo una buena escalabilidad.
• Responsabilidad: Cada nodo de Oracle genera una parte de firma basada en su parte de clave privada, y otros participantes pueden verificar la corrección de esta parte de firma usando la parte de clave pública correspondiente, lo que permite la responsabilidad. Si es correcta, estas partes de firma se acumulan para producir una firma completa.

Por lo tanto, el protocolo de firma de umbral de Schnorr tiene ventajas significativas en los oráculos descentralizados en cuanto a mejorar la seguridad, confiabilidad, flexibilidad, escalabilidad y responsabilidad.

3.3 Acoplamiento de la Descentralización y la Gestión de Claves

En la tecnología de gestión de claves, un Oráculo posee una clave completa z y, utilizando BIP32 junto con incrementos ω, puede derivar una multitud de claves secundarias z+ω^{(1)} y claves nietas z+ω^{(1)}+ω^{(2)}. Para diferentes eventos, el Oráculo puede usar varias claves privadas nietas z+ω^{(1)}+ω^{(2)} para generar firmas correspondientes σ para los eventos respectivos msg.

En el escenario de Oracle descentralizado, hay n participantes, y una firma de umbral requiere t+1 participantes, donde t < n. Cada uno de los nodos Oracle n posee una parte de clave privada z_i, i=1,...,n. Estas n partes de clave privada z_i corresponden a una clave privada completa z, pero la clave privada completa z nunca aparece. Bajo la condición de que la clave privada completa z no aparezca, t+1 nodos Oracle utilizan sus partes de clave privada z_i, i=1,...,t+1 para generar partes de firma σ_i' para el mensaje msg', y estas partes de firma σ_i' se combinan en una firma completa σ'. Los validadores que utilizan la clave pública completa Z pueden verificar la corrección del par mensaje-firma (msg',σ'). Dado que se requiere que t+1 nodos Oracle generen colectivamente la firma de umbral, proporciona alta seguridad.

Sin embargo, en un escenario de Oracle descentralizado, la clave privada completa z no aparece, por lo que la derivación de clave directa utilizando BIP32 no es posible. En otras palabras, la tecnología de Oracle descentralizado y la tecnología de gestión de claves no se pueden integrar directamente.

El papel "Derivación de claves distribuida para la gestión multiparte de activos digitales de blockchainPropone un esquema de derivación de clave distribuida en escenarios de firma de umbral. La idea principal se basa en polinomios de interpolación de Lagrange, donde la parte de la clave privada z_i y la clave privada completa z satisfacen la siguiente relación de interpolación:

Añadiendo el incremento ω a ambos lados de la ecuación se obtiene:

Esta ecuación muestra que la parte de la clave privada z_i más el incremento ω todavía satisface la relación de interpolación con la clave privada completa z más ω. En otras palabras, la parte de la clave privada hija z_i+ω y la clave hija z+ω satisfacen la relación de interpolación. Por lo tanto, cada participante puede usar su parte de la clave privada z_i más el incremento ω para derivar la parte de la clave privada hija z_i+ω, utilizada para generar partes de firma hijas, y validarlas usando la clave pública hija correspondiente Z+ω⋅G.

Sin embargo, se debe considerar BIP32 endurecido y no endurecido. BIP32 endurecido toma la clave privada, el código de la cadena y la ruta como entrada, realiza SHA512 y produce el incremento y el código de la cadena hijo. Por otro lado, BIP32 no endurecido toma la clave pública, el código de la cadena y la ruta como entrada, realiza SHA512 y produce el incremento y el código de la cadena hijo. En un escenario de firma de umbral, la clave privada no existe, por lo que solo se puede utilizar BIP32 no endurecido. O, utilizando una función de hash homomórfica, se puede aplicar BIP32 endurecido. Sin embargo, una función de hash homomórfica difiere de SHA512 y no es compatible con el BIP32 original.

3.4 OP-DLC: Oracle Trust-minimized

En el DLC, el contrato entre Alice y Bob se ejecuta en función del resultado firmado del Oráculo, lo que requiere un cierto nivel de confianza en el Oráculo. Por lo tanto, el comportamiento correcto del Oráculo es una premisa importante para el funcionamiento del DLC.

Para reducir la confianza en el Oracle, se ha llevado a cabo investigaciones sobre la ejecución de DLC basado en los resultados de n Oracles, disminuyendo la dependencia de un solo Oracle.

• El modelo “n-of-n” implica usar n Oráculos para firmar el contrato y ejecutar el contrato basado en los resultados de todos los Oráculos. Este modelo requiere que todos los Oráculos estén en línea para firmar. Si algún Oráculo se desconecta o hay un desacuerdo sobre los resultados, afecta la ejecución del contrato de DLC. La suposición de confianza aquí es que todos los Oráculos son honestos.
• El modelo "k-of-n" implica usar n Oráculos para firmar el contrato, ejecutando el contrato basado en los resultados de cualquier k Oráculos. Si más de k Oráculos conspiran, afecta la ejecución justa del contrato. Además, el número de CETs requeridos en el modelo "k-of-n" es C_n^k veces el de un solo Oráculo o el modelo "n-of-n". La suposición de confianza en este modelo es que al menos k de n Oráculos son honestos.

Simplemente aumentar el número de Oráculos no logra la desconfianza de los Oráculos porque, después de acciones maliciosas por parte de un Oráculo, la parte perjudicada en el contrato no tiene recurso en cadena.

Por lo tanto, proponemos OP-DLC, que incorpora un mecanismo de desafío optimista en DLC. Antes de participar en el establecimiento del DLC, los n Oráculos deben hacer una promesa y construir un juego OP sin permisos en la cadena de bloques de antemano, comprometiéndose a no actuar maliciosamente. Si algún Oráculo actúa maliciosamente, entonces Alice, Bob, cualquier otro Oráculo honesto u cualquier otro observador honesto de terceros puede iniciar un desafío. Si el desafiante gana el juego, el sistema en cadena penaliza al Oráculo malicioso al confiscar su depósito. Además, OP-DLC también puede adoptar el modelo "k-de-n" para firmar, donde el valor de k puede incluso ser 1. Por lo tanto, la suposición de confianza se reduce a solo necesitar un participante honesto en la red para iniciar un desafío OP y penalizar a un nodo Oráculo malicioso.

Al liquidar OP-DLC basado en los resultados de la computación de la Capa 2:

• Si un Oráculo firma con resultados incorrectos, causando que Alice sufra una pérdida, Alice puede usar los resultados correctos de cálculo de Capa 2 para desafiar el juego OP sin permiso anticipado del Oráculo. Ganando el juego, Alice puede penalizar al Oráculo malicioso y compensar su pérdida.
• De manera similar, Bob, otros nodos honestos del Oráculo y observadores honestos de terceros también pueden iniciar desafíos. Sin embargo, para evitar desafíos maliciosos, el retador también debe comprometerse.

Por lo tanto, OP-DLC facilita la supervisión mutua entre los nodos oráculo, minimizando la confianza depositada en los oráculos. Este mecanismo solo requiere un participante honesto y tiene una tolerancia a fallos del 99%, abordando eficazmente el riesgo de colusión de oráculos.

3.5 OP-DLC + Puente Dual BitVM

Cuando se utiliza DLC para puentes entre cadenas, la distribución de fondos debe ocurrir en el momento de liquidación del contrato DLC:

• Necesita preajustarse a través de CETs, lo que significa que la granularidad de liquidación de fondos de DLC está limitada, como 0.1 BTC en la red Bison. Esto plantea un problema: las interacciones de activos de Capa 2 para los usuarios no deben estar restringidas por la granularidad de fondos de los CETs de DLC.
• Cuando Alice desea liquidar sus activos de Capa 2, fuerza la liquidación de los activos de Capa 2 del usuario Bob a la Capa 1 también. Esto plantea un problema: cada usuario de Capa 2 debería tener la libertad de elegir sus depósitos y retiros de forma independiente de las acciones de otros usuarios.
• Alice y Bob negocian el gasto. El problema aquí es que requiere que ambas partes estén dispuestas a cooperar.

Por lo tanto, para abordar el problema mencionado anteriormente, proponemos el puente dual OP-DLC + BitVM. Esta solución permite a los usuarios depositar y retirar a través del puente sin permisos de BitVM, así como a través del mecanismo OP-DLC, logrando cambios en cualquier grado y mejorando la liquidez.

En el OP-DLC, el Oráculo es la federación BitVM, con Alice como usuario regular y Bob como la federación BitVM. Al configurar OP-DLC, los CETs construidos permiten el gasto inmediato de la salida de Alice en la Capa 1, mientras que la salida de Bob incluye un “juego DLC al que Alice puede desafiar” con un período de bloqueo temporal. Cuando Alice quiera retirarse:

• Si la federación BitVM, actuando como el Oráculo, firma correctamente, Alice puede retirar en la Capa 1. Sin embargo, Bob puede retirar en la Capa 1 después del período de bloqueo temporal.
• Si la federación de BitVM, actuando como el Oráculo, hace trampa, causando una pérdida a Alice, ella puede desafiar el UTXO de Bob. Si el desafío tiene éxito, la cantidad de Bob puede ser confiscada. Nota: otro miembro de la federación de BitVM también puede iniciar el desafío, pero Alice, al ser la parte perjudicada, es la más motivada para hacerlo.
• Si la federación BitVM, actuando como el Oráculo, engaña, causando una pérdida a Bob, un miembro honesto de la federación BitVM puede desafiar el "juego BitVM" para penalizar al nodo oráculo tramposo.

Además, si el usuario Alice quiere retirarse de la Capa 2 pero los CET preestablecidos en el contrato OP-DLC no coinciden con la cantidad, Alice puede elegir los siguientes métodos:

• Retirarse a través de BitVM, con el operador de BitVM adelantando la cantidad en la Capa 1. El puente de BitVM asume que hay al menos un participante honesto en la federación de BitVM.
• Retirar a través de un CET específico en OP-DLC, con el cambio restante proporcionado por el operador de BitVM en la Capa 1. Retirar a través de OP-DLC cerrará el canal DLC, pero los fondos restantes en el canal DLC se moverán al pool de la Capa 1 de BitVM, sin obligar a otros usuarios de la Capa 2 a retirarse. El puente OP-DLC asume que hay al menos un participante honesto en el canal.
• Alice y Bob negocian gastos sin la participación de un Oráculo, requiriendo cooperación de Bob.

Por lo tanto, el puente dual OP-DLC + BitVM ofrece las siguientes ventajas:

• BitVM resuelve el problema de cambio del canal DLC, reduce la cantidad de CET requeridos y no se ve afectado por la granularidad de los fondos CET;
• Al combinar el puente OP-DLC con el puente BitVM, proporciona a los usuarios múltiples canales para depósitos y retiros, mejorando la experiencia del usuario;
• Establecer el consorcio BitVM tanto como Bob y el oráculo, y utilizar el mecanismo OP, minimiza la confianza en el oráculo;
• Integrar el retiro excedente del canal DLC en el pool del puente BitVM mejora la utilización de fondos.

4. Conclusión

DLC surgió antes de la activación de Segwit v1 (Taproot) y ya ha sido integrado con la Red Lightning, lo que permite la extensión de DLC para actualizar y ejecutar contratos continuos dentro del mismo canal de DLC. Con tecnologías como Taproot y BitVM, se pueden implementar verificaciones y liquidaciones de contratos fuera de la cadena más complejos dentro de DLC. Además, al integrar el mecanismo de desafío OP, es posible minimizar la confianza en los Oráculos.

Declaración:

1. Este artículo es una reimpresión de medio, originalmente titulado “Tecnología base de Bitlayer: DLC y sus consideraciones de optimización”. Los derechos de autor pertenecen al autor original, Bitlayer. Si hay alguna objeción a esta reimpresión, por favor contacte al Equipo de Gate Learn. El equipo lo manejará de acuerdo con los procedimientos pertinentes lo más rápido posible.

2. Descargo de responsabilidad: Las opiniones expresadas en este artículo representan únicamente las opiniones personales del autor y no constituyen ningún consejo de inversión.

3. Otras versiones del artículo en otros idiomas han sido traducidas por el equipo de Gate Learn. Sin mencionar de Gate.io, los artículos traducidos no pueden ser copiados, difundidos o plagiados.