Nick Szabo

Lors d’un achat, nous voulons que le vendeur soit payé et que le client reçoive le bien promis. Vérifier les deux côtés prend du temps et nécessite parfois un intermédiaire. Dans Smart Contracts, en 1994, Nick Szabo examine les conditions qu’un protocole informatique pourrait exécuter : une procédure définie d’échange de messages et d’actions. Il cherche à réduire les possibilités de fraude et le coût du respect des accords. L’idée ne se limite pas aux blockchains : la technique doit faciliter l’exécution d’engagements précis. Le qualificatif « intelligent » ne signifie pas que le programme comprend toutes les intentions humaines. [1]

Dans son travail de 1997, Szabo associe protocoles contractuels et interfaces utilisateur. Son exemple simple est le distributeur automatique : on voit le prix, insère des pièces et reçoit le produit. L’interface présente l’échange, le mécanisme l’exécute. Dans une application complexe, l’écran peut suggérer autre chose que ce que fait réellement le code. Une exécution correcte ne suffit donc pas. Il faut rendre les conditions compréhensibles, tenir compte du temps et reconnaître les situations que l’algorithme ne décrit pas entièrement. L’automatisation devrait aider à décider, sans cacher les conséquences. [2]

Un fichier numérique se copie facilement. Szabo s’est demandé si une rareté numérique pouvait reposer sur une production manifestement coûteuse. Dans Bit Gold, un ordinateur résout un problème et produit une preuve de travail, Proof of Work. Des services d’horodatage ajoutent une information temporelle ; un registre de propriété distribué répartit les enregistrements entre plusieurs opérateurs. Le résultat précédent fournit le problème suivant. Ensemble, ces éléments permettraient de créer, transférer et vérifier des pièces numériques. Enchaîner des calculs ne constitue pourtant pas à lui seul le consensus complet de Bitcoin, les règles selon lesquelles le réseau s’accorde sur son historique. [3]

Imaginons qu’Anna envoie à Thomas un fichier contenant un résultat de calcul et en garde une copie. À qui appartient alors cette pièce de Bit Gold ? Tous deux ont les bits : le fichier seul ne prouve pas une propriété exclusive. Le projet s’appuie plutôt sur une chaîne de transferts de propriété signés numériquement et inscrits au registre. Thomas doit vérifier cet historique, le travail de calcul et l’horodatage. La preuve de travail renseigne sur la production ; le registre indique à qui la pièce appartient. Aucune de ces tâches ne disparaît parce que les données ont coûté cher à produire. [3]

Un résultat de même longueur ne demande pas nécessairement le même effort à tous. Certains disposent d’un ordinateur plus efficace ; des équipements futurs peuvent rendre bon marché un travail auparavant coûteux. Bit Gold tient donc compte de la période de production et des différences entre machines. Les pièces ne sont pas automatiquement fongibles, c’est-à-dire interchangeables comme unités équivalentes du seul fait de leur longueur. Le projet envisage des négociants regroupant des pièces de valeurs différentes en lots de valeur approximativement égale. Cela ajoute des règles et une évaluation. Une production coûteuse ne remplit pas, à elle seule, toutes les fonctions attendues d’une monnaie. [3]

Szabo mentionne RPOW de Hal Finney comme une expérience liée et effectivement réalisée. Le nom signifie Reusable Proofs of Work, des preuves de travail réutilisables. Un serveur protégé et l’attestation à distance y jouent un rôle important : cette dernière sert à vérifier quel programme tourne sur un appareil distant. Cela aide à poser la bonne question : que puis-je vérifier moi-même, et où dois-je faire confiance à des hypothèses sur le matériel ou son opérateur ? Bit Gold, RPOW et BTC ne forment pas un seul système. Leurs thèmes se rejoignent, mais leurs registres, transferts et points de confiance diffèrent. [3]

Dès 1994, Szabo évoque une voiture achetée à crédit dont l’accès aux clés dépendrait des remboursements. La règle paraît simple, jusqu’à imaginer la voiture sur l’autoroute : l’immobiliser à cet instant serait dangereux. Le projet prévoit donc des exceptions de fonctionnement sûr et la suppression de la restriction après remboursement du prêt. L’exemple résume son approche : imposer une condition ne suffit pas ; il faut aussi examiner le moment, les conséquences et la fin des restrictions. Une possibilité technique n’est pas encore un produit abouti et sûr. [1]

Le whitepaper expliquant la conception de Bitcoin est paru sous le nom Satoshi Nakamoto. Les thèmes de Szabo présentent des liens intellectuels avec lui, mais leur ressemblance ne prouve pas qu’il en soit l’auteur. Connaître l’argent numérique ou écrire sur la confiance n’établit pas l’usage de ce pseudonyme. Il est plus utile de lire les propositions concrètes : comment les unités naissent, qui consigne les transferts et ce que le destinataire doit vérifier. On peut ainsi apprécier l’apport de Szabo sans fonder l’histoire sur une supposition non démontrée. [4]