Discussion sur les principes techniques et les idées d'optimisation du DLC

1. Aperçu

Le contrat de logarithme discret (DLC) est un schéma de paiement conditionnel basé sur un oracle, proposé par Tadge Dryja du MIT en 2018. Le DLC permet aux deux parties de réaliser des paiements en fonction de conditions prédéfinies, les participants déterminent à l'avance les résultats possibles et pré-signent, et le paiement peut être exécuté lorsque l'oracle signe le résultat. Cela permet au DLC de garantir la sécurité des dépôts en bitcoins tout en réalisant de nouvelles applications financières décentralisées.

Comparé au réseau Lightning, le DLC présente les avantages suivants :

• Meilleure confidentialité : les détails du contrat ne sont partagés qu'entre les parties impliquées et ne sont pas stockés sur la blockchain.
• Support des contrats financiers complexes : il est possible de créer et d'exécuter directement des dérivés, des assurances et d'autres contrats complexes sur le réseau Bitcoin.
• Réduire le risque de la contrepartie : les fonds sont bloqués dans un contrat multi-signatures et ne seront libérés que lorsque le résultat d'un événement prédéfini se produira.
• Pas besoin de gérer les canaux de paiement : opérations simplifiées, pas besoin de créer et de maintenir des canaux de paiement.
• Meilleure évolutivité dans des scénarios spécifiques : offre une meilleure évolutivité en ce qui concerne les contrats complexes.

Cependant, le DLC présente encore certains risques et problèmes :

• Les clés privées et les nombres aléatoires des oracles peuvent être divulgués ou perdus, entraînant une perte d'actifs.
• Les oracles présentent des risques de confiance centralisés et sont vulnérables aux attaques par déni de service.
• Les oracles décentralisés ne peuvent pas dériver les clés directement.
• Les nœuds d'oracle peuvent conspirer, il existe toujours des problèmes de confiance.
• La signature conditionnelle nécessite de déterminer à l'avance un ensemble d'événements, ce qui entraîne une limite minimale sur la redistribution des actifs.

Cet article explorera certaines solutions d'optimisation pour résoudre les problèmes mentionnés ci-dessus et améliorer la sécurité de l'écosystème Bitcoin.

2. Fonctionnement du DLC

Prenons l'exemple d'Alice et Bob qui signent un accord de pari, où le pari est la parité du hachage du n+kème bloc. Si c'est un nombre impair, Alice gagne, sinon Bob gagne. Le DLC construit une signature conditionnelle en transmettant les informations du bloc via un oracle, permettant au gagnant de remporter tous les actifs.

Les étapes spécifiques sont les suivantes :

1. Initialisation : définir le générateur de courbe elliptique G, d'ordre q.

2. Génération de clés : oracle, Alice et Bob génèrent chacun une clé privée et une clé publique. Oracle : clé privée z, clé publique Z = z·G Alice: clé privée x, clé publique X = x·G
   Bob: clé privée y, clé publique Y = y·G

3. Transaction de capitalisation : Alice et Bob créent une transaction de capitalisation, chacun verrouillant 1BTC dans une sortie multisignature 2-of-2.

4. Exécution de contrat : créer deux transactions d'exécution de contrat (CET), utilisées pour dépenser des transactions d'investissement.

5. Engagement de calcul d'oracle: R := k·G S := R - hash(OddNumber,R)·Z S' := R - hash(EvenNumber,R)·Z Broadcast (R,S,S')

6. Alice et Bob calculent la nouvelle clé publique : PK^Alice := X + S PK^Bob := Y + S'

7. Règlement : L'oracle génère s ou s' en fonction de la valeur de hachage du n+k ième bloc. Nombre impair:s := k - hash(NombreImpair,R)·z nombre pair:s' := k - hash(NombrePair,R)·z

8. Retrait: Le gagnant calcule une nouvelle clé privée en fonction de s ou s' et retire des actifs. Alice:sk^Alice := x + s Bob:sk^Bob := y + s'

L'analyse montre que la nouvelle clé privée calculée et la nouvelle clé publique satisfont la relation de logarithme discret, permettant ainsi de retirer des fonds.

De plus, il est nécessaire d'ajouter un verrouillage temporel pour limiter le temps de retrait des fonds, afin d'empêcher l'autre partie de retirer des actifs après le délai.

3. DLC Optimisation

3.1 Gestion des clés

La clé privée et le nombre aléatoire de l'oracle sont essentiels pour la sécurité ; une fuite ou une perte peut entraîner divers problèmes de sécurité :

1. Clé privée perdue : impossible de régler, un contrat de remboursement doit être exécuté
2. Fuite de clé privée : tous les DLC sont exposés au risque de règlement frauduleux
3. Fuite ou réutilisation des nombres aléatoires : peut dériver la clé privée
4. Nombre aléatoire perdu : impossible de régler un DLC spécifique

Il est conseillé de prendre les mesures suivantes :

• Utiliser BIP32 pour dériver des clés enfants ou des clés petits-enfants pour la signature
• Utiliser la valeur de hachage de la clé privée et du compteur comme nombre aléatoire

3.2 oracle décentralisé

Utiliser la signature de seuil Schnorr pour réaliser un oracle décentralisé présente les avantages suivants :

• Amélioration de la sécurité : gestion des clés décentralisée, réduction du risque de point de défaillance unique
• Contrôle distribué : aucune entité unique ne détient tous les pouvoirs de signature.
• Améliorer la disponibilité : il suffit d'atteindre le seuil pour signer
• Flexibilité et évolutivité : différents seuils peuvent être définis pour s'adapter à divers scénarios.
• Responsabilité : vérifiabilité de la correctitude de chaque fragment de signature de nœud.

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

Dans le cadre des scénarios de oracles décentralisés, la clé privée complète n'apparaît pas, et il n'est pas possible d'utiliser directement BIP32 pour la dérivation de clés. On peut adopter une méthode de dérivation de clés distribuée :

• Selon le polynôme d'interpolation de Lagrange, les fragments de clé privée et la clé privée complète satisfont la relation d'interpolation.
• Les fragments de clé privée, ajoutés à l'incrément, conservent toujours la relation d'interpolation avec les sous-clés.
• Chaque partie participante peut dériver des fragments de clé privée pour générer des fragments de signature.

Il est nécessaire de prendre en compte les problèmes de compatibilité entre BIP32 amélioré et non amélioré.

3.4 OP-DLC: minimisation de la confiance des oracles

Proposer le mécanisme OP-DLC, introduire un défi optimiste :

• L'oracle doit être staké à l'avance pour construire un jeu OP sur la chaîne.
• Tout participant honnête peut contester les actes malveillants.
• Si le défi est réussi, alors il y aura une punition sur la chaîne pour les oracles malveillants.
• Un modèle de signature "k-of-n" peut être utilisé, la valeur de k peut être 1.
• L'hypothèse de confiance est réduite à un seul participant honnête dans le réseau.

3.5 OP-DLC + BitVM 双桥

Combiner OP-DLC et BitVM pour résoudre les problèmes de DLC lors de l'utilisation d'un pont inter-chaînes :

• Utiliser BitVM pour résoudre le problème de la monnaie, réduire le nombre de CET
• Fournir plusieurs canaux de dépôt et de retrait, permettant un rendu de monnaie à toute granularité.
• Définir l'alliance BitVM comme Bob et l'oracle, minimiser la confiance
• Le montant de retrait du canal DLC introduit le pool de fonds BitVM, augmentant l'utilisation.

4. Conclusion

DLC combine des technologies nouvelles telles que Taproot et BitVM, permettant une validation et un règlement des contrats hors chaîne plus complexes. Grâce au mécanisme de défi OP, il est possible de réaliser une minimisation de la confiance des oracles, apportant plus de possibilités à l'écosystème Bitcoin.