Reusable Proofs of Work

Le 15 août 2004, Hal Finney invita les participants d’une liste de discussion sur la cryptographie à essayer sa nouvelle expérience. Il s’appuyait sur Hashcash, créé par Adam Back : l’ordinateur essaie différentes entrées jusqu’à obtenir un résultat satisfaisant une condition donnée. La recherche prend du temps de calcul, alors que vérifier le résultat est rapide. C’est ce qu’on appelle Proof of Work, une preuve de travail. Contre les courriels indésirables, elle peut servir de timbre payé en calculs. Finney voulait savoir si cette preuve pouvait ensuite passer d’une personne à l’autre, au lieu de perdre son utilité après un seul usage. RPOW signifie précisément « preuves de travail réutilisables ». [1] [2] [4]

Imaginons qu’Anna possède un jeton numérique valable et l’envoie à Pierre. Si elle lui a seulement transmis un fichier, elle peut en avoir gardé une copie. Pierre présente donc le jeton au serveur RPOW pour l’échanger. Le serveur vérifie qu’il n’a pas encore été utilisé, le marque comme consommé et signe un nouveau jeton préparé par le programme de Pierre. La copie de l’ancien jeton conservée par Anna sera désormais refusée. Pierre peut transmettre le nouveau à Ève, qui répétera l’opération. Ce qui est réutilisé, c’est donc la valeur transmise, pas un même fichier indéfiniment valable. Tant que le destinataire n’a pas terminé l’échange, l’expéditeur peut encore dépenser le jeton initial avant lui. [2] [11]

L’entrée pouvait être un Hashcash nouvellement calculé ou un jeton RPOW encore inutilisé. En sortie, le serveur produisait un nouveau jeton muni d’une signature numérique RSA, c’est-à-dire d’une attestation vérifiable mathématiquement. RSA est une méthode de calcul de cette signature : une clé secrète permet de la créer, tandis que la clé publique correspondante permet de la vérifier. Il s’agit de données numériques vérifiables, pas de l’image d’une signature manuscrite. Cette signature permettait de vérifier l’origine du jeton, mais ne disait pas à elle seule s’il avait déjà été échangé. Un registre des entrées utilisées servait à cela. Les transferts suivants n’exigeaient pas de refaire chaque fois la recherche coûteuse de Hashcash : une nouvelle signature était obtenue contre l’invalidation de l’ancienne preuve. Il ne s’agissait ni de recycler de l’électricité ni de multiplier gratuitement un droit sur du travail déjà accompli. [2]

La valeur désignait ici un niveau de difficulté de calcul, pas un prix en couronnes ou en dollars. Le Hashcash de l’époque utilisait SHA-1, une fonction qui produit une courte empreinte numérique à partir de données, et cherchait une empreinte commençant par un certain nombre de bits à zéro. Un bit est un chiffre binaire. Chaque zéro supplémentaire exigé double approximativement le nombre moyen d’essais. Un jeton de niveau 21 représentait donc le même travail attendu que deux jetons de niveau 20 et pouvait être divisé en ceux-ci. Une division ou un regroupement devait conserver la somme de cette valeur de calcul. Cela ne fixait aucun taux de change ni aucun pouvoir d’achat : des ordinateurs plus rapides pouvaient produire le même type de jeton à moindre coût. [2] [10]

Double spend signifie dépenser deux fois la même valeur. RPOW avait donc besoin d’une liste des preuves déjà échangées. La base de données entière n’était pas dans la carte protégée : elle était stockée sur l’ordinateur hôte ordinaire. La carte conservait une empreinte de l’état de cette base et contrôlait des preuves cryptographiques lors des consultations. Elle utilisait le principe de Merkle Tree, un arbre d’empreintes permettant de vérifier une partie des données à partir d’une empreinte commune. Il fallait détecter aussi bien la modification d’enregistrements que le retour à une ancienne base où un jeton tout juste dépensé n’apparaissait pas encore. Sans cette protection, l’opérateur aurait pu transformer plusieurs fois la même entrée en nouveaux jetons. [3]

Le serveur effectuait les opérations sensibles dans une IBM 4758, une carte informatique autonome installée dans un ordinateur ordinaire. Elle devait protéger les clés de signature et les données sensibles, y compris contre le propriétaire de la machine. En cas d’intervention physique détectée, elle pouvait effacer les secrets. L’ordinateur hôte relayait les messages et stockait la base, mais le système ne lui accordait pas sa confiance. C’était le cœur de l’idée de Finney : exploiter le serveur ne devait pas permettre de fabriquer arbitrairement de nouveaux jetons. Cette protection supposait néanmoins un matériel et un programme corrects, ainsi que des clés bien protégées. Elle ne constituait pas une promesse absolue d’inviolabilité. [3] [9]

Publier le code source ne suffit pas : l’opérateur peut montrer un programme et en exécuter un autre. RPOW utilisait donc remote attestation, l’attestation à distance de la configuration. La carte fournissait des informations signées sur le programme qu’elle exécutait. On pouvait compiler le code publié avec les outils appropriés et comparer l’empreinte de l’image du programme obtenue à celle annoncée. Il ne s’agissait donc pas simplement de comparer le texte d’un fichier source. La confiance dans les signatures remontait, par une chaîne de certificats, jusqu’à une clé d’IBM. Cette vérification aidait à savoir quel programme tournait réellement, mais ne prouvait ni l’absence de bogues ni l’infaillibilité du fabricant et de ses procédures de certification. [3] [9]

RPOW rappelle eCash par l’échange de jetons numériques. Pourtant, dans le fonctionnement original décrit, la confidentialité ne reposait pas sur la signature aveugle. Finney comptait sur une connexion chiffrée jusqu’à la carte protégée et sur un programme vérifiable qui ne conservait pas les liens entre jetons émis et reçus. L’ordinateur hôte ne devait donc pas voir leur contenu en clair. Il pouvait néanmoins observer l’adresse réseau du client, l’heure et le volume des échanges. Présenter plusieurs fois le même jeton permettait aussi de relier certains événements. La documentation conservée décrit déjà la prise en charge de Tor, un réseau qui fait passer la connexion par plusieurs relais et masque au serveur l’adresse réseau d’origine de l’utilisateur. Elle présente en revanche la signature aveugle comme un ajout ultérieur possible. Cette fonction envisagée ne doit pas être présentée comme faisant partie du fonctionnement décrit à l’époque. [8] [10]

RPOW ne se limitait pas à une proposition sur papier : il disposait d’un serveur en fonctionnement et d’un logiciel client accessible. Mais Finney prévenait dès le départ qu’il s’agissait d’une version expérimentale précoce. Une modification nécessaire du programme serveur pouvait invalider des jetons déjà émis. Le projet les destinait à un usage personnel, expérimental et non commercial, pas à une monnaie de valeur garantie. Même une carte protégée ne pouvait obliger l’opérateur à laisser le serveur allumé. Le projet initial est terminé ; ses pages et son code conservés servent de sources historiques. Décrire les usages de SHA-1, de RSA et du matériel de l’époque ne revient donc pas à recommander cette architecture pour un service de paiement actuel. [1] [4] [5] [7]

Finney voulait concrétiser une partie de l’idée de Bit Gold de Nick Szabo : un objet numérique peut coûter du travail à créer, puis être transmis. La documentation de RPOW prévoyait aussi la coopération de plusieurs serveurs. Réduire tout le projet à un ordinateur unique pour toujours serait donc trop simple. Chaque jeton désignait toutefois le serveur auprès duquel il devait être échangé ; ajouter des machines ne supprimait pas cette dépendance. Bitcoin a suivi une autre voie. Des nœuds indépendants, c’est-à-dire des ordinateurs exécutant un logiciel de vérification, contrôlent des règles communes et un historique public. Les mineurs concourent pour ajouter de nouveaux blocs valides : des ensembles de transactions reliés à l’enregistrement précédent. RPOW aide ainsi à comprendre ce que Proof of Work ne résout pas seul : comment reconnaître un ordre valide des transferts, et à qui faire confiance pour y parvenir. [1] [6] [11]