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

1. Introduction

Le contrat de logarithme discret (DLC) est une solution d'exécution de contrat Bitcoin basée sur des oracles, proposée par Tadge Dryja du MIT en 2018. Le DLC permet aux deux parties d'effectuer des paiements conditionnels en fonction de conditions prédéfinies, les participants signant à l'avance les résultats possibles, et l'exécution du paiement se produisant lorsque l'oracle signe le résultat. Cela permet au DLC de réaliser de nouvelles applications financières décentralisées sur Bitcoin tout en garantissant la sécurité des dépôts.

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

• Meilleure protection de la vie privée, les détails du contrat sont partagés uniquement entre les parties impliquées.
• Support des contrats financiers complexes et flexibles, tels que les dérivés, l'assurance, etc.
• Réduire le risque de contrepartie, fonds bloqués dans un contrat multi-signatures
• Pas besoin de gérer les canaux de paiement
• Offrir une meilleure évolutivité en matière de contrats complexes

Cependant, il existe encore certains problèmes et risques liés au DLC :

• Risque de fuite ou de perte de la clé d'oracle
• Problème de centralisation des oracles
• Les oracles décentralisés ne peuvent pas effectuer de dérivation de clés
• Risque de collusion des oracles
• Problème de rendu de monnaie à montant fixe

Cet article explorera le principe du DLC et proposera quelques solutions d'optimisation pour résoudre les problèmes susmentionnés.

2. Principe du DLC

Prenons l'exemple d'Alice et Bob signant 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, et si c'est un nombre pair, Bob gagne.

Initialisation:

• Générateur d'elliptic curve G, ordre q
• clé privée d'oracle z, clé publique Z=z·G
• La clé privée d'Alice x, la clé publique X=x·G
• Clé privée de Bob y, clé publique Y=y·G

Injection de capital: Alice et Bob verrouillent chacun 1 BTC dans une sortie multi-signature 2-of-2.

Exécution des transactions de contrat : créer deux CET pour dépenser les transactions de capital.

Oracle s'engage: R := k·G
S := R - hash(OddNumber,R)·Z S' := R - hash(EvenNumber,R)·Z 广播(R,S,S')

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

Règlement: Résultat impair : s := k - hash(OddNumber,R)·z Résultat pair : s' := k - hash(EvenNumber,R)·z

Retrait de fonds : Nouvelle clé privée d'Alice : sk^Alice := x + s Nouvelle clé privée de Bob : sk^Bob := y + s'

3. Plan d'optimisation DLC

3.1 Gestion des clés

La gestion des clés d'oracle fait face aux risques suivants :

1. clé privée perdue : impossible de régler, exécuter le remboursement
2. fuite de clé privée z : pourrait être utilisé pour signer n'importe quel message
3. fuite ou réutilisation du nombre aléatoire k : la clé privée z peut être calculée.
4. perte du nombre aléatoire k : le DLC correspondant ne peut pas être réglé

Conseils:

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

3.2 Oracle décentralisé

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

• Améliorer la sécurité, gestion des clés décentralisée
• Contrôle distribué, réduction des risques de concentration de pouvoir
• Améliorer la disponibilité, certaines pannes de nœuds n'affectent pas l'ensemble
• Flexible et extensible, différents seuils peuvent être définis
• Responsable, les fragments de signature peuvent être vérifiés

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

Les oracles décentralisés ne peuvent pas utiliser directement BIP32 pour dériver des clés. Une méthode de dérivation de clés distribuée peut être adoptée :

Les fragments de clé privée z_i et la clé privée complète z satisfont la relation d'interpolation de Lagrange: z = Σ(z_i · λ_i)

L'ajout de l'incrément dérivé ω continue de satisfaire la relation d'interpolation : z + ω = Σ((z_i + ω) · λ_i)

Chaque partie participante peut dériver des fragments de sous-clé privée z_i + ω.

Mais il faut prendre en compte la différence entre BIP32 renforcé et non renforcé.

3.4 OP-DLC: minimisation de la confiance de l'oracle

Proposer un plan OP-DLC :

• Staking anticipé d'oracle pour construire des jeux OP sur la chaîne
• Tout participant honnête peut lancer un défi
• Si le défi est réussi, alors punissez le prophète du mal.
• Peut être utilisé en combinaison avec le modèle "k-of-n"

Avantages :

• Les nœuds d'oracle se surveillent mutuellement
• Il suffit d'un participant honnête, taux de tolérance aux pannes de 99%
• Résoudre le risque de collusion des oracles

3.5 OP-DLC + BitVM双桥

Combiner OP-DLC avec BitVM:

• Résoudre le problème de la monnaie avec BitVM
• Fournir plusieurs canaux de dépôt et de retrait
• L'alliance BitVM agit en tant qu'oracle, réalisant une minimisation de la confiance.
• Améliorer l'utilisation des fonds

4. Conclusion

Le DLC, combiné avec des technologies telles que Taproot et BitVM, permet de réaliser des vérifications et des règlements de contrats off-chain plus complexes. Le mécanisme de défi OP permet de minimiser la confiance envers les oracles, offrant de nouvelles possibilités pour le développement des DLC.