b-money, les versions évolutives

La crypto-anarchie de Tim May me fascine. Contrairement aux communautés
traditionnellement associées au mot "anarchie", dans une crypto-anarchie le
gouvernement n'est pas temporairement détruit mais définitivement interdit et
définitivement inutile. C'est une communauté où la menace de la violence est
impuissante parce que la violence est impossible, et la violence est impossible
parce que ses participants ne peuvent être reliés ni à leur vrai nom ni à leur
emplacement physique.

Jusqu'à présent, il n'est pas clair, même en théorie, comment une telle
communauté pourrait fonctionner. Une communauté se définit par la coopération de
ses participants, et une coopération efficace exige un moyen d'échange (la
monnaie) et un moyen de faire respecter les contrats. Traditionnellement, ces
services ont été fournis par le gouvernement ou par des institutions soutenues
par lui, et uniquement à des entités légales. Dans cet article, je décris un
protocole par lequel ces services peuvent être fournis à, et par, des entités
intraçables.

Je vais en réalité décrire deux protocoles. Le premier n'est pas praticable, car
il fait un usage intensif d'un canal de diffusion anonyme synchrone et impossible
à brouiller. Il servira toutefois à motiver le second, plus praticable. Dans les
deux cas, je suppose l'existence d'un réseau intraçable, où les émetteurs et les
destinataires ne sont identifiés que par des pseudonymes numériques (c'est-à-dire
des clés publiques) et où chaque message est signé par son émetteur et chiffré à
destination de son destinataire.

Dans le premier protocole, chaque participant tient une base de données
(distincte) indiquant combien d'argent appartient à chaque pseudonyme. Ces
comptes définissent collectivement la propriété de la monnaie, et la manière
dont ils sont mis à jour est l'objet de ce protocole.

1. La création de monnaie. N'importe qui peut créer de la monnaie en diffusant la
solution d'un problème de calcul jusque-là non résolu. Les seules conditions sont
qu'il doit être facile de déterminer quel effort de calcul a été nécessaire pour
résoudre le problème, et que la solution ne doit par ailleurs avoir aucune
valeur, ni pratique ni intellectuelle. Le nombre d'unités monétaires créées est
égal au coût de l'effort de calcul exprimé en un panier standard de marchandises.
Par exemple, si un problème demande 100 heures pour être résolu sur l'ordinateur
qui le résout le plus économiquement, et qu'il faut 3 paniers standards pour
acheter 100 heures de temps de calcul sur cet ordinateur au prix du marché,
alors, lors de la diffusion de la solution de ce problème, chacun crédite le
compte du diffuseur de 3 unités.

2. Le transfert de monnaie. Si Alice (propriétaire du pseudonyme K_A) souhaite
transférer X unités de monnaie à Bob (propriétaire du pseudonyme K_B), elle
diffuse le message "Je donne X unités de monnaie à K_B" signé par K_A. Lors de la
diffusion de ce message, chacun débite le compte de K_A de X unités et crédite le
compte de K_B de X unités, à moins que cela ne crée un solde négatif sur le
compte de K_A, auquel cas le message est ignoré.

3. La conclusion des contrats. Un contrat valide doit indiquer, pour chaque
partie qui y participe, une réparation maximale en cas de défaillance. Il devrait
aussi désigner une partie qui assurera l'arbitrage en cas de litige. Toutes les
parties à un contrat, y compris l'arbitre, doivent diffuser leur signature avant
qu'il ne prenne effet. Lors de la diffusion du contrat et de toutes les
signatures, chaque participant débite le compte de chaque partie du montant de sa
réparation maximale et crédite un compte spécial, identifié par un hachage
sécurisé du contrat, de la somme des réparations maximales. Le contrat prend
effet si les débits aboutissent pour toutes les parties sans produire de solde
négatif ; sinon le contrat est ignoré et les comptes sont rétablis. Un exemple de
contrat pourrait ressembler à ceci :

K_A s'engage à envoyer à K_B la solution du problème P avant le 0:0:0 1/1/2000.
K_B s'engage à payer à K_A 100 UM (unités monétaires) avant le 0:0:0 1/1/2000.
K_C s'engage à assurer l'arbitrage en cas de litige. K_A s'engage à payer un
maximum de 1000 UM en cas de défaillance. K_B s'engage à payer un maximum de 200
UM en cas de défaillance. K_C s'engage à payer un maximum de 500 UM en cas de
défaillance.

4. Le dénouement des contrats. Si un contrat se dénoue sans litige, chaque partie
diffuse un message signé "Le contrat de hachage SHA-1 H se dénoue sans
réparations." ou éventuellement "Le contrat de hachage SHA-1 H se dénoue avec les
réparations suivantes : ..." Lors de la diffusion de toutes les signatures,
chaque participant crédite le compte de chaque partie du montant de sa réparation
maximale, supprime le compte du contrat, puis crédite ou débite le compte de
chaque partie selon le barème de réparations s'il y en a un.

5. L'exécution forcée des contrats. Si les parties à un contrat ne parviennent
pas à s'accorder sur un dénouement approprié, même avec l'aide de l'arbitre,
chaque partie diffuse un barème de réparations/d'amendes proposé ainsi que tout
argument ou élément de preuve en sa faveur. Chaque participant détermine alors les
réparations et/ou amendes effectives et modifie ses comptes en conséquence.

Dans le second protocole, les comptes indiquant qui possède combien d'argent sont
tenus par un sous-ensemble des participants (appelés désormais serveurs) et non
par tout le monde. Ces serveurs sont reliés par un canal de diffusion de type
Usenet. Le format des messages de transaction diffusés sur ce canal reste le même
que dans le premier protocole, mais les participants concernés par chaque
transaction devraient vérifier que le message a bien été reçu et traité avec
succès par un sous-ensemble de serveurs choisi au hasard.

Comme il faut accorder un certain degré de confiance aux serveurs, un mécanisme
est nécessaire pour les maintenir honnêtes. Chaque serveur est tenu de déposer
une certaine somme d'argent sur un compte spécial, destinée à servir d'amendes
potentielles ou de récompenses en cas de preuve d'inconduite. De plus, chaque
serveur doit périodiquement publier et s'engager sur l'état courant de ses bases
de création monétaire et de propriété de la monnaie. Chaque participant devrait
vérifier que le solde de ses propres comptes est correct et que la somme des
soldes n'est pas supérieure au montant total de monnaie créée. Cela empêche les
serveurs, même en cas de collusion totale, d'accroître durablement et sans coût
la masse monétaire. Les nouveaux serveurs peuvent aussi se servir des bases
publiées pour se synchroniser avec les serveurs existants.

Le protocole proposé dans cet article permet à des entités pseudonymes et
intraçables de coopérer plus efficacement, en leur fournissant un moyen d'échange
et une méthode pour faire respecter les contrats. Le protocole peut probablement
être rendu plus efficace et plus sûr, mais j'espère qu'il constitue un pas vers
une crypto-anarchie possible en pratique autant qu'en théorie.