Solana : vision et architecture

Solana : vision et architecture#

Solana est une blockchain de couche 1 (layer 1) conçue pour atteindre des débits de transactions comparables à ceux des systèmes centralisés, tout en préservant les propriétés fondamentales d’un réseau décentralisé : résistance à la censure, transparence et sécurité cryptographique. Là où la plupart des blockchains font un compromis entre vitesse et décentralisation, Solana propose une approche radicalement différente en repensant la notion même de temps dans un système distribué.

L’intuition fondatrice de Solana repose sur une observation simple mais profonde : si chaque noeud d’un réseau distribué peut prouver cryptographiquement le passage du temps avant d’entrer en consensus, alors le consensus lui-même devient beaucoup plus rapide. Cette idée, appelée Proof of History (PoH), constitue le pilier sur lequel reposent les sept autres innovations techniques du protocole. Ensemble, ces huit innovations permettent a Solana d’atteindre des débits théoriques de 65 000 transactions par seconde avec des temps de finalité inferieurs a une seconde.

Ce chapitre est le coeur du livre. Nous y étudierons l’histoire du projet, le problème fondamental du temps dans les systèmes distribués, le mécanisme de Proof of History en détail – avec une simulation Python pour en comprendre le fonctionnement intime – puis les huit innovations architecturales qui font de Solana une blockchain unique. Nous terminerons par une comparaison chiffrée avec les autres protocoles majeurs.

Historique de Solana#

Définition 32 (Solana)

Solana est une blockchain à haute performance créée par Anatoly Yakovenko. Le nom provient de Solana Beach, une ville cotière de Californie où Yakovenko et ses cofondateurs ont vécu et travaillé.

Anatoly Yakovenko est un ingénieur système formé chez Qualcomm, où il a passé plus de douze ans à travailler sur les systèmes d’exploitation embarqués et les protocoles de communication sans fil. Son expérience des systèmes temps réel et du traitement massivement parallèle a profondément influencé la conception de Solana. En 2017, il publie un whitepaper intitule Proof of History: A Clock for Blockchain, dans lequel il décrit un mécanisme permettant de creer une horloge cryptographique vérifiable sans coordination entre les noeuds.

Remarque 24

La chronologie du projet illustre la rapidité d’exécution de l’équipe :

  • Novembre 2017 : publication du whitepaper sur Proof of History.

  • Février 2018 : création de Solana Labs par Yakovenko, Greg Fitzgerald et Stephen Akridge.

  • Mars 2020 : lancement du mainnet-beta.

  • Septembre 2021 : panne de 17 heures due à un afflux massif de transactions (IDO Raydium).

  • 2022-2023 : plusieurs interruptions supplémentaires, conduisant à des améliorations significatives du protocole.

  • 2024 : lancement de Firedancer, un second client validateur développé par Jump Crypto en C++, renforçant la diversité et la résilience du réseau.

Les pannes successives du réseau, loin d’être fatales, ont servi de catalyseur pour renforcer le protocole. Chaque interruption a conduit à des correctifs architecturaux : amélioration de la gestion de la mémoire dans le traitement des transactions, introduction du mecanisme QUIC pour le controle de flux, et diversification des clients validateurs avec Firedancer. Cette résilience progressive est caractéristique des protocoles blockchain en phase de maturation.

Le problème du temps#

Dans un système centralisé, le temps est trivial : un serveur unique possède une horloge et tous les évènements sont ordonnés par rapport à cette reference. Dans un système distribué, la situation est radicalement différente.

Définition 33 (Horloge logique)

Une horloge logique est un mécanisme permettant d’assigner un ordre aux évènements dans un système distribué sans reposer sur une horloge physique synchronisée. Au lieu de mesurer le temps réel, une horloge logique capture la relation de causalité entre les évènements : si l’évènement \(A\) cause l’évènement \(B\), alors l’horloge de \(A\) doit préceder celle de \(B\).

Le problème fondamental est le suivant : dans un réseau de noeuds géographiquement répartis, il n’existe pas d’horloge globale. Chaque noeud possède sa propre horloge physique, mais ces horloges dérivent les unes par rapport aux autres (quelques microsecondes par seconde pour les meilleurs oscillateurs à quartz). Les protocoles de synchronisation comme NTP (Network Time Protocol) offrent une precision de l’ordre de quelques millisecondes, ce qui est insuffisant pour ordonner des transactions qui arrivent à des intervalles de microsecondes.

De plus, la latence réseau est variable et imprévisible. Un message entre deux noeuds peut prendre 10 ms ou 500 ms selon la congestion du réseau, les routes empruntées et les conditions physiques. Cette variabilité rend impossible toute hypothèse fiable sur l’ordre d’arrivée des messages.

Remarque 25

En 1978, Leslie Lamport publie l’article fondateur Time, Clocks, and the Ordering of Events in a Distributed System. Il y démontre qu’il est possible d’ordonner les évènements d’un système distribué en utilisant uniquement les relations de causalité, sans horloge physique partagée. Les estampilles de Lamport (Lamport timestamps) assignent un compteur entier à chaque évènement, incrementé à chaque opération locale et mis à jour lors de la réception de messages. Cependant, les estampilles de Lamport ne capturent qu’un ordre partiel : deux évènements concurrents (sans relation causale) ne peuvent pas etre ordonnés de manière déterministe. C’est précisément ce problème que Proof of History résout.

Pour une blockchain, le problème du temps est critique. Les validateurs doivent se mettre d’accord sur l”ordre des transactions. Dans Bitcoin et Ethereum, cet accord est atteint par le consensus lui-même (Proof of Work ou Proof of Stake), ce qui est coûteux en temps et en ressources. Solana adopte une approche différente : établir un ordre vérifiable avant le consensus, en construisant une horloge cryptographique.

Proof of History (PoH)#

La Proof of History est l’innovation centrale de Solana. Elle répond au problème du temps en construisant une horloge cryptographique que tout le monde peut vérifier.

Définition 34 (Proof of History (PoH))

La Proof of History est une chaine séquentielle de hachages SHA-256 ou chaque hash depend du hash précédent :

\[h_n = \text{SHA-256}(h_{n-1})\]

Cette chaine constitue une fonction de délai vérifiable (Verifiable Delay Function, VDF) : la générer requiert un temps séquentiel incompressible (chaque hash doit attendre le précédent), mais vérifier la chaine peut etre parallélisé (chaque segment peut etre vérifié indépendamment). Des évènements (transactions) sont insérés entre les hachages, ce qui fournit une preuve cryptographique de leur ordre et du passage du temps entre eux.

L’idée est élégante dans sa simplicité. Le leader (le validateur désigne pour produire le bloc courant) exécute continuellement la fonction de hachage SHA-256. Quand une transaction arrive, elle est insérée dans le flux : le hash suivant prend en entrée le hash précédent et les données de la transaction. Ce mécanisme crée un enregistrement inviolable de l’ordre des évènements.

Remarque 26

La distinction entre génération et vérification est cruciale. Générer la séquence de hachages est inhéremment séquentiel : il faut calculer \(h_1\) pour obtenir \(h_2\), puis \(h_2\) pour obtenir \(h_3\), etc. Aucun parallélisme n’est possible. En revanche, une fois la sequence générée, elle peut etre vérifiée en parallèle : un vérifieur peut prendre \(h_{500}\) et vérifier que \(\text{SHA-256}(h_{500}) = h_{501}\) indépendamment de tout autre calcul. Cette asymétrie est la clé de la scalabilité de Solana.

Simulation : une mini-chaine PoH#

Implémentons une chaine PoH minimale pour comprendre le mécanisme.

Hide code cell source

 
import hashlib
import time

def poh_generate(seed: str, n_hashes: int, events: dict[int, str] | None = None) -> list[dict]:
    """
    Genere une chaine Proof of History.

    Parameters
    ----------
    seed : str
        Graine initiale.
    n_hashes : int
        Nombre de hachages séquentiels.
    events : dict
        Dictionnaire {position: données} des évènements à insérer.

    Returns
    -------
    list[dict]
        La chaine PoH avec les hachages et évènements.
    """
    if events is None:
        events = {}

    chain = []
    current_hash = seed

    for i in range(n_hashes):
        if i in events:
            # Inserer l'evenement dans le hash
            data = events[i]
            current_hash = hashlib.sha256(
                (current_hash + data).encode()
            ).hexdigest()
            chain.append({"index": i, "hash": current_hash, "event": data})
        else:
            current_hash = hashlib.sha256(
                current_hash.encode()
            ).hexdigest()
            chain.append({"index": i, "hash": current_hash, "event": None})

    return chain

Hide code cell source

 
# --- Generation sequentielle ---
seed = "solana_genesis_block"
n = 1000

start = time.perf_counter()
chain = poh_generate(seed, n)
elapsed_gen = time.perf_counter() - start

print(f"Génération de {n} hachages séquentiels : {elapsed_gen*1000:.2f} ms")
print(f"Premier hash : {chain[0]['hash'][:32]}...")
print(f"Dernier hash : {chain[-1]['hash'][:32]}...")

Génération de 1000 hachages séquentiels : 2.30 ms
Premier hash : 6c231376022868b5e25cb28d8b99f6da...
Dernier hash : 653f050db4bddd6ea123fd8af8e241f4...

Hide code cell source

 
# --- Verification (simulee comme parallelisable) ---
def poh_verify_segment(chain: list[dict], start_idx: int, end_idx: int) -> bool:
    """Vérifie un segment de la chaine PoH."""
    for i in range(start_idx, end_idx):
        entry = chain[i]
        if i == 0:
            continue  # pas de predecesseur a verifier
        prev_hash = chain[i - 1]["hash"]
        if entry["event"]:
            expected = hashlib.sha256(
                (prev_hash + entry["event"]).encode()
            ).hexdigest()
        else:
            expected = hashlib.sha256(prev_hash.encode()).hexdigest()
        if entry["hash"] != expected:
            return False
    return True

# Verification complete (un seul coeur)
start = time.perf_counter()
valid = poh_verify_segment(chain, 0, n)
elapsed_verify = time.perf_counter() - start

print(f"Vérification complête ({n} hachages) : {elapsed_verify*1000:.2f} ms")
print(f"Chaine valide : {valid}")

# Verification par segments (simulant le parallelisme)
n_segments = 4
segment_size = n // n_segments

start = time.perf_counter()
# En realite, ces segments seraient verifies en parallele sur 4 coeurs
times_per_segment = []
for s in range(n_segments):
    s_start = time.perf_counter()
    poh_verify_segment(chain, s * segment_size, (s + 1) * segment_size)
    times_per_segment.append(time.perf_counter() - s_start)

elapsed_parallel_simul = max(times_per_segment)

print(f"\nVérification par {n_segments} segments :")
print(f"  Temps du segment le plus long : {elapsed_parallel_simul*1000:.2f} ms")
print(f"  Gain potentiel avec {n_segments} coeurs : ~{elapsed_verify/elapsed_parallel_simul:.1f}x")

Vérification complête (1000 hachages) : 1.75 ms
Chaine valide : True

Vérification par 4 segments :
  Temps du segment le plus long : 0.40 ms
  Gain potentiel avec 4 coeurs : ~4.4x

Insertion d’évènements dans le flux PoH#

Exemple 13

Insérons trois transactions dans notre chaine PoH à des positions précises. Chaque évènement est haché avec le hash précédent, ce qui l’ancre de manière inviolable dans la séquence temporelle.

events = {
    100: "tx:Alice->Bob:5SOL",
    300: "tx:Charlie->Diana:2SOL",
    700: "tx:Eve->Frank:10SOL",
}
chain = poh_generate("genesis", 1000, events)

La transaction d’Alice arrive au hash 100, celle de Charlie au hash 300, celle d’Eve au hash 700. Leur ordre est cryptographiquement prouvé : pour modifier l’ordre, il faudrait recalculer toute la chaine a partir du point de modification, ce qui est calculatoirement infaisable en temps réel.

Hide code cell source

 
# Démonstration de l'insertion d'évènements
events = {
    100: "tx:Alice->Bob:5SOL",
    300: "tx:Charlie->Diana:2SOL",
    700: "tx:Eve->Frank:10SOL",
}

chain_with_events = poh_generate("genesis", 1000, events)

# Afficher les évènements et leur contexte
print("Evènements insérés dans la chaine PoH :\n")
for entry in chain_with_events:
    if entry["event"]:
        prev_hash = chain_with_events[entry["index"] - 1]["hash"][:16]
        print(f"  Position {entry['index']:>4d} | Evenement : {entry['event']}")
        print(f"               | Hash precedent : {prev_hash}...")
        print(f"               | Hash resultat  : {entry['hash'][:16]}...")
        print()

# Verifier que la chaine est valide
valid = poh_verify_segment(chain_with_events, 0, 1000)
print(f"Chaine avec évènements valide : {valid}")

Evènements insérés dans la chaine PoH :

  Position  100 | Evenement : tx:Alice->Bob:5SOL
               | Hash precedent : 68c7e24bed17607a...
               | Hash resultat  : 65b0c068895b0552...

  Position  300 | Evenement : tx:Charlie->Diana:2SOL
               | Hash precedent : d8a368613a5d568d...
               | Hash resultat  : e59088f19eed4cb8...

  Position  700 | Evenement : tx:Eve->Frank:10SOL
               | Hash precedent : 5a6f6100f8b07837...
               | Hash resultat  : 11e91efb2f1e46a8...

Chaine avec évènements valide : True

Visualisation de la chaine PoH#

Hide code cell source

 
import matplotlib.pyplot as plt
import matplotlib.patches as mpatches
import numpy as np
import seaborn as sns

sns.set_theme(style="whitegrid", palette="muted", font_scale=1.1)

# Régénérer la chaine pour cette cellule (indépendance entre cellules)
events = {
    100: "tx:Alice->Bob:5SOL",
    300: "tx:Charlie->Diana:2SOL",
    700: "tx:Eve->Frank:10SOL",
}
chain_with_events = poh_generate("genesis", 1000, events)

fig, ax = plt.subplots(figsize=(14, 4))

# Représenter un segment de la chaine PoH (positions 90 a 110)
segment_start, segment_end = 90, 115
positions = list(range(segment_start, segment_end))
y_base = 0.5

# Dessiner la chaine de hachages
for i, pos in enumerate(positions):
    color = "#4A90D9" if chain_with_events[pos]["event"] is None else "#E74C3C"
    size = 200 if chain_with_events[pos]["event"] is None else 400
    ax.scatter(i, y_base, s=size, c=color, zorder=5, edgecolors="white", linewidths=1.5)

    # Flèches entre les hachages
    if i > 0:
        ax.annotate(
            "", xy=(i - 0.15, y_base), xytext=(i - 0.85, y_base),
            arrowprops=dict(arrowstyle="->", color="#7F8C8D", lw=1.5)
        )

# Annoter l'évènement à la position 100
event_idx = positions.index(100)
ax.annotate(
    "tx:Alice->Bob:5SOL\n(position 100)",
    xy=(event_idx, y_base + 0.05),
    xytext=(event_idx, y_base + 0.35),
    fontsize=9, ha="center", color="#E74C3C", fontweight="bold",
    arrowprops=dict(arrowstyle="->", color="#E74C3C", lw=1.5),
    bbox=dict(boxstyle="round,pad=0.3", facecolor="#FADBD8", edgecolor="#E74C3C")
)

# Labels
hash_labels_pos = [0, event_idx, len(positions) - 1]
for p in hash_labels_pos:
    short_hash = chain_with_events[positions[p]]["hash"][:8]
    ax.text(p, y_base - 0.18, f"{short_hash}...", fontsize=7,
            ha="center", va="top", family="monospace", color="#555")

ax.set_xlim(-1, len(positions))
ax.set_ylim(0, 1.2)
ax.set_xlabel("Position dans la chaine PoH", fontsize=11)
ax.set_title("Chaine Proof of History avec insertion d'evenement", fontsize=13, fontweight="bold")
ax.set_yticks([])

# Légende
legend_elements = [
    mpatches.Patch(facecolor="#4A90D9", edgecolor="white", label="Hash standard"),
    mpatches.Patch(facecolor="#E74C3C", edgecolor="white", label="Hash avec evenement"),
]
ax.legend(handles=legend_elements, loc="upper left", framealpha=0.9)

plt.show()
_images/f5ed381e54bf191b536ff2b70a219bded024da10f87192a9f0530a78642587a1.png

Les 8 innovations de Solana#

Solana ne repose pas uniquement sur Proof of History. Le protocole combine huit innovations techniques qui, ensemble, permettent d’atteindre des performances inegalées parmi les blockchains décentralisées.

Définition 35 (Tower BFT)

Tower BFT est l’algorithme de consensus de Solana, une variante de PBFT (Practical Byzantine Fault Tolerance) optimisée grace a PoH. Les validateurs votent sur des blocs estampillés par PoH. Chaque vote est associé a un verrou exponentiel (exponential lockout) : un validateur qui vote pour un bloc a la hauteur \(h\) est verrouillé pendant \(2^k\) slots, ou \(k\) est le nombre de votes consécutifs pour cette branche. Ce mécanisme rend les forks coûteux et permet d’atteindre la finalité sans communication directe entre tous les validateurs.

Définition 36 (Turbine)

Turbine est le protocole de propagation des blocs, inspiré de BitTorrent. Au lieu d’envoyer un bloc entier à chaque validateur, le leader découpe le bloc en shreds (fragments) et les distribue dans un arbre de propagation. Chaque noeud ne retransmet qu’une petite partie des données, ce qui reduit la bande passante requise de \(O(n)\) a \(O(\log n)\) pour un réseau de \(n\) validateurs.

Définition 37 (Gulf Stream)

Gulf Stream est le protocole de transfert de transactions sans mempool. Au lieu de conserver les transactions en attente dans un pool local (comme Bitcoin ou Ethereum), Gulf Stream transmet les transactions directement aux prochains leaders prévus dans le calendrier de rotation. Cette approche reduit le temps de confirmation et la pression mémoire sur les validateurs.

Définition 38 (Sealevel)

Sealevel est le moteur d’exécution parallèle des transactions de Solana. Chaque transaction Solana déclare explicitement les comptes qu’elle lira et ecrira. Deux transactions dont les ensembles de comptes ne se chevauchent pas peuvent etre executées simultanément sur des coeurs différents. Si \(T_1\) accède aux comptes \(\{A, B\}\) et \(T_2\) aux comptes \(\{C, D\}\), avec \(\{A, B\} \cap \{C, D\} = \emptyset\), alors \(T_1\) et \(T_2\) s’exécutent en parallèle.

Exemple 14

Considerons trois transactions en attente :

  • \(T_1\) : Alice transfère 5 SOL à Bob (comptes : Alice, Bob)

  • \(T_2\) : Charlie transfère 2 SOL à Diana (comptes : Charlie, Diana)

  • \(T_3\) : Bob transfère 1 SOL à Eve (comptes : Bob, Eve)

Sealevel détecte que \(T_1\) et \(T_2\) n’ont aucun compte en commun : elles s’exécutent en parallèle. En revanche, \(T_3\) partage le compte Bob avec \(T_1\) : elle doit attendre la fin de \(T_1\). L’ordonnancement optimal est donc : \(T_1 \parallel T_2\), puis \(T_3\).

Définition 39 (Pipelining (TPU))

Le pipelining dans le TPU (Transaction Processing Unit) de Solana décompose le traitement d’un bloc en quatre étapes exécutées en pipeline :

  1. Fetch : réception des données depuis le réseau.

  2. SigVerify : vérification des signatures (GPU).

  3. Banking : exécution des transactions et mise à jour des comptes.

  4. Write : écriture des résultats sur le disque et diffusion.

Pendant que l’étape Banking traite le lot \(n\), SigVerify traite le lot \(n+1\) et Fetch recoit le lot \(n+2\).

Définition 40 (Cloudbreak)

Cloudbreak est la base de données de comptes de Solana, conçue pour être horizontalement scalable. Les comptes sont stockés dans des fichiers mappés en mémoire (memory-mapped files) et indexés par leur clé publique. Cette architecture permet des lectures et écritures concurrentes sur des comptes différents, en harmonie avec l’exécution parallèle de Sealevel.

Définition 41 (Archivers)

Les Archivers (renommés depuis en Accounts DB replication) constituent le système de stockage distribué de Solana. Les données historiques de la blockchain sont découpées en fragments et réparties entre des noeuds de stockage, de sorte qu’aucun noeud individuel n’a besoin de stocker l’intégralité de l’historique. Ce mécanisme s’inspire du codage par effacement (erasure coding) pour garantir la disponibilité des données.

Visualisation du pipeline TPU#

Hide code cell source

 
import matplotlib.pyplot as plt
import matplotlib.patches as mpatches
import numpy as np
import seaborn as sns

sns.set_theme(style="whitegrid", palette="muted", font_scale=1.1)

fig, ax = plt.subplots(figsize=(14, 5))

stages = ["Fetch", "SigVerify\n(GPU)", "Banking", "Write"]
colors = ["#3498DB", "#9B59B6", "#E67E22", "#27AE60"]
n_stages = len(stages)
n_lots = 6

# Dessiner les blocs du pipeline
for lot in range(n_lots):
    for stage in range(n_stages):
        t = lot + stage  # position temporelle
        rect = plt.Rectangle(
            (t + 0.05, stage + 0.1), 0.9, 0.8,
            facecolor=colors[stage], alpha=0.75,
            edgecolor="white", linewidth=2
        )
        ax.add_patch(rect)
        ax.text(
            t + 0.5, stage + 0.5, f"Lot {lot+1}",
            ha="center", va="center", fontsize=9,
            fontweight="bold", color="white"
        )

# Axes et labels
ax.set_xlim(-0.2, n_lots + n_stages - 0.5)
ax.set_ylim(-0.3, n_stages + 0.5)
ax.set_xlabel("Temps (slots)", fontsize=12)
ax.set_ylabel("")
ax.set_yticks([s + 0.5 for s in range(n_stages)])
ax.set_yticklabels(stages, fontsize=11)
ax.set_xticks(range(n_lots + n_stages))
ax.set_xticklabels([f"$t_{{{i}}}$" for i in range(n_lots + n_stages)], fontsize=10)
ax.set_title("Pipelining du TPU : 4 étapes en parallèle", fontsize=13, fontweight="bold")

# Legende
legend_elements = [
    mpatches.Patch(facecolor=c, label=s.replace("\n", " "), edgecolor="white")
    for s, c in zip(stages, colors)
]
ax.legend(handles=legend_elements, loc="upper right", framealpha=0.9)

ax.invert_yaxis()
plt.show()
_images/2177b5abaa07fd2ff213f0ad7838e2830dadbd2d40eaf80750eeeebc04a570ef.png

Remarque 27

Le pipelining est une technique classique en architecture des processeurs, appliquée ici au traitement des transactions. Sans pipelining, chaque lot devrait traverser les quatre etapes séquentiellement avant que le lot suivant ne commence. Avec le pipelining, le débit est multiplié par le nombre d’étapes (ici 4) une fois le pipeline rempli, au prix d’une latence initiale (pipeline fill delay) de \(n_{\text{etapes}} - 1\) slots.

Performances et comparaison#

Comment Solana se positionne-t-elle par rapport aux autres blockchains majeures ? Comparons les métriques clés.

Hide code cell source

 
import pandas as pd
import matplotlib.pyplot as plt
import numpy as np
import seaborn as sns

sns.set_theme(style="whitegrid", palette="muted", font_scale=1.1)

# Donnees comparatives
data = {
    "Blockchain": ["Solana", "Ethereum", "Bitcoin", "Polygon"],
    "TPS theorique": [65000, 100000, 7, 7000],
    "TPS reel moyen": [4000, 30, 5, 300],
    "Finalite (s)": [0.4, 780, 3600, 120],
    "Cout par tx ($)": [0.00025, 1.50, 2.00, 0.01],
}

df = pd.DataFrame(data)
df = df.set_index("Blockchain")
print(df.to_markdown())

| Blockchain   |   TPS theorique |   TPS reel moyen |   Finalite (s) |   Cout par tx ($) |
|:-------------|----------------:|-----------------:|---------------:|------------------:|
| Solana       |           65000 |             4000 |            0.4 |           0.00025 |
| Ethereum     |          100000 |               30 |          780   |           1.5     |
| Bitcoin      |               7 |                5 |         3600   |           2       |
| Polygon      |            7000 |              300 |          120   |           0.01    |

Remarque 28

Les chiffres de TPS théoriques sont issus des documentations officielles et doivent etre interprétés avec prudence. Le TPS théorique d’Ethereum à 100 000 suppose la réalisation complête de la feuille de route de sharding (danksharding). Le TPS réel moyen de Solana inclut les transactions de vote des validateurs, qui représentent une part significative du trafic. Les coûts par transaction varient fortement selon la congestion du réseau. Ces chiffres offrent néanmoins un ordre de grandeur utile pour situer les protocoles les uns par rapport aux autres.

Hide code cell source

 
import matplotlib.pyplot as plt
import numpy as np
import seaborn as sns

sns.set_theme(style="whitegrid", palette="muted", font_scale=1.1)

blockchains = ["Solana", "Ethereum", "Bitcoin", "Polygon"]
tps_reel = [4000, 30, 5, 300]
finalite = [0.4, 780, 3600, 120]
cout = [0.00025, 1.50, 2.00, 0.01]

fig, axes = plt.subplots(1, 3, figsize=(16, 5))
bar_colors = ["#9945FF", "#627EEA", "#F7931A", "#8247E5"]

# TPS reel
bars = axes[0].bar(blockchains, tps_reel, color=bar_colors, edgecolor="white", linewidth=1.5)
axes[0].set_ylabel("Transactions par seconde")
axes[0].set_title("TPS réel moyen", fontweight="bold")
axes[0].set_yscale("log")
for bar, val in zip(bars, tps_reel):
    axes[0].text(bar.get_x() + bar.get_width() / 2, bar.get_height() * 1.3,
                 f"{val:,}", ha="center", va="bottom", fontsize=9, fontweight="bold")

# Finalite
bars = axes[1].bar(blockchains, finalite, color=bar_colors, edgecolor="white", linewidth=1.5)
axes[1].set_ylabel("Secondes")
axes[1].set_title("Temps de finalité", fontweight="bold")
axes[1].set_yscale("log")
for bar, val in zip(bars, finalite):
    label = f"{val:.1f}s" if val < 60 else f"{val/60:.0f}min"
    axes[1].text(bar.get_x() + bar.get_width() / 2, bar.get_height() * 1.3,
                 label, ha="center", va="bottom", fontsize=9, fontweight="bold")

# Cout par transaction
bars = axes[2].bar(blockchains, cout, color=bar_colors, edgecolor="white", linewidth=1.5)
axes[2].set_ylabel("Dollars ($)")
axes[2].set_title("Coût par transaction", fontweight="bold")
axes[2].set_yscale("log")
for bar, val in zip(bars, cout):
    axes[2].text(bar.get_x() + bar.get_width() / 2, bar.get_height() * 1.3,
                 f"${val}", ha="center", va="bottom", fontsize=9, fontweight="bold")

fig.suptitle("Comparaison des blockchains majeures", fontsize=14, fontweight="bold", y=1.02)
plt.show()
_images/bf5755e98017129e93674535a315cc0e9f4168afeb4c02874f4de093b6e9bc5c.png

Remarque 29

Le trilemme de la blockchain, formulé par Vitalik Buterin, postule qu’une blockchain ne peut optimiser simultanément que deux des trois propriétés suivantes : décentralisation, sécurité et scalabilité. Solana fait le choix explicite de privilégier la scalabilité et la securité, au prix d’exigences matérielles élevées pour les validateurs (CPU multicoeur, GPU, 128 Go de RAM, SSD NVMe rapide, connexion 1 Gbps). Ce choix reduit le nombre de validateurs potentiels (~1900 en 2024) par rapport a Ethereum (~900 000 validateurs), ce qui soulève des questions légitimes sur la décentralisation du réseau.

Remarque 30

Les interruptions de service constituent la critique la plus fréquente a l’encontre de Solana. Entre septembre 2021 et février 2023, le réseau a connu plus de dix interruptions significatives, causées par des afflux de transactions non regulés, des bugs dans le consensus et des problèmes de mémoire. Solana a répondu par : (1) l’introduction du protocole QUIC pour le controle de flux en remplacement d’UDP, (2) des marchés de frais localisés (local fee markets) pour isoler la congestion, (3) le developpement de Firedancer, un client validateur independant en C++ par Jump Crypto, qui apporte diversité logicielle et performances supérieures. Depuis 2024, la stabilité du réseau s’est considérablement améliorée.

Résumé#

Ce chapitre a présenté l’architecture de Solana en partant du problème fondamental qu’elle resout : l’absence d’horloge globale dans les systèmes distribués.

Proof of History constitue l’innovation centrale. En construisant une chaine séquentielle de hachages SHA-256, Solana crée une horloge cryptographique vérifiable qui ordonne les évènements avant le consensus. Notre simulation a montré que la génération de cette chaine est inhéremment séquentielle, mais que sa vérification peut être parallélisée – une asymétrie essentielle pour la scalabilité.

Les huit innovations de Solana – PoH, Tower BFT, Turbine, Gulf Stream, Sealevel, Pipelining, Cloudbreak et Archivers – ne sont pas des composants indépendants mais un système intègre. PoH fournit l’horloge, Tower BFT l’utilise pour un consensus rapide, Turbine propage les blocs efficacement, Gulf Stream élimine le mempool, Sealevel exécute les transactions en parallèle, le pipelining maximise le débit du TPU, Cloudbreak offre un stockage de comptes scalable, et les Archivers distribuent le stockage historique.

Solana se positionne clairement du côté de la scalabilité dans le trilemme de la blockchain, avec des performances brutes qui surpassent largement les autres L1 generalistes. Ce choix impose des exigences matérielles élevées aux validateurs, ce qui constitue un compromis assumé sur la décentralisation. Les chapitres suivants montreront comment cette architecture se traduit concrètement dans le modèle de comptes et le traitement des transactions.

Contenu