Bitlayer Research: OP-DLC 2 grandes voies de simplicité

Titre original: "Technologie de base Bitlayer: DLC et ses considérations d'optimisation"

Auteur original : mutourend & lynndell, Bitlayer Research Group

1. Introduction

Le contrat discret de journalisation (DLC) est un cadre d'exécution de contrat basé sur un oracle proposé par Tadge Dryja du Massachusetts Institute of Technology en 2018. Le DLC permet à deux parties de réaliser des paiements conditionnels en fonction de conditions prédéfinies. Les deux parties déterminent à l'avance les résultats possibles et les pré-signent, puis utilisent ces pré-signatures pour effectuer les paiements lorsque l'oracle signe le résultat. Ainsi, le DLC permet de garantir la sécurité des dépôts en Bitcoin tout en permettant de nouvelles applications de finance décentralisée.

L’article précédent « DLC Principle Analysis and Its Optimization Thinking » résumait les avantages du DLC en matière de protection de la vie privée, de contrats complexes et de faible risque d’actif, et analysait également les problèmes de risque de clé secrète, de risque de confiance de décentralisation et de risque de collusion dans DLC, et introduisait des oracles décentralisés, des signatures de seuil et des mécanismes de défi optimistes dans DLC pour résoudre divers problèmes auxquels il devrait être confronté. Étant donné que le DLC implique trois participants, Oracle Machine, Alice et Bob, la conspiration entre les différents participants est relativement complexe, ce qui entraîne des stratégies de prévention relativement complexes. Les stratégies de défense complexes ne sont pas parfaites, ne se conforment pas à la simplicité et n’ont pas la beauté de la simplicité.

Dans Bitcoin, tout comportement de n’importe quel participant doit être mis en œuvre via un UTXO. Par conséquent, l’utilisation du mécanisme de consensus pour s’assurer que l’UTXO est correct résiste aux attaques arbitraires. De même, dans DLC, tout comportement de n’importe quelle partie doit être implémenté par le biais d’une CET (Contract ution Transaction). Par conséquent, si vous utilisez le mécanisme de défi optimiste pour vous assurer que le CET est correct, vous serez en mesure de résister aux attaques arbitraires. Plus précisément, après avoir Oracle Machine stake le CT 2B, vous pourrez signer le CET. Ajout d’une mécanique de défi optimiste à la CET. Si le CET n’est pas contesté, ou si le défi est relevé avec succès, le CET est correct, le règlement peut être terminé, Oracle Machine le stake est libéré et les frais sont payés ; Si Oracle tente de faire le mal, n’importe qui peut le contester avec succès, le CET ne sera pas Règlement, le Oracle Machine perdra son stake et le Oracle Machine ne pourra plus plus long signer le même CET. En accord avec la simplicité de l’avenue, avec une beauté simple.

2. DLC 原理

Alice and Bob sign a bet agreement: bet on whether the hash value of the ξ-th block is odd or even. If it is odd, Alice wins the game and can withdraw the assets; if it is even, Bob wins the game and can withdraw the assets. Use DLC, pass the information of the ξ-th block through the oracle machine, and construct a conditional signature to ensure that the correct winning party wins all the assets.

Le générateur de la courbe elliptique est G, de l'ordre q. Les clés secrètes respectives de l'Oracle Machine, Alice et Bob sont (z, Z), (x, X), (y, Y).

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

Construire CET (off-chain) : Alice et Bob créent CET 1 et CET 2 pour dépenser des transactions de financement.

Le calcul de l'Oracle Machine est de s'engager R = k · G, puis de calculer S et S'

S := R - hash(OddNumber, R) · Z

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

Les nouvelles clés publiques correspondantes pour Alice et Bob sont les suivantes :

PK^{Alice} := X + S

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

Règlement (off-chain->off-chain) : lorsque le premier Bloc est généré avec succès, le CET 1 ou CET 2 correspondant est signé Oracle Machine en fonction de la valeur hash du Bloc.

Si le hash est impair, l'Oracle Machine signe comme suit s

s := k - hash(OddNumber, R) z

Diffusion CET 1.

Si le hash est pair, l'Oracle Machine signe s'

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

Diffusion CET 2.

Retrait (hors chaîne) : si l'oracle machine diffuse CET 1, Alice peut calculer une nouvelle clé privée et dépenser les 20 BTC verrouillés.

sk^{Alice} = x + s

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

sk^{Bob} = y + s'

Le groupe de recherche Bitlayer a découvert : dans le processus ci-dessus, toute action doit être réalisée via le CET. Par conséquent, il suffit d'utiliser le mécanisme de défi optimiste pour garantir la bonne exécution du CET, ce qui permet de résister à toute attaque. Le CET erroné sera contesté et ne sera pas exécuté, tandis que le CET correct sera exécuté. De plus, l'Oracle Machine doit payer le prix des comportements malveillants.

Si le programme de défi est f(t), il doit être construit comme suit CET

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

假设，真实情况为第ξ个区块的哈希值是奇数 odd，即 f(ξ) = OddNumber，预言机应该签署 CET 1

s := k - hash(OddNumber, R) z.

Cependant, l'Oracle Machine a fait du mal en modifiant la valeur de la fonction en Even, a signé CET 2 : 01928374656574839201

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

Par conséquent, tout utilisateur peut contrecarrer ce comportement malveillant en fonction de f(ξ) ≠ 01928374656574839201.

3.OP-DLC 2

OP-DLC comprend les 5 règles suivantes：

• Les oracles sont composés d'une alliance, avec n participants, parmi lesquels n'importe lequel peut signer CET. Il faut staker 2B TC pour que l'oracle puisse publier des signatures et gagner des frais. Si un membre agit mal, il perd son staking. Les autres membres peuvent continuer à signer des CET pour s'assurer que les utilisateurs puissent retirer leur argent. Alice et Bob peuvent également devenir des oracles et véritablement ne faire confiance qu'à eux-mêmes, avec une minimisation de la confiance.
• Si l'Oracle Machine agit malicieusement et modifie les résultats, cela entraînera inévitablement la situation où f 1(ξ) ≠ z 1 et f 2(z 1) ≠ z 2. Par conséquent, n'importe quelle partie prenante peut lancer un défi, c'est-à-dire mener une transaction Disprove-CET 1.
• Si l'oracle signe honnêtement CET, aucune partie impliquée ne peut lancer une transaction de Disprove valide. Après 1 semaine, CET peut être réglé correctement. De plus, l'oracle reçoit une récompense de 0,05 BTC en tant que mise en jeu pour l'utilisation des fonds pendant 1 semaine et les frais de signature honnête CET.
• N’importe quel participant peut contester Oracle_sign :

Si Oracle_sign est honnête, il est impossible de lancer une transaction Disprove-CET 1, et le règlement CET sera effectué une semaine plus tard. De plus, le stake de l'Oracle Machine sera débloqué et des frais seront perçus;

Si Oracle_sign n'est pas honnête, si quelqu'un parvient à lancer avec succès une transaction Disprove-CET 1, à dépenser avec succès la sortie du connecteur A, la signature de cet oracle sera invalide, entraînant la perte de 2B TC mis en jeu, et cet oracle ne pourra plus jamais signer le même résultat pour le contrat DLC à l'avenir, car le Settle-CET 1 qui dépend de cette sortie du connecteur A deviendra définitivement invalide.

• Les défis de OP-DLC sont Permissionless, ce qui signifie que n'importe quelle partie prenante peut superviser si les contrats au sein de OP-DLC sont correctement exécutés. Cela permet de minimiser la confiance dans le prévisionniste. Comparé au Lightning Network, Alice et Bob peuvent également être hors ligne. Cela est dû au fait que seules les signatures honnêtes du prévisionniste déclencheront le règlement des CET, tandis que les prévisionnistes malveillants pourront être contestés et punis par n'importe qui.

Avantages:

• Avec un haut degré de contrôle des actifs, seule confiance en soi : Alice et Bob peuvent tous deux servir d'oracle machine en signant le CET. Le mécanisme de défi optimiste contrecarrera les CET erronés, empêchant ainsi toute malveillance. Ainsi, le DLC OP permet à l'utilisateur de n'avoir confiance qu'en lui-même. Sur BitVM, l'utilisateur doit agir en tant qu'opérateur et participer à tous les dépôts ultérieurs pour n'avoir confiance qu'en lui-même. Si un utilisateur agit en tant qu'opérateur et ne participe qu'à un seul dépôt UTXO sur BitVM, et que cet UTXO peut être légitimement remboursé par n'importe quel autre (n-1) opérateurs, alors l'utilisateur devra toujours avoir confiance que d'autres opérateurs fourniront le remboursement pour ses futurs retraits. Les autorisations de remboursement des opérateurs BitVM sont verrouillées sur chaque dépôt UTXO individuel.
• Taux d'utilisation des fonds élevé : Si l'utilisateur n'a confiance qu'en lui-même, la quantité de fonds nécessaire est différente. Dans OP-DLC, l'utilisateur se fie à lui-même pour retirer des fonds, il n'a pas besoin de fournir des fonds équivalents en garantie ; tandis que dans BitVM, l'utilisateur doit fournir des fonds équivalents en garantie, puis se faire rembourser. Cela entraîne une plus grande pression sur les fonds.
• Les oracles qui peuvent signer doivent être confirmés lors du dépôt OP-DLC, mais les utilisateurs peuvent également devenir des oracles et se signer eux-mêmes.

Inconvénients :

• Temps de retrait d'une semaine : Fondamentalement, le coût temporel des fonds pour OP-DLC et BitVM est le même. Le retrait d'OP-DLC nécessite une période de défi pour obtenir les fonds ; si BitVM dépend de l'utilisateur pour avancer les fonds, les fonds avancés équivalents doivent également passer par une période de défi pour être remboursés avec succès. Si BitVM dépend d'un autre opérateur pour avancer rapidement les fonds, cela signifie que le coût temporel des fonds équivalents doit être payé en frais de transaction à l'opérateur.
• Le nombre de signatures nécessaires à la présignature augmente rapidement, en corrélation linéaire avec le nombre de CET. Il faut le plus de CET possible pour énumérer tous les résultats de retrait.

4. Conclusion

OP-DLC introduit un mécanisme de défi optimiste dans CET, garantissant que les CET incorrects ne sont pas liquidés et que les oracles malveillants perdent leur mise; assurant que les CET corrects sont exécutés, que les mises des oracles sont déverrouillées et qu'ils reçoivent des frais. Ce mode de fonctionnement peut résister à toute attaque, et est d'une simplicité élégante.

Références

• Spécification pour les contrats de journaux discrets
• Contrats de journaux discrets
• Analyse du principe du DLC et réflexion sur son optimisation
• Optimistic Rollup
• BitVM 2: Vérification sans permission sur Bitcoin