Vom Bitcoin-Schreibtisch zur Solana-Küche

Bitcoin verfügt über eine Skriptsprache — Script genannt — die bewusst eingeschränkt ist. Sie ist nicht Turing-vollständig, erlaubt keine Schleifen und lässt nur elementare Operationen zu: Signaturen prüfen, Timelocks kontrollieren oder Multisig-Schemata einrichten. Diese Einfachheit trägt dazu bei, das Verhalten von Bitcoin berechenbar zu machen und die Ausführungsfläche zu verringern, auch wenn die Sicherheit von Bitcoin von zahlreichen Elementen des Protokolls abhängt.

Ethereum ist einen anderen Weg gegangen: Es hat die EVM (Ethereum Virtual Machine) eingeführt, eine Turing-vollständige Umgebung, in der Smart Contracts ausgeführt werden können. Auf Protokollebene werden Zustandsübergänge nach einem sequenziellen Modell verarbeitet, auch wenn Implementierungen bestimmte interne Aufgaben parallelisieren können.

Solana hat auf die Herausforderung der Skalierbarkeit mit einer radikal anderen Architektur geantwortet: der SVM (Solana Virtual Machine) und der Sealevel-Runtime.

Das Kontenmodell von Solana (und der SVM)

Auf Ethereum « besitzt » ein Smart Contract seinen Zustand: Die Daten liegen im Vertrag selbst. In der SVM ist das Design entkoppelt:

- Der Code liegt in einem Programmkonto; seine Aktualisierbarkeit hängt vom Bereitstellungsmechanismus und der konfigurierten Autorität ab
- Die Daten (der Zustand) liegen in separaten Konten, die vom Programm kontrolliert werden

Das ermöglicht es Sealevel, Transaktionen im Voraus zu analysieren: Wenn Transaktion A die Konten {X, Y} betrifft und Transaktion B die Konten {Z, W}, können beide parallel und ohne Konflikt ausgeführt werden.

Dieses Modell ermöglicht es, Transaktionen, die nicht dieselben Konten beanspruchen, parallel auszuführen. Es kann den Durchsatz erhöhen, erlaubt aber für sich genommen nicht, einen quantitativen Vorteil gegenüber der EVM bei gleichwertiger Hardware abzuleiten. Es wurde kein Bitcoin-Hyper-spezifischer Leistungstest veröffentlicht.

Was das für Entwickler bedeutet

Programme für die SVM werden in Rust (oder in C/C++) geschrieben und zu eBPF-Bytecode kompiliert. Ein weitverbreitetes Framework ist Anchor, das Makros und Konventionen hinzufügt, um die Entwicklung zu erleichtern.

Die Dokumentation von Bitcoin Hyper nennt als Ziel eine unmittelbare Kompatibilität, oder « Drop-in-Kompatibilität », mit dem Solana-Ökosystem. Laut Projekt könnte ein bestehendes Programm mit begrenzten Anpassungen funktionieren, etwa der Änderung des RPC-Endpunkts und einiger Netzwerkparameter. Die Dokumentation sieht ausserdem eine Kompatibilität mit Werkzeugen wie der Solana-CLI, Anchor und IDE-Plugins vor. Der tatsächliche Grad der Kompatibilität muss noch unabhängig überprüft werden.

Würde dieser Grad an Kompatibilität erreicht, könnte er die Einstiegshürde für mit Solana vertraute Entwickler senken. Allerdings garantiert die gemeinsame Nutzung einer auf der SVM basierenden Umgebung für sich genommen nicht die Kompatibilität der Programme, der APIs, der Systemprogramme, der Werkzeuge oder der Verhaltensweisen der Runtime. Es handelt sich noch um ein Entwurfsziel und nicht um ein unabhängig überprüftes Ergebnis.

Was noch zu klären ist

Dennoch sollten mehrere Punkte transparent angesprochen werden:

Die vollständige Kompatibilität wurde nicht unabhängig überprüft: Das Devnet ist selektiv und die öffentlichen Tests sind begrenzt
Unterschiede im Gebührenmodell: Laut Projektdokumentation verwendet Bitcoin Hyper $HYPER für die Gebühren anstelle von SOL, sodass sich einige Abstraktionen unterscheiden
Abhängigkeiten von den Systemprogrammen von Solana: Einige Solana-Anwendungen stützen sich auf Systemprogramme (wie das offizielle Token Program), die möglicherweise nicht in identischer Form verfügbar sind

Die Behauptung einer « Drop-in »-Kompatibilität ist noch zu überprüfen. Ihre Beurteilung erfordert eine öffentliche technische Dokumentation, einen ausreichenden Zugang zum Devnet und reproduzierbare Tests, die sich auf die Programme, die Werkzeuge und die Systemabhängigkeiten beziehen.

Die Franchise-Analogie

Man kann sich die SVM als die Küche eines Franchise-Restaurants vorstellen. Das Rezept steht für den Code und das Lokal steht für das Netzwerk, auf dem er ausgeführt wird. Bitcoin Hyper will eine Ausstattung anbieten, die mit jener von Solana kompatibel ist, doch es ist noch nicht nachgewiesen, dass alle Komponenten identisch sind oder dass das Ergebnis in allen Fällen dasselbe ist.

Der Unterschied liegt in der Hauptzutat: Anstelle von SOL als « Treibstoff » der Küche würde hier $HYPER verwendet.

Die Solana Virtual Machine, erklärt für alle, die nur Bitcoin kennen