Joseph Poon

Acheter un café ne demande pas d’en informer le monde entier. Sur la couche de base de Bitcoin, un réseau d’ordinateurs vérifie pourtant le paiement et l’inscrit dans un historique commun. Joseph Poon et Thaddeus Dryja ont cherché à alléger ce travail grâce aux canaux de paiement. La proposition liée ici porte la date du 14 janvier 2016 et la mention DRAFT 0.5.9.2. C’est un point de départ important de Lightning ; ses composants actuels doivent aussi beaucoup à d’autres personnes. [1]

Imaginons qu’Anna et Pavel déposent des bitcoins dans un canal. Ils signent ensuite de nouvelles répartitions de cette somme : après un paiement, Anna possède une part plus petite et Pavel une part plus grande. Chaque changement n’a pas à rejoindre l’historique public. Une transaction Bitcoin permet de faire appliquer la répartition finale. En cas de litige, réagir à un ancien état et respecter les délais comptent aussi. La sécurité implique donc une surveillance, pas seulement la conservation du dernier solde. [1]

Le destinataire n’a pas besoin d’un canal direct avec l’expéditeur. Le paiement peut passer par d’autres participants grâce à un HTLC, une condition associant paiement, valeur secrète et délai. BOLT 2 nomme la valeur révélée payment_preimage et son empreinte cryptographique connue à l’avance payment_hash. Le logiciel vérifie leur correspondance. Trouver un chemin ne garantit pas le succès : les conditions doivent être remplies, tandis qu’une erreur ou une expiration exige le traitement prévu pour un échec. [3]

Les portefeuilles et les nœuds de développeurs différents ont besoin de règles communes plus précises qu’une proposition générale. C’est le rôle des BOLTs, les spécifications de Lightning. Elles décrivent notamment les messages, les itinéraires de paiement et la structure des transactions, et continuent d’évoluer. Cosigner le livre blanc ne fait pas de Poon l’auteur de chaque modification ultérieure. Comprendre un logiciel actuel demande aussi de consulter sa documentation et la spécification concernée. [2]

Avec Vitalik Buterin, Poon a également rédigé le projet de travail Plasma du 11 août 2017. Il ne s’agit pas d’un canal de paiement Bitcoin. Des chaînes secondaires traitent les transactions et s’appuient sur une chaîne parente, par exemple Ethereum, pour faire respecter leurs règles. Une hiérarchie de blockchains remplace donc le réseau d’accords entre paires de participants. Déplacer le travail hors de la couche de base est un objectif commun, mais les mécanismes et les risques diffèrent. [4]

Plasma publie normalement sur la chaîne racine des engagements cryptographiques compacts, comparables à des empreintes vérifiables de registres. Les détails restent ailleurs. Une empreinte aide à vérifier des données fournies, mais ne permet pas de lire les données manquantes. Or démontrer une fraude nécessite les registres pertinents. Leur rétention constitue donc un problème distinct : un hash publié ne garantit pas que l’utilisateur recevra tout ce qui est nécessaire pour défendre ses fonds. [4]

Avec Plasma, il faut savoir comment retirer ses fonds si une chaîne secondaire échoue. La proposition prévoit des retraits différés et la possibilité de contester une demande incorrecte. Elle suppose une chaîne racine disponible et fonctionnant correctement, où la procédure peut être exécutée. Ce n’est pas une promesse de retrait immédiat lors de n’importe quelle panne. Les règles de sortie, les données disponibles et les délais font partie de la sécurité. [4]

Le document ultérieur Plasma Contracts décrit explicitement une recherche communautaire. Il cite notamment Dan Robinson et Kelvin Fichter aux côtés de Joseph Poon, sans soutenir un projet particulier. Le nom Plasma sur le site d’un service ne prouve donc pas, à lui seul, une recommandation de l’auteur. L’apport de Poon se lit dans les documents et leurs questions : que déplacer hors de la blockchain, et comment laisser aux utilisateurs les moyens d’obtenir un règlement correct ? [5]