Alliance: un accord habituellement formel, solennel et contraignant.
Ce mot est devenu l’un des mots les plus chargés de l’espace Bitcoin. Les alliances sont considérées comme la meilleure chose depuis le pain tranché. Elles sont également considérées comme la chose la plus dangereuse depuis la bombe atomique. Certains pensent qu’elles ne contribueront pas réellement à mettre à l’échelle Bitcoin, mais qu’elles sont soignées.
Tout le monde a une attitude complètement différente envers elles. Il y a la faction pro-alliance, la faction anti-alliance et la faction ambivalente. Pour aggraver les choses, le terme “alliance” est très vague et décrit des propositions matures et concrètes au protocole qui seraient classées comme des alliances.
Les degrés de différence entre les fonctionnalités des différentes propositions qui ont été proposées sont énormes. Certaines d’entre elles créent des espaces de conception entièrement nouveaux pour ce qu’il est possible de construire au-dessus de Bitcoin, tandis que d’autres n’ajoutent à proprement parler aucune nouvelle fonctionnalité ; elles optimisent simplement des choses qui sont déjà possibles, mais avec un grand degré de complexité et de frais généraux.
Lire plus
Créons une nouvelle définition spécifique à Bitcoin.
Alliance: Tout script qui garantit que certaines ou toutes les sorties créées par une transaction dépensant une entrée avec un script d’alliance devront répondre à certains critères spécifiés pour que la transaction de dépense soit valide selon le consensus.
En termes moins stricts, si un script Bitcoin se limite actuellement à qui peut dépenser une pièce en exigeant une preuve d’autorisation, comme une signature cryptographique, ou quand elle peut être dépensée, par exemple après l’expiration d’un verrou temporel ou que le dépensier puisse montrer le préimage d’un hachage, un script d’alliance restreint comment la pièce peut être dépensée, c’est-à-dire à qui, combien à quel destinataire, etc. Un script d’alliance peut même restreindre une pièce de monnaie afin qu’elle ne puisse être dépensée que vers un autre script d’alliance.
Cette dernière partie est le cœur de ce qui a fait de l’alliance un mot si controversé. Beaucoup de gens ont de grandes réservations sur l’ajout d’une nouvelle façon de “verrouiller” les bitcoins qui peut s’auto-copier et garantir que les futures pièces seront limitées de la même manière. Beaucoup de gens s’inquiètent également de ce qui pourrait être utilisé pour nuire à la fongibilité ou instaurer des régimes de censure.
Je pense qu’il est nécessaire de souligner que ces deux choses peuvent être accomplies actuellement, sans aucune capacité de script d’alliance, simplement en utilisant les portefeuilles multisignatures (multisig). Toute autorité peut refuser d’autoriser le traitement des retraits des échanges à moins que ce ne soit vers une adresse 2 sur 2 multisignature où cette autorité détient une clé. À partir de là, elle peut simplement refuser de signer des transactions envoyant vers des adresses où elle ne détient pas de clé requise, et établir ainsi une liste noire ou blanche selon son désir, et ce, entièrement hors-chaîne.
Cela dit, il est toujours important que les utilisateurs de Bitcoin aient une compréhension solide de la différence de puissance et de flexibilité entre toutes les différentes propositions d’alliance qui existent actuellement.
Il y a deux choses fondamentales que les alliances cherchent à permettre afin d’appliquer des restrictions sur comment les pièces sont dépensées: l’introspection et le transport des données.
L’introspection est la capacité d’inspecter différentes parties de la transaction qui est en cours d’évaluation lorsqu’on essaye de dépenser une pièce spécifique. Ainsi, par exemple, si vous souhaitez restreindre une pièce de monnaie afin qu’elle ne puisse être dépensée que vers une adresse spécifique, vous devez être en mesure de comparer l’adresse specifiée dans le script d’alliance de l’entrée avec l’adresse spécifiée dans la sortie de la transaction qui la dépense. Les opcodes qui permettent l’introspection nous donnent la possibilité de comparer différentes parties de la transaction de dépense avec les restrictions incluses dans le script en cours d’évaluation. Plus vous pouvez obtenir de granularité concernant les parties particulières d’une transaction que vous pouvez examiner, plus l’introspection est puissante.
Le transport des données est lié à l’introspection et, à bien des égards, une conséquence de celle-ci, vous permettant de vous assurer que certaines informations sont transférées et incluses dans chaque nouveau script d’alliance afin qu’elles puissent être utilisées dans l’évaluation suivante du script d’alliance. Ceci est accompli en utilisant l’introspection pour restreindre certaines parties de la transaction de manière si étroite qu’elles doivent inclure les données exactes souhaitées, sinon elles ne sont pas valides. Plus vous avez de capacité introspective, plus vous pouvez transporter de manière flexible les données et plus vous pouvez utiliser ces données.
Ce n’est que la première introduction d’une série d’articles à venir au cours des prochaines semaines qui examineront toutes les principales propositions d’alliance qui sont à un stade mature, ont récemment suscité de l’intérêt ou sont suffisamment importantes pour que les développeurs conviennent de leur utilité, sans qu’il y ait encore de conception concrète. Cela ne sera pas complet à 100 %, mais ce sera relativement complet. Certaines d’entre elles ne sont pas strictement des alliances en soi, mais se composent très étroitement avec elles.
Celles-ci comprennent :
- CheckTemplateVerify (CTV)
- CheckSigFromStack (CSFS)
- OP_CAT
- OP_VAULT
- OP_CHECKCONTRACTVERIFY
- OP_CHAT
- LOTUS
Résumé : Le terme “alliance” est très controversé dans l’espace Bitcoin car il désigne un accord qui restreint la manière dont les bitcoins peuvent être dépensés. On distingue plusieurs factions (pro, anti, ambivalente) envers les alliances. Ces scripts garantissent que certaines ou toutes les sorties d’une transaction répondent à des critères consensuels. Bien que les inquiétudes sur la fongibilité ou la censure existent, de telles restrictions peuvent déjà être mises en place via des portefeuilles multisignatures. Les deux éléments clés des alliances sont l’introspection (inspection des parties de la transaction en cours d’évaluation) et le transport des données (garantir que des informations sont maintenues dans les nouveaux scripts d’alliance). La série d’articles à venir examinera les principales propositions actuelles d’alliances dans l’écosystème Bitcoin.
