Bitcoin est un système de monnaie programmable et constitue la première implémentation de ce qu’on appelle les smart contracts ou contrats autonomes. À chaque transaction, des scripts sont exécutés pour vérifier que les fonds dépensés remplissent les conditions voulues par l’utilisateur précédent. De nombreuses conditions sont peuvent être mises en place (divulgation d’un secret, verrou temporel, multisignature), même si le plus souvent les fonds sont simplement dépensés grâce à la signature d’un utilisateur unique.

Bitcoin repose sur un modèle de pièces (UTXO), où chaque pièce est verrouillée par un script incomplet écrit sur la chaîne. Lors d’une transaction, les pièces de bitcoin en entrée sont déverrouillées par un script complémentaire. Puis, de nouvelles pièces sont créées à partir des anciennes grâce à de naouveaux scripts de verrouillage, ce qui perpétue le caractère programmable du système.

Lorsque j’ai découvert comment les transactions fonctionnaient et ce qu’elles permettaient, j’ai été fasciné par l’élégance de cette solution. Néanmoins, en approfondissant ma recherche, j’ai été perturbé par l’existence d’une chose qui différait des autres, une exception : le schéma Pay to Script Hash, qu’on abrège couramment en P2SH.

 

Les différents schémas : P2PK, P2PKH, P2MS et P2SH

Des scripts sont impliqués dans chaque transaction du réseau Bitcoin. Le langage de script est constitué de plus d’une centaine de codes opération, de sorte qu’un large éventail de possibilités s’offre à nous vis-à-vis des conditions qu’on souhaite imposer.

Cependant, dans le but d’améliorer la communication entre les différentes applications et de limiter le risque de perte, certains standards de scripts, ou schémas, ont émergé.

 

P2PK : Pay to Public Key

Le premier schéma s’appelle Pay to Public Key (P2PK), qu’on peut traduire littéralement en français par « payer à la clé publique ». Il s’agit d’envoyer des fonds vers la clé publique (public key) d’un utilisateur, que lui seul pourrait dépenser en signant avec sa clé privée. Le script de verrouillage (parfois appelé scriptPubKey) permettant ce type d’envoi est :

<clé publique> CHECKSIG

Au moment de la dépense, l’utilisateur doit utiliser un script de déverrouillage (parfois appelé scriptSig) contenant simplement sa signature :

<signature>

Pour l’expliquer en français, l’exécution successive de ces deux scripts permet de vérifier que la signature fournie par l’utilisateur correspond à sa clé publique, auquel cas elle est valide.

Si le schéma P2PK était utilisé dans les premiers jours de Bitcoin, notamment pour recevoir les gains de minage, il est aujourd’hui tombé en désuétude au profit d’un schéma rival : P2PKH.

 

P2PKH : Pay to Public Key Hash

Pay to Public Key Hash (P2PKH), littéralement « payer à l’empreinte de la clé publique », est le deuxième type de schéma apparu dans Bitcoin dès le début, grâce à la conception de Satoshi Nakamoto. Ce schéma permet non pas de réaliser un paiement vers une clé publique, mais vers l’empreinte d’une clé publique, et de faire en sorte que le système de script de Bitcoin vérifie quand même que la signature correspond à la clé publique lors de la dépense des fonds. L’empreinte de la clé publique est alors considérée comme la donnée essentielle de l’adresse, qui dans ce cas commence toujours par un 1, comme par exemple 1DzxhUphLFq8FZPGbFgLF8Ssz3hMX9EuMp.

Le script de verrouillage ici est :

DUP HASH160 <empreinte de la clé publique> EQUALVERIFY CHECKSIG

Et le script de déverrouillage est :

<signature> <clé publique>

Pour le dire en français, l’exécution des deux scripts permet de :

• Vérifier que le passage de la clé publique fournie par la fonction de hachage HASH160 (l’empreinte) est égale à l’empreinte qui est spécifiée dans le script ;
• Vérifier la signature fournie correspond à la clé publique fournie.

L’avantage de ce schéma est qu’il permet d’avoir des adresses plus courtes (l’information à encoder n’est que de 20 octets au lieu de 65 octets pour une clé publique), chose pour laquelle Satoshi Nakamoto l’a implémenté. De plus, en ne révélant la clé publique qu’au moment de la dépense, ce schéma accroît aussi la sécurité contre la menace (très hypothétique) de l’ordinateur quantique.

 

P2MS : Pay To MultiSig

Le schéma Pay To MultiSig (P2SH), littéralement « payer à la multisignature », s’est popularisé début 2012. Il s’agit essentiellement d’un schéma qui permet d’exiger la signature de M personnes faisant partie d’un groupe de N participants, via le script de verrouillage :

M <clé publique 1> ... <clé publique N> N CHECKMULTISIG

Le script de déverrouillage correspondant est :

<leurre (0)> <signature 1> ... <signature M>

Pour plus d’informations sur la multisignature, je vous invite à lire mon article sur les adresses multisignatures.

C’est ce schéma, particulièrement exigeant au niveau de la mise en place, qui a motivé la création du schéma P2SH.

 

P2SH

Pay to Script Hash (P2SH), littéralement « payer à l’empreinte du script ». Ce schéma reprend l’idée derrière P2PKH, à la seule différence que la donnée hachée ici n’est pas une clé publique, mais le script lui-même ! Le script en question est alors appelé script de règlement (redeem script) et son empreinte est la donnée constituante de l’adresse, cette dernière commençant toujours par un 3 à l’instar de 3DyDCGSC59yYY46dnRH7Vw1iKbV8zeW36q.

Ce type de schéma a pour avantage de permettre à un utilisateur d’y inclure n’importe quel script et de pouvoir recevoir des fonds de la quasi-totalité des portefeuilles existants. Le fardeau de la construction et du déverrouillage du script revient donc au détenteur de l’adresse, non à celui qui envoie les fonds, ce qui simplifie grandement la communication.

Le script de verrouillage pour le schéma P2SH est :

HASH160 <empreinte du script de règlement> EQUAL

Et le script de déverrouillage est un script de la forme :

[éléments de déverrouillage] <script de règlement>

En français, cela veut dire que le système de script originel de Bitcoin va vérifier que le hachage du script de règlement est égal à l’empreinte inscrite dans le script. Et c’est tout.

Comment ça, « c’est tout » ? Le script de règlement n’est pas exécuté ? N’importe qui connaissant le script pourrait dépenser les bitcoins ?

Comme on va le voir, ce n’est pas le cas et le script de règlement est bien exécuté, bien que ce ne soit pas indiqué explicitement.

 

Règles et exceptions : OP_EVAL et P2SH

Dans la vie, il y a souvent une manière élégante de faire les choses, qui demande parfois plus d’efforts initiaux mais qui préserve l’ordre et la simplicité, et une manière grossière, plus facile à implémenter mais qui complique les choses et crée le désordre.

Ainsi, dans le système législatif d’un pays, il est plus facile de créer et de faire voter de nouvelles lois execeptionnelles que de réformer en profondeur le système. Cette tendance à l’inflation législative fait qu’on se retrouve avec des pays comme la France, qui cumule 73 codes juridiques en vigueur et qui vit de 214 taxes et impôts ainsi que d’une myriade de cotisations sociales.

En informatique comme en droit, l’ajout de nouvelles exceptions crée de la dette technique, rendant le système plus complexe à appréhender, plus difficile à maintenir et plus susceptible de ne pas fonctionner comme attendu. P2SH fait partie de ces exceptions.

 

Le code opération mort-né : OP_EVAL

L’idée d’implémenter un schéma de script qui utilise l’empreinte d’un autre script comme identifiant est née en 2011, afin de reproduire ce qui est réalisé dans la schéma P2PKH. Toutefois, cette idée n’a pas été développée initialement comme P2SH, mais à travers OP_EVAL, un nouveau code opération permettant l’exécution récursive d’un script à l’intérieur d’un autre script.

L’ajout de ce code opération, proposé le 18 octobre 2011 par Gavin Andresen, devait être implémenté comme un soft fork, via le remplacement de l’instruction nulle OP_NOP1.

Un schéma standard aurait également été ajouté. Le script de verrouillage imaginé pour ce schéma était :

DUP HASH160 <empreinte du script de règlement> EQUALVERIFY EVAL

Le script de déverrouillage correspondant était :

[éléments de déverrouillage] <script de règlement>

Pour le dire en français, l’exécution des deux scripts côte à côte aurait permis de :

• Vérifier que le hachage du script de règlement soit égal à l’empreinte spécifiée dans le script de verrouillage ;
• Vérifier que l’exécution du script de règlement combiné aux éléments de déverrouillage soit bien valide.

Néanmoins cette solution n’a pas été acceptée, celle-ci ayant été jugée trop dangereuse au niveau du pouvoir de récursion. À la place c’est un autre modèle, plus restrictif, qui a prévalu : le schéma P2SH.

 

Comment fonctionne P2SH ?

P2SH a été proposé le 3 janvier 2012 comme alternative à OP_EVAL et à d’autres propositions. Il a été intégré au protocole Bitcoin le 1^er avril sous la forme d’un soft fork activé par les mineurs.

L’exécution de ce type de script fonctionne exactement comme le schéma lié à OP_EVAL, à l’exception qu’une partie du script n’est pas explicitement indiquée. D’une part, la vérification de la correspondance entre l’empreinte indiquée et le script de règlement est bien réalisée par le script de verrouillage. En effet, celui-ci devient (comme on l’a vu) :

DUP HASH160 <empreinte du script de règlement> EQUALVERIFY EVAL

D’autre part, l’évaluation du script de règlement est effectuée implicitement grâce à une exception ajoutée au code source. Dès que les nœuds du réseau reconnaissent le schéma, ils l’interprètent différemment. Ainsi dans Bitcoin Core, on peut observer la condition suivante au sein de la fonction VerifyScript de l’interpréteur :

// Additional validation for spend-to-script-hash transactions:
if ((flags & SCRIPT_VERIFY_P2SH) && scriptPubKey.IsPayToScriptHash())
{
    ...
}

Cette exception permet l’exécution du script de règlement après l’exécution des deux scripts (déverrouillage et verrouillage). D’où le fait qu’on indique les éléments de déverrouillage avant de pousser le script de règlement dans le script de déverrouillage :

[éléments de déverrouillage] <script de règlement>

Si cette solution est pratique, elle crée une complexité et n’est pas très élégante. Comme l’a dit Gavin Andresen dans l’explication du BIP-16 :

Reconnaître une forme « spéciale » de scriptPubKey et réaliser une validation supplémentaire quand elle est détectée, c’est laid. Cependant, l’avis général est que les alternatives sont soit encore plus laides, soit plus complexes à implémenter, et/ou étendent le pouvoir du langage d’expression de manière dangereuse.

L’implémentation initiale de P2SH a donc compliqué les choses. Mais cela ne s’est pas arrêté pas là, car l’activation de SegWit en 2017 a ajouté de la complexité au modèle.

 

SegWit, P2SH-P2WPKH et P2SH-P2WSH

En août 2017, la mise à niveau SegWit a été intégrée à Bitcoin (BTC) sous la forme d’un soft fork. Celle-ci avait pour objectif de corriger la malléabilité des transactions, d’augmenter la capacité transactionnelle, d’améliorer la vérification des signatures et de faciliter les modifications futures du protocole.

Pour ce faire, SegWit implémentait un nouveau modèle de transaction, où les signatures sont situées dans une partie séparée de la transaction appelée le témoin (d’où le nom de Segregated Witness). Afin d’implémenter ce changement comme un soft fork, il a été nécessaire d’introduire un moyen d’accéder au nouveau type de transaction sans briser la compatibilité avec les anciennes adresses.

C’est ainsi que 4 nouveaux types d’adresse ont vu le jour : deux nouveaux types « natifs », P2WPKH (Pay to Witness Public Key Hash) et P2WSH (Pay to Witness Script Hash), incompatibles avec portefeuilles ne supportant pas SegWit ; et deux types « imbriqués » associés, P2SH-P2WPKH et P2SH-P2WSH, qui permettent la transition grâce à l’emploi de P2SH.

Pour ces deux derniers types d’adresse, le schéma utilisé est P2SH avec un script de règlement de la forme :

<version SegWit> <empreinte>

Dans la version 0 de SegWit (la seule qui existe pour le moment), l’empreinte est affectée à une clé publique ou à un script selon sa longueur : si elle est de 20 octets, elle est interprétée comme une empreinte de clé publique ; si elle est de 32 octets, elle est interprétée comme une empreinte de script. Cette empreinte est aussi appelée « programme ».

Ce script est anyone-can-spend puisque le script de règlement suffit à déverrouiller la pièce :

<script de règlement>

Comme pour P2SH, la connaissance du script de règlement ne suffit pourtant pas à dépenser les fonds, car une nouvelle exception est ajoutée au code de façon à ce que les éléments de déverrouillage soient transférées dans le témoin. Dans Bitcoin Core, cette exception se traduit par :

// P2SH witness program
if (flags & SCRIPT_VERIFY_WITNESS) {
    ...
}

SegWit a ainsi apporté un nouveau lot de complexité, et notamment un deuxième niveau de récursion. Dans le cas du schéma P2SH-P2WSH, on a en effet une série de 3 scripts imbriqués. Le premier script est le script de déverrouillage que l’on a présenté au début de cet article :

HASH160 <empreinte du script de règlement> EQUAL

Le deuxième script est le script de règlement spécifique à P2SH :

<version SegWit> <empreinte du script SegWit>

Le troisième est le script SegWit, indiqué dans le témoin avec les éléments de déverrouillage au moment de la dépense des fonds. Par exemple, il peut s’agir d’un script de multisignature comme vu précédemment :

2 <clé publique 1> <clé publique 2> 2 CHECKMULTISIG

qu’on complète avec les éléments :

0 <signature 1> <signature 2>

 

Conclusion

Pay to Script Hash (P2SH) est donc une manière imparfaite mais très pratique de permettre aux utilisateurs de payer à l’empreinte d’un script, c’est-à-dire à une adresse simple qui correspond à un script. La récursion qui intervient dans l’exécution du script aurait pu être implémentée de manière plus élégante grâce au code opération OP_EVAL, mais ce dernier a été jugé trop dangereux par la communauté pour voir le jour.

En ajoutant une nouvelle exception au protocole pour être exécuté, le schéma P2SH représente un vecteur de complexité. De plus, cette complexité est démultipliée par l’incorporation de SegWit, qui ajoute de nouvelles exceptions rigides à P2SH et qui finit de détourner complètement le fonctionnement originel du système de script de Bitcoin.

Néanmoins, ce qui est fait est fait, et aujourd’hui ces changements commencent à être connus dans l’écosystème, et on peut donc espérer que cette complexité n’impacte pas trop les nouveaux développeurs. En particulier, le schéma P2SH est répandu dans tout l’écosystème, par les protocoles associés à Bitcoin tel que Bitcoin Cash, Litecoin ou Dash. Seuls les développeurs de Bitcoin SV ont se sont opposés à cette particularité de manière catégorique et ont choisi de désactiver P2SH en février 2020.

Ce qu’il faut retenir de tout ceci, c’est que Bitcoin, au-delà de son aspect technique, est un système économique et social. Il évolue selon les exigences de ses utilisateurs, si bien qu’il est impossible de le comprendre sans appréhender les dynamiques sous-jacentes qui ont été à l’œuvre dans le passé.

 

---

Sources

Gavin Andresen, BIP-11 (M-of-N Standard Transactions), 18 octobre 2011.
Gavin Andresen, BIP-12 (OP_EVAL), 18 octobre 2011.
Gavin Andresen, BIP-16 (Pay to Script Hash), 3 janvier 2012.
Mike Hearn, On consensus and forks, 12 août 2015.
Eric Lombrozo, Johnson Lau et Pieter Wuille, BIP-141 (Segregated Witness), 21 décembre 2015.

La vision que se fait Eric Voskuil des cryptomonnaies est probablement l’une des visions les plus claires et les plus pertinentes de tout l’écosystème. Ayant identifié la proposition de valeur de Bitcoin, il cherche par ses courts textes à nous démontrer, par le biais de raisonnements logiques, quels sont les mécanismes qui permettent de satisfaire cette proposition de valeur.

Sur la preuve d’enjeu, Eric Voskuil a un avis tranché : contrairement à la preuve de travail, elle ne résiste pas convenablement à la censure. Dans un article intitulé « Proof of Stake Fallacy », ou « Sophisme de la preuve d’enjeu » en français, il explique (je traduis) :

La sécurité des confirmations requiert une autorité pour sélectionner les transactions. Bitcoin confie périodiquement cette autorité au mineur qui produit la plus grande preuve de travail. Toutes les formes de travail se ramènent nécessairement à la consommation d’énergie. Il est essentiel qu’une telle preuve soit indépendante de l’historique de la chaîne. Celle-ci peut être appelée la preuve « externe ».

L’unique autre source d’autorité sélective dépend par conséquent de l’historique de la chaîne, source qui peut être désignée comme « interne ». Il existe une théorie selon laquelle une telle preuve d’enjeu (PDE) constitue une alternative comparable à la preuve de travail (PDT) en matière de sécurité des confirmations. Il est vrai que la PDE et la PDT délèguent toutes les deux le contrôle sur la sélection des transactions à une personne en charge de la plus grande réserve d’un certain capital.

La différence se situe dans la déployabilité du capital. La PDT exclut le capital qui ne peut pas être converti en travail, alors que la PDE exclut tout capital qui ne peut pas acquérir des unités de la monnaie. Cette différence a une conséquence importante sur la sécurité.

Dans le Principe des autres moyens, il est montré que la résistance à la censure dépend des personnes qui paient les mineurs pour vaincre le censeur. Vaincre la censure n’est pas possible dans un système de PDE, puisque le censeur a acquis la part majoritaire et ne peut pas être évincé. De ce fait, les systèmes de PDE ne sont pas résistants à la censure et la théorie est par conséquent invalide.

Voyons en détail ce qu’Eric Voskuil veut dire dans cet extrait.

 

Qu’est-ce que la censure ?

La mot censure nous vient du verbe latin cēnseō signifiant « déclarer, juger », en particulier dans le cadre du cens de la Rome antique, le recensement quinquennal des citoyens romain et de leurs biens, ayant pour but de faciliter le recrutement militaire, la délimitation des droits, l’organisation des scrutins et le calcul de l’impôt. Le censeur était alors le magitrat en charge de gérer et d’évaluer toutes les informations relatives à ce dénombrement.

Cet aspect de jugement se retrouve par ailleurs dans le sens critique qu’on porte parfois au mot censure qui s’apparente alors à un blâme ou à un reproche, notamment en matière littéraire.

Au Moyen Âge, la censure se caractérisait par la relecture et la correction des ouvrages rédigés par les moines copistes pour s’assurer que tout était conforme à la foi et à l’orthodoxie religieuse. Néanmoins, l’apparition de l’imprimerie au XV^ème siècle a bouleversé les choses : le nombre de livres a explosé, et ce faisant, a retiré le contrôle que l’Église avait sur la publication des écrits, contrôle qui a été transféré à l’État.

La censure a par conséquent acquis son sens politique actuel, en désignant l’examen que le pouvoir gouvernemental fait préalablement des livres, journaux, pièces de théâtre, etc., pour en permettre ou prohiber la publication ou la représentation. Par la suite, le terme a fini par nommer toute atteinte à la liberté d’expression, quel que soit le support, que cette atteinte se fasse avant ou après la diffusion.

Avec le développement des médias de masse et surtout des grandes plateformes de publication sur Internet, le terme décrit désormais aussi tout choix d’édition qu’une entité privée prend vis-à-vis de ses clients ou de ses utilisateurs. Il ne s’agit pas d’une atteinte à la liberté d’expression au sens strict. Néanmoins, il arrive que la volonté de censure étatique se manifeste par la censure privée (on parle de censure indirecte) : un État peut sanctionner Youtube s’il constate que la plateforme héberge des vidéos ayant un contenu inapproprié, et par conséquent la plateforme va supprimer préventivement toutes les vidéos susceptibles de causer problème. C’est toute la perversité du pouvoir dans le monde actuel, où l’État n’intervient directement que très rarement et où les entreprises privées servent de mandataires (l’impôt indirect en est un exemple).

Cela nous amène au domaine financier où la censure privée est également présente. Les banques, en ayant la capacité d’intervenir, peuvent choisir d’empêcher le virement d’un client ou de suspendre son compte, si elles constatent un comportement « douteux » qui pourrait leur attirer des ennuis légaux. De cette manière, les banques françaises interdisent régulièrement à leurs clients d’envoyer des fonds vers les plateformes d’échange de cryptomonnaies. Puisque le domaine financier est soumis à des réglementations drastiques étouffant la concurrence, et que l’usage de l’argent liquide est restreint (ce qui impose la possession d’un compte bancaire pour bien vivre), cette censure financière est l’un problèmes majeurs de notre époque.

C’est l’un des problèmes que Bitcoin cherche à résoudre. En effet, l’une des caractéristiques primordiales de Bitcoin est sa résistance à la censure.

 

Preuve de travail et résistance à la censure

Par censure, Eric Voskuil entend une « confirmation subjective » des transactions, c’est-à-dire le fait pour un mineur ou un ensemble de mineurs de choisir les transactions sur une base qui n’est pas économiquement rationnelle. Si la censure de certaines transactions n’est pas appliquée par la majorité de la puissance de calcul, cela ne pose pas de problème parce que les mineurs concurrents finiront par valider cette transaction. Cependant, si un ensemble de mineurs détient une majorité de la puissance de calcul, il peut imposer la censure en invalidant tous les blocs qui incluent les transactions indésirables.

C’est pourquoi Bitcoin n’est pas impossible à censurer.

Toutefois ce dernier est difficile à censurer, ou pour mieux dire, résistant à la censure.

Cette résistance à la censure est à comprendre sur la durée, à long terme. Tel que Eric Voskuil l’explique dans son essai intitulé « Censorship Resistance Property » ou « Propriété de résistance à la censure », son modèle concerne en effet un Bitcoin arrivé à maturité, utilisé globalement, où la rémunération des mineurs provient essentiellement des frais de transactions et non plus de la création monétaire.

C’est ce mécanisme des frais de transaction couplé à la preuve de travail qui crée la possibilité de combattre la censure dans Bitcoin. Ainsi que l’écrit Voskuil :

Dans le cas d’une censure active, les frais peuvent augmenter sur les transactions ne réussissent pas à être confirmées. Ce supplément de frais crée un profit potentiel plus grand pour les mineurs qui confirment les transactions censurées. À un niveau suffisant, cette opportunité produit une concurrence supplémentaire et par conséquent un taux de hachage total croissant.

Si la puissance de hachage qui ne censure pas outrepasse celle du censeur, l’imposition de la censure échoue.

Puisque la preuve de travail est externe à la chaîne, il est toujours possible d’ajouter de la puissance de minage afin de vaincre le censeur : les mineurs les moins regardants et les plus avides de profit se procureront du matériel afin de miner les transactions censurées et récupérer les frais associés.

Ce mécanisme s’applique jusqu’à la résistance à la censure de l’État, chose qui est primordiale. En effet, un Bitcoin arrivé à maturité serait une menace directe contre la pérennité l’État en lui retirant le contrôle sur la masse monétaire et le transfert de capitaux. C’est pourquoi l’État aurait tout intérêt à miner lui-même, même dans le cas où il aurait rélégué Bitcoin au marché noir. De plus, comme le dit Eric Voskuil, « seul l’État peut perpétuellement subventionner ses opérations, puisqu’il peut lever l’impôt et profiter de la préservation de son propre régime monétaire. »

Même dans ce cas, il suffirait que le niveau des frais des transactions censurées atteigne le niveau des revenus de l’État, ce qui semble énorme, mais pas infaisable dans le cadre d’une réelle guerre économique entre l’autorité et la liberté.

La preuve de travail est donc résistante à la censure, dans le sens où il est toujours possible d’outrepasser le censeur.

 

Pourquoi la preuve d’enjeu n’est pas aussi résistante à la censure

Voyons maintenant pourquoi la preuve d’enjeu ne peut pas arriver à un tel résultat.

Le preuve d’enjeu se base sur la possessions de jetons ou sur une autre donnée interne de la chaîne qui en dérive. Pour ajouter un bloc, un validateur doit donc prouver qu’il est investi dans le système. Cela permet de dissuader un comportement du validateur qui irait à l’encontre de l’utilité de la cryptomonnaie, car une mauvaise action (comme une attaque de double dépense par réorganisation de la chaîne par exemple) pourrait provoquer une chute du prix et donc une baisse de valeur de son capital.

Cependant, toute censure n’aurait pas un impact négatif sur le prix de la cryptomonnaie en question. En outre, comme on l’a dit, l’État aurait des intérêts bien plus grands en jeu et supporterait les pertes liées à une baisse du prix.

On peut arguer qu’il est très difficile pour un acteur ou un groupe d’acteurs de réunir plus de la moitié des unités de la cryptomonnaie en question.

Néanmoins, les validateurs sont des êtres humains influençables, et, bien qu’il puissent rester anonymes, il est raisonnable de penser que les plus gros acteurs seront désireux de respecter la loi. Par exemple, les grandes plateformes d’échange (Kraken, Coinbase), qui concentrent le plus grand nombre de jetons et qui redistribuent les intérêts à leurs clients, sont clairement identifiées, et se plient à toutes les réglementations (identification du client, lutte contre le blanchiment d’argent) pour continuer à exercer.

La situation est encore pire dans la preuve d’enjeu déléguée qui répartit la charge de la validation entre un petit nombre d’acteurs qui sont pas anonymes la plupart du temps. Un exemple de censure est le gel des fonds de la Fondation Tron sur la plateforme Steem en février 2020 : les validateurs (« témoins ») ont en effet appliqué un soft fork (22.2) rendant ces fonds invalides. Cette censure n’était pas imposée par une majorité des jetons et il a été possible pour la Fondation Tron et quelques plateformes d’échange de rétablir la situation le 2 mars 2020. Néanmoins, cette affaire nous éclaire très bien sur les mécanismes en jeu et nous prouve que la censure est un problème réel sur ces chaînes.

Il est donc assez facile pour l’État de faire en sorte qu’une censure soit imposée, notamment si les transactions censurées sont considérées comme hautement immorales par une majorité de la population, telles que les transactions provenant d’un cartel de la drogue très violent, d’une organisation terroriste, d’un réseau pédophile, etc.

Ainsi, la censure est réalisable sur les chaînes utilisant la preuve d’enjeu, tout comme elle l’est sur celles utilisant la preuve de travail. Cependant, si dans le cas de la preuve de travail, il est toujours possible de combattre la censure en réunissant une puissance de calcul supérieure au censeur, cette solution n’est en revanche pas toujours une option dans le cas de la preuve d’enjeu, qui est par nature interne. En effet, une fois que le censeur (qui peut être un ensemble d’acteurs) a réuni plus de 50 % des jetons, il est intouchable.

Dans cette situation, il reste toujours la solution du hard fork pour expulser sélectivement le censeur. Mais il s’agit généralement d’une mesure ayant des effets plus délétères que le statu quo : répartition de la valeur entre deux chaînes, nouvelle distribution n’étant pas forcément meilleure que l’ancienne, perte de confiance dans le protocole pour les validateurs, etc. Le hard fork n’est donc pas désirable, notamment dans le cas d’une cryptomonnaie arrivée à maturité.

C’est en cela que la preuve d’enjeu résiste moins bien à la censure que la preuve de travail.

---

Eric Voskuil est le développeur en chef de libbitcoin, un ensemble de bibliothèques permettant de construire des applications interagissant avec la chaîne de blocs de Bitcoin. Il participe aussi au développement du protocole et en possède une connaissance pointue. À côté de cela, il rédige de courts textes sur la crypto-économie, c’est-à-dire sur ce qui fait que Bitcoin et ses dérivés parviennent à exister malgré leur relation conflictuelle avec l’autorité.