Die Solana Virtual Machine (SVM) ist die Ausführungsumgebung, die Solana-Programme verarbeitet und deren Zustandsänderungen im Netzwerk anwendet. Programme werden in das Solana Bytecode Format, kurz sBPF, kompiliert und in einer Sandbox-Runtime ausgeführt. Transaktionen geben an, welche Programme sie aufrufen und auf welche Konten jede Anweisung lesend oder schreibend zugreifen darf, wodurch die Runtime die nötigen Informationen erhält, um Zustand zu laden und kompatible Arbeit zu planen.

Die SVM trennt ausführbaren Programmcode von veränderlichen Kontodaten und verwendet Compute Units, um den Ressourcenverbrauch zu messen. Dieses Modell unterstützt Solanas parallele Sealevel-Runtime, weil Transaktionen, die keine miteinander konkurrierenden beschreibbaren Konten anfordern, gleichzeitig verarbeitet werden können. Die SVM ist eine Ausführungsschicht, nicht Solanas Konsensmechanismus, Validator-Client oder Proof-of-History-Uhr.

Was ist die Solana Virtual Machine?

Die Solana Virtual Machine (SVM) ist die Ausführungsumgebung, die Smart-Contract-Programme ausführt und Transaktionsanweisungen auf Solana verarbeitet. Anders als bei Systemen, in denen ein Smart Contract seinen eigenen Zustand speichert, trennt Solana Programmcode von Datenkonten. Transaktionen geben an, welche Programme und Konten sie verwenden werden, sodass das Netzwerk unabhängige Transaktionen parallel verarbeiten kann.

Der Begriff SVM kann sich auch auf Solana-kompatible Ausführungsumgebungen beziehen, die von anderen Blockchain-Netzwerken verwendet werden. Diese Netzwerke können ähnliche Programme und Entwicklerwerkzeuge unterstützen, während sie unterschiedliche Konsens-, Sequenzierungs-, Datenverfügbarkeits- oder Abwicklungssysteme nutzen. SVM-Kompatibilität beschreibt daher die Ausführungsumgebung, nicht das Sicherheitsmodell des zugrunde liegenden Netzwerks.

Wie funktioniert die Solana Virtual Machine?

Die Solana Virtual Machine verarbeitet jede Transaktion mithilfe der in dieser Transaktion aufgeführten Programme und Konten.

1. Erforderliche Konten laden: Die SVM identifiziert den Gebührenzahler, die Unterzeichner, die beschreibbaren Konten und die Programme, die die Transaktion benötigt.

2. Anweisungen ausführen: Anweisungen werden der Reihe nach durch die relevanten Solana-Programme ausgeführt, die bei Bedarf auch andere Programme aufrufen können.

3. Berechtigungen und Limits anwenden: Die Runtime prüft während der Ausführung Kontoeigentümerschaft, Unterzeichnerberechtigungen, Schreibzugriff und Compute-Unit-Limits.

4. Ergebnis verifizieren: Nach der Ausführung bestätigt die SVM, dass Guthaben und Kontodaten den Protokollregeln von Solana entsprechen.

5. Transaktion bestätigen: Wenn jede Anweisung erfolgreich ist, werden die Zustandsänderungen gemeinsam aufgezeichnet. Wenn eine fehlschlägt, aktualisiert die Transaktion den Anwendungszustand nicht teilweise.

Da Transaktionen angeben, auf welche Konten sie zugreifen, kann Solana Transaktionen, die unterschiedliche Konten verwenden, parallel ausführen, was dem Netzwerk hilft, einen höheren Durchsatz zu unterstützen.

Was sind die wichtigsten Vorteile und Anwendungsfälle der SVM?

Die SVM ist für Anwendungen konzipiert, die eine vorhersehbare Programmausführung benötigen und von explizitem Kontozugriff profitieren können. Ihre Leistung hängt sowohl vom Runtime-Design als auch davon ab, ob Transaktionen um denselben beschreibbaren Zustand konkurrieren.

1. Deklarierter Kontozugriff ermöglicht parallele Planung. Transaktionen listen die Konten auf, die sie vor der Ausführung benötigen, sodass der Scheduler konfliktfreie Transaktionen auf verschiedenen Prozessorkernen ausführen kann, während er gemeinsam genutzten beschreibbaren Zustand schützt.

2. Programme und Zustand bleiben getrennt. Ein zustandsloses Programm kann über viele Datenkonten hinweg arbeiten, was wiederverwendbare Anwendungslogik unterstützt und Entwicklern ermöglicht, den Zustand für Nebenläufigkeit zu organisieren, anstatt Code zu duplizieren.

3. Atomare Transaktionen können mehrere Anweisungen zusammensetzen. Eine Transaktion kann nacheinander mehrere Programme aufrufen und entweder jede erfolgreiche Zustandsänderung gemeinsam bestätigen oder die gesamte Transaktion ablehnen, wenn eine Anweisung fehlschlägt.

4. Compute Units machen Ressourcennutzung explizit. Die Runtime misst die Programmarbeit und ermöglicht es Transaktionen, ein angemessenes Budget anzufordern, was Validatoren hilft, die Ausführung zu begrenzen, während Nutzer Priorität über die Gebührenmechanismen des Netzwerks ausdrücken.

Was sind Beispiele für SVM-Programme und -Netzwerke?

SVM-Technologie kommt in Solana-Anwendungen und in Netzwerken vor, die Solana-kompatible Ausführung wiederverwenden. Die Beispiele unterscheiden sich in Abwicklung und Infrastruktur, sodass SVM-Unterstützung allein sie nicht zum selben Netzwerk macht.

• Native Solana-Programme. Das System-Programm erstellt Konten, während Vote-, Stake-, Compute-Budget- und Address-Lookup-Table-Programme Kernfunktionen bereitstellen, die direkt von der Solana-Runtime unterstützt werden.

• Solana-Anwendungsprogramme. DEXs, Kreditmärkte, NFT-Plattformen und Spiele stellen sBPF-Programme bereit, die auf Nutzer-, Markt-, Vault-, Mint- und Positionskonten arbeiten, die mit jeder Anweisung übergeben werden.

• Eclipse-Ausführung. Eclipse verwendet eine SVM-basierte Ausführungsumgebung und wickelt die Abwicklung über Ethereum-bezogene Infrastruktur ab, was veranschaulicht, wie die Runtime in einem anderen modularen Blockchain-Stack sitzen kann.

• Lokale SVM-Testtools. Tools wie LiteSVM reproduzieren relevantes Runtime-Verhalten für Entwicklung und Tests, ohne dass jeder Testfall Transaktionen an ein Live-Validator-Cluster senden muss.

Was sind die Einschränkungen und Risiken der SVM?

Das Leistungsmodell der SVM schafft spezifische Designbeschränkungen. Entwickler müssen Konten genau deklarieren, unnötige Konflikte reduzieren und innerhalb der Runtime-Limits bleiben, während Nutzer weiterhin gewöhnlichen Smart-Contract- und Transaktionsrisiken ausgesetzt sind.

1. Gemeinsame beschreibbare Konten können Parallelität einschränken. Transaktionen, die dasselbe beschreibbare Konto benötigen, können nicht sicher gemeinsam ausgeführt werden, sodass ein populäres globales Zustandskonto trotz paralleler Runtime zu einem Anwendungsengpass werden kann.

2. Programme erfordern Solana-spezifisches Entwicklungswissen. Entwickler müssen sBPF-Kompilierung, Kontoeigentümerschaft, programmabgeleitete Adressen, programmübergreifende Aufrufe, Compute-Budgets und mietbezogene Kontenanforderungen verstehen.

3. Compute- und Kontolimits können komplexe Aufrufe ablehnen. Eine Transaktion kann fehlschlagen, wenn sie ihr Compute-Budget überschreitet, zu viele Ressourcen referenziert, Kontodaten unsachgemäß vergrößert oder Aufruftiefe- und Runtime-Beschränkungen erreicht.

4. SVM-Kompatibilität bedeutet nicht Solana-Sicherheit. Eine separate SVM-Chain kann andere Validatoren, Bridges, Sequencer, Datenverfügbarkeit oder Upgrade-Kontrollen verwenden, wodurch Vertrauensannahmen entstehen, die nichts mit dem Ausführungs-Bytecode zu tun haben.

Wie unterscheidet sich die SVM von der EVM?

Die SVM unterscheidet sich von der EVM hauptsächlich durch ihr Kontomodell, ihren Bytecode und ihren Ansatz für Nebenläufigkeit. Solana-Transaktionen deklarieren den Kontozugriff vor der Ausführung, und Programme arbeiten auf separaten Zustandskonten, wodurch Sealevel konfliktfreie Arbeit parallel planen kann. Ethereum-Verträge enthalten normalerweise Code und Speicher an derselben Adresse, und die traditionelle EVM-Ausführung folgt der geordneten Transaktionssequenz. Beide Umgebungen erfordern deterministische Ergebnisse über validierende Knoten hinweg, aber ihre Entwicklerwerkzeuge, Gebührenmessung, Zustandslayouts und Kompatibilitätsstandards unterscheiden sich.

Verwandte Konzepte

1. Was ist ein Smart Contract?

2. Was ist Gas?

3. Was ist ein Validator?

4. Was ist Blockchain?

Weiterführende Literatur

1. Was sind die besten Solana Virtual Machine (SVM)-Projekte von 2025?

2. Was ist Eclipse (ES), das erste SVM-gestützte Layer 2 auf Ethereum?

3. Was ist Solscan und wie verwendet man den Solana Blockchain Explorer?

4. Solana vs. Ethereum: Eine vergleichende Analyse