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

1. Aperçu

Les contrats de logarithme discret (DLC) sont une solution d'exécution de contrat intelligent basée sur des oracles, proposée par Tadge Dryja du MIT en 2018. Les DLC permettent aux deux parties d'effectuer des paiements conditionnels en fonction de conditions prédéfinies, les participants déterminant à l'avance les résultats possibles et signant. Lorsque l'oracle signe le résultat, le paiement peut être exécuté. Cela permet la réalisation de nouvelles applications financières décentralisées sur le réseau Bitcoin, tout en garantissant la sécurité des fonds des utilisateurs.

Par rapport au réseau Lightning, les DLC présentent 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.
• Prise en charge des contrats financiers complexes : possibilité de créer et d'exécuter directement des produits dérivés, des assurances et d'autres contrats complexes sur le réseau Bitcoin.
• Réduire le risque de contrepartie : les fonds sont verrouillés dans un contrat multi-signatures et ne sont libérés que lorsque le résultat de l'événement prévu se produit.
• Pas besoin de gérer les canaux de paiement : pas besoin de créer ou de maintenir des canaux de paiement.
• Scalabilité dans des scénarios spécifiques : offre une meilleure scalabilité en matière de contrats complexes.

Bien que le DLC ait de nombreux avantages dans l'écosystème Bitcoin, il existe encore certains problèmes à résoudre :

• Risque de sécurité des clés
• Problème de centralisation des oracles
• Les oracles décentralisés ne peuvent pas dériver directement des clés.
• Risque de conspiration des oracles
• Limite de rendu de monnaie à montant fixe

Cet article analysera le principe du DLC et proposera quelques solutions d'optimisation pour résoudre les problèmes mentionnés ci-dessus.

2. Fonctionnement du DLC

Prenons l'exemple du pari entre Alice et Bob sur la parité du hachage du n+kème bloc :

1. Initialisation : génération des paramètres de la courbe elliptique

2. Génération de clés : l'oracle, Alice et Bob génèrent chacun une clé privée et une clé publique

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

4. Exécution du contrat de transaction : Créer deux transactions d'exécution de contrat ( CET ) pour dépenser des transactions de capital.

5. Engagement de calcul d'oracle : calculer R, S et S', puis diffuser

6. Alice et Bob calculent une nouvelle clé publique

7. Règlement : L'oracle génère s ou s' en fonction du hachage du bloc et le diffuse.

8. Retrait: Le gagnant calcule une nouvelle clé privée en fonction de s ou s' et retire des actifs.

De plus, il est nécessaire d'ajouter un mécanisme de verrouillage temporel pour s'assurer qu'une partie retire les fonds dans le délai imparti, sinon l'autre partie peut retirer les actifs avec la clé privée d'origine.

3. Plan d'optimisation DLC

3.1 Gestion des clés

La sécurité de la clé privée de l'oracle et du nombre aléatoire est cruciale, car elle peut entraîner les problèmes suivants :

1. Oracles ont perdu la clé privée : impossible de régler, besoin d'exécuter le contrat de remboursement
2. Fuite de clé privée d'oracle : tous les contrats font face à un risque de fraude.
3. Fuite ou réutilisation de nombres aléatoires par l'oracle : clé privée pouvant être déduite.
4. Perte de nombre aléatoire de l'oracle : impossible de régler un contrat spécifique

Il est suggéré d'adopter les mesures suivantes :

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

3.2 Oracle décentralisé

L'utilisation de signatures de seuil Schnorr pour réaliser un oracle décentralisé présente les avantages suivants :

• Améliorer la sécurité : gestion des clés décentralisée, réduction du risque de point de défaillance unique.
• Contrôle distribué : éviter la concentration excessive du pouvoir
• Améliorer la disponibilité : le système peut fonctionner normalement même si certains nœuds ne sont pas disponibles.
• Flexibilité et évolutivité : différents seuils peuvent être définis pour s'adapter à divers scénarios.
• Responsabilité : chaque fragment de signature des nœuds peut être vérifié indépendamment.

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

Dans les oracles décentralisés, la clé privée complète n'existe pas, il n'est pas possible d'utiliser directement BIP32 pour dériver des clés. On peut utiliser une méthode de dérivation de clés distribuée :

• En utilisant 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 et la clé privée complète satisfont toujours la relation d'interpolation après avoir ajouté une augmentation.
• Chaque partie participante peut dériver des fragments de clés privées enfants, utilisés pour générer des fragments de signatures enfants.

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

3.4 OP-DLC: minimisation de la confiance des oracle

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

• Oracle staked in advance pour construire un jeu OP sur la chaîne
• Tout participant honnête peut initier un défi.
• Si le défi est réussi, punissez le prophète maléfique.
• Un modèle de signature "k-of-n" peut être utilisé, où la valeur de k peut être 1.
• L'hypothèse de confiance est réduite à un seul participant honnête

3.5 OP-DLC + BitVM double pont

Combiner OP-DLC et BitVM pour résoudre les problèmes de DLC dans les ponts inter-chaînes :

• Utiliser BitVM pour résoudre le problème de la monnaie.
• Fournir plusieurs canaux de dépôt et de retrait
• Réaliser une minimisation de la confiance des oracles via le mécanisme OP
• Améliorer l'utilisation des fonds

4. Conclusion

Le DLC combiné avec des technologies telles que Taproot et BitVM permet de réaliser des validations et règlements de contrats hors chaîne plus complexes. Grâce au mécanisme de défi OP, il est possible d'atteindre une minimisation de la confiance des oracles, offrant ainsi plus de possibilités à l'écosystème Bitcoin.