La Solana Virtual Machine (SVM) est l'environnement d'exécution qui traite les programmes Solana et applique leurs changements d'état sur l'ensemble du réseau. Les programmes sont compilés au format de bytecode Solana, ou sBPF, et s'exécutent dans un runtime isolé. Les transactions identifient les programmes qu'elles appellent ainsi que les comptes que chaque instruction peut lire ou écrire, ce qui donne au runtime les informations nécessaires pour charger l'état et planifier les travaux compatibles.

La SVM sépare le code exécutable des programmes des données de compte modifiables et utilise des compute units pour mesurer la consommation de ressources. Ce modèle prend en charge le runtime parallèle Sealevel de Solana, car les transactions qui ne demandent pas de comptes inscriptibles en conflit peuvent être traitées simultanément. La SVM est une couche d'exécution, et non le mécanisme de consensus de Solana, son client validateur ou son horloge Proof of History.

Qu'est-ce que la Solana Virtual Machine ?

La Solana Virtual Machine (SVM) est l'environnement d'exécution qui exécute les programmes de smart contract et traite les instructions de transaction sur Solana. Contrairement aux systèmes où un smart contract stocke son propre état, Solana sépare le code des programmes des comptes de données. Les transactions précisent quels programmes et quels comptes elles utiliseront, ce qui permet au réseau de traiter en parallèle des transactions indépendantes.

Le terme SVM peut aussi désigner les environnements d'exécution compatibles avec Solana utilisés par d'autres réseaux blockchain. Ces réseaux peuvent prendre en charge des programmes et des outils de développement similaires tout en recourant à des systèmes différents de consensus, de séquençage, de disponibilité des données ou de règlement. La compatibilité SVM décrit donc l'environnement d'exécution, et non le modèle de sécurité du réseau sous-jacent.

Comment fonctionne la Solana Virtual Machine ?

La Solana Virtual Machine traite chaque transaction à l'aide des programmes et des comptes indiqués dans cette transaction.

1. Charger les comptes requis : la SVM identifie le payeur des frais, les signataires, les comptes inscriptibles et les programmes dont la transaction a besoin.

2. Exécuter les instructions : les instructions s'exécutent dans l'ordre via les programmes Solana concernés, qui peuvent aussi appeler d'autres programmes en cas de besoin.

3. Appliquer les permissions et les limites : le runtime vérifie la propriété des comptes, les permissions de signature, l'accès en écriture et les limites de compute units pendant l'exécution.

4. Vérifier le résultat : après l'exécution, la SVM confirme que les soldes et les données de compte respectent les règles du protocole Solana.

5. Valider la transaction : si chaque instruction réussit, les changements d'état sont enregistrés ensemble. Si une seule échoue, la transaction ne met pas à jour partiellement l'état de l'application.

Comme les transactions déclarent les comptes auxquels elles accèdent, Solana peut exécuter en parallèle des transactions qui utilisent des comptes différents, ce qui aide le réseau à prendre en charge un débit plus élevé.

Quels sont les principaux avantages et cas d'usage de la SVM ?

La SVM est conçue pour les applications qui ont besoin d'une exécution prévisible des programmes et qui peuvent tirer parti d'un accès explicite aux comptes. Ses performances dépendent à la fois de la conception du runtime et du fait que les transactions se disputent ou non le même état inscriptible.

1. La déclaration de l'accès aux comptes permet une planification parallèle. Les transactions listent les comptes dont elles ont besoin avant l'exécution, ce qui permet à l'ordonnanceur d'exécuter des transactions non conflictuelles sur différents cœurs de processeur tout en protégeant l'état inscriptible partagé.

2. Les programmes et l'état restent séparés. Un programme sans état peut fonctionner sur de nombreux comptes de données, ce qui favorise la réutilisation de la logique applicative et permet aux développeurs d'organiser l'état en vue de la concurrence plutôt que de dupliquer le code.

3. Les transactions atomiques peuvent composer plusieurs instructions. Une transaction peut appeler plusieurs programmes à la suite et soit enregistrer ensemble tous les changements d'état réussis, soit rejeter l'intégralité de la transaction lorsqu'une instruction échoue.

4. Les compute units rendent l'usage des ressources explicite. Le runtime mesure le travail des programmes et permet aux transactions de demander un budget adapté, ce qui aide les validateurs à encadrer l'exécution tandis que les utilisateurs expriment leur priorité via les mécanismes de frais du réseau.

Quels sont des exemples de programmes et de réseaux SVM ?

La technologie SVM apparaît dans les applications Solana et dans les réseaux qui réutilisent une exécution compatible avec Solana. Ces exemples diffèrent par leur règlement et leur infrastructure ; le simple support de la SVM ne suffit donc pas à en faire un même réseau.

• Programmes natifs de Solana. Le System Program crée des comptes, tandis que les programmes vote, stake, compute-budget et address-lookup-table fournissent des fonctions essentielles directement prises en charge par le runtime Solana.

• Programmes applicatifs Solana. Les DEX, les marchés de prêt, les plateformes NFT et les jeux déploient des programmes sBPF qui opèrent sur les comptes utilisateur, marché, vault, mint et position fournis avec chaque instruction.

• Exécution Eclipse. Eclipse utilise un environnement d'exécution basé sur la SVM tout en réglant via une infrastructure liée à Ethereum, ce qui illustre comment le runtime peut s'insérer dans une autre pile blockchain modulaire.

• Outils de test SVM locaux. Des outils comme LiteSVM reproduisent le comportement pertinent du runtime pour le développement et les tests sans exiger que chaque cas de test soumette des transactions à un cluster de validateurs en direct.

Quelles sont les limites et les risques de la SVM ?

Le modèle de performance de la SVM crée des contraintes de conception précises. Les développeurs doivent déclarer les comptes avec exactitude, réduire les contentions inutiles et rester dans les limites du runtime, tandis que les utilisateurs restent exposés aux risques habituels des smart contracts et des transactions.

1. Les comptes inscriptibles partagés peuvent limiter le parallélisme. Les transactions qui nécessitent le même compte inscriptible ne peuvent pas s'exécuter ensemble en toute sécurité ; un compte d'état global très sollicité peut donc devenir un goulot d'étranglement pour l'application, malgré un runtime parallèle.

2. Les programmes exigent des connaissances de développement spécifiques à Solana. Les développeurs doivent comprendre la compilation sBPF, la propriété des comptes, les program-derived addresses, les invocations inter-programmes, les budgets de compute units et les exigences de comptes liées au rent.

3. Les limites de calcul et de comptes peuvent rejeter des appels complexes. Une transaction peut échouer lorsqu'elle dépasse son budget de calcul, référence trop de ressources, fait croître anormalement les données de compte ou atteint les restrictions de profondeur d'appel et du runtime.

4. La compatibilité SVM n'équivaut pas à la sécurité de Solana. Une chaîne SVM distincte peut recourir à des validateurs, des bridges, des séquenceurs, une disponibilité des données ou des contrôles de mise à niveau différents, ce qui crée des hypothèses de confiance sans lien avec le bytecode d'exécution.

En quoi la SVM diffère-t-elle de l'EVM ?

La SVM diffère de l'EVM principalement par son modèle de comptes, son bytecode et son approche de la concurrence. Les transactions Solana déclarent l'accès aux comptes avant l'exécution, et les programmes opèrent sur des comptes d'état distincts, ce qui permet à Sealevel de planifier en parallèle des travaux non conflictuels. Les contrats Ethereum conservent habituellement le code et le stockage à la même adresse, et l'exécution EVM traditionnelle suit l'ordre séquentiel des transactions. Les deux environnements exigent des résultats déterministes sur l'ensemble des nœuds validateurs, mais leurs outils de développement, leur mesure des frais, leur organisation de l'état et leurs normes de compatibilité sont différents.

Concepts associés

1. Qu'est-ce qu'un smart contract ?

2. Qu'est-ce que le gas ?

3. Qu'est-ce qu'un validateur ?

4. Qu'est-ce que la blockchain ?

Pour aller plus loin

1. Quels sont les principaux projets Solana Virtual Machine (SVM) de 2025 ?

2. Qu'est-ce qu'Eclipse (ES), le premier layer 2 propulsé par la SVM sur Ethereum ?

3. Qu'est-ce que Solscan et comment utiliser l'explorateur de la blockchain Solana ?

4. Solana vs Ethereum : une analyse comparative