Discussion sur les principes techniques et les idées d'optimisation du DLC
1. Introduction
Le contrat de logarithme discret ( DLC ) est un schéma d'exécution de contrat Bitcoin basé sur des oracles, proposé par Tadge Dryja du MIT en 2018. Le DLC permet à deux parties d'effectuer des paiements conditionnels en fonction de conditions prédéfinies, les participants signant à l'avance les résultats possibles et exécutant le paiement lorsque l'oracle signe le résultat. Par rapport au réseau Lightning, le DLC présente des avantages en termes de confidentialité, de soutien aux contrats financiers complexes et de réduction des risques de contrepartie.
Bien que le DLC ait un grand potentiel dans les applications de l'écosystème Bitcoin, il existe encore certains risques et problèmes :
La fuite ou la perte de la clé de l'oracle peut entraîner des pertes d'actifs.
La centralisation des oracles entraîne des risques de confiance
Les oracles décentralisés ont du mal à réaliser la dérivation de clés
Risque de collusion des nœuds d'oracle
Limite de rendu de monnaie à montant fixe
Cet article explorera certaines solutions d'optimisation pour relever ces défis auxquels le DLC est confronté, afin d'améliorer la sécurité de l'écosystème Bitcoin.
2. Fonctionnement du DLC
Prenons l'exemple d'Alice et Bob pariant sur la parité du hash du n+kème bloc, le processus de base du DLC est le suivant :
Génération de clés: L'oracle, Alice et Bob génèrent chacun une paire de clés publiques et privées.
Transaction de capital: Alice et Bob créent une sortie multi-signature 2-of-2, chacun verrouillant 1 BTC.
Exécution du contrat de transaction : Créer deux CET pour dépenser la transaction d'investissement.
L'oracle s'engage à calculer et à diffuser (R,S,S').
Les parties calculent la nouvelle clé publique.
Règlement : L'oracle diffuse s ou s' en fonction de la valeur de hachage du bloc.
Retrait : le gagnant retire 2 BTC avec une nouvelle clé privée.
Utilisez un verrouillage temporel tout au long du processus pour garantir la sécurité des fonds.
3. DLC Optimisation
3.1 Gestion des clés
La gestion des clés des oracles fait face aux risques suivants :
La perte de la clé privée entraîne une impossibilité de règlement.
La divulgation de la clé privée a entraîné un règlement frauduleux
La fuite ou la réutilisation de nombres aléatoires entraîne la fuite de la clé privée
La perte de nombre aléatoire empêche le règlement.
Il est recommandé d'utiliser BIP32 pour dériver des sous-clés, et d'utiliser la clé privée et la valeur de hachage du compteur comme nombre aléatoire pour améliorer la sécurité.
3.2 Oracle décentralisé
L'utilisation de la signature seuil Schnorr permet de réaliser un oracle décentralisé, avec les avantages suivants :
Améliorer la sécurité, réduire les points de défaillance uniques
Mise en œuvre du contrôle des clés distribuées
Améliorer la disponibilité du système
S'adapter de manière flexible aux différents besoins en matière de sécurité
Support de la traçabilité
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 la dérivation des clés. Il est possible d'adopter une méthode de dérivation de clés distribuée, en utilisant un polynôme d'interpolation de Lagrange pour établir la relation entre les fragments de clé privée et la clé privée complète, afin de supporter la dérivation de sous-clés.
3.4 OP-DLC: minimisation de la confiance des oracles
Proposer un plan OP-DLC, introduire un mécanisme de défi optimiste:
Oracle staked à l'avance pour construire des jeux OP sur la chaîne
Toute partie honnête peut initier un défi
Si le défi est réussi, cela punira le méchant oracle.
Peut être utilisé en combinaison avec le modèle "k-of-n"
OP-DLC ne nécessite qu'une seule partie honnête pour fonctionner, ce qui réduit considérablement l'hypothèse de confiance.
3.5 OP-DLC + BitVM double pont
Combiner OP-DLC et BitVM pour résoudre le problème de répartition des fonds DLC :
Support de la monnaie de rendu à n'importe quelle granularité
Fournir plusieurs canaux de dépôt et de retrait
Oracle à confiance minimale
Améliorer le taux d'utilisation des fonds
4. Conclusion
La technologie DLC continue de se développer et de s'améliorer. En combinant des nouvelles technologies comme Taproot, BitVM, les DLC devraient à l'avenir permettre une validation et un règlement de contrats hors chaîne plus complexes, tout en réalisant une minimisation de la confiance des oracles grâce au mécanisme OP.
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.
7 J'aime
Récompense
7
5
Partager
Commentaire
0/400
BakedCatFanboy
· Il y a 5h
Le nom Oracle Machine semble peu fiable...
Voir l'originalRépondre0
GateUser-3824aa38
· Il y a 5h
Cette Oracle Machine est aussi fiable que Satoshi Nakamoto ?
Voir l'originalRépondre0
BottomMisser
· Il y a 5h
Hehe, mieux vaut laisser tomber. Un Oracle Machine centralisé ose aussi jouer.
Voir l'originalRépondre0
GasWastingMaximalist
· Il y a 5h
Oracle Machine a encore échoué ? Ce n'est pas à BTC de porter cette charge.
Voir l'originalRépondre0
YieldHunter
· Il y a 5h
Techniquement parlant, le risque oracle fait que tout cela ressemble à un pot de miel de dégen prêt à exploser... passe
Solution d'optimisation de la technologie DLC : améliorer la sécurité de l'écosystème Bitcoin
Discussion sur les principes techniques et les idées d'optimisation du DLC
1. Introduction
Le contrat de logarithme discret ( DLC ) est un schéma d'exécution de contrat Bitcoin basé sur des oracles, proposé par Tadge Dryja du MIT en 2018. Le DLC permet à deux parties d'effectuer des paiements conditionnels en fonction de conditions prédéfinies, les participants signant à l'avance les résultats possibles et exécutant le paiement lorsque l'oracle signe le résultat. Par rapport au réseau Lightning, le DLC présente des avantages en termes de confidentialité, de soutien aux contrats financiers complexes et de réduction des risques de contrepartie.
Bien que le DLC ait un grand potentiel dans les applications de l'écosystème Bitcoin, il existe encore certains risques et problèmes :
Cet article explorera certaines solutions d'optimisation pour relever ces défis auxquels le DLC est confronté, afin d'améliorer la sécurité de l'écosystème Bitcoin.
2. Fonctionnement du DLC
Prenons l'exemple d'Alice et Bob pariant sur la parité du hash du n+kème bloc, le processus de base du DLC est le suivant :
Génération de clés: L'oracle, Alice et Bob génèrent chacun une paire de clés publiques et privées.
Transaction de capital: Alice et Bob créent une sortie multi-signature 2-of-2, chacun verrouillant 1 BTC.
Exécution du contrat de transaction : Créer deux CET pour dépenser la transaction d'investissement.
L'oracle s'engage à calculer et à diffuser (R,S,S').
Les parties calculent la nouvelle clé publique.
Règlement : L'oracle diffuse s ou s' en fonction de la valeur de hachage du bloc.
Retrait : le gagnant retire 2 BTC avec une nouvelle clé privée.
Utilisez un verrouillage temporel tout au long du processus pour garantir la sécurité des fonds.
3. DLC Optimisation
3.1 Gestion des clés
La gestion des clés des oracles fait face aux risques suivants :
Il est recommandé d'utiliser BIP32 pour dériver des sous-clés, et d'utiliser la clé privée et la valeur de hachage du compteur comme nombre aléatoire pour améliorer la sécurité.
3.2 Oracle décentralisé
L'utilisation de la signature seuil Schnorr permet de réaliser un oracle décentralisé, avec les avantages suivants :
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 la dérivation des clés. Il est possible d'adopter une méthode de dérivation de clés distribuée, en utilisant un polynôme d'interpolation de Lagrange pour établir la relation entre les fragments de clé privée et la clé privée complète, afin de supporter la dérivation de sous-clés.
3.4 OP-DLC: minimisation de la confiance des oracles
Proposer un plan OP-DLC, introduire un mécanisme de défi optimiste:
OP-DLC ne nécessite qu'une seule partie honnête pour fonctionner, ce qui réduit considérablement l'hypothèse de confiance.
3.5 OP-DLC + BitVM double pont
Combiner OP-DLC et BitVM pour résoudre le problème de répartition des fonds DLC :
4. Conclusion
La technologie DLC continue de se développer et de s'améliorer. En combinant des nouvelles technologies comme Taproot, BitVM, les DLC devraient à l'avenir permettre une validation et un règlement de contrats hors chaîne plus complexes, tout en réalisant une minimisation de la confiance des oracles grâce au mécanisme OP.