Actu-crypto

🔒
❌ About FreshRSS
There are new articles available, click to refresh the page.
☐ ☆ ✇ Comprendre la cryptomonnaie

Pay to Script Hash (P2SH) pleinement expliqué

By: Ludovic Lars —

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.

Transaction : UTXO et scripts

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 1er 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.

☐ ☆ ✇ Comprendre la cryptomonnaie

La preuve de travail rĂ©siste mieux Ă  la censure que la preuve d’enjeu

By: Ludovic Lars —

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Ă©.

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 cette autoritĂ© au mineur qui produit la plus grande preuve de travail. Toutes les formes de travail se ramĂšnent Ă  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 Other Means Principle, 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Ă©. En tant que tels, 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 », 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.

❌