Titre original : "Bitlayer Core Technology : DLC et ses considérations d'optimisation"

Auteur original : Mutourend Lynndell, Bitlayer Research Group

1. Introduction

Discreet Log Contract (DLC) est un cadre d'exécution de contrat basé sur Oracle proposé par Tadge Dryja du MIT en 2018. Le DLC permet à deux parties d'effectuer des paiements conditionnels basés sur des conditions prédéfinies. Les deux parties prédéterminent et pré-signent les résultats possibles, et utilisent ces pré-signatures pour exécuter le paiement lorsque l'oracle signe les résultats. Par conséquent, le DLC permet de nouvelles applications financières décentralisées tout en garantissant la sécurité des dépôts Bitcoin.

L'article précédent « Analyse des principes du DLC et réflexions d'optimisation » résumait les avantages du DLC en termes de protection de la vie privée, de contrats complexes et de faible risque d'actifs. Il analysait également l'existence de risques clés, de risques de confiance décentralisée, de risques de collusion, etc. problèmes du DLC et introduire des oracles décentralisés, des signatures de seuil, des mécanismes de défi optimistes, etc. dans le DLC pour résoudre divers problèmes auxquels il devrait être confronté. Étant donné que le DLC implique trois parties : l'oracle, Alice et Bob, il est relativement complexe pour différentes parties de s'entendre pour attaquer de manière exhaustive, ce qui aboutit à une stratégie de prévention relativement complexe. Les stratégies de défense complexes ne sont pas parfaites, ne sont pas conformes au principe de simplicité et n’ont pas la beauté de la simplicité.

Dans Bitcoin, tout comportement de tout participant doit être mis en œuvre via UTXO. Par conséquent, l’utilisation du mécanisme de consensus pour garantir qu’UTXO est correct peut résister aux attaques arbitraires. De même, dans DLC, tout comportement de tout participant doit être mis en œuvre via CET (Contract Execution Transaction). Par conséquent, l’utilisation du mécanisme de défi optimiste pour garantir que CET est correct peut résister à toute attaque. Plus précisément, une fois que l'oracle a promis 2B TC, il peut signer le CET. Ajoutez un mécanisme de défi optimiste au CET. Si le CET n'est pas contesté ou répond avec succès au défi, le CET est correct et le règlement peut être effectué, et l'oracle est désengagé et reçoit des frais de traitement. Si l'Oracle tente de faire le mal, n'importe qui peut contester avec succès, le CET ne sera pas contesté ; réglé, et l'oracle perdra. Le dépôt est déposé et l'oracle ne peut plus signer le même CET. En accord avec la grande simplicité, il a la beauté de la simplicité.

2.Principe DLC

Alice et Bob signent un accord de pari : parier que la valeur de hachage du ξème bloc est un nombre impair ou pair. S'il s'agit d'un nombre impair, Alice gagne la partie et peut retirer les actifs ; s'il s'agit d'un nombre pair, Bob gagne la partie et peut retirer les actifs. À l'aide du DLC, les informations du ξème bloc sont transmises via l'oracle pour construire une signature conditionnelle afin que le bon gagnant remporte tous les actifs.

Le générateur de la courbe elliptique est G et l'ordre est q. Les paires de clés de l'oracle, Alice et Bob sont respectivement (z, Z), (x, X), (y, Y).

Transaction de financement (en chaîne) : Alice et Bob créent ensemble une transaction de financement, chacun verrouillant 10 BTC dans une sortie multi-signature 2 sur 2 (une clé publique X appartient à Alice et une clé publique Y appartient à Bob) .

Construction du CET (hors chaîne) : Alice et Bob créent le CET 1 et le CET 2 pour dépenser des transactions d'injection de capital.

L'oracle calcule l'engagement R = k · G, puis calcule S et S'

S := R - hachage (Nombre Impair, R) · Z

S' := R - hachage(EvenNumber, R) · Z

Alors les nouvelles clés publiques correspondant à Alice et Bob sont les suivantes :

PK^{Alice} := X + S

PK^{Bob} := Y + S'.

Règlement (hors chaîne -> en chaîne) : lorsque le ξème bloc est généré avec succès, l'oracle signera le CET 1 ou CET 2 correspondant en fonction de la valeur de hachage du bloc.

Si le hachage est impair, l'oracle signe s comme suit

s := k - hachage(Nombre Impair, R) z

Diffusion CET 1.

Si le hachage est pair, l'oracle signe s'

s' := k - hachage(EvenNumber, R) z

Diffusion CET 2.

Retirer des pièces (en chaîne) : Si l'oracle diffuse CET 1, Alice peut calculer la nouvelle clé privée et dépenser les 20 BTC verrouillés.

sk^{Alice} = x + s

Si l'oracle diffuse CET 2, Bob peut calculer la nouvelle clé privée et dépenser les 20 BTC verrouillés.

sk^{Bob} = y + s'

L'équipe de recherche de Bitlayer a découvert que dans le processus ci-dessus, tout comportement doit être mis en œuvre via CET. Par conséquent, il suffit d’utiliser le mécanisme de défi optimiste pour s’assurer que CET est correct et qu’il peut résister à toute attaque. Les mauvais CET seront contestés et non exécutés, tandis que les bons CET seront exécutés. De plus, l’oracle doit payer le prix d’un comportement malveillant.

Le programme à contester est f(t), alors CET doit être construit comme suit

s = k - hachage(f(t), R) z.

Supposons que la situation réelle est que la valeur de hachage du ξème bloc est un nombre impair impair, c'est-à-dire f(ξ) = OddNumber, et l'oracle doit signer CET 1

s := k - hachage (Nombre Impair, R) z.

Cependant, l'oracle a fait quelque chose de mal et a changé la valeur de la fonction en Even, signant CET 2 :

s' := k - hachage(EvenNumber, R) z.

Par conséquent, tout utilisateur peut vaincre ce comportement malveillant selon f(ξ) ≠ OddNumber.

3.OP-DLC2 

OP-DLC comprend les 5 dispositions suivantes :

  • L'oracle est composé d'une alliance. Il y a n participants dans l'alliance, et n'importe quel membre peut signer le CET. Ce n'est qu'en promettant 2B TC que la machine Oracle peut émettre des signatures et percevoir des frais de traitement. Si un membre fait le mal, la mise est perdue. Les autres membres peuvent continuer à signer le CET pour garantir que les utilisateurs peuvent retirer des fonds. Alice et Bob peuvent également devenir des oracles, ne faisant véritablement confiance qu'à eux-mêmes et minimisant la confiance.

  • Si l'oracle fait quelque chose de mal et modifie le résultat, cela conduira inévitablement à la situation où f 1(ξ) ≠ z 1, f 2(z 1) ≠ z 2. Par conséquent, n’importe quel participant peut lancer une contestation, c’est-à-dire effectuer une transaction Disprove-CET 1.

  • Si l'oracle signe honnêtement le CET, aucune partie ne peut initier une transaction de réfutation valide. Après 1 semaine, le CET peut être réglé correctement. De plus, la machine Oracle reçoit une récompense de 0,05 BTC pour l'occupation du capital d'une semaine de son 2B TC promis et les frais de traitement pour la signature honnête du CET.

  • Tout participant peut défier Oracle_sign :

    Si Oracle_sign est honnête, la transaction Disprove-CET 1 ne peut pas être initiée et le règlement CET sera exécuté après 1 semaine. De plus, la machine Oracle s'engage à débloquer et à percevoir des frais de traitement ;

    Si Oracle_sign est malhonnête, c'est-à-dire que quelqu'un lance avec succès une transaction Disprove-CET 1 et dépense avec succès la sortie du connecteur A, la signature de l'oracle sera invalide et le TC 2B promis sera perdu et l'oracle ne pourra plus pour l'utiliser à l'avenir. Le contrat DLC initie une signature avec le même résultat, car le Settle-CET 1 qui s'appuie sur la sortie du connecteur A sera définitivement invalide.

  • Les défis dans OP-DLC sont sans autorisation, c'est-à-dire que tout participant peut contrôler si le contrat dans OP-DLC est exécuté correctement. Par conséquent, la confiance dans l’oracle est minimisée. Par rapport au Lightning Network, Alice et Bob peuvent également être hors ligne. Parce que l’oracle ne réglera le CET qu’avec des signatures honnêtes, et que les mauvais oracles seront défiés et punis par n’importe qui.

avantage:

  • Avoir un contrôle élevé sur les actifs et ne faire confiance qu'à eux-mêmes : Alice et Bob peuvent tous deux devenir des oracles et signer le CET. Le mécanisme de défi optimiste va vaincre le mauvais CET, donc le mal ne peut pas être fait. Par conséquent, OP-DLC permet aux utilisateurs de ne croire qu'en eux-mêmes. Dans BitVM, les utilisateurs doivent agir en tant qu'opérateurs et doivent participer à tous les dépôts ultérieurs afin de ne se faire confiance qu'en eux-mêmes. Si un utilisateur en tant qu'opérateur ne participe qu'à un seul dépôt UTXO dans BitVM et que cet UTXO peut être légalement remboursé par tout autre (n-1) opérateur, l'utilisateur devra toujours faire confiance à d'autres opérateurs pour avancer des fonds à l'avenir. Les autorisations de remboursement de l'opérateur BitVM sont verrouillées sur chaque dépôt UTXO.

  • Utilisation élevée du capital : si les utilisateurs ne font confiance qu’à eux-mêmes, le montant des fonds requis est différent. Dans OP-DLC, les utilisateurs dépendent de leurs propres retraits et n'ont pas besoin d'avancer un montant égal de fonds ; dans BitVM, les utilisateurs doivent avancer un montant égal de fonds puis être remboursés. Cela entraîne une plus grande pression financière.

  • L'oracle qui peut signer doit être déterminé lors d'un dépôt dans OP-DLC, mais l'utilisateur peut également devenir oracle et signer pour lui-même.

défaut:

  • Le délai de retrait prend 1 semaine : Essentiellement, les coûts en temps d'investissement d'OP-DLC et de BitVM existent et sont égaux. Les retraits OP-DLC doivent passer par une période de contestation avant de pouvoir obtenir les fonds ; si BitVM compte sur les utilisateurs pour progresser eux-mêmes, le même montant de fonds avancés doit également passer par une période de contestation avant de pouvoir être remboursé avec succès. Si BitVM s'appuie sur d'autres opérateurs pour avancer le paiement des retraits rapides, cela signifie que l'opérateur doit payer le même montant de fonds et de temps que les frais de traitement.

  • Le nombre de signatures nécessitant une pré-signature augmente rapidement et est linéairement lié au nombre de CET. Autant de CET que possible sont nécessaires pour énumérer tous les résultats de retrait.

4. Conclusion

OP-DLC introduit le mécanisme de défi optimiste dans CET pour garantir qu'un mauvais CET n'est pas réglé et que l'oracle malveillant correspondant perd son engagement ; il garantit que le bon CET est exécuté, que l'engagement oracle est déverrouillé et que les frais de traitement sont obtenus. Cette méthode peut résister à toute attaque et a la beauté de la simplicité.

les références

  • Spécification pour les contrats de journaux discrets

  • Contrats de journaux discrets

  • Analyse du principe DLC et considérations d'optimisation

  • Cumul optimiste

  • BitVM 2 : vérification sans autorisation sur Bitcoin