Discussion sur les principes techniques du DLC et les stratégies d'optimisation
1. Introduction
Le contrat à base 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 d'effectuer des paiements conditionnels en fonction de conditions prédéterminées, les participants déterminant à l'avance les résultats possibles et effectuant une pré-signature. Lorsque l'oracle signe le résultat, ces pré-signatures sont utilisées pour exécuter le paiement. Le DLC permet 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, le DLC présente les avantages suivants:
Meilleure protection de la vie privée
Prise en charge de contrats financiers complexes et flexibles
Réduire le risque de contrepartie
Pas besoin de gérer les canaux de paiement
Fournir une bonne évolutivité en matière de contrats complexes
Cependant, le DLC présente encore certains problèmes, tels que :
Risque de fuite ou de perte de la clé oracle
Problème de centralisation des oracles
Les oracles décentralisés ne peuvent pas utiliser directement les clés dérivées de BIP32.
Risque de collusion des nœuds d'oracle
Il existe une limite de montant minimum lors de la redistribution des fonds.
Cet article proposera quelques idées d'optimisation pour améliorer la sécurité de l'écosystème Bitcoin.
2. Principe du DLC
Alice et Bob signent un contrat de pari : prédire la parité du hachage du n+kème bloc. Si c'est impair, Alice gagne, si c'est pair, Bob gagne. En utilisant un oracle pour transmettre les informations du bloc, ils construisent une signature conditionnelle, permettant au gagnant de remporter tous les actifs.
Initialisation : générateur G de courbe elliptique, ordre q.
Génération de clés : les oracles, Alice et Bob génèrent chacun une clé privée et une clé publique.
Transaction de financement : Alice et Bob créent une transaction de financement, chacun verrouillant 1 BTC dans une sortie multi-signature 2-of-2.
Exécution de transactions de contrat : Créer deux transactions d'exécution de contrat (CET) pour dépenser la transaction d'investissement.
Engagement de calcul de l'oracle : R := k ⋅ G, S := R - hash( impair, R) ⋅ Z, S' := R - hash( pair, R) ⋅ Z, diffusion( R, S, S').
Alice et Bob calculent chacun une nouvelle clé publique : PK^Alice := X + S, PK^Bob := Y + S'.
Règlement : Après l'apparition du bloc n+k, l'oracle génère s ou s' en fonction de la parité de la valeur de hachage.
Retrait: le gagnant utilise s ou s' pour calculer une nouvelle clé privée et retirer des actifs.
3. Optimisation de DLC
3.1 Gestion des clés
Les clés privées des oracle et les nombres aléatoires sont cruciaux, et présentent les risques suivants:
La perte de la clé privée entraîne une impossibilité de règlement.
La divulgation de la clé privée peut permettre à un attaquant de contrôler tous les résultats des contrats.
La fuite ou la réutilisation d'un nombre aléatoire peut permettre de calculer la clé privée
La perte du nombre aléatoire entraîne l'impossibilité de régler.
Il est recommandé d'utiliser BIP32 pour dériver des sous-clés, en utilisant une valeur aléatoire composée de la clé privée et d'un hachage du compteur, afin d'éviter les doublons ou les pertes.
3.2 Oracle décentralisé
L'utilisation de la signature seuil Schnorr pour réaliser un oracle décentralisé présente les avantages suivants :
Renforcer la sécurité, gestion des clés décentralisée
Réaliser un contrôle distribué
Améliorer la disponibilité du système
Flexible et évolutif
Responsable
3.3 Couplage de la décentralisation et de la gestion des clés
Les oracle décentralisés ne peuvent pas utiliser directement les clés dérivées par BIP32. Une méthode de dérivation de clé distribuée peut être adoptée, basée sur le polynôme d'interpolation de Lagrange, pour s'assurer que les fragments de clé privée et la clé privée complète respectent la relation d'interpolation. Cependant, 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
Introduction d'un mécanisme de défi optimiste, l'oracle doit être mis en jeu à l'avance. En cas de malversation, tout participant honnête peut lancer un défi. Réduire l'hypothèse de confiance, il suffit qu'il y ait un participant honnête.
3.5 OP-DLC + BitVM double pont
En combinant BitVM, résoudre le problème de la monnaie de change des fonds DLC, réaliser des remboursements de n'importe quel degré et une plus grande liquidité des fonds. Les utilisateurs peuvent déposer et retirer des fonds via le mécanisme BitVM ou OP-DLC, l'alliance BitVM agissant en tant qu'oracle, Alice étant un utilisateur ordinaire.
4. Conclusion
Le DLC combiné avec des technologies telles que Taproot et BitVM permet de réaliser une vérification et un règlement de contrats hors chaîne plus complexes. Grâce au mécanisme de défi OP, il permet une minimisation de la confiance envers les oracles, apportant ainsi plus de possibilités à l'écosystème Bitcoin.
Cette page peut inclure du contenu de tiers fourni à des fins d'information uniquement. Gate ne garantit ni l'exactitude ni la validité de ces contenus, n’endosse pas les opinions exprimées, et ne fournit aucun conseil financier ou professionnel à travers ces informations. Voir la section Avertissement pour plus de détails.
13 J'aime
Récompense
13
4
Reposter
Partager
Commentaire
0/400
RektButAlive
· Il y a 23h
Mieux que Lightning, c'est juste que les Bots ont un petit problème.
Voir l'originalRépondre0
CodeZeroBasis
· 08-13 08:16
C'est fou ce DLC !
Voir l'originalRépondre0
ShitcoinConnoisseur
· 08-12 07:22
La protection de la vie privée a été discutée si longtemps, à quoi ça sert ?
Optimisation de la technologie DLC : améliorer la sécurité de l'écosystème Bitcoin et les cas d'utilisation
Discussion sur les principes techniques du DLC et les stratégies d'optimisation
1. Introduction
Le contrat à base 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 d'effectuer des paiements conditionnels en fonction de conditions prédéterminées, les participants déterminant à l'avance les résultats possibles et effectuant une pré-signature. Lorsque l'oracle signe le résultat, ces pré-signatures sont utilisées pour exécuter le paiement. Le DLC permet 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, le DLC présente les avantages suivants:
Cependant, le DLC présente encore certains problèmes, tels que :
Cet article proposera quelques idées d'optimisation pour améliorer la sécurité de l'écosystème Bitcoin.
2. Principe du DLC
Alice et Bob signent un contrat de pari : prédire la parité du hachage du n+kème bloc. Si c'est impair, Alice gagne, si c'est pair, Bob gagne. En utilisant un oracle pour transmettre les informations du bloc, ils construisent une signature conditionnelle, permettant au gagnant de remporter tous les actifs.
Initialisation : générateur G de courbe elliptique, ordre q.
Génération de clés : les oracles, Alice et Bob génèrent chacun une clé privée et une clé publique.
Transaction de financement : Alice et Bob créent une transaction de financement, chacun verrouillant 1 BTC dans une sortie multi-signature 2-of-2.
Exécution de transactions de contrat : Créer deux transactions d'exécution de contrat (CET) pour dépenser la transaction d'investissement.
Engagement de calcul de l'oracle : R := k ⋅ G, S := R - hash( impair, R) ⋅ Z, S' := R - hash( pair, R) ⋅ Z, diffusion( R, S, S').
Alice et Bob calculent chacun une nouvelle clé publique : PK^Alice := X + S, PK^Bob := Y + S'.
Règlement : Après l'apparition du bloc n+k, l'oracle génère s ou s' en fonction de la parité de la valeur de hachage.
Retrait: le gagnant utilise s ou s' pour calculer une nouvelle clé privée et retirer des actifs.
3. Optimisation de DLC
3.1 Gestion des clés
Les clés privées des oracle et les nombres aléatoires sont cruciaux, et présentent les risques suivants:
Il est recommandé d'utiliser BIP32 pour dériver des sous-clés, en utilisant une valeur aléatoire composée de la clé privée et d'un hachage du compteur, afin d'éviter les doublons ou les pertes.
3.2 Oracle décentralisé
L'utilisation de la signature seuil Schnorr pour réaliser un oracle décentralisé présente les avantages suivants :
3.3 Couplage de la décentralisation et de la gestion des clés
Les oracle décentralisés ne peuvent pas utiliser directement les clés dérivées par BIP32. Une méthode de dérivation de clé distribuée peut être adoptée, basée sur le polynôme d'interpolation de Lagrange, pour s'assurer que les fragments de clé privée et la clé privée complète respectent la relation d'interpolation. Cependant, 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
Introduction d'un mécanisme de défi optimiste, l'oracle doit être mis en jeu à l'avance. En cas de malversation, tout participant honnête peut lancer un défi. Réduire l'hypothèse de confiance, il suffit qu'il y ait un participant honnête.
3.5 OP-DLC + BitVM double pont
En combinant BitVM, résoudre le problème de la monnaie de change des fonds DLC, réaliser des remboursements de n'importe quel degré et une plus grande liquidité des fonds. Les utilisateurs peuvent déposer et retirer des fonds via le mécanisme BitVM ou OP-DLC, l'alliance BitVM agissant en tant qu'oracle, Alice étant un utilisateur ordinaire.
4. Conclusion
Le DLC combiné avec des technologies telles que Taproot et BitVM permet de réaliser une vérification et un règlement de contrats hors chaîne plus complexes. Grâce au mécanisme de défi OP, il permet une minimisation de la confiance envers les oracles, apportant ainsi plus de possibilités à l'écosystème Bitcoin.