Solana est une blockchain rapide, sécurisée et résistante à la censure permettant de déployer des applications décentralisées. Sécurisée par la preuve d’enjeu, son innovation majeure est son système d’horodatage, appelé proof of history. Cette nouvelle architecture permet à Solana de traiter un très grand nombre de transactions par seconde. Nous présenterons son fonctionnement en détail dans cet article.

Cet article vous est proposé dans le cadre de la campagne de subventions de Solana.

La genèse de Solana

Le projet Solana a vu le jour en 2017 sous l’égide d’Anatoly Yakovenko. Il est le fondateur de Solana mais aussi le créateur de la proof of history. Dans le livre blanc original, il y présente une méthode inédite d’horodatage d’un registre distribué.

L’un de ses anciens collègues de Qualcomm, Greg Fitzgerald, le rejoint alors pour programmer un réseau blockchain basé sur la proof of history. Après avoir déployé le premier réseau de test, ils publient la version officielle du livre blanc en 2018. Avec 4 autres associés, ils fondent la société Solana Labs.

Dans la foulée, Solana Labs se lance dans une série A et lève plus de 20 millions de dollars lors différentes ventes de son token, le SOL. Ces tours de financement privés s’étalent sur plus d’un an, d’avril 2018 à juillet 2019. L’équipe développe activement son projet, et le testnet public voit le jour en 2020. Grâce à un programme d’incitation pour les participants, c’est un succès. En mars 2021, Solana organise une vente de tokens publique sur CoinList et lève 1,76 million de dollars supplémentaires. Le Mainnet voit le jour en version bêta dans un même temps.

Sami a réalisé une interview d’Anatoly Yakovenko, créateur de Solana, disponible sur notre chaîne YouTube.

Les promesses sont immenses : avec cette nouvelle méthode d’horodatage couplée à un mécanisme de consensus en proof of stake, Solana se targue de pouvoir proposer un débit théorique de 50 000 transactions par seconde, pour des frais infimes.

Trois ans plus tard, le pari est tenu et la plateforme d’applications décentralisées choisie par FTX pour déployer son DEX (Serum) fonctionne à plein régime.

La proof of history ou preuve d’histoire

S’accorder sur le temps est crucial dans le domaine des réseaux distribués. C’est aussi l’un des challenges les plus difficiles à relever. Dans le livre blanc de Bitcoin, Satoshi Nakamoto est bien conscient que son mécanisme de consensus est révolutionnaire, car il permet à un réseau distribué d’horodater son registre de façon infaillible. C’est ainsi qu’il ne parle pas de blockchain, mais de timestamp server – serveur d’horodatage.

Les réseaux distribués utilisent souvent des solutions centralisées pour s’accorder sur le temps. Dans le domaine des blockchains, où le réseau ne peut faire appel à une tierce partie pour mesurer le temps, la solution au problème s’avère très complexe. Synchroniser le réseau prend beaucoup de temps, car les informations doivent se propager à travers tous les nœuds avant qu’un consensus ne soit établi.

Prouver l’écoulement du temps grâce à la cryptographie

L’idée de la proof of history est d’encoder l’horodatage directement au sein des messages transitant sur le réseau. Le consensus au sujet des transactions n’intervient qu’une fois cette première étape validée, ce qui permet d’augmenter drastiquement les performances et le débit de la blockchain.

La proof of history est donc un mécanisme qui permet de prouver l’écoulement du temps entre deux événements grâce à la cryptographie. Ce mécanisme est basé sur une séquence de calculs particulière, plus précisément, il s’agit d’une fonction de hachage séquentielle.

L’avantage de ce nouveau mécanisme est que les nœuds du réseau n’ont pas à attendre d’être coordonnés au sujet de l’horodatage. Chacun peut vérifier rapidement que l’horodatage d’un message (comme une requête de transaction) est correct grâce à la proof of history.

La fonction utilisée pour créer le registre de la proof of history est aussi appelée high-frequency Verifiable Delay Function (VDF). Elle s’exécute en plusieurs étapes (d’où la notion de délai) et produit un résultat unique, qui est publiquement vérifiable. Elle est dite “haute fréquence” car elle est exécutée plusieurs milliers de fois par seconde. Il est également à noter qu’il est impossible de prédire le résultat de la fonction sans l’exécuter.

Les VDF sont déjà utilisées dans les systèmes distribués, par exemple pour élire aléatoirement un producteur de bloc.

La proof of history de Solana utilise ce type de fonctions pour décompter le temps et mettre en ordre les événements (comme les messages) au sein des blocs de la chaîne.

Fonctionnement de la séquence

La fonction est exécutée en boucle. Elle génère un hash en sortie, via l’algorithme bien connu SHA256. Lors du prochain tour, elle utilise à nouveau ce hash en entrée. De façon périodique, le résultat de sortie est assorti d’un nombre, le décompte, puis enregistré.

Le hash est dit pre-image resistant, c’est-à-dire qu’à partir de cette valeur de sortie, il est impossible de déduire la valeur d’entrée. De plus, l’exécution de cette fonction est impossible à paralléliser : en effet, étant donné qu’il est impossible de prédire quelle sera la valeur de sortie de la fonction, il faut nécessairement exécuter entièrement la séquence pour trouver un hash.

Ainsi, on peut être certain du temps s’étant écoulé entre chaque décompte généré. De même, on est assuré que l’ordre enregistré pour chaque décompte est identique à ce qui s’est passé en temps réel.

Insertion de données

Il est également possible d’insérer des données au sein de la séquence. Leur hash est ajouté au dernier état généré. Ensuite, l’état, les données ajoutées et le décompte sont publiés : cela modifiera donc toutes les futures sorties.

Ici encore, le processus ne peut pas être exécuté en parallèle. La fonction de hachage choisie doit être :

• à sens unique : on ne peut pas déduire son antécédent à partir de l’image ;
• résistante aux collisions : deux antécédents différents ne peuvent pas donner la même image.

Avec ces conditions, il est impossible de créer une entrée qui générerait un hash souhaité dans le futur, ou de créer un historique alternatif avec les mêmes hashes. Le passage du temps est ainsi encodé au sein d’une structure de données vérifiable.

Les entrées dans le registre de la proof of history peuvent aussi contenir des références à la proof of history elle-même :

Il suffit qu’un utilisateur de la blockchain signe un message contenant la référence avec sa clef privée. Cela permet alors de prouver que le message a été signé après la création du décompte.

Ainsi, cette boucle peut être utilisée pour enregistrer des événements et les mettre en ordre dans le temps :

• Les messages faisant référence à un échantillon du registre de la proof of history ont été créés après l’échantillon ;
• Les messages insérés dans la boucle et hachés avec l’état du registre ont été créés avant l’insertion suivante.

Vérification de la proof of history

L’avantage de ce mécanisme est que la vérification des preuves est parallélisable, contrairement à leur génération. Elles sont découpées en plusieurs petits morceaux, traités chacun par un cœur du CPU. Le ratio entre le temps passé à générer une séquence et le temps de vérification sera de (1/nombre de cœurs). C’est là que réside le secret du débit en transactions par seconde très élevé de Solana.

Ce système d’horodatage présente un avantage certain par rapport à la preuve de travail classique. Il intervient avant le consensus des producteurs de blocs, ce qui permet de gagner un temps précieux et de traiter une grande quantité de données en peu de temps.

La preuve d’histoire est ainsi l’innovation majeure sur laquelle est construite l’architecture de Solana. Comme nous le verrons dans les articles suivants, les briques technologiques qui composent Solana tirent parti de ce nouveau mécanisme d’horodatage des événements, à commencer par son algorithme de consensus, nommé Tower BFT.