Les DLC évoluent pour répondre aux besoins institutionnels


Les contrats de journaux discrets sont un concept ancien dans ce domaine à ce stade, proposé par Thaddeus Dryja (co-créateur du protocole Lightning Network) en 2017. Les DLC sont une structure de contrat intelligente conçue pour résoudre trois problèmes liés aux schémas contractuels avant la proposition  : premièrement, l’évolutivité du contrat intelligent lui-même, qui nécessitait une plus grande empreinte en chaîne pour un plus grand ensemble de résultats potentiels ; deuxièmement, la question de l’introduction des données externes à la blockchain « dans la blockchain » pour le règlement des contrats ; et enfin, la vie privée des utilisateurs du contrat intelligent. Le schéma de base est très simple, deux parties créent une adresse multisig composée des deux et choisissent un oracle.

Après cela, ils créent un ensemble de transactions d'exécution de contrat qui interagissent avec l'oracle. Supposons que l'oracle annonce le prix du bitcoin et que les participants parient sur le prix du bitcoin, l'oracle publie un ensemble d'engagements concernant les messages qu'il signera afin « d'annoncer » le prix du bitcoin à un certain prix. temps.

Les CET sont construits de telle sorte que la signature sur chaque CET qu'un participant donne à l'autre soit cryptée à l'aide des signatures d'adaptateur. Chaque signature pour le règlement du contrat à un prix donné ne peut être déchiffrée qu'avec les informations du message oracle signé attestant ce prix donné. L'oracle publie simplement ses engagements concernant les messages pour toutes les données pour lesquelles il agit en tant qu'oracle, et tout participant peut utiliser ces informations de manière non interactive pour créer un DLC.

Les DLC évoluent pour répondre aux besoins institutionnels

Le dernier élément est une transaction de remboursement limitée dans le temps, si l'oracle ne diffuse jamais les informations nécessaires pour régler le DLC, après l'expiration d'une période de verrouillage prolongée au-delà de la durée du contrat, les deux parties sont simplement remboursées de leur argent. Cela résout les trois problèmes majeurs décrits par Tadge (Thaddeus) dans le livre blanc original du DLC : il est évolutif, ne nécessitant qu'une seule transaction pour financer le contrat et une seule transaction pour le régler ; cela permet aux données externes d'être « introduites » dans la blockchain ; et cela résout le problème de la confidentialité, dans la mesure où les oracles diffusent aveuglément des données au public, ils n'ont aucune idée de qui les utilise comme oracle dans un contrat. Vous pouvez même utiliser une fédération de plusieurs oracles, où si la valeur qu'ils attestent est suffisamment proche les unes des autres, le contrat est réglé correctement.

Une dernière chose importante à noter avec les DLC, c'est que les oracles mentant pour régler les contrats de manière incorrecte sont un modèle très différent de celui d'un multisig de séquestre traditionnel. Dans le modèle de dépôt fiduciaire, un oracle peut choisir de nuire de manière sélective à un seul utilisateur en signant un règlement inapproprié. Il est possible d'atténuer les dommages à la réputation, mais dans le modèle DLC, un oracle ne peut pas le faire.

Lorsqu'ils signent un message, celui-ci est utilisé pour régler chaque DLC connecté à ce message de règlement et à cette heure. Il n'y a aucun moyen d'agir de manière sélective et malveillante envers une seule partie car ils ne savent pas qui les utilise. Le seul véritable défaut de ce système, outre la confiance inéluctable dans un oracle, est le problème de coordination.

Selon la nature du contrat, par exemple un pari sur le prix du Bitcoin par rapport à un pari sur un jeu de sport (l'équipe X gagne ou l'équipe Y gagne), il pourrait y avoir soit une poignée de CET, soit un ensemble massif de CET pour couvrir tous résultats potentiels. Cela ouvre deux problèmes  : premièrement, si l'ensemble des transactions est suffisamment important, cela crée un risque de problèmes de réseau et d'attaques DoS qui font perdre du temps aux gens en ne complétant pas le contrat établi ; deuxièmement, la possibilité d'un problème d'option gratuite qui nécessiterait une transaction en chaîne pour être traitée. Il y aurait un problème d'option gratuite si le contrat est établi et finalisé, mais que la partie qui obtient la signature complète du financement ne l'a pas diffusé.

Cela leur permettrait de financer le DLC en chaîne uniquement s'il est en leur faveur et pas autrement, et le seul moyen pour l'autre partie d'échapper à cette situation serait de doubler son financement en chaîne. DLC Markets LN Markets a récemment publié un article décrivant une nouvelle spécification DLC qu'ils ont conçue pour adapter un mécanisme DLC aux acteurs institutionnels. La suite existante de projets s'appuyant sur les DLC a été davantage adaptée aux consommateurs de détail, ce qui a laissé la possibilité de modifier la conception pour répondre aux besoins des acteurs institutionnels plus larges.

Certains problèmes pour les clients institutionnels sont : le problème des options gratuites, qui n'est pas acceptable dans ce type d'environnement ; le deuxième est le manque d'appels de marge, c'est-à-dire qu'une position soit fermée si une partie ne dispose pas de suffisamment de capital de marge pour couvrir sa partie de la transaction au prix actuel, ou si cette partie ajoute la marge supplémentaire requise pour la maintenir ouverte ; enfin, la possibilité d'utiliser le capital de manière plus efficace plutôt que de le garder bloqué dans une seule position du début à la fin du contrat. Pour résoudre tous ces problèmes, LN Markets a introduit le concept de coordinateur DLC. Plutôt que des pairs dans un contrat se coordonnant directement entre eux pour gérer le financement et la négociation du contrat, le coordinateur peut s'asseoir au milieu et aider à faciliter cela.

Cela résout le problème des options gratuites de manière assez élégante, en demandant au coordinateur de faciliter les négociations contractuelles. Plutôt que chaque pair interagisse directement les uns avec les autres pour signer l’exécution du contrat et les transactions de financement, ils soumettent leurs signatures pour tout cela au coordinateur. À aucun moment l’un ou l’autre des participants n’aura accès aux signatures nécessaires pour financer le contrat, supprimant ainsi la possibilité d’avoir une option gratuite.

Le coordinateur est le seul à avoir les deux signatures, et pour résoudre le problème de leur collusion avec un participant ou de leur malveillance et de leur refus de soumettre la transaction de financement pour une autre raison, la transaction de financement comprend le paiement de frais pour leur fonctionnement en tant que un coordinateur. Cela les incite directement à soumettre la transaction de financement une fois que le DLC a été négocié et signé. Une autre efficacité considérable réside dans le processus de coordination de la construction du DLC en premier lieu.

Sans le coordinateur impliqué, les participants devraient communiquer entre eux, échanger des adresses et des informations UTXO, puis coordonner la mise en place du DLC. Avec le coordinateur, les utilisateurs peuvent simplement enregistrer un xpub et certains UTXO auprès du coordinateur, ainsi que leurs offres de conditions contractuelles. Lorsqu'une personne accepte une offre existante, le coordinateur dispose de toutes les informations nécessaires pour construire les CET, après quoi il peut simplement les fournir à la personne qui accepte l'offre pour vérifier et signer, puis transmettre les signatures au coordinateur.

L'offrant initial recevra ensuite les CET à vérifier, signer et retourner dès qu'ils seront en ligne et décidera d'accepter la contrepartie, les renvoyant au coordinateur qui pourra alors combiner les signatures et soumettre l'opération de financement. Liquidations L'implication du coordinateur offre également un point de communication fiable pour ajouter la dernière pièce manquante aux DLC appliqués en milieu professionnel : liquidations et traitement ajoutant une marge supplémentaire. Il y avait une belle infographie tirée du livre blanc inclus dans l'article écrit par LN Markets annonçant la proposition, mais j'ai l'impression que celle-ci est beaucoup plus intuitive à comprendre.

En plus de tous les CET attachés aux messages Oracle pour les annonces de prix qui pourraient avoir lieu à l'expiration du contrat, il existe également des transactions de règlement spéciales pour les périodes précédant l'expiration réelle du contrat – dont l'intervalle peut être décidé par les participants en fonction de la fréquence. l'oracle publie des messages de prix à l'adresse. Chaque partie dispose d'un CET spécial pour chacun de ces « heures de liquidation », où si le prix est en dehors de la fourchette contractuelle (c'est-à-dire que tous les fonds sont dus à une seule partie) à l'un de ces points de liquidation, ils peuvent simplement soumettre cette transaction.

et régler le contrat plus tôt. Si, à l'approche d'un moment de liquidation, une partie se trouve au point de liquidation, elle peut utiliser le coordinateur pour coordonner l'ajout de marge au contrat et permettre à l'autre partie de réaliser une partie de ses gains en retirant des fonds du contrat. Cela impliquerait que les deux parties dépensent en collaboration du financement multisig vers un nouveau DLC qui recevrait plus de fonds de la partie sous-garantie et permettrait à la partie « gagnante » de retirer une partie des fonds.

Le nouveau DLC serait par ailleurs réglé à la même heure d'expiration et avec les mêmes points de liquidation définis avant cela. Cette dynamique rend les capacités beaucoup plus conformes aux attentes des investisseurs institutionnels ; la capacité de gérer les liquidités plus efficacement, de faire expirer un contrat plus tôt si une partie est sous-garantie en fonction du prix actuel du marché, et la possibilité d'ajouter des garanties supplémentaires en réponse à un événement de liquidation à venir. Quel est le problème ? Pour certains, cela peut ressembler à une série d'ajustements très mineurs et finalement non pertinents par rapport à la spécification originale du DLC, mais ces petits changements prennent quelque chose qui, en raison de ses défauts existants, n'avait pas beaucoup de potentiel en dehors de l'utilisation par les consommateurs de détail et le placent dans la ligue.

de pouvoir potentiellement répondre aux besoins d’acteurs économiques et de pools de capitaux beaucoup plus importants. Si le réseau Lightning a constitué un énorme pas en avant pour l'utilisation transactionnelle du Bitcoin, je pense qu'il a le potentiel de constituer un bond en avant similaire pour l'utilisation du Bitcoin par les marchés financiers et financiers. Chaque cas d'utilisation de Bitcoin ne sera pas un cas d'utilisation que tout le monde aime ou dont tout le monde a besoin, et certains peuvent même avoir des externalités qu'ils créent pour d'autres cas d'utilisation, mais en tant que système ouvert, c'est la réalité du fonctionnement de Bitcoin.

N’importe qui peut s’appuyer dessus. Cette proposition n'est peut-être pas un cas d'utilisation principal pour de nombreuses personnes qui lisent ceci, mais cela ne devrait pas vous faire ignorer le fait qu'elle pourrait devenir un cas très important.

Les DLC évoluent pour répondre aux besoins institutionnels


Les contrats de journaux discrets sont un concept ancien dans ce domaine à ce stade, proposé par Thaddeus Dryja (co-créateur du protocole Lightning Network) en 2017. Les DLC sont une structure de contrat intelligente conçue pour résoudre trois problèmes liés aux schémas contractuels avant la proposition  : premièrement, l’évolutivité du contrat intelligent lui-même, qui nécessitait une plus grande empreinte en chaîne pour un plus grand ensemble de résultats potentiels ; deuxièmement, la question de l’introduction des données externes à la blockchain « dans la blockchain » pour le règlement des contrats ; et enfin, la vie privée des utilisateurs du contrat intelligent.

Le schéma de base est très simple, deux parties créent une adresse multisig composée des deux et choisissent un oracle. Après cela, ils créent un ensemble de transactions d'exécution de contrat qui interagissent avec l'oracle. Supposons que l'oracle annonce le prix du bitcoin et que les participants parient sur le prix du bitcoin, l'oracle publie un ensemble d'engagements concernant les messages qu'il signera afin « d'annoncer » le prix du bitcoin à un certain prix. temps. Les CET sont construits de telle sorte que la signature sur chaque CET qu'un participant donne à l'autre soit cryptée à l'aide des signatures d'adaptateur. Chaque signature pour le règlement du contrat à un prix donné ne peut être déchiffrée qu'avec les informations du message oracle signé attestant ce prix donné. L'oracle publie simplement ses engagements concernant les messages pour toutes les données pour lesquelles il agit en tant qu'oracle, et tout participant peut utiliser ces informations de manière non interactive pour créer un DLC. Le dernier élément est une transaction de remboursement limitée dans le temps, si l'oracle ne diffuse jamais les informations nécessaires pour régler le DLC, après l'expiration d'une période de verrouillage prolongée au-delà de la durée du contrat, les deux parties sont simplement remboursées de leur argent.

Cela résout les trois problèmes majeurs décrits par Tadge (Thaddeus) dans le livre blanc original du DLC : il est évolutif, ne nécessitant qu'une seule transaction pour financer le contrat et une seule transaction pour le régler ; cela permet aux données externes d'être « introduites » dans la blockchain ; et cela résout le problème de la confidentialité, dans la mesure où les oracles diffusent aveuglément des données au public, ils n'ont aucune idée de qui les utilise comme oracle dans un contrat. Vous pouvez même utiliser une fédération de plusieurs oracles, où si la valeur qu'ils attestent est suffisamment proche les unes des autres, le contrat est réglé correctement. Une dernière chose importante à noter avec les DLC, c'est que les oracles mentant pour régler les contrats de manière incorrecte sont un modèle très différent de celui d'un multisig de séquestre traditionnel. Dans le modèle de dépôt fiduciaire, un oracle peut choisir de nuire de manière sélective à un seul utilisateur en signant un règlement inapproprié. Il est possible d'atténuer les dommages à la réputation, mais dans le modèle DLC, un oracle ne peut pas le faire. Lorsqu'ils signent un message, celui-ci est utilisé pour régler chaque DLC connecté à ce message de règlement et à cette heure. Il n'y a aucun moyen d'agir de manière sélective et malveillante envers une seule partie car ils ne savent pas qui les utilise.

Le seul véritable défaut de ce système, outre la confiance inéluctable dans un oracle, est le problème de coordination. Selon la nature du contrat, par exemple un pari sur le prix du Bitcoin par rapport à un pari sur un jeu de sport (l'équipe X gagne ou l'équipe Y gagne), il pourrait y avoir soit une poignée de CET, soit un ensemble massif de CET pour couvrir tous résultats potentiels. Cela ouvre deux problèmes  : premièrement, si l'ensemble des transactions est suffisamment important, cela crée un risque de problèmes de réseau et d'attaques DoS qui font perdre du temps aux gens en ne complétant pas le contrat établi ; deuxièmement, la possibilité d'un problème d'option gratuite qui nécessiterait une transaction en chaîne pour être traitée. Il y aurait un problème d'option gratuite si le contrat est établi et finalisé, mais que la partie qui obtient la signature complète du financement ne l'a pas diffusé. Cela leur permettrait de financer le DLC en chaîne uniquement s'il est en leur faveur et pas autrement, et le seul moyen pour l'autre partie d'échapper à cette situation serait de doubler son financement en chaîne.

Marchés DLC

LN Markets a récemment publié un article décrivant une nouvelle spécification DLC qu'ils ont conçue pour adapter un mécanisme DLC aux acteurs institutionnels. La suite existante de projets s'appuyant sur les DLC a été davantage adaptée aux consommateurs de détail, ce qui a laissé la possibilité de modifier la conception pour répondre aux besoins des acteurs institutionnels plus larges.

Certains problèmes pour les clients institutionnels sont : le problème des options gratuites, qui n'est pas acceptable dans ce type d'environnement ; le deuxième est le manque d'appels de marge, c'est-à-dire qu'une position soit fermée si une partie ne dispose pas de suffisamment de capital de marge pour couvrir sa partie de la transaction au prix actuel, ou si cette partie ajoute la marge supplémentaire requise pour la maintenir ouverte ; enfin, la possibilité d'utiliser le capital de manière plus efficace plutôt que de le garder bloqué dans une seule position du début à la fin du contrat.

Pour résoudre tous ces problèmes, LN Markets a introduit le concept de coordinateur DLC. Plutôt que des pairs dans un contrat se coordonnant directement entre eux pour gérer le financement et la négociation du contrat, le coordinateur peut s'asseoir au milieu et aider à faciliter cela. Cela résout le problème des options gratuites de manière assez élégante, en demandant au coordinateur de faciliter les négociations contractuelles. Plutôt que chaque pair interagisse directement les uns avec les autres pour signer l’exécution du contrat et les transactions de financement, ils soumettent leurs signatures pour tout cela au coordinateur. À aucun moment l’un ou l’autre des participants n’aura accès aux signatures nécessaires pour financer le contrat, supprimant ainsi la possibilité d’avoir une option gratuite. Le coordinateur est le seul à avoir les deux signatures, et pour résoudre le problème de leur collusion avec un participant ou de leur malveillance et de leur refus de soumettre la transaction de financement pour une autre raison, la transaction de financement comprend le paiement de frais pour leur fonctionnement en tant que un coordinateur. Cela les incite directement à soumettre la transaction de financement une fois que le DLC a été négocié et signé.

Une autre efficacité considérable réside dans le processus de coordination de la construction du DLC en premier lieu. Sans le coordinateur impliqué, les participants devraient communiquer entre eux, échanger des adresses et des informations UTXO, puis coordonner la mise en place du DLC. Avec le coordinateur, les utilisateurs peuvent simplement enregistrer un xpub et certains UTXO auprès du coordinateur, ainsi que leurs offres de conditions contractuelles. Lorsqu'une personne accepte une offre existante, le coordinateur dispose de toutes les informations nécessaires pour construire les CET, après quoi il peut simplement les fournir à la personne qui accepte l'offre pour vérifier et signer, puis transmettre les signatures au coordinateur. L'offrant initial recevra ensuite les CET à vérifier, signer et retourner dès qu'ils seront en ligne et décidera d'accepter la contrepartie, les renvoyant au coordinateur qui pourra alors combiner les signatures et soumettre l'opération de financement.

Liquidations

L'implication du coordinateur offre également un point de communication fiable pour ajouter la dernière pièce manquante aux DLC appliqués en milieu professionnel : liquidations et traitement ajoutant une marge supplémentaire.

Il y avait une belle infographie tirée du livre blanc inclus dans l'article écrit par LN Markets annonçant la proposition, mais j'ai l'impression que celle-ci est beaucoup plus intuitive à comprendre. En plus de tous les CET attachés aux messages Oracle pour les annonces de prix qui pourraient avoir lieu à l'expiration du contrat, il existe également des transactions de règlement spéciales pour les périodes précédant l'expiration réelle du contrat – dont l'intervalle peut être décidé par les participants en fonction de la fréquence. l'oracle publie des messages de prix à l'adresse. Chaque partie dispose d'un CET spécial pour chacun de ces « heures de liquidation », où si le prix est en dehors de la fourchette contractuelle (c'est-à-dire que tous les fonds sont dus à une seule partie) à l'un de ces points de liquidation, ils peuvent simplement soumettre cette transaction. et régler le contrat plus tôt.

Si, à l'approche d'un moment de liquidation, une partie se trouve au point de liquidation, elle peut utiliser le coordinateur pour coordonner l'ajout de marge au contrat et permettre à l'autre partie de réaliser une partie de ses gains en retirant des fonds du contrat. Cela impliquerait que les deux parties dépensent en collaboration du financement multisig vers un nouveau DLC qui recevrait plus de fonds de la partie sous-garantie et permettrait à la partie « gagnante » de retirer une partie des fonds. Le nouveau DLC serait par ailleurs réglé à la même heure d'expiration et avec les mêmes points de liquidation définis avant cela.

Cette dynamique rend les capacités beaucoup plus conformes aux attentes des investisseurs institutionnels ; la capacité de gérer les liquidités plus efficacement, de faire expirer un contrat plus tôt si une partie est sous-garantie en fonction du prix actuel du marché, et la possibilité d'ajouter des garanties supplémentaires en réponse à un événement de liquidation à venir.

Quel est le problème ?

Pour certains, cela peut ressembler à une série d'ajustements très mineurs et finalement non pertinents par rapport à la spécification originale du DLC, mais ces petits changements prennent quelque chose qui, en raison de ses défauts existants, n'avait pas beaucoup de potentiel en dehors de l'utilisation par les consommateurs de détail et le placent dans la ligue. de pouvoir potentiellement répondre aux besoins d’acteurs économiques et de pools de capitaux beaucoup plus importants. Si le réseau Lightning a constitué un énorme pas en avant pour l'utilisation transactionnelle du Bitcoin, je pense qu'il a le potentiel de constituer un bond en avant similaire pour l'utilisation du Bitcoin par les marchés financiers et financiers.

Chaque cas d'utilisation de Bitcoin ne sera pas un cas d'utilisation que tout le monde aime ou dont tout le monde a besoin, et certains peuvent même avoir des externalités qu'ils créent pour d'autres cas d'utilisation, mais en tant que système ouvert, c'est la réalité du fonctionnement de Bitcoin. N’importe qui peut s’appuyer dessus. Cette proposition n'est peut-être pas un cas d'utilisation principal pour de nombreuses personnes qui lisent ceci, mais cela ne devrait pas vous faire ignorer le fait qu'elle pourrait devenir un cas très important.