Optimisation DLC : une solution simple pour une grande simplicité
En 2018, Tadge Dryja du MIT a proposé le cadre d'exécution de contrat basé sur les oracles, Discreet Log Contract (DLC). Le DLC permet aux deux parties d'effectuer des paiements conditionnels en fonction de conditions prédéfinies, avec des résultats possibles déterminés à l'avance et des pré-signatures. Lorsqu'un oracle signe le résultat, ces pré-signatures sont utilisées pour exécuter le paiement. Ce mécanisme permet de garantir la sécurité des dépôts en bitcoins tout en réalisant de nouvelles applications financières décentralisées.
L'analyse précédente a examiné les avantages des DLC en matière de protection de la vie privée, de contrats complexes, de risques d'actifs, etc., et a également souligné des problèmes tels que les risques de clés, les risques de confiance décentralisée et les risques de collusion. Bien que l'introduction d'oracles décentralisés, de signatures de seuil et de mécanismes de défi optimiste puisse résoudre ces problèmes, la situation des attaques de collusion entre les différentes parties impliquées (oracle, Alice et Bob) dans les DLC est complexe, ce qui rend les stratégies de défense relativement compliquées. Cette stratégie de défense complexe n'est pas parfaite et manque de simplicité.
Dans Bitcoin, toute action d'une partie participante doit être réalisée via UTXO. Par conséquent, tant que l'UTXO est correct, il est possible de résister à toute attaque. De même, dans le DLC, toute action doit être exécutée via le contrat CET( pour réaliser la transaction ). Tant que le mécanisme de défi optimiste garantit que le CET est correct, il est possible de résister à toute attaque. Plus précisément, l'oracle doit miser 2BTC avant de pouvoir signer le CET. En ajoutant un mécanisme de défi optimiste au CET, si le CET n'est pas contesté ou réussit à faire face à un défi, il est considéré comme correct et peut être réglé, l'oracle retire sa mise et reçoit des frais; si l'oracle tente de mal agir, quiconque peut réussir à contester, ce CET ne pourra pas être réglé, l'oracle perdra sa mise et ne pourra plus signer le même CET. Ce plan est simple et efficace.
Principe du DLC
Prenons l'exemple d'Alice et Bob pariant sur la parité du hachage du ξème bloc : si c'est un nombre impair, Alice gagne ; si c'est un nombre pair, Bob gagne. Le DLC transmet les informations du bloc via un oracle pour construire une signature conditionnelle, permettant à la partie gagnante d'obtenir tous les actifs.
Le générateur de courbe elliptique est G, d'ordre q. Les paires de clés de l'oracle, Alice et Bob sont respectivement (z, Z), (x, X), (y, Y).
Injection de fonds : Alice et Bob investissent chacun 10 BTC, verrouillés dans une sortie multisig 2-of-2.
Construire CET : Alice et Bob créent CET1 et CET2 pour dépenser les transactions d'investissement.
Calcul de l'engagement de l'oracle R = k · G, puis calcul de S et S:'
S := R - hash(OddNumber, R) · Z
S' := R - hash(EvenNumber, R) · Z
La nouvelle clé publique correspondante à Alice et Bob :
PK^Alice := X + S
PK^Bob := Y + S'
Règlement : Après la génération du ξ-ème bloc, l'oracle signe le CET1 ou CET2 correspondant selon la valeur de hachage.
Si le hachage est impair, l'oracle signe s :
s := k - hash(NombreImpair, R) z
Diffusion CET1.
Si le hachage est pair, l'oracle signe s':
s' := k - hash(EvenNumber, R) z
Diffusion CET2.
Retrait: Si CET1 est diffusé, Alice peut calculer une nouvelle clé privée et dépenser 20BTC:
sk^Alice = x + s
Si le CET2 est diffusé, Bob peut calculer une nouvelle clé privée et dépenser 20BTC :
sk^Bob = y + s'
La recherche a révélé que toute action dans le processus susmentionné doit être réalisée via CET. Par conséquent, il suffit d'utiliser un mécanisme de défi optimiste pour garantir que CET est correct, afin de résister à toute attaque. Un CET erroné sera contesté et non exécuté, tandis qu'un CET correct sera exécuté. De plus, l'oracle doit payer le prix de comportements malveillants.
Le programme de défi est f(t), CET doit être construit comme suit :
s = k - hash(f(t), R) z
Supposons que la valeur de hachage du ξ-ème bloc soit un nombre impair, c'est-à-dire f(ξ) = OddNumber, l'oracle doit signer CET1:
s := k - hash(OddNumber, R) z
Mais si l'oracle agit mal, en modifiant la valeur de la fonction en Even et en signant CET2 :
s' := k - hash(EvenNumber, R) z
Alors, tout utilisateur peut contrecarrer ce comportement malveillant en fonction de f(ξ) ≠ OddNumber.
OP-DLC 2
OP-DLC contient les dispositions suivantes :
Les oracles sont constitués d'une alliance, où n'importe quel membre peut signer un CET. Il faut staker 2 BTC pour pouvoir publier une signature et gagner des frais. Les membres malveillants perdent leur mise, tandis que les autres membres peuvent toujours signer des CET pour garantir le retrait des utilisateurs. Alice et Bob peuvent également devenir des oracles, réalisant qu'ils ne croient qu'en eux-mêmes.
Si l'oracle malveillant modifie les résultats, cela entraînera nécessairement f1(ξ) ≠ z1, f2(z1) ≠ z2. Toute partie participante peut initier un défi de transaction Disprove-CET1.
Lorsqu'un oracle signe honnêtement le CET, aucune partie participante ne peut initier une transaction Disprove valide. Une semaine plus tard, le CET peut être réglé correctement, et l'oracle reçoit une récompense de 0,05 BTC, en tant que rémunération pour avoir mis en jeu 2 BTC pendant une semaine et signé honnêtement le CET.
Toute partie prenante peut contester Oracle_sign:
Si Oracle_sign est honnête, il ne peut pas initier l交易 Disprove-CET1, le règlement CET sera exécuté une semaine plus tard. Le verrouillage des mises oracle est levé et des frais de transaction sont perçus.
Si Oracle_sign n'est pas honnête, toute personne réussissant à initier une transaction Disprove-CET1 et à dépenser la sortie de connector A, alors la signature de cet oracle est invalide, entraînant une perte de 2BTC de garantie, et il ne sera plus possible de demander une signature avec le même résultat pour ce contrat DLC à l'avenir.
Le défi dans OP-DLC est qu'il n'est pas nécessaire d'obtenir une autorisation ; toute partie participante peut surveiller si le contrat est correctement exécuté, réalisant ainsi une minimisation de la confiance dans l'oracle. Comparé au réseau Lightning, Alice et Bob peuvent également être hors ligne, car l'oracle ne règlera le CET que si les signatures sont honnêtes, et un oracle malveillant peut être contesté et puni par quiconque.
Avantages :
Haute maîtrise des actifs, se fier uniquement à soi-même : Alice et Bob peuvent devenir des oracles signant des CET, le mécanisme de défi optimiste contrecarrera les CET erronés, empêchant toute malveillance. L'OP-DLC permet aux utilisateurs de ne faire confiance qu'à eux-mêmes.
Taux d'utilisation des fonds élevé : les utilisateurs comptent sur leurs propres retraits, sans avoir besoin d'avancer des fonds équivalents.
Les oracles pouvant signer doivent être déterminés au moment du dépôt, mais les utilisateurs peuvent devenir des oracles et se signer eux-mêmes.
Inconvénients :
Délai de retrait d'une semaine : En essence, le coût temporel des fonds est le même pour OP-DLC et BitVM. Le retrait d'OP-DLC doit passer par une période de contestation ; si BitVM dépend du remboursement des fonds avancés par l'utilisateur, le montant équivalent des fonds avancés doit également passer par une période de contestation pour être remboursé avec succès.
Le nombre de signatures à pré-signer augmente rapidement, et est en relation linéaire avec le nombre de CET. Il faut autant de CET que possible pour énumérer tous les résultats de retrait.
Conclusion
OP-DLC introduit le mécanisme de défi optimiste dans CET, garantissant que les CET incorrects ne soient pas réglés et que les pertes des oracles malveillants soient mises en jeu ; garantissant que les CET corrects soient exécutés et que le dépôt des oracles soit débloqué et reçoive des frais. Cette méthode peut résister à toute attaque, illustrant la beauté de la simplicité.
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.
14 J'aime
Récompense
14
3
Partager
Commentaire
0/400
ChainSherlockGirl
· 07-20 18:09
Encore une pièce de théâtre sur le stationnement des fonds off-chain~ Quel Grands investisseurs se cache derrière l'Oracle Machine ?
Voir l'originalRépondre0
WhaleMinion
· 07-20 17:57
L'optimisation est-elle utile ? Le mécanisme est très simple.
OP-DLC : Mettre en œuvre une mise à niveau anti-attaque pour les contrats DLC avec une solution simple
Optimisation DLC : une solution simple pour une grande simplicité
En 2018, Tadge Dryja du MIT a proposé le cadre d'exécution de contrat basé sur les oracles, Discreet Log Contract (DLC). Le DLC permet aux deux parties d'effectuer des paiements conditionnels en fonction de conditions prédéfinies, avec des résultats possibles déterminés à l'avance et des pré-signatures. Lorsqu'un oracle signe le résultat, ces pré-signatures sont utilisées pour exécuter le paiement. Ce mécanisme permet de garantir la sécurité des dépôts en bitcoins tout en réalisant de nouvelles applications financières décentralisées.
L'analyse précédente a examiné les avantages des DLC en matière de protection de la vie privée, de contrats complexes, de risques d'actifs, etc., et a également souligné des problèmes tels que les risques de clés, les risques de confiance décentralisée et les risques de collusion. Bien que l'introduction d'oracles décentralisés, de signatures de seuil et de mécanismes de défi optimiste puisse résoudre ces problèmes, la situation des attaques de collusion entre les différentes parties impliquées (oracle, Alice et Bob) dans les DLC est complexe, ce qui rend les stratégies de défense relativement compliquées. Cette stratégie de défense complexe n'est pas parfaite et manque de simplicité.
Dans Bitcoin, toute action d'une partie participante doit être réalisée via UTXO. Par conséquent, tant que l'UTXO est correct, il est possible de résister à toute attaque. De même, dans le DLC, toute action doit être exécutée via le contrat CET( pour réaliser la transaction ). Tant que le mécanisme de défi optimiste garantit que le CET est correct, il est possible de résister à toute attaque. Plus précisément, l'oracle doit miser 2BTC avant de pouvoir signer le CET. En ajoutant un mécanisme de défi optimiste au CET, si le CET n'est pas contesté ou réussit à faire face à un défi, il est considéré comme correct et peut être réglé, l'oracle retire sa mise et reçoit des frais; si l'oracle tente de mal agir, quiconque peut réussir à contester, ce CET ne pourra pas être réglé, l'oracle perdra sa mise et ne pourra plus signer le même CET. Ce plan est simple et efficace.
Principe du DLC
Prenons l'exemple d'Alice et Bob pariant sur la parité du hachage du ξème bloc : si c'est un nombre impair, Alice gagne ; si c'est un nombre pair, Bob gagne. Le DLC transmet les informations du bloc via un oracle pour construire une signature conditionnelle, permettant à la partie gagnante d'obtenir tous les actifs.
Le générateur de courbe elliptique est G, d'ordre q. Les paires de clés de l'oracle, Alice et Bob sont respectivement (z, Z), (x, X), (y, Y).
Injection de fonds : Alice et Bob investissent chacun 10 BTC, verrouillés dans une sortie multisig 2-of-2.
Construire CET : Alice et Bob créent CET1 et CET2 pour dépenser les transactions d'investissement.
Calcul de l'engagement de l'oracle R = k · G, puis calcul de S et S:'
S := R - hash(OddNumber, R) · Z S' := R - hash(EvenNumber, R) · Z
La nouvelle clé publique correspondante à Alice et Bob : PK^Alice := X + S PK^Bob := Y + S'
Règlement : Après la génération du ξ-ème bloc, l'oracle signe le CET1 ou CET2 correspondant selon la valeur de hachage.
Si le hachage est impair, l'oracle signe s : s := k - hash(NombreImpair, R) z Diffusion CET1.
Si le hachage est pair, l'oracle signe s': s' := k - hash(EvenNumber, R) z Diffusion CET2.
Retrait: Si CET1 est diffusé, Alice peut calculer une nouvelle clé privée et dépenser 20BTC: sk^Alice = x + s
Si le CET2 est diffusé, Bob peut calculer une nouvelle clé privée et dépenser 20BTC : sk^Bob = y + s'
La recherche a révélé que toute action dans le processus susmentionné doit être réalisée via CET. Par conséquent, il suffit d'utiliser un mécanisme de défi optimiste pour garantir que CET est correct, afin de résister à toute attaque. Un CET erroné sera contesté et non exécuté, tandis qu'un CET correct sera exécuté. De plus, l'oracle doit payer le prix de comportements malveillants.
Le programme de défi est f(t), CET doit être construit comme suit : s = k - hash(f(t), R) z
Supposons que la valeur de hachage du ξ-ème bloc soit un nombre impair, c'est-à-dire f(ξ) = OddNumber, l'oracle doit signer CET1: s := k - hash(OddNumber, R) z
Mais si l'oracle agit mal, en modifiant la valeur de la fonction en Even et en signant CET2 : s' := k - hash(EvenNumber, R) z
Alors, tout utilisateur peut contrecarrer ce comportement malveillant en fonction de f(ξ) ≠ OddNumber.
OP-DLC 2
OP-DLC contient les dispositions suivantes :
Les oracles sont constitués d'une alliance, où n'importe quel membre peut signer un CET. Il faut staker 2 BTC pour pouvoir publier une signature et gagner des frais. Les membres malveillants perdent leur mise, tandis que les autres membres peuvent toujours signer des CET pour garantir le retrait des utilisateurs. Alice et Bob peuvent également devenir des oracles, réalisant qu'ils ne croient qu'en eux-mêmes.
Si l'oracle malveillant modifie les résultats, cela entraînera nécessairement f1(ξ) ≠ z1, f2(z1) ≠ z2. Toute partie participante peut initier un défi de transaction Disprove-CET1.
Lorsqu'un oracle signe honnêtement le CET, aucune partie participante ne peut initier une transaction Disprove valide. Une semaine plus tard, le CET peut être réglé correctement, et l'oracle reçoit une récompense de 0,05 BTC, en tant que rémunération pour avoir mis en jeu 2 BTC pendant une semaine et signé honnêtement le CET.
Toute partie prenante peut contester Oracle_sign:
Le défi dans OP-DLC est qu'il n'est pas nécessaire d'obtenir une autorisation ; toute partie participante peut surveiller si le contrat est correctement exécuté, réalisant ainsi une minimisation de la confiance dans l'oracle. Comparé au réseau Lightning, Alice et Bob peuvent également être hors ligne, car l'oracle ne règlera le CET que si les signatures sont honnêtes, et un oracle malveillant peut être contesté et puni par quiconque.
Avantages :
Haute maîtrise des actifs, se fier uniquement à soi-même : Alice et Bob peuvent devenir des oracles signant des CET, le mécanisme de défi optimiste contrecarrera les CET erronés, empêchant toute malveillance. L'OP-DLC permet aux utilisateurs de ne faire confiance qu'à eux-mêmes.
Taux d'utilisation des fonds élevé : les utilisateurs comptent sur leurs propres retraits, sans avoir besoin d'avancer des fonds équivalents.
Les oracles pouvant signer doivent être déterminés au moment du dépôt, mais les utilisateurs peuvent devenir des oracles et se signer eux-mêmes.
Inconvénients :
Délai de retrait d'une semaine : En essence, le coût temporel des fonds est le même pour OP-DLC et BitVM. Le retrait d'OP-DLC doit passer par une période de contestation ; si BitVM dépend du remboursement des fonds avancés par l'utilisateur, le montant équivalent des fonds avancés doit également passer par une période de contestation pour être remboursé avec succès.
Le nombre de signatures à pré-signer augmente rapidement, et est en relation linéaire avec le nombre de CET. Il faut autant de CET que possible pour énumérer tous les résultats de retrait.
Conclusion
OP-DLC introduit le mécanisme de défi optimiste dans CET, garantissant que les CET incorrects ne soient pas réglés et que les pertes des oracles malveillants soient mises en jeu ; garantissant que les CET corrects soient exécutés et que le dépôt des oracles soit débloqué et reçoive des frais. Cette méthode peut résister à toute attaque, illustrant la beauté de la simplicité.