1. Introduction

Le contrat de journal discret (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 d'exécuter des paiements conditionnels basés sur des conditions prédéfinies. Les parties déterminent les résultats possibles, les pré-signent et utilisent ces pré-signatures pour exécuter des paiements lorsque l'Oracle approuve le résultat. 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.

Par rapport au Lightning Network, DLC présente les avantages significatifs suivants :

• Confidentialité : DLC offre une meilleure protection de la vie privée que le Lightning Network. Les détails du contrat ne sont partagés qu'entre les parties impliquées et ne sont pas stockés sur la blockchain. En revanche, les transactions du Lightning Network sont acheminées via des canaux et des nœuds publics, rendant leurs informations publiques et transparentes.
• Complexité et flexibilité des contrats financiers : DLC peut créer et exécuter directement des contrats financiers complexes sur le réseau Bitcoin, tels que des dérivés, des assurances et des paris, tandis que le Lightning Network est principalement utilisé pour des paiements rapides de petites valeurs et ne peut pas prendre en charge des applications complexes.
• Risque de contrepartie réduit : Les fonds DLC sont bloqués dans des contrats multi-signatures et ne sont libérés que lorsque le résultat d'un événement prédéfini se produit, réduisant ainsi le risque que l'une des parties ne respecte pas le contrat. Bien que le Lightning Network réduise le besoin de confiance, il comporte encore certains risques de contrepartie dans la gestion des canaux et la fourniture de liquidités.
• Pas besoin de gérer les canaux de paiement : les opérations DLC ne nécessitent pas la création ou la maintenance de canaux de paiement, qui sont essentiels au Lightning Network et impliquent une gestion complexe et gourmande en ressources.
• Scalabilité pour des cas d'utilisation spécifiques : Alors que le Lightning Network augmente quelque peu le débit des transactions Bitcoin, le DLC offre une meilleure scalabilité pour les contrats complexes sur Bitcoin.

Bien que les DLC offrent des avantages significatifs dans l'écosystème Bitcoin, il existe encore certains risques et problèmes, tels que :

• Risque clé : Il existe un risque de fuite ou de perte des clés privées d'Oracle et des nonces engagés, entraînant la perte des actifs des utilisateurs.
• Risque de confiance centralisé : la centralisation dans les oracles peut facilement mener à des attaques de déni de service.
• Problème de dérivation de clé décentralisée : si l'Oracle est décentralisé, les nœuds Oracle ne possèdent que des parts de la clé privée. Cependant, les nœuds Oracle décentralisés ne peuvent pas utiliser directement BIP32 pour la dérivation de clé basée sur ces parts de clé privée.
• Risque de collusion : Si les nœuds Oracle collaborent entre eux ou avec une partie, le problème de confiance avec les Oracles reste irrésolu. Un mécanisme de surveillance fiable est nécessaire pour minimiser la confiance dans les Oracles.
• Problème de changement de dénomination fixe : Les signatures conditionnelles nécessitent un ensemble déterministe et énumérable d'événements avant de construire le contrat pour construire la transaction. Ainsi, l'utilisation de DLC pour la réaffectation d'actifs a une restriction de montant minimum, entraînant le problème de changement de dénomination fixe.

Pour remédier à ces problèmes, cet article propose plusieurs solutions et idées d'optimisation pour atténuer les risques et les problèmes associés aux DLC, améliorant ainsi la sécurité de l'écosystème Bitcoin.

2. Principe DLC

Alice et Bob concluent un accord de paris sur la valeur de hash du (n+k)-ème bloc est impair ou pair. S'il est impair, Alice remporte le jeu et peut retirer les actifs dans le temps t; s'il est pair, Bob remporte le jeu et peut retirer les actifs dans le temps t. En utilisant le DLC, les informations du (n+k)-ème bloc sont transmises via un Oracle pour construire une signature conditionnelle, garantissant que le bon gagnant obtient tous les actifs.

Initialisation : Le générateur de la courbe elliptique est G, et son ordre est q.

Génération de clés : L'Oracle, Alice et Bob génèrent indépendamment leurs propres clés privées et publiques.

• La clé privée de l'Oracle est z et sa clé publique est Z, satisfaisant Z=z⋅G;
• La clé privée d'Alice est x et sa clé publique est X, satisfaisant X=x⋅G;
• La clé privée de Bob est y, et sa clé publique est Y, satisfaisant Y=y⋅G.

Transaction de financement : Alice et Bob créent ensemble une transaction de financement, verrouillant chacun 1 BTC dans une sortie multi-signature 2-sur-2 (une clé publique X appartient à Alice, et l'autre Y à Bob).

Transactions d'exécution de contrat (CET) : Alice et Bob créent deux CET pour dépenser la transaction de financement.

L'Oracle calcule l'engagement

puis calcule S et S′

et diffuse (R, S, S′).

Alice et Bob calculent chacun la nouvelle clé publique correspondante

Règlement : Après l'apparition du (n+k)-ème bloc, l'Oracle génère le s ou s' correspondant en fonction de la valeur de hash de ce bloc.

• Si la valeur de hash du bloc (n+k) est impaire, l'Oracle calcule et diffuse

• Si la valeur de hash du bloc (n+k) est paire, l'Oracle calcule et diffuse

Retrait : Alice ou Bob peuvent retirer les actifs en fonction du s ou s′ diffusé par l'Oracle.

• Si l'Oracle diffuse s, Alice peut calculer la nouvelle clé privée sk^{Alice} et retirer les 2 BTC verrouillés

• Si l'Oracle diffuse s′, Bob peut calculer la nouvelle clé privée sk^{Bob} et retirer les 2 BTC verrouillés

Analyse: La nouvelle clé privée sk^{Alice} calculée par Alice et la nouvelle clé publique PK^{Alice} satisfait la relation du logarithme discret

Ainsi, le retrait d'Alice sera réussi.

De même, la nouvelle clé privée sk^{Bob} calculée par Bob et la nouvelle clé publique PK^{Bob} satisfont la relation du logarithme discret

Ainsi, le retrait de Bob sera réussi.

De plus, si l'Oracle diffuse s, cela est utile pour Alice, mais pas pour Bob car Bob ne peut pas calculer la nouvelle clé privée correspondante sk^{Bob}. De même, si l'Oracle diffuse s′, cela est utile pour Bob, mais pas pour Alice, car Alice ne peut pas calculer la nouvelle clé privée correspondante sk^{Alice}. Enfin, la description ci-dessus omet le verrouillage temporel. Un verrouillage temporel doit être ajouté pour permettre à une partie de calculer la nouvelle clé privée et de retirer dans le temps t. Sinon, si cela dépasse le temps t, l'autre partie peut utiliser la clé privée d'origine pour retirer les actifs.

3. Optimisations DLC

3.1 Gestion des clés

Dans le protocole DLC, la clé privée de l'Oracle et le nonce engagé sont cruciaux. La fuite ou la perte de la clé privée de l'Oracle et du nonce engagé peut entraîner les quatre problèmes de sécurité suivants :

(1) Oracle Perd Clé Privée z

Si l'Oracle perd sa clé privée, le DLC ne peut pas être réglé, ce qui rend nécessaire l'exécution d'un contrat de remboursement de DLC. Par conséquent, le protocole DLC inclut une transaction de remboursement pour prévenir les conséquences de la perte de la clé privée de l'Oracle.

(2) Fuite de la clé privée z d'Oracle

Si la clé privée de l'Oracle est divulguée, tous les DLC basés sur cette clé privée encourent le risque d'un règlement frauduleux. Un attaquant qui vole la clé privée peut signer n'importe quel message souhaité, obtenant un contrôle total sur les résultats de tous les contrats futurs. De plus, l'attaquant n'est pas limité à émettre un seul message signé mais peut également publier des messages contradictoires, comme signer que la valeur de hachage du (n+k)-ième bloc est à la fois impaire et paire.

(3) Fuite ou Réutilisation de Nonce k par Oracle

Si l'Oracle divulgue le nonce k, alors lors de la phase de règlement, que l'Oracle diffuse s ou s′, un attaquant peut calculer la clé privée de l'Oracle z comme suit :

Si l'Oracle réutilise le nonce k, alors après deux règlements, un attaquant peut résoudre le système d'équations basé sur les signatures diffusées par l'Oracle pour déduire la clé privée z de l'Oracle dans l'un des quatre scénarios possibles.

cas 1:

cas 2:

cas 3:

cas 4:

(4) Oracle Perd Nonce k

Si l'oracle perd le nonce k, le DLC correspondant ne peut pas être réglé, ce qui nécessite l'exécution d'un contrat de remboursement de DLC.

Par conséquent, pour renforcer la sécurité de la clé privée de l'Oracle, il est conseillé d'utiliser BIP32 pour dériver des clés enfant ou petit-enfant pour la signature. De plus, pour augmenter la sécurité du nonce, il convient d'utiliser la valeur de hachage k:=hash(z, counter) comme nonce k, pour éviter la répétition ou la perte du nonce.

3.2 Oracle Décentralisé

Dans les contrats à terme, le rôle de l'Oracle est crucial car il fournit des données externes clés qui déterminent le résultat du contrat. Pour renforcer la sécurité de ces contrats, des Oracles décentralisés sont nécessaires. Contrairement aux Oracles centralisés, les Oracles décentralisés répartissent la responsabilité de fournir des données précises et infalsifiables à travers de multiples nœuds indépendants, réduisant ainsi le risque lié à un point de défaillance unique et diminuant la probabilité de manipulation ou d'attaques ciblées. Avec un Oracle décentralisé, les contrats à terme peuvent atteindre un plus haut degré de décentralisation et de fiabilité, garantissant que l'exécution du contrat repose entièrement sur l'objectivité des conditions préétablies.

Les signatures seuils de Schnorr peuvent être utilisées pour implémenter des Oracles décentralisés. Les signatures seuils de Schnorr offrent les avantages suivants :

• Sécurité renforcée : En distribuant la gestion des clés, les signatures seuillées réduisent le risque de points de défaillance uniques. Même si les clés de certains participants sont compromises ou attaquées, le système entier reste sécurisé tant que la violation ne dépasse pas un seuil prédéfini.
• Contrôle distribué : Les signatures seuils permettent un contrôle distribué de la gestion des clés, éliminant une entité unique détenant tous les pouvoirs de signature, réduisant ainsi les risques associés à la concentration du pouvoir.
• Disponibilité améliorée : les signatures peuvent être complétées tant qu'un certain nombre de nœuds Oracle sont d'accord, augmentant la flexibilité et la disponibilité du système. Même si certains nœuds ne sont pas disponibles, la fiabilité globale du système n'est pas affectée.
• Flexibilité et évolutivité : Le protocole de signature de seuil peut définir différents seuils selon les besoins pour répondre à diverses exigences de sécurité et scénarios. De plus, il est adapté aux réseaux à grande échelle, offrant une bonne évolutivité.
• Responsabilité : Chaque nœud Oracle génère une part de signature basée sur sa propre clé privée, et d'autres participants peuvent vérifier la justesse de cette part de signature en utilisant la part de clé publique correspondante, permettant ainsi d'assurer la responsabilité. Si elle est correcte, ces parts de signature sont accumulées pour produire une signature complète.

Par conséquent, le protocole de signature seuil de Schnorr présente des avantages significatifs dans les oracles décentralisés en termes d'amélioration de la sécurité, de la fiabilité, de la flexibilité, de la scalabilité et de la responsabilité.

3.3 Couplage de la décentralisation et de la gestion des clés

Dans la technologie de gestion des clés, un Oracle possède une clé complète z et, en utilisant BIP32 avec des incréments ω, peut dériver une multitude de clés enfant z+ω^{(1)} et de clés petit-enfant z+ω^{(1)}+ω^{(2)}. Pour différents événements, l'Oracle peut utiliser diverses clés privées petit-enfant z+ω^{(1)}+ω^{(2)} pour générer des signatures correspondantes σ pour les messages d'événements respectifs.

Dans le scénario de l'Oracle décentralisé, il y a n participants, et une signature de seuil requiert t+1 participants, où t

Cependant, dans un scénario d'Oracle décentralisé, la clé privée complète z n'apparaît pas, et par conséquent, la dérivation de clé directe en utilisant BIP32 n'est pas possible. En d'autres termes, la technologie d'Oracle décentralisé et la technologie de gestion de clés ne peuvent pas être directement intégrées.

Le document "Dérivation de clé distribuée pour la gestion multi-parties des actifs numériques de la blockchainproposes un schéma de dérivation de clé distribué dans des scénarios de signature seuil. L'idée principale est basée sur les polynômes d'interpolation de Lagrange, où la part de clé privée z_i et la clé privée complète z satisfont la relation d'interpolation suivante :

Ajouter l'incrément ω des deux côtés de l'équation donne :

Cette équation montre que la part de clé privée z_i plus l'incrément ω satisfait toujours la relation d'interpolation avec la clé privée complète z plus ω. En d'autres termes, la part de clé privée enfant z_i+ω et la clé enfant z+ω satisfont la relation d'interpolation. Par conséquent, chaque participant peut utiliser sa part de clé privée z_i plus l'incrément ω pour dériver la part de clé privée enfant z_i+ω, utilisée pour générer des parts de signature enfant, et les valider en utilisant la clé publique enfant correspondante Z+ω⋅G.

Cependant, il faut prendre en compte BIP32 durci et non durci. BIP32 durci prend la clé privée, le code de chaîne et le chemin en entrée, effectue SHA512 et produit l'incrémentation et le code de chaîne enfant. BIP32 non durci, d'autre part, prend la clé publique, le code de chaîne et le chemin en entrée, effectue SHA512 et produit l'incrémentation et le code de chaîne enfant. Dans un scénario de signature de seuil, la clé privée n'existe pas, donc seul BIP32 non durci peut être utilisé. Ou, en utilisant une fonction de hachage homomorphique, BIP32 durci peut être appliqué. Cependant, une fonction de hachage homomorphique diffère de SHA512 et n'est pas compatible avec le BIP32 original.

3.4 OP-DLC: Oracle Trust-minimized

Dans le DLC, le contrat entre Alice et Bob est exécuté sur la base du résultat signé de l'Oracle, nécessitant ainsi un certain niveau de confiance envers l'Oracle. Par conséquent, le comportement correct de l'Oracle est une prémisse majeure pour le fonctionnement du DLC.

Pour réduire la confiance dans l'Oracle, des recherches ont été menées sur l'exécution de DLC basés sur les résultats de n Oracles, réduisant la dépendance à l'égard d'un seul Oracle.

• Le modèle "n-of-n" consiste à utiliser n Oracles pour signer le contrat et à exécuter le contrat en fonction des résultats de tous les Oracles. Ce modèle nécessite que tous les Oracles soient en ligne pour la signature. Si un Oracle se déconnecte ou s'il y a un désaccord sur les résultats, cela affecte l'exécution du contrat DLC. L'hypothèse de confiance ici est que tous les Oracles sont honnêtes.
• Le modèle « k-of-n » implique l'utilisation de n Oracles pour signer le contrat, exécutant le contrat en fonction des résultats de k Oracles. Si plus de k Oracles complotent, cela affecte l'exécution équitable du contrat. De plus, le nombre de CETs requis dans le modèle « k-of-n » est C_n^k fois celui d'un seul Oracle ou du modèle « n-of-n ». L'hypothèse de confiance dans ce modèle est qu'au moins k sur n Oracles sont honnêtes.

Augmenter simplement le nombre d'Oracles ne permet pas de dissiper la méfiance à l'égard des Oracles car, après des actions malveillantes d'un Oracle, la partie lésée dans le contrat n'a aucun recours sur la chaîne.

Par conséquent, nous proposons OP-DLC, qui intègre un mécanisme de défi optimiste dans le DLC. Avant de participer à la mise en place du DLC, n Oracles doivent s'engager et construire un jeu OP sur chaîne sans permission à l'avance, s'engageant à ne pas agir de manière malveillante. Si un Oracle agit de manière malveillante, alors Alice, Bob, tout autre Oracle honnête, ou tout autre observateur honnête tiers peut lancer un défi. Si le challenger gagne le jeu, le système on-chain punit l'Oracle malveillant en confisquant son dépôt. De plus, OP-DLC peut également adopter le modèle « k-sur-n » pour la signature, où la valeur de k peut même être 1. Par conséquent, l'hypothèse de confiance est réduite à avoir seulement un participant honnête dans le réseau pour lancer un défi OP et pénaliser un nœud Oracle malveillant.

Lors du règlement de l'OP-DLC basé sur les résultats de calcul de la couche 2 :

• Si un Oracle signe avec des résultats incorrects, causant ainsi une perte à Alice, Alice peut utiliser les résultats corrects du calcul de la couche 2 pour contester le jeu OP sans permission prêtée à l'avance de l'Oracle sur chaîne. En remportant le jeu, Alice peut pénaliser l'Oracle malveillant et compenser sa perte.
• De même, Bob, d'autres nœuds Oracle honnêtes et des observateurs tiers honnêtes peuvent également lancer des défis. Cependant, pour éviter les défis malveillants, le challenger doit également s'engager.

Ainsi, OP-DLC facilite la surveillance mutuelle entre les nœuds oracle, minimisant la confiance accordée aux oracles. Ce mécanisme ne nécessite qu'un seul participant honnête et possède une tolérance aux fautes de 99 %, ce qui permet de traiter efficacement le risque de collusion des oracles.

Pont double 3.5 OP-DLC + BitVM

Lorsque le DLC est utilisé pour les ponts inter-chaînes, la distribution des fonds doit avoir lieu lors du règlement du contrat DLC :

• Il nécessite un pré-réglage via les CET, ce qui signifie que la granularité du règlement des fonds de DLC est limitée, par exemple à 0,1 BTC sur le réseau Bison. Cela pose un problème : les interactions d'actifs de la couche 2 pour les utilisateurs ne devraient pas être limitées par la granularité des fonds des CET de DLC.
• Lorsque Alice souhaite régler ses actifs de couche 2, cela force le règlement des actifs de couche 2 de l'utilisateur Bob vers la couche 1 également. Cela soulève un problème : chaque utilisateur de couche 2 devrait avoir la liberté de choisir ses dépôts et retraits indépendamment des actions des autres utilisateurs.
• Alice et Bob négocient les dépenses. Le problème ici est qu'il faut que les deux parties soient prêtes à coopérer.

Par conséquent, pour résoudre le problème susmentionné, nous proposons le pont double OP-DLC + BitVM. Cette solution permet aux utilisateurs de déposer et de retirer via le pont sans permission de BitVM ainsi que par le mécanisme OP-DLC, réalisant des modifications à n'importe quelle granularité et améliorant la liquidité.

Dans l'OP-DLC, l'Oracle est la fédération BitVM, avec Alice en tant qu'utilisateur régulier et Bob en tant que fédération BitVM. Lors de la configuration de l'OP-DLC, les CETs permettent de dépenser immédiatement la sortie d'Alice sur la couche 1, tandis que la sortie de Bob inclut un 'jeu DLC qu'Alice peut défier' avec une période de verrouillage temporel. Lorsqu'Alice souhaite retirer :

• Si la fédération BitVM, agissant en tant qu'Oracle, signe correctement, Alice peut retirer sur la couche 1. Cependant, Bob peut retirer sur la couche 1 après la période de verrouillage temporel.
• Si la fédération BitVM, agissant en tant qu'Oracle, triche, causant une perte à Alice, elle peut défier l'UTXO de Bob. Si le défi réussit, le montant de Bob peut être confisqué. Remarque : un autre membre de la fédération BitVM peut également initier le défi, mais Alice, en tant que partie lésée, est la plus motivée pour le faire.
• Si la fédération BitVM, agissant en tant qu'Oracle, triche, causant une perte à Bob, un membre honnête de la fédération BitVM peut contester le "jeu BitVM" pour pénaliser le nœud Oracle tricheur.

De plus, si l'utilisateur Alice souhaite se retirer de la couche 2 mais que les CET prédéfinis dans le contrat OP-DLC ne correspondent pas au montant, Alice peut choisir les méthodes suivantes :

• Retrait via BitVM, avec l'opérateur BitVM avançant le montant sur la couche 1. Le pont BitVM suppose qu'il y a au moins un participant honnête dans la fédération BitVM.
• Retirer via un CET spécifique dans OP-DLC, avec le reste du changement fourni par l'opérateur BitVM sur la couche 1. Le retrait via OP-DLC fermera le canal DLC, mais les fonds restants dans le canal DLC seront transférés au pool de la couche 1 de BitVM, sans contraindre les autres utilisateurs de la couche 2 à effectuer un retrait. Le pont OP-DLC suppose qu'il y a au moins un participant honnête dans le canal.
• Alice et Bob négocient les dépenses sans l'intervention d'un Oracle, exigeant la coopération de Bob.

Par conséquent, le pont double OP-DLC + BitVM offre les avantages suivants:

• BitVM résout le problème de changement du canal DLC, réduit le nombre de CET requis et n'est pas affecté par la granularité des fonds CET ;
• En combinant le pont OP-DLC avec le pont BitVM, il fournit aux utilisateurs plusieurs canaux pour les dépôts et les retraits, améliorant l'expérience utilisateur;
• En configurant le consortium BitVM à la fois en tant que Bob et l'oracle, et en utilisant le mécanisme OP, cela réduit au minimum la confiance en l'oracle;
• Intégrer le retrait excessif du canal DLC dans le pool de pont BitVM améliore l'utilisation des fonds.

4. Conclusion

Le DLC est apparu avant l'activation de Segwit v1 (Taproot) et a déjà été intégré au réseau Lightning, permettant l'extension du DLC pour mettre à jour et exécuter des contrats continus au sein du même canal DLC. Avec des technologies comme Taproot et BitVM, des vérifications et des règlements de contrats hors chaîne plus complexes peuvent être mis en œuvre dans le cadre du DLC. De plus, en intégrant le mécanisme de défi OP, il est possible de minimiser la confiance dans les Oracles.

Déclaration :

1. Cet article est reproduit à partir demoyen, intitulé à l'origine « Technologie de base Bitlayer : DLC et ses considérations d'optimisation ». Les droits d'auteur appartiennent à l'auteur original, Bitlayer. Si vous avez des objections à cette réimpression, veuillez contacter le Équipe Gate Learn. L'équipe le traitera selon les procédures pertinentes le plus rapidement possible.

2. Avertissement : Les points de vue et opinions exprimés dans cet article ne représentent que les points de vue personnels de l'auteur et ne constituent pas un conseil en investissement.

3. D'autres versions de l'article ont été traduites par l'équipe Gate Learn. Sans mention de Gate, les articles traduits ne peuvent être copiés, diffusés ou plagiés.