Cet article concerne un concept technologique basé sur la mise à niveau proposée du protocole Taproot. Si vous n'êtes pas encore familier avec les bases du fonctionnement de Taproot, il est recommandé de lire d'abord cet explicateur.
Racine pivotante, une mise à niveau potentielle du protocole Bitcoin proposée pour la première fois par Gregory Maxwell, contributeur de Bitcoin Core, en est à ses derniers stades de développement. La technologie consiste en une combinaison astucieuse d’astuces cryptographiques qui permettraient aux utilisateurs de cacher des contrats intelligents complexes dans des transactions d’apparence régulière – la complexité n’est révélée que si les parties à un contrat ne coopèrent pas.
Tirant parti de cette idée, les contributeurs de Bitcoin Core, notamment (mais sans s'y limiter) Jeremy Rubin, Antoine Riard, Gleb Naumenko et Gregory Maxwell lui-même, ont spéculé sur un concept général appelé pools de paiement, pools de participation ou des pools de pièces. Ces pools – nous nous en tiendrons à les appeler pools de paiement pour l'instant – permettraient à des groupes d'utilisateurs de partager la propriété des mêmes pièces (techniquement : UTXO) telles qu'enregistrées sur la blockchain Bitcoin, tout en permettant à chacun de ces utilisateurs d'effectuer (ou de recevoir) des paiements. avec eux. Alors que le groupe et ses membres individuels « se cachent » dans une structure Taproot, ils bénéficient tous de plus de confidentialité, de flexibilité des contrats intelligents et d’autres avantages… et ils peuvent même profiter de ces avantages hors chaîne, faisant des pools de paiement une nouvelle solution de couche deux.
Bien que les spécificités de la conception varient un peu d’une proposition de pool de paiement à l’autre, le concept général est le même. Voici l’idée de base…
Partager une pièce
Premièrement, pour créer un pool de paiement, les utilisateurs combinent leurs (fractions de) pièces en les regroupant dans une adresse Taproot partagée entre eux. Supposons donc qu’Alice possède trois pièces, Bob en possède deux et Carol en possède une, pour un total de six. Ensemble, ils créent une transaction qui envoie ces pièces à l'adresse partagée, ce qui en fait un pool de paiement de six pièces.
Sur la blockchain, l’adresse du pool de paiement ressemble à une adresse Bitcoin classique, contenant désormais six pièces. Mais sous la surface, Alice, Bob et Carol ont intelligemment utilisé Taproot pour s'assurer que chacun d'eux garde le contrôle de sa propre part de pièces dans le pool de paiement. Alice peut à tout moment réclamer trois pièces de l'adresse, Bob peut à tout moment en réclamer deux et Carol une.
En effet, il n’existe que deux options principales pour dépenser des pièces à partir de l’adresse.
La première option consiste à dépenser directement à partir de l’adresse, en termes techniques le chemin de clé Taproot. Cela nécessite la coopération (c'est-à-dire des signatures cryptographiques) de la part des trois participants. Si Alice, Bob et Carol sont tous d’accord, les six pièces peuvent être dépensées comme bon leur semble, et cela ressemblera à n’importe quelle autre transaction régulière sur le réseau Bitcoin. Le trio peut par exemple décider de renvoyer leurs soldes respectifs à des adresses individuelles : trois pour Alice, deux pour Bob et une pour Carol. Mais s’ils le souhaitaient, ils pourraient également coopérer pour faire don des six pièces à Julian, ou les dépenser de toute autre manière sur laquelle ils pourraient convenir. L’important est qu’ils doivent tous les trois participer, afin que personne ne dépense son solde sans sa propre coopération.
La deuxième option principale se compose en réalité de plusieurs sous-options. Avant d'envoyer leurs pièces au pool de paiement, Alice, Bob et Carol ont caché quelque chose dans l'arbre cryptographique derrière l'adresse Taproot : ils ont inclus des moyens alternatifs pour envoyer des fonds depuis le pool de paiement. (Actuellement, cela pourrait être réalisé en demandant aux trois participants de pré-signer les transactions à partir de ces chemins, ce qui nécessiterait une certaine complexité pour configurer toutes les options et ne s'adapterait pas très bien ; les mises à niveau de protocole proposées pourraient potentiellement rendre cela plus facile à l'avenir. .)
Si l'un des participants choisissait de dépenser les pièces du pool de paiement via un chemin Taproot alternatif, il enverrait généralement un montant correspondant au solde de ce participant à une adresse de son choix, comme une adresse individuelle qu'il contrôle. (Dans le cas d’Alice, trois pièces à sa propre adresse, dans le cas de Bob deux à son adresse et dans le cas de Carol une.)
En utilisant cette voie alternative, les pièces restantes sont également automatiquement dépensées. Cela peut être fait de plusieurs manières en fonction de la conception du pool de paiement, offrant différents compromis en termes de complexité et d'évolutivité.
La solution la plus simple consiste à envoyer également à chaque autre participant sa part de pièces, à l’adresse de son choix. En d’autres termes : si un utilisateur quitte le pool, tout le monde quitte le pool.
Une deuxième solution, préférée par Riard et Naumenko, consiste à envoyer toutes les pièces restantes vers un neufs pool de paiement, qui ressemble exactement au premier pool de paiement, simplement supprimé de tout ce qui impliquait l'utilisateur maintenant quitté. Cette conception offre la meilleure expérience utilisateur, mais elle est la plus difficile à mettre à l’échelle, notamment parce qu’elle doit se préparer à tous les scénarios de sortie possibles, y compris tous les scénarios de sortie possibles pour tous les nouveaux pools potentiels. Cependant, une mise à niveau potentielle du protocole Bitcoin, qui n'a pas encore été nommée, pourrait permettre d'atteindre une grande échelle afin de garantir que les règles du pool de paiement précédent soient transférées à tout nouveau pool de paiement.
Rubin estime cependant que cette deuxième solution n'est pas pratique et préfère opter pour quelque chose entre la première et la deuxième solution : certains participants reçoivent immédiatement leurs pièces à une adresse de leur choix, d'autres participants voient leurs pièces envoyées vers un nouveau pool de paiement. Cette conception offre une expérience utilisateur moins idéale, mais serait mieux évolutive, et la mise à niveau potentielle du protocole OP_CHECKTEMPLATEVERIFY contribuerait à simplifier la conception et à augmenter encore plus l'échelle. (Les sorties se feraient via les Tree Payments ; ces types de paiements sont explorés plus en détail dans cet article.)
(Il existe davantage de compromis entre la deuxième et la troisième solutions, mais les détails de tous les avantages et inconvénients sortent du cadre de cet article ; lisez le discussion sur la liste de diffusion bitcoin-dev pour plus de détails.)
Pour voir ce que cela signifie lorsque les pièces restantes sont envoyées vers un nouveau pool de paiement, disons qu'Alice, Bob et Carol choisissent la deuxième option, où TOUTE les pièces restantes sont envoyées à un nouveau pool de paiement. Si, dans cette conception, Alice quitte le premier pool de paiement, trois pièces sont envoyées à une adresse de son choix, tandis que les trois autres pièces sont envoyées vers un nouveau pool de paiement entre Bob et Carol. À ce stade, Alice a à nouveau le contrôle exclusif de ses propres pièces, même si peu de choses ont changé pour Bob et Carol. Les deux peuvent toujours coopérer pour dépenser les trois pièces restantes comme ils le souhaitent, ou l'un ou l'autre peut sortir unilatéralement, comme Alice l'avait fait auparavant.
Si Bob quitte ensuite unilatéralement le deuxième pool de paiement, il envoie deux pièces à une adresse de son choix et une pièce à un pool de paiement encore plus récent (le troisième) avec seulement Carol. (Bien sûr, dans cet exemple simplifié, une conception dans laquelle ce dernier pool de paiement est remplacé par une adresse choisie par Carol aurait en réalité plus de sens, mais c'est un détail de mise en œuvre.)
Ce qu’il faut retenir, c’est que les participants à un pool de paiement peuvent coopérer pour effectuer n’importe quel type de paiement à partir du pool, tandis que chacun d’entre eux peut à tout moment sortir avec ses propres pièces, laissant les autres participants contrôler les leurs.
Placer le paiement dans le pool de paiement
Nous avons donc établi que tous les participants peuvent individuellement retirer leur solde d'un pool de paiement ou, s'ils sont tous d'accord, dépenser depuis ce pool. C’est cette deuxième option qui permet en réalité quelque chose d’astucieux : le pool de paiement peut être dynamique. Tant que tous les participants sont d’accord, ils ne peuvent pas simplement se rembourser eux-mêmes ou payer d’autres personnes (comme Julian), mais ils peuvent faire quelque chose d’encore plus intéressant. Ils peuvent déplacer leurs fonds vers des versions plus récentes du pool de paiement, avec des conceptions différentes.
Cela permet par exemple à n'importe lequel d'entre eux de dépenser depuis le pool.
Disons qu'Alice achète une nouvelle voiture et souhaite la payer avec un bitcoin. Alice, Bob et Carol pourraient alors créer une transaction à partir du pool de paiement qui enverrait une pièce au concessionnaire automobile et enverrait les cinq pièces restantes à un concessionnaire automobile. neufs pool de paiement qui ressemble au premier, sauf que cette fois Alice ne peut en sortir qu'unilatéralement avec deux pièces, une de moins qu'avant.
La transaction, quant à elle, ressemblait à n’importe quelle autre transaction Bitcoin régulière. Le concessionnaire automobile (ou les espions de la blockchain) peuvent conclure qu'Alice possédait les six pièces et en a simplement utilisé une pour acheter la voiture, et a conservé les cinq autres comme monnaie. Ils n'auraient aucune idée que certaines des pièces appartiennent à Bob et Carol, ni qu'ils ont été impliqués dans la transaction.
La prochaine fois, lorsque Bob effectuera un paiement et qu’Alice et Carol coopéreront, celui-ci sera effectué à partir du même pool de paiement, ressemblant une fois de plus à une transaction Bitcoin ordinaire pour le monde extérieur. Dans l’itération résultante du pool de paiement, Bob peut sortir avec une pièce au lieu de deux. Pendant ce temps, les mêmes espions de la blockchain ont peut-être pensé qu'Alice effectuait à nouveau un paiement, ce qui les confondait davantage. (Et même si les espions de la blockchain découvraient d’une manière ou d’une autre que l’adresse est en réalité un pool de paiement entre Alice, Bob et Carol, ils ne pourraient toujours pas dire lequel des trois a effectué le dernier paiement.)
Chaque fois qu'Alice, Bob ou Carol dépensent des pièces, la transaction peut provenir de l'un d'entre eux, et personne en dehors du pool de paiement ne peut faire la différence.
Les pools de paiement ne permettent pas seulement de dépenser. Si Alice souhaite recharger son « solde » dans le pool de paiement, elle peut également le faire. Alice, Bob et Carol coopéreraient dans ce cas pour déplacer les cinq pièces actuelles vers une nouvelle adresse Taproot, à laquelle Alice, dans la même transaction, enverrait une pièce supplémentaire à partir de l'une de ses propres adresses (individuelles). La nouvelle adresse Taproot contiendrait à nouveau six pièces, dont trois appartenant à Alice, comme en témoigne son option de sortie unilatérale.
De la même manière, de tout nouveaux utilisateurs pourraient également rejoindre le pool de paiement. Si Alice, Bob et Carol acceptent de laisser Dave participer, ils coopèrent tous les trois avec Dave pour créer une transaction qui envoie les fonds du pool de paiement ainsi que les nouvelles pièces de Dave vers un nouveau pool de paiement, conçu pour permettre également à Dave de participer - et de sortir. s'il le voulait.
De plus, les participants au pool de paiement ont la possibilité de se payer entre eux. Si Alice payait par exemple une pièce à Bob, les trois pourraient coopérer pour envoyer les fonds vers un nouveau pool de paiement où Alice aurait une pièce soustraite de son solde et Bob aurait une pièce ajoutée. Sur la blockchain, encore une fois, cela ressemblerait à un paiement régulier, et les espions de la blockchain n’auraient aucune idée de qui a payé qui, ni combien. (Il convient de souligner que Dave aurait pu entrer dans le pool de la même manière, en recevant un paiement interne de l’un des participants existants.)
Avec un peu plus de complexité (et idéalement avec au moins une mise à niveau supplémentaire du protocole Bitcoin comme Pas d'entrée), les transferts pourraient même être effectués hors chaîne. Lorsqu'Alice paie Bob, tous les participants créeraient dans ce cas une transaction dépensant des fonds vers un nouveau pool de paiement, mais cette transaction ne serait partagée qu'entre eux - et non diffusée sur le réseau (à moins que quelqu'un ne tente de tricher). De cette façon, Alice, Bob et Carol pourraient continuer à mettre à jour leur solde « en interne » et même laisser Dave accéder à la piscine à un moment donné. Lorsqu'ils acceptent tous de fermer le pool, ils peuvent créer une transaction finale qui dépense à partir du pool de paiement d'origine, attribuant à chacun son dernier solde.
Semblable à une idée plus ancienne connue sous le nom de Usines de canaux, ces types de pools de paiement pourraient éventuellement même être utilisés pour héberger eux-mêmes des canaux Lightning, des coffres-forts ou d'autres protocoles de couche deux. Cela peut offrir la possibilité d'« envelopper » tout type de couche de protocole supplémentaire dans de tels pools, cachant ainsi toute leur complexité dans des transactions identiques et d'apparence régulière.