Du bureau de Bitcoin à la cuisine de Solana

Bitcoin dispose d’un langage de script — appelé Script — délibérément limité. Il n’est pas Turing-complet, n’autorise pas les boucles et ne permet que des opérations élémentaires : vérifier des signatures, contrôler des timelocks ou configurer des schémas multisig. Cette simplicité contribue à rendre son comportement prévisible et à réduire la surface d’exécution, même si la sécurité de Bitcoin dépend de nombreux éléments du protocole.

Ethereum a suivi une voie différente : il a introduit l’EVM (Ethereum Virtual Machine), un environnement Turing-complet dans lequel des smart contracts peuvent être exécutés. Au niveau du protocole, les transitions d’état sont traitées selon un modèle séquentiel, même si les implémentations peuvent paralléliser certaines tâches internes.

Solana a répondu au défi de la scalabilité avec une architecture radicalement différente : la SVM (Solana Virtual Machine) et le runtime Sealevel.

Le modèle de comptes de Solana (et de la SVM)

Sur Ethereum, un smart contract « possède » son état : les données résident dans le contrat lui-même. Dans la SVM, la conception est découplée :

- Le code réside dans un compte de programme ; sa possibilité de mise à jour dépend du mécanisme de déploiement et de l’autorité configurée
- Les données (l’état) résident dans des comptes séparés, contrôlés par le programme

Cela permet à Sealevel d’analyser les transactions à l’avance : si la transaction A affecte les comptes {X, Y} et la transaction B les comptes {Z, W}, les deux peuvent être exécutées en parallèle sans conflit.

Ce modèle permet d’exécuter en parallèle des transactions qui ne sollicitent pas les mêmes comptes. Il peut accroître la capacité de traitement, mais ne permet pas, à lui seul, de déduire un avantage quantitatif par rapport à l’EVM avec un matériel équivalent. Aucun test de performance spécifique à Bitcoin Hyper n’a été publié.

Ce que cela implique pour les développeurs

Les programmes destinés à la SVM sont écrits en Rust (ou en C/C++) et compilés en bytecode eBPF. Un framework largement utilisé est Anchor, qui ajoute des macros et des conventions afin de faciliter le développement.

La documentation de Bitcoin Hyper présente comme objectif une compatibilité immédiate, ou « drop-in compatibility », avec l’écosystème Solana. Selon le projet, un programme existant pourrait fonctionner avec des adaptations limitées, telles que la modification de l’endpoint RPC et de certains paramètres réseau. La documentation prévoit également une compatibilité avec des outils tels que la CLI de Solana, Anchor et les plugins d’IDE. Le degré effectif de compatibilité reste à vérifier de manière indépendante.

Si ce niveau de compatibilité était atteint, il pourrait réduire la barrière à l’entrée pour les développeurs familiers de Solana. Toutefois, le partage d’un environnement fondé sur la SVM ne garantit pas, à lui seul, la compatibilité des programmes, des API, des programmes système, des outils ou des comportements du runtime. Il s’agit encore d’un objectif de conception et non d’un résultat vérifié de manière indépendante.

Ce qui reste encore à clarifier

Cela étant dit, plusieurs points doivent être signalés avec transparence :

La compatibilité complète n’a pas été vérifiée de manière indépendante : la devnet est sélective et les tests publics sont limités
Différences dans le modèle de frais : selon la documentation du projet, Bitcoin Hyper utilise $HYPER pour les frais à la place de SOL, de sorte que certaines abstractions diffèrent
Dépendances aux programmes système de Solana : certaines applications Solana s’appuient sur des programmes système (comme le Token Program officiel) qui pourraient ne pas être disponibles sous une forme identique

L’affirmation d’une compatibilité « drop-in » reste à vérifier. Son évaluation nécessite une documentation technique publique, un accès suffisant à la devnet et des tests reproductibles portant sur les programmes, les outils et les dépendances du système.

L’analogie de la franchise

On peut imaginer la SVM comme la cuisine d’un restaurant franchisé. La recette représente le code et l’établissement représente le réseau sur lequel il s’exécute. Bitcoin Hyper entend proposer un équipement compatible avec celui de Solana, mais il n’a pas encore été démontré que tous les composants sont identiques ni que le résultat est le même dans tous les cas.

La différence réside dans l’ingrédient principal : au lieu de SOL comme « carburant » de la cuisine, $HYPER serait utilisé ici.

La Solana Virtual Machine expliquée à ceux qui ne connaissent que Bitcoin