Le Contrat Log Discret (DLC) est un cadre d'exécution de contrat basé sur un oracle proposé en 2018 par des chercheurs du Massachusetts Institute of Technology. Il permet aux deux parties d'effectuer des paiements conditionnels selon des conditions prédéfinies, en déterminant à l'avance les résultats possibles et en pré-signant, afin d'exécuter les paiements lorsque l'oracle signe le résultat. Cela permet au DLC de réaliser de nouvelles applications financières décentralisées tout en garantissant la sécurité des dépôts en bitcoin.
Le texte précédent a résumé les avantages des DLC en matière de protection de la vie privée, de contrats complexes et de faible risque d'actifs, tout en analysant les risques associés aux clés, aux risques de confiance décentralisée et aux risques de collusion auxquels il est confronté. L'article propose d'introduire des oracles décentralisés, des signatures de seuil et des mécanismes de défi optimiste pour faire face à ces problèmes. Étant donné que les DLC impliquent des oracles, Alice et Bob, les situations d'attaque de collusion entre les différentes parties impliquées sont complexes, ce qui rend également les stratégies de défense relativement compliquées. Cette stratégie de défense complexe n'est pas parfaite, ne correspond pas à la philosophie du "grand chemin est simple" et manque de beauté dans sa simplicité.
Dans Bitcoin, le comportement de toute partie impliquée doit être réalisé par UTXO. Ainsi, en s'assurant que l'UTXO est correct par le mécanisme de consensus, cela peut résister à toute attaque. De même, dans un DLC, toute action doit être réalisée par CET(Contract Execution Transaction). En utilisant le mécanisme de défi optimiste pour assurer la validité du CET, cela peut résister à toute attaque. Plus précisément, l'oracle doit mettre en jeu 2 BTC avant de pouvoir signer le CET. Le mécanisme de défi optimiste est inclus dans le CET. Si le CET n'est pas contesté ou répond avec succès à un défi, il est considéré comme correct et le règlement est effectué, l'oracle retire sa mise et reçoit des frais. Si l'oracle tente de commettre un acte malveillant, 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. Cette méthode est conforme au principe "la simplicité est la sophistication suprême", ayant une beauté de simplicité.
Principe du DLC
Alice et Bob signent un contrat de pari : parier si le hachage du ξème bloc est impair ou pair. Si c'est impair, Alice gagne le jeu et peut retirer des actifs ; si c'est pair, Bob gagne le jeu et peut retirer des actifs. Grâce au DLC, un oracle transmet les informations du ξème bloc pour construire une signature conditionnelle, permettant au gagnant correct de remporter tous les actifs.
Le générateur de courbe elliptique est G, de degré q. Les paires de clés de l'oracle, Alice et Bob sont respectivement (z, Z), (x, X), (y, Y).
Transaction de capitalisation ( sur la chaîne ) : Alice et Bob créent conjointement une transaction de capitalisation, chacun verrouillant 10 BTC dans une sortie multisignature 2-of-2 ( où une clé publique X appartient à Alice et une clé publique Y appartient à Bob ).
Construire la chaîne hors ligne CET( : Alice et Bob créent CET1 et CET2, utilisés pour dépenser des transactions d'investissement.
Oracles calculent l'engagement R = k · G, puis calculent S et S'.
S := R - hash)OddNumber, R( · Z
S' := R - hash)EvenNumber, R( · Z
Les nouvelles clés publiques correspondantes d'Alice et Bob sont les suivantes :
PK^Alice := X + S
PK^Bob := Y + S'.
sur chaîne ) : Lorsque le ξ-ème bloc est généré, l'oracle signe le CET1 ou CET2 correspondant en fonction de la valeur de hachage de ce bloc.
Si le hachage est impair, l'oracle signe s
s := k - hash(OddNumber, R) z
Diffusion CET1.
Si le hachage est pair, l'oracle signe s'
s' := k - hash(EvenNumber, R) z
Diffusion CET2.
Retrait ( sur la chaîne ) : Si l'oracle diffuse CET1, Alice peut calculer une nouvelle clé privée et dépenser les 20 BTC verrouillés.
sk^Alice = x + s
Si l'oracle diffuse CET2, Bob peut calculer une nouvelle clé privée et dépenser les 20 BTC verrouillés.
sk^Bob = y + s'
Une étude a révélé que : dans le processus ci-dessus, toute action doit être réalisée par le CET. Par conséquent, il suffit d'utiliser un mécanisme de défi optimiste pour garantir que le CET est correct afin de résister à toute attaque. Un CET incorrect sera contesté et non exécuté, tandis qu'un CET correct sera exécuté. De plus, l'oracle doit payer le prix pour les comportements malveillants.
Le programme à défier est f(t), il doit être construit comme suit pour CET.
s = k - hash(f)t(, R( z.
Supposons que la situation réelle soit que le hachage du ξ-ème bloc est un nombre impair odd, c'est-à-dire f)ξ) = OddNumber, l'oracle doit signer CET1.
s := k - hash(NombreImpair, R) z.
Mais si l'oracle agit mal et change la valeur de la fonction en Even, il a signé CET2:
s' := k - hash(EvenNumber, R) z.
Alors, tout utilisateur peut contrecarrer ce comportement malveillant en se basant sur f(ξ) ≠ OddNumber.
OP-DLC 2
OP-DLC comprend les 5 dispositions suivantes :
L'oracle est composé d'une alliance, qui comprend n participants, et tout membre peut signer un CET. Après avoir mis en jeu 2 BTC, l'oracle peut publier une signature pour gagner des frais. Si un membre agit de manière malveillante, il perdra sa mise. Les autres membres peuvent continuer à signer des CET, garantissant ainsi que les utilisateurs peuvent retirer des fonds. Alice et Bob peuvent également devenir des oracles, réalisant ainsi qu'ils doivent véritablement croire en eux-mêmes et minimiser la confiance.
Si l'oracle agit de manière malveillante et modifie les résultats, cela entraînera nécessairement f1(ξ) ≠ z1, f2(z1) ≠ z2. Par conséquent, toute partie participante peut initier un défi, c'est-à-dire effectuer une transaction Disprove-CET1.
Si l'oracle signe honnêtement le CET, aucune partie participante ne peut initier une transaction Disprove valide. Après une semaine, le CET peut être réglé correctement. De plus, l'oracle reçoit une récompense de 0,05 BTC, en tant que frais d'occupation de fonds pour son engagement de 2 BTC pendant une semaine ainsi que des frais pour avoir signé honnêtement le CET.
Toute partie participante peut contester Oracle_sign :
Si Oracle_sign est honnête, il ne sera pas possible d'initier une transaction Disprove-CET1, le règlement CET sera exécuté une semaine plus tard. Le déblocage du staking de l'oracle, et obtenir des frais;
Si Oracle_sign n'est pas honnête, c'est-à-dire que quelqu'un réussit à initier une transaction Disprove-CET1, dépensant avec succès la sortie du connecteur A, alors la signature de cet oracle est invalide, avec une perte de 2BTC en garantie, et à l'avenir, cet oracle ne pourra plus initier de signature pour le même résultat concernant ce contrat DLC, car le Settle-CET1 qui dépend de la sortie du connecteur A sera définitivement invalide.
Le défi dans OP-DLC est que c'est sans autorisation, n'importe quelle partie participante peut superviser l'exécution correcte des contrats dans l'OP-DLC. Cela permet de minimiser la confiance dans les oracles. Par rapport au réseau Lightning, Alice et Bob peuvent également être hors ligne. Comme seuls les oracles avec des signatures honnêtes peuvent régler le CET, les oracles malveillants peuvent être contestés et punis par quiconque.
Avantages :
Haute maîtrise des actifs, ne faire confiance qu'à soi-même : Alice et Bob peuvent tous deux devenir des oracles et signer le CET. Le mécanisme d'optimisme défiera les CET erronés, rendant ainsi impossible le mal. Par conséquent, l'OP-DLC permet à l'utilisateur de ne faire confiance qu'à lui-même. En revanche, dans BitVM, l'utilisateur doit agir en tant qu'Opérateur et participer à tous les dépôts ultérieurs pour ne faire confiance qu'à lui-même.
Taux d'utilisation des fonds élevé : si l'utilisateur ne fait confiance qu'à lui-même, dans l'OP-DLC, l'utilisateur dépend de lui-même pour retirer des fonds, sans avoir besoin d'un fonds de contrepartie ; tandis que dans BitVM, l'utilisateur doit fournir un fonds de contrepartie, puis se faire rembourser, ce qui entraîne une pression financière plus importante.
Les oracles capables de signer doivent être déterminés lors du dépôt de fonds OP-DLC, mais l'utilisateur peut également devenir oracle et signer pour lui-même.
Inconvénients:
Délai de retrait de 1 semaine : en essence, le coût du temps des fonds pour OP-DLC et BitVM est présent et équivalent. Le retrait d'OP-DLC nécessite une période de contestation ; si BitVM dépend de l'avance de fonds par l'utilisateur, les fonds avancés équivalents doivent également passer par une période de contestation pour être remboursés avec succès.
Le nombre de signatures à pré-signer augmente rapidement, 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 un mécanisme de défi optimiste dans le CET, garantissant que les CET erronés ne soient pas réglés et que les pertes des oracles malveillants soient mises en gage ; garantissant que les CET corrects soient exécutés, et que le gage des oracles soit déverrouillé et reçoive des frais de transaction. Cette approche peut résister à toute attaque, ayant une beauté de 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.
10 J'aime
Récompense
10
8
Reposter
Partager
Commentaire
0/400
OvertimeSquid
· 07-15 22:01
Décentralisation ça peut vraiment marcher
Voir l'originalRépondre0
ponzi_poet
· 07-15 09:51
Encore en train de parler de l'Oracle Machine.
Voir l'originalRépondre0
ApeWithNoFear
· 07-14 06:45
Consensus est de l'or, hein ?...
Voir l'originalRépondre0
SchrodingerPrivateKey
· 07-14 06:45
La grande voie est la plus simple, c'est merveilleux~
Voir l'originalRépondre0
SleepTrader
· 07-14 06:43
La chaîne doit encore être embellie.
Voir l'originalRépondre0
BuyHighSellLow
· 07-14 06:41
stake challenge incroyable de pensée
Voir l'originalRépondre0
NotFinancialAdvice
· 07-14 06:39
Encore de nouveaux concepts si compliqués...
Voir l'originalRépondre0
ValidatorViking
· 07-14 06:21
les nœuds éprouvés par la bataille ne sont pas impressionnés par un autre engouement pour le consensus. montrez-moi d'abord les métriques de disponibilité
OP-DLC 2: Simplification du Mécanisme de consensus DLC pour réaliser une confiance minimale
OP-DLC 2: La simplicité est la clé
Le Contrat Log Discret (DLC) est un cadre d'exécution de contrat basé sur un oracle proposé en 2018 par des chercheurs du Massachusetts Institute of Technology. Il permet aux deux parties d'effectuer des paiements conditionnels selon des conditions prédéfinies, en déterminant à l'avance les résultats possibles et en pré-signant, afin d'exécuter les paiements lorsque l'oracle signe le résultat. Cela permet au DLC de réaliser de nouvelles applications financières décentralisées tout en garantissant la sécurité des dépôts en bitcoin.
Le texte précédent a résumé les avantages des DLC en matière de protection de la vie privée, de contrats complexes et de faible risque d'actifs, tout en analysant les risques associés aux clés, aux risques de confiance décentralisée et aux risques de collusion auxquels il est confronté. L'article propose d'introduire des oracles décentralisés, des signatures de seuil et des mécanismes de défi optimiste pour faire face à ces problèmes. Étant donné que les DLC impliquent des oracles, Alice et Bob, les situations d'attaque de collusion entre les différentes parties impliquées sont complexes, ce qui rend également les stratégies de défense relativement compliquées. Cette stratégie de défense complexe n'est pas parfaite, ne correspond pas à la philosophie du "grand chemin est simple" et manque de beauté dans sa simplicité.
Dans Bitcoin, le comportement de toute partie impliquée doit être réalisé par UTXO. Ainsi, en s'assurant que l'UTXO est correct par le mécanisme de consensus, cela peut résister à toute attaque. De même, dans un DLC, toute action doit être réalisée par CET(Contract Execution Transaction). En utilisant le mécanisme de défi optimiste pour assurer la validité du CET, cela peut résister à toute attaque. Plus précisément, l'oracle doit mettre en jeu 2 BTC avant de pouvoir signer le CET. Le mécanisme de défi optimiste est inclus dans le CET. Si le CET n'est pas contesté ou répond avec succès à un défi, il est considéré comme correct et le règlement est effectué, l'oracle retire sa mise et reçoit des frais. Si l'oracle tente de commettre un acte malveillant, 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. Cette méthode est conforme au principe "la simplicité est la sophistication suprême", ayant une beauté de simplicité.
Principe du DLC
Alice et Bob signent un contrat de pari : parier si le hachage du ξème bloc est impair ou pair. Si c'est impair, Alice gagne le jeu et peut retirer des actifs ; si c'est pair, Bob gagne le jeu et peut retirer des actifs. Grâce au DLC, un oracle transmet les informations du ξème bloc pour construire une signature conditionnelle, permettant au gagnant correct de remporter tous les actifs.
Le générateur de courbe elliptique est G, de degré q. Les paires de clés de l'oracle, Alice et Bob sont respectivement (z, Z), (x, X), (y, Y).
Transaction de capitalisation ( sur la chaîne ) : Alice et Bob créent conjointement une transaction de capitalisation, chacun verrouillant 10 BTC dans une sortie multisignature 2-of-2 ( où une clé publique X appartient à Alice et une clé publique Y appartient à Bob ).
Construire la chaîne hors ligne CET( : Alice et Bob créent CET1 et CET2, utilisés pour dépenser des transactions d'investissement.
Oracles calculent l'engagement R = k · G, puis calculent S et S'.
S := R - hash)OddNumber, R( · Z
S' := R - hash)EvenNumber, R( · Z
Les nouvelles clés publiques correspondantes d'Alice et Bob sont les suivantes :
PK^Alice := X + S
PK^Bob := Y + S'.
sur chaîne ) : Lorsque le ξ-ème bloc est généré, l'oracle signe le CET1 ou CET2 correspondant en fonction de la valeur de hachage de ce bloc.
Si le hachage est impair, l'oracle signe s
s := k - hash(OddNumber, R) z
Diffusion CET1.
Si le hachage est pair, l'oracle signe s'
s' := k - hash(EvenNumber, R) z
Diffusion CET2.
Retrait ( sur la chaîne ) : Si l'oracle diffuse CET1, Alice peut calculer une nouvelle clé privée et dépenser les 20 BTC verrouillés.
sk^Alice = x + s
Si l'oracle diffuse CET2, Bob peut calculer une nouvelle clé privée et dépenser les 20 BTC verrouillés.
sk^Bob = y + s'
Une étude a révélé que : dans le processus ci-dessus, toute action doit être réalisée par le CET. Par conséquent, il suffit d'utiliser un mécanisme de défi optimiste pour garantir que le CET est correct afin de résister à toute attaque. Un CET incorrect sera contesté et non exécuté, tandis qu'un CET correct sera exécuté. De plus, l'oracle doit payer le prix pour les comportements malveillants.
Le programme à défier est f(t), il doit être construit comme suit pour CET.
s = k - hash(f)t(, R( z.
Supposons que la situation réelle soit que le hachage du ξ-ème bloc est un nombre impair odd, c'est-à-dire f)ξ) = OddNumber, l'oracle doit signer CET1.
s := k - hash(NombreImpair, R) z.
Mais si l'oracle agit mal et change la valeur de la fonction en Even, il a signé CET2:
s' := k - hash(EvenNumber, R) z.
Alors, tout utilisateur peut contrecarrer ce comportement malveillant en se basant sur f(ξ) ≠ OddNumber.
OP-DLC 2
OP-DLC comprend les 5 dispositions suivantes :
L'oracle est composé d'une alliance, qui comprend n participants, et tout membre peut signer un CET. Après avoir mis en jeu 2 BTC, l'oracle peut publier une signature pour gagner des frais. Si un membre agit de manière malveillante, il perdra sa mise. Les autres membres peuvent continuer à signer des CET, garantissant ainsi que les utilisateurs peuvent retirer des fonds. Alice et Bob peuvent également devenir des oracles, réalisant ainsi qu'ils doivent véritablement croire en eux-mêmes et minimiser la confiance.
Si l'oracle agit de manière malveillante et modifie les résultats, cela entraînera nécessairement f1(ξ) ≠ z1, f2(z1) ≠ z2. Par conséquent, toute partie participante peut initier un défi, c'est-à-dire effectuer une transaction Disprove-CET1.
Si l'oracle signe honnêtement le CET, aucune partie participante ne peut initier une transaction Disprove valide. Après une semaine, le CET peut être réglé correctement. De plus, l'oracle reçoit une récompense de 0,05 BTC, en tant que frais d'occupation de fonds pour son engagement de 2 BTC pendant une semaine ainsi que des frais pour avoir signé honnêtement le CET.
Toute partie participante peut contester Oracle_sign :
Si Oracle_sign est honnête, il ne sera pas possible d'initier une transaction Disprove-CET1, le règlement CET sera exécuté une semaine plus tard. Le déblocage du staking de l'oracle, et obtenir des frais;
Si Oracle_sign n'est pas honnête, c'est-à-dire que quelqu'un réussit à initier une transaction Disprove-CET1, dépensant avec succès la sortie du connecteur A, alors la signature de cet oracle est invalide, avec une perte de 2BTC en garantie, et à l'avenir, cet oracle ne pourra plus initier de signature pour le même résultat concernant ce contrat DLC, car le Settle-CET1 qui dépend de la sortie du connecteur A sera définitivement invalide.
Le défi dans OP-DLC est que c'est sans autorisation, n'importe quelle partie participante peut superviser l'exécution correcte des contrats dans l'OP-DLC. Cela permet de minimiser la confiance dans les oracles. Par rapport au réseau Lightning, Alice et Bob peuvent également être hors ligne. Comme seuls les oracles avec des signatures honnêtes peuvent régler le CET, les oracles malveillants peuvent être contestés et punis par quiconque.
Avantages :
Haute maîtrise des actifs, ne faire confiance qu'à soi-même : Alice et Bob peuvent tous deux devenir des oracles et signer le CET. Le mécanisme d'optimisme défiera les CET erronés, rendant ainsi impossible le mal. Par conséquent, l'OP-DLC permet à l'utilisateur de ne faire confiance qu'à lui-même. En revanche, dans BitVM, l'utilisateur doit agir en tant qu'Opérateur et participer à tous les dépôts ultérieurs pour ne faire confiance qu'à lui-même.
Taux d'utilisation des fonds élevé : si l'utilisateur ne fait confiance qu'à lui-même, dans l'OP-DLC, l'utilisateur dépend de lui-même pour retirer des fonds, sans avoir besoin d'un fonds de contrepartie ; tandis que dans BitVM, l'utilisateur doit fournir un fonds de contrepartie, puis se faire rembourser, ce qui entraîne une pression financière plus importante.
Les oracles capables de signer doivent être déterminés lors du dépôt de fonds OP-DLC, mais l'utilisateur peut également devenir oracle et signer pour lui-même.
Inconvénients:
Délai de retrait de 1 semaine : en essence, le coût du temps des fonds pour OP-DLC et BitVM est présent et équivalent. Le retrait d'OP-DLC nécessite une période de contestation ; si BitVM dépend de l'avance de fonds par l'utilisateur, les fonds avancés équivalents doivent également passer par une période de contestation pour être remboursés avec succès.
Le nombre de signatures à pré-signer augmente rapidement, 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 un mécanisme de défi optimiste dans le CET, garantissant que les CET erronés ne soient pas réglés et que les pertes des oracles malveillants soient mises en gage ; garantissant que les CET corrects soient exécutés, et que le gage des oracles soit déverrouillé et reçoive des frais de transaction. Cette approche peut résister à toute attaque, ayant une beauté de simplicité.