Die Solana Virtual Machine — erklärt für Bitcoin-Nutzer
Warum schlägt Bitcoin Hyper vor, die Solana Virtual Machine als Ausführungsumgebung zu nutzen? Ein Leitfaden für Leserinnen und Leser, die Bitcoin verstehen, aber mit Smart Contracts noch wenig vertraut sind.
Zu Bildungszwecken. Der Inhalt dieses Beitrags dient ausschliesslich der Information und Erläuterung. Er stellt keine Finanzberatung dar. Vollständiger Haftungsausschluss.
Vom Schreibtisch von Bitcoin in die Küche von Solana
Bitcoin verfügt über eine Skriptsprache — sie heisst Script — und sie ist bewusst eingeschränkt. Sie ist nicht turingvollständig, unterstützt keine Schleifen und erlaubt nur elementare Operationen: Signaturen prüfen, Zeitsperren kontrollieren, Multisignatur-Konstruktionen einrichten. Gerade diese Einfachheit macht sie sicher und berechenbar.
Ethereum wählte den entgegengesetzten Weg: Es führte die EVM (Ethereum Virtual Machine) ein, eine turingvollständige Umgebung, in der sich beliebige Programme (Smart Contracts) schreiben lassen. Leistungsfähig, aber mit einem Nachteil: Die Ausführung erfolgt seriell. Ein Contract nach dem anderen, der Reihe nach.
Solana beantwortete die Skalierungsfrage mit einer grundlegend anderen Architektur: der SVM (Solana Virtual Machine) und der Laufzeitumgebung Sealevel.
Das Account-Modell von Solana (und der SVM)
Bei Ethereum „besitzt“ ein Smart Contract seinen Zustand — die Daten liegen innerhalb des Contracts. In der SVM ist der Entwurf entkoppelt:
- - Der Code (das Programm) liegt in einem unveränderlichen Account
- - Die Daten (der Zustand) liegen in separaten Accounts, die vom Programm kontrolliert werden
Dadurch kann Sealevel Transaktionen vorab analysieren: Wenn Transaktion A die Accounts {X, Y} berührt und Transaktion B die Accounts {Z, W}, lassen sie sich parallel und konfliktfrei ausführen.
Die praktische Folge ist ein deutlich höherer Durchsatz als bei der EVM auf vergleichbarer Hardware.
Was das für Entwickler bedeutet
SVM-Programme werden in Rust (oder C/C++) geschrieben und zu eBPF-Bytecode kompiliert. Das verbreitetste Framework ist Anchor, das Makros und Konventionen ergänzt und die Entwicklung vereinfacht.
Das erklärte Ziel von Bitcoin Hyper ist Drop-in-Kompatibilität: Nach der Projektdokumentation soll ein bestehendes Solana-Programm mit minimalen Anpassungen auf Hyper laufen — es genügen ein anderer RPC-Endpunkt und einige Netzwerkeinstellungen. Dieselben Werkzeuge (Solana CLI, Anchor, IDE-Plug-ins) sollen unverändert funktionieren.
Gelänge dies, wäre es ein alles andere als trivialer Wettbewerbsvorteil: Das Solana-Ökosystem zählt Tausende Entwickler und einen grossen Bestand vorhandener Programme. Sie auf Bitcoin Hyper zu übertragen, würde die Einstiegshürde deutlich senken. Derzeit handelt es sich jedoch eher um ein Entwurfsziel als um ein unabhängig verifiziertes Ergebnis.
Was bislang offen ist
Einige Punkte sollten dabei offen benannt werden:
- Die vollständige Kompatibilität ist nicht unabhängig verifiziert: Der Zugang zum Devnet erfolgt selektiv, öffentliche Tests sind begrenzt
- Unterschiede im Gebührenmodell: Bitcoin Hyper verwendet für Gebühren $HYPER statt SOL — einige Abstraktionen unterscheiden sich daher
- Abhängigkeiten von Solana-Systemprogrammen: Manche Solana-Anwendungen stützen sich auf Systemprogramme (etwa das offizielle Token Program), die möglicherweise nicht in identischer Form verfügbar sind
Die Aussage zur „drop-in-kompatiblen“ Ausführung verdient einen Vertrauensvorschuss — aber ebenso eine kritische Prüfung. Testen Sie im Devnet, bevor Sie etwas voraussetzen. In einer Produktivumgebung ist dies bislang nicht unabhängig verifiziert worden.
Die Franchise-Analogie
Stellen Sie sich die SVM als die Küche eines Franchise-Restaurants vor. Das Rezept (der Rust-Code) ist überall dasselbe. Der Standort mag sich unterscheiden (Bitcoin Hyper statt Solana-Mainnet), doch die Ausstattung (SVM-Laufzeitumgebung, Anchor) ist identisch. Das fertige Gericht sollte dasselbe sein.
Der Unterschied liegt in der Hauptzutat: Statt SOL ist der „Brennstoff“ dieser Küche $HYPER.