Discussion sur les principes techniques et les solutions d'optimisation du DLC

1. Introduction

Le contrat de logarithme discret (, DLC), est un schéma d'exécution de contrat basé sur un oracle, proposé par Tadge Dryja du MIT en 2018. Le DLC permet aux deux parties de procéder à des paiements conditionnels en fonction de conditions prédéfinies, les participants déterminant à l'avance les résultats possibles et effectuant une pré-signature. Lorsque l'oracle signe le résultat, le paiement peut être exécuté. Cela permet au DLC de réaliser de nouvelles applications financières décentralisées sur le réseau Bitcoin tout en garantissant la sécurité des dépôts en Bitcoin.

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

• Meilleure protection de la vie privée, les détails du contrat ne sont partagés qu'entre les parties participantes.
• Prise en charge de contrats financiers plus complexes et flexibles, tels que des dérivés, des assurances, etc.
• Réduire le risque de contrepartie, les fonds sont verrouillés dans une signature multiple.
• Pas besoin de gérer les canaux de paiement
• Fournir une meilleure évolutivité en matière de contrats complexes

Cependant, le DLC présente encore certains problèmes à résoudre :

• Risque de fuite de la clé privée et du nombre aléatoire de l'oracle
• Problèmes de confiance dus à la centralisation des oracles
• Les oracles décentralisés ne peuvent pas effectuer directement la dérivation de clés.
• Risque de collusion des oracles
• Limite de rendu de monnaie à montant fixe

Cet article proposera quelques solutions d'optimisation pour améliorer la sécurité de l'écosystème Bitcoin.

2. Principe du DLC

Prenons l'exemple d'Alice et Bob pariant sur la parité du hachage du n+kème bloc pour expliquer le principe du DLC :

1. Initialisation : générer G, ordre q

2. Génération de clés: 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 capital: Alice et Bob verrouillent chacun 1 BTC dans une sortie multi-signature 2-of-2

4. Exécution des transactions de contrat : créer deux CET pour les transactions d'apport.

5. Calcul des oracles : R = k·G S = R - hash(OddNumber,R)·Z S' = R - hash(NombrePair,R)·Z Diffusion (R,S,S')

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

7. Règlement: Nombre impair de hachage : s = k - hash(NombreImpair,R)·z Hash pair: s' = k - hash(EvenNumber,R)·z

8. Retrait : Alice : sk^Alice = x + s Bob : sk^Bob = y + s'

La nouvelle clé privée et la nouvelle clé publique satisfont à la relation de logarithme discret, garantissant un retrait correct.

3. Optimisation DLC

3.1 Gestion des clés

La fuite de la clé privée de l'oracle et du nombre aléatoire peut entraîner :

• Impossible de régler, remboursement nécessaire
• Règlement de fraude
• La clé privée a été compromise
• Impossible de régler un contrat spécifique

Conseil:

• Utiliser BIP32 pour dériver des clés privées
• Utiliser la clé privée et le hachage du compteur comme nombre aléatoire

3.2 Oracle décentralisé

Utiliser la signature de seuil Schnorr pour réaliser un oracle décentralisé, avantages :

• Renforcer la sécurité
• Contrôle distribué
• Améliorer la disponibilité
• Flexible et évolutif
• Responsabilité possible

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

Il est difficile d'utiliser directement les clés dérivées de BIP32 avec des oracles décentralisés. On peut adopter une méthode de dérivation de clés distribuées :

1. Les fragments de clé privée et la clé privée complète satisfont à la relation d'interpolation de Lagrange.
2. En ajoutant un incrément ω des deux côtés, la relation d'interpolation est toujours satisfaite.
3. Chaque partie peut dériver des fragments de sous-clé privée pour générer des fragments de sous-signature.
4. Utiliser BIP32 non renforcé ou une fonction de hachage homomorphe

3.4 OP-DLC: minimisation de la confiance des oracles

Proposer un mécanisme de défi optimiste:

1. Oracle de mise en jeu anticipée pour construire des jeux OP sur la chaîne
2. Toute partie honnête peut initier un défi.
3. Si le défi est réussi, alors punissez le mauvais prophète.
4. Un modèle de signature k-of-n peut être utilisé
5. Il suffit d'un participant honnête pour réaliser

3.5 OP-DLC + BitVM double pont

Combiner OP-DLC et BitVM :

1. Résoudre le problème de la monnaie de fonds DLC
2. Fournir plusieurs canaux de dépôt et de retrait
3. Réaliser une minimisation de la confiance dans les oracles
4. Améliorer l'utilisation des fonds dans le canal DLC

4. Conclusion

DLC combiné avec des technologies telles que Taproot et BitVM, permet de réaliser des validations et des règlements de contrats off-chain plus complexes. Grâce au mécanisme de défi OP, il est possible de minimiser la confiance envers les oracles. À l'avenir, DLC pourrait soutenir davantage d'applications financières innovantes sur le réseau Bitcoin.