Título original: "Tecnología Bitlayer Core: DLC y sus consideraciones de optimización"
Autor original: mutourend lynndell, Bitlayer Research Group
1. Introducción
Discreet Log Contract (DLC) es un marco de ejecución de contratos basado en Oracle propuesto por Tadge Dryja del MIT en 2018. DLC permite que dos partes realicen pagos condicionales según condiciones predefinidas. Ambas partes predeterminan y firman previamente los posibles resultados, y utilizan estas firmas previas para ejecutar el pago cuando el oráculo firma los resultados. Por lo tanto, DLC permite nuevas aplicaciones financieras descentralizadas al tiempo que garantiza la seguridad de los depósitos de Bitcoin.
El artículo anterior "Análisis de los principios de DLC y pensamientos de optimización" resumió las ventajas de DLC en términos de protección de la privacidad, contratos complejos y bajo riesgo de activos. También analizó la existencia de riesgos clave, riesgos de confianza descentralizada, riesgos de colusión, etc. problemas de DLC e introducir oráculos descentralizados, firmas de umbral, mecanismos de desafío optimistas, etc. en DLC para resolver varios problemas que debería enfrentar. Dado que el DLC involucra a tres partes: el oráculo, Alice y Bob, es relativamente complejo para diferentes partes confabularse para atacar exhaustivamente, lo que resulta en una estrategia de prevención relativamente compleja. Las estrategias de defensa complejas no son perfectas, no se ajustan al principio de simplicidad y carecen de la belleza de la simplicidad.
En Bitcoin, cualquier comportamiento de cualquier participante debe implementarse a través de UTXO. Por lo tanto, utilizar el mecanismo de consenso para garantizar que UTXO sea correcto puede resistir ataques arbitrarios. De manera similar, en DLC, cualquier comportamiento de cualquier participante debe implementarse a través de CET (Transacción de ejecución de contrato). Por lo tanto, utilizar el mecanismo de desafío optimista para garantizar que CET sea correcto puede resistir cualquier ataque. Específicamente, después de que el oráculo prometa 2B TC, puede firmar CET. Agregar un mecanismo de desafío optimista al CET. Si CET no es cuestionado o responde con éxito al desafío, CET es correcto y se puede completar la liquidación, y el oráculo no está comprometido y recibe tarifas de manejo. Si el Oráculo intenta hacer el mal, cualquiera puede desafiar con éxito, el CET no lo será; Se liquida y el oráculo perderá. El depósito se deposita y el oráculo no puede volver a firmar el mismo CET. En consonancia con la gran sencillez, tiene la belleza de la sencillez.
2.Principio DLC
Alice y Bob firman un acuerdo de apuestas: apuestan a que el valor hash del ξésimo bloque es un número par o impar. Si es un número impar, Alice gana el juego y puede retirar los activos; si es un número par, Bob gana el juego y puede retirar los activos. Usando DLC, la información del bloque ξ se pasa a través del oráculo para construir una firma condicional de modo que el ganador correcto gane todos los activos.
El generador de la curva elíptica es G y el orden es q. Los pares de claves del oráculo, Alice y Bob, son (z, Z), (x, X), (y, Y) respectivamente.
Transacción de financiación (en cadena): Alice y Bob crean una transacción de financiación juntos, cada uno de los cuales bloquea 10 BTC en una salida de firma múltiple 2 de 2 (una clave pública X pertenece a Alice y una clave pública Y pertenece a Bob). .
Construcción de CET (fuera de la cadena): Alice y Bob crean CET 1 y CET 2 para gastar transacciones de inyección de capital.
El oráculo calcula el compromiso R = k · G, luego calcula S y S'
S := R - hash(NúmeroImpar, R) · Z
S' := R - hash(NúmeroPar, R) · Z
Entonces las nuevas claves públicas correspondientes a Alice y Bob son las siguientes:
PK^{Alicia} := X + S
PK^{Bob} := Y + S'.
Liquidación (fuera de la cadena -> dentro de la cadena): cuando el ξésimo bloque se genera con éxito, el oráculo firmará el CET 1 o CET 2 correspondiente según el valor hash del bloque.
Si el hash es impar, el oráculo firma s de la siguiente manera
s := k - hash(NúmeroImpar, R) z
Emisión CET 1.
Si el hash es par, el oráculo firma s'
s' := k - hash(NúmeroPar, R) z
Emisión CET 2.
Retirar monedas (en cadena): si el oráculo transmite CET 1, Alice puede calcular la nueva clave privada y gastar los 20 BTC bloqueados.
sk^{Alicia} = x + s
Si el oráculo transmite CET 2, Bob puede calcular la nueva clave privada y gastar los 20 BTC bloqueados.
sk^{Bob} = y + s'
El equipo de investigación de Bitlayer descubrió que en el proceso anterior, cualquier comportamiento debe implementarse a través de CET. Por lo tanto, sólo es necesario utilizar el mecanismo de desafío optimista para garantizar que CET sea correcto y pueda resistir cualquier ataque. Los CET incorrectos serán impugnados y no ejecutados, mientras que los CET correctos sí se ejecutarán. Además, el oráculo debe pagar un precio por el comportamiento malicioso.
El programa a desafiar es f(t), entonces CET debe construirse de la siguiente manera
s = k - hash(f(t), R) z.
Supongamos que la situación real es que el valor hash del ξésimo bloque es un número impar, es decir, f (ξ) = OddNumber, y el oráculo debe firmar CET 1
s := k - hash(NúmeroImpar, R) z.
Sin embargo, el oráculo hizo algo malo y cambió el valor de la función a Par, firmando CET 2:
s' := k - hash(NúmeroPar, R) z.
Por lo tanto, cualquier usuario puede vencer este comportamiento malicioso según f(ξ) ≠ OddNumber.
3.OP-DLC 2
OP-DLC incluye las siguientes 5 disposiciones:
El oráculo está compuesto por una alianza. Hay n participantes en la alianza y cualquier miembro puede firmar CET. Sólo prometiendo 2B TC la máquina Oracle puede emitir firmas y ganar tarifas de gestión. Si un miembro hace el mal, se pierde la apuesta. Otros miembros pueden continuar firmando CET para garantizar que los usuarios puedan retirar fondos. Alice y Bob también pueden convertirse en oráculos, confiando verdaderamente sólo en ellos mismos y minimizando la confianza.
Si el oráculo hace algo malo y modifica el resultado, inevitablemente conducirá a la situación en la que f 1(ξ) ≠ z 1, f 2(z 1) ≠ z 2. Por lo tanto, cualquier participante puede iniciar un desafío, es decir, realizar una transacción Disprove-CET 1.
Si el oráculo firma CET honestamente, ninguna de las partes puede iniciar una transacción de refutación válida. Después de 1 semana, el CET se podrá liquidar correctamente. Además, la máquina Oracle recibe una recompensa de 0,05 BTC como la ocupación de capital de 1 semana de sus 2B TC prometidos y la tarifa de gestión por firmar honestamente CET.
Cualquier participante puede desafiar Oracle_sign:
Si Oracle_sign es honesto, no se puede iniciar la transacción Disprove-CET 1 y la liquidación CET se ejecutará después de 1 semana. Además, la máquina Oracle se compromete a desbloquearse y recibir tarifas de gestión;
Si Oracle_sign es deshonesto, es decir, alguien inicia con éxito una transacción Disprove-CET 1 y gasta con éxito la salida del conector A, la firma del oráculo no será válida, el TC 2B prometido se perderá y el oráculo ya no podrá para usarlo en el futuro El contrato DLC inicia una firma con el mismo resultado, porque el Settle-CET 1 que depende de la salida del conector A quedará permanentemente inválido.
Los desafíos en OP-DLC no tienen permiso, es decir, cualquier participante puede supervisar si el contrato en OP-DLC se ejecuta correctamente. Por tanto, se minimiza la confianza en el oráculo. En comparación con Lightning Network, Alice y Bob también pueden estar desconectados. Porque el oráculo resolverá el CET sólo con firmas honestas, y los oráculos malvados serán desafiados y castigados por cualquiera.
ventaja:
Tengan un alto control sobre los activos y sólo confíen en sí mismos: Alice y Bob pueden convertirse en oráculos y firmar CET. El mecanismo de desafío optimista derrotará al AEC equivocado, por lo que no se puede hacer el mal. Por lo tanto, OP-DLC permite a los usuarios creer sólo en sí mismos. En BitVM, los usuarios deben actuar como operadores y deben participar en todos los depósitos posteriores para poder confiar únicamente en sí mismos. Si un usuario como Operador solo participa en un único depósito UTXO en BitVM, y el UTXO puede ser reembolsado legalmente por cualquier otro (n-1) Operador, el usuario aún necesitará confiar en otros Operadores para adelantar los fondos en el futuro. Los permisos de reembolso del Operador BitVM están bloqueados en cada UTXO de depósito.
Alta utilización del capital: si los usuarios sólo confían en sí mismos, la cantidad de fondos necesarios es diferente. En OP-DLC, los usuarios dependen de sus propios retiros y no necesitan adelantar una cantidad igual de fondos. En BitVM, los usuarios deben adelantar una cantidad igual de fondos y luego recibir un reembolso. Esto trae consigo una mayor presión financiera.
El oráculo que puede firmar debe determinarse al realizar un depósito en OP-DLC, pero el usuario también puede convertirse en oráculo y firmar por sí mismo.
defecto:
El tiempo de retiro es de 1 semana: esencialmente, los costos de tiempo de capital de OP-DLC y BitVM existen y son iguales. Los retiros de OP-DLC deben pasar por un período de desafío antes de que se puedan obtener los fondos; si BitVM depende de que los usuarios avancen ellos mismos, la misma cantidad de fondos adelantados también debe pasar por un período de desafío antes de que puedan ser reembolsados con éxito. Si BitVM depende de otros operadores para adelantar fondos rápidamente, significa que el operador debe pagar la misma cantidad de fondos y costos de tiempo que las tarifas de manejo.
El número de firmas que requieren firma previa está creciendo rápidamente y está relacionado linealmente con el número de CET. Se necesitan tantos CET como sea posible para enumerar todos los resultados de los retiros.
4.Conclusión
OP-DLC introduce el mecanismo de desafío optimista en CET para garantizar que no se liquide el CET incorrecto y que el oráculo malicioso correspondiente pierda su compromiso; garantiza que se ejecute el CET correcto, se desbloquee el compromiso del oráculo y se obtenga la tarifa de procesamiento; Este método puede resistir cualquier ataque y tiene la belleza de la simplicidad.
Referencias
Especificación para contratos de registro discreto
Contratos de registro discreto
Consideraciones de optimización y análisis de principios de DLC
Resumen optimista
BitVM 2: Verificación sin permisos en Bitcoin
