Einleitung
Im Jahr 2024 erlebte Solana einen dramatischen Aufstieg, wobei der Total Value Locked (TVL) von einer Milliarde US-Dollar zu Beginn des Jahres auf fast fünf Milliarden US-Dollar anstieg und es zur viertgrößten öffentlichen Blockchain machte.
Im Vergleich zu Ethereum bietet Solana den Nutzern eine überlegene Erfahrung mit schnelleren Geschwindigkeiten und niedrigeren Kosten. Der auf Proof of History basierende Konsensmechanismus und das asynchrone Transaktionsverarbeitungsmodell bieten Entwicklern einen hohen Transaktionsdurchsatz und eine geringe Latenz, was es zu einer bevorzugten Plattform für alle Arten von dezentralen Anwendungen macht.
BlockSec hat speziell die Serie "Solana vereinfacht" geplant, die grundlegende Konzepte von Solana, praktische Anleitungen zur Analyse von Solana-Transaktionen und Tutorials zum Schreiben von Solana-Smart Contracts abdeckt.
Als erster Artikel in dieser Serie wird sich dieser Text mit den Schlüsselkonzepten innerhalb des Solana-Netzwerks befassen, einschließlich seiner Betriebsabläufe, seines Account-Modells und seiner Transaktionen, um die Grundlage für das Schreiben korrekter und effizienter Smart Contracts in Solana zu legen.
eBPF: Der Grundstein der Solana-Transaktionsausführung
Für das Schreiben und Ausführen von Smart Contracts benötigen Blockchains in der Regel eine Programmiersprache und eine Turing-vollständige Rechenumgebung.
Smart Contracts auf Ethereum werden üblicherweise in einer Hochsprache namens Solidity geschrieben. Der Compiler übersetzt sie in Bytecode, der dann in der Ethereum Virtual Machine (EVM) ausgeführt wird. Anstatt eine völlig neue virtuelle Umgebung und Sprache zu entwickeln, hat Solana beschlossen, bestehende fortschrittliche Technologien voll auszunutzen. Die eBPF (extended Berkeley Packet Filter) virtuelle Maschine, die ursprünglich zur Erweiterung der Funktionalitäten des Linux-Kernels entwickelt wurde, wurde von Solana als seine zugrundeliegende Ausführungsumgebung ausgewählt.
Welche Vorteile bietet eBPF gegenüber der EVM?
Im Gegensatz zur EVM, die auf interpretierte Ausführung beschränkt ist, unterstützt eBPF Just-In-Time (JIT)-Kompilierung, wodurch Bytecode in Maschinencode-Instruktionen übersetzt werden kann, die der Prozessor direkt ausführen kann. Eine solche Fähigkeit erhöht die Programmeffizienz erheblich.
Darüber hinaus verfügt eBPF über einen effizienten Instruktionssatz und eine ausgereifte Infrastruktur. Entwickler können Smart Contracts mit der Sprache Rust erstellen. Durch die Nutzung des eBPF-Backends des LLVM-Compiler-Frameworks können die Rust-Programme direkt in eBPF-Bytecode kompiliert werden.
Solanas Account-Modell
Solana Account Struktur
Daten werden auf Solana in Form von Accounts gespeichert. Wie unten dargestellt, können alle Daten innerhalb von Solana als eine riesige Schlüssel-Wert-Datenbank konzipiert werden. Die Schlüssel in dieser Datenbank sind die Account-Adressen. Für "Wallet"-Accounts (d.h. Accounts, die direkt von Solana-Benutzern über öffentliche/private Schlüsselpaare kontrolliert werden) sind diese Adressen öffentliche Schlüssel, die mit dem Ed25519-Signatursystem generiert wurden. Die Werte in der Datenbank bestehen aus spezifischen Details jedes Accounts, einschließlich des Guthabens und anderer relevanter Informationen.
Solana verwendet die folgende Struktur namens AccountInfo, um einen Account zu beschreiben.
Die AccountInfo für jeden Account enthält vier Felder. Hier ist eine Erklärung für jedes:
-
Feld
Data: Dieses Feld speichert die Daten, die sich auf den Account beziehen. Wenn der Account ein Programm (d.h. ein Smart Contract) ist, speichert es den eBPF-Bytecode. Andernfalls wird das Format der Daten im Allgemeinen vom Account-Ersteller definiert. -
Feld
Executable: Dieses Feld wird verwendet, um anzuzeigen, ob der Account ein Programm ist. Es ist wichtig zu beachten, dass Programme auf Solana im Gegensatz zu Ethereum aktualisiert werden können. -
Feld
Lamports: Dieses Feld speichert den Saldo der Solana-Tokens auf dem Account. Lamports sind eigentlich die kleinste Einheit des SOL-Tokens (1 SOL = 1 Milliarde Lamports). -
Feld
Owner: Dieses Feld gibt den Eigentümer des Accounts an. Auf Solana hat jeder Account einen "Eigentümer". Beispielsweise ist der Eigentümer aller "Wallet"-Accounts das Systemprogramm, ein spezieller Account im Solana-Netzwerk, der für Funktionen wie die Account-Erstellung zuständig ist. Der Account-Eigentümer ist die einzige Person, die Account-Daten ändern und Lamports vom Saldo abziehen kann (jeder kann jedoch Lamports erhöhen, indem er Geld auf den Account überweist).
Vordefinierte Solana-Accounts
Solana hat eine Reihe vordefinierter ausführbarer Programme, die als Native Programs bekannt sind und an festen Adressen bereitgestellt werden. Mit der Aktualisierung des Solana-Netzwerks können diese vordefinierten Programme auch aktualisiert werden. Sie dienen als APIs und Bibliotheksfunktionen und bieten spezifische Funktionalitäten innerhalb des Solana-Netzwerks.
Innerhalb der Native Programs ist das System Program eines, mit dem Entwickler häufig interagieren. Das Systemprogramm stellt Entwicklern eine Reihe von Anweisungen zur Verfügung, von denen jede eine unabhängige Aufgabe ausführt. Entwickler können beispielsweise die Anweisung CreateAccount verwenden, um neue Accounts zu erstellen, oder die Anweisung Transfer, um Lamports an andere Accounts zu übertragen.
Ein weiteres häufiges Native Program ist das BPF Loader-Programm. Es ist der Eigentümer aller anderen Programm-Accounts und für die Bereitstellung, Aktualisierung und Ausführung benutzerdefinierter Programme zuständig. Wenn ein "Wallet"-Account ein von ihm bereitgestelltes Programm aktualisieren muss, geschieht dies tatsächlich durch Delegation an das BPF Loader-Programm, da nur der Eigentümer eines Programms die direkte Befugnis hat, Daten zu ändern.
Zusätzlich zu den Native Programs bietet Solana auch eine Reihe von Accounts namens Sysvars. Diese Accounts stellen Programmen auf Solana Informationen und globale Variablen zur aktuellen Zustand des Solana-Netzwerks zur Verfügung, wie z. B. die aktuelle Uhr und den neuesten Blockhash.
Account-Miete
Auf der Solana-Blockchain muss jeder Account eine bestimmte Anzahl von Lamports als Mindestsaldo beibehalten, bekannt als Miete. Im Gegensatz zur Miete im realen Leben ist die Miete auf Solana rückforderbar. Um sicherzustellen, dass die Daten in einem Account auf der Kette verfügbar sind, muss der Account einen angemessenen Betrag an Lamports enthalten. Die Höhe der Miete hängt von der Größe der vom Account belegten Daten ab.
Jede Transaktion, die versucht, den Account-Saldo unter den Mietbetrag zu reduzieren, schlägt fehl, es sei denn, sie reduziert den Saldo auf genau Null. Eine Reduzierung des Saldos auf Null bedeutet, dass die Miete des Accounts zurückgefordert wurde, und am Ende der Transaktion wird Solana die Daten des entsprechenden Accounts im Rahmen des Garbage Collection-Prozesses löschen.
🧐 Solana-Accounts in Solana Scans anzeigen
Um die oben genannten Konzepte besser zu verstehen, haben wir das "Hello World"-Projekt von Solana verwendet, um ein Programm-Account bereitzustellen, das mit dem Solana-Blockchain-Explorer Solscan eingesehen werden kann.
Wie im obigen Bild gezeigt, können wir zuerst sehen, dass der Account als "Programm" gekennzeichnet ist. Ein Teil der Lamports wurde vom Saldo des Absenders als Miete für diesen Account abgezogen, daher ist das Feld SOL Balance nicht leer. Da der von uns erstellte Account ein Programm ist, ist sein Feld Executable auf Ja gesetzt.
Sie sind vielleicht verwirrt, dass das Feld Executable Data eine Adresse und keinen eBPF-Code speichert. Wie bereits erwähnt, ermöglicht Solana Programm-Updates, und dies wird tatsächlich über ein "Proxy"-Muster implementiert. Da direkte Änderungen am Programm-Account anfangs nicht erlaubt sind, erstellt Solana einen separaten Daten-Account, um das eBPF-Programm zu speichern, während das Datenfeld im Programm-Account nur die Adresse dieses Daten-Accounts speichert.
Wenn eine Aktualisierung des Programms erforderlich ist, muss nur das Datenfeld des Daten-Accounts geändert werden. Durch die Verwendung von Solscan zur Anzeige des Daten-Accounts stellen wir fest, dass er als "Program Executable Data Account" gekennzeichnet ist und sein Feld Data das eigentliche Programm speichert.
Das Feld Owner im Abschnitt "More Info" ist der BPF Loader, was mit den vorherigen Ausführungen übereinstimmt.
Manche bemerken vielleicht, dass das letzte Feld von "Overview" Upgrade Authority lautet, welches nicht in der AccountInfo vorhanden ist. Was bedeutet das?
Wie bereits erwähnt, delegiert der "Wallet"-Account Programm-Updates an den BPF Loader. Vor dem Update prüft der BPF Loader, ob der Delegierende der Account ist, der das Programm ursprünglich bereitgestellt hat. Da der Eigentümer des Programm-Accounts bereits als BPF Loader festgelegt ist, hat er keinen Platz mehr, um diese Information zu speichern. Daher platziert Solana dies in das Datenfeld des Daten-Accounts. Deshalb gibt es im "Overview" ein Feld Upgrade Authority, und es ist tatsächlich die Wallet-Adresse, die das Programm bereitgestellt hat.
Das folgende Bild zeigt die Beziehung zwischen dem Programm-Account und dem Daten-Account. Beachten Sie, dass das Datenfeld des Daten-Accounts sowohl die Wallet-Adresse als auch den eBPF-Code enthält.
Transaktionen und Instruktionen in Solana
In Solana führen Benutzer Programme aus, indem sie Transaktionen auslösen. Ein einzigartiges Merkmal von Solana ist seine Fähigkeit, diese Transaktionen parallel auszuführen, was ein Hauptgrund für seine blitzschnellen Transaktionsgeschwindigkeiten ist. Nun wollen wir uns genauer ansehen, wie Transaktionen in Solana konzipiert sind.
Eine Solana-Transaktion besteht aus Signaturen und einer Nachricht. Eine Transaktion kann mehrere Signaturen enthalten. Die Nachricht einer Transaktion besteht aus vier Teilen, wie unten dargestellt.
Der Header und das Compact Array of Account Addresses geben alle an der Transaktion beteiligten Accounts und deren Eigenschaften während der Transaktion an, einschließlich, ob der Account ein Unterzeichner ist und ob er während der Ausführung beschreibbar ist. Mit diesen Informationen kann Solana die von den Unterzeichner-Accounts bereitgestellten Signaturen überprüfen und Transaktionen parallel verarbeiten, solange diese Transaktionen keine Accounts enthalten, die auf denselben Zustand schreiben.
Der Recent Blockhash dient als Zeitstempel für die Transaktion. Wenn der Blockhash einer Transaktion 150 Blöcke älter als der neueste Blockhash ist, gilt sie als abgelaufen und wird nicht ausgeführt.
Das Compact Array of Instructions ist der wichtigste Teil der Transaktion und enthält eine oder mehrere Instruktionen. Eine Instruktion löst im Wesentlichen die Ausführung einer Routine aus, die von einem Programm-Account bereitgestellt wird. Jede Instruktion besteht aus drei Feldern, wie unten dargestellt.
Das erste Feld, Program ID Index, gibt den Empfänger der Instruktion an, also das On-Chain-Programm, das die Instruktion verarbeiten muss. Anstatt eine 32-Byte-Adresse zu speichern, wird diese Adresse im Compact Array of Account Addresses der Transaktionsnachricht abgelegt, und das Feld speichert nur einen u8-Index, der auf die Adresse im Array verweist.
Ähnlich wie beim ersten Feld speichert das zweite Feld Account-Adressen-Indizes, bekannt als Compact Array of Account Address Indexes. Dieses Array gibt alle an dieser Instruktion beteiligten Accounts an.
Das letzte Feld ist ein Byte-Array, das die zusätzlichen Daten enthält, die das Programm zur Verarbeitung der Instruktion benötigt, wie z. B. Funktionsargumente.
Es ist wichtig zu beachten, dass Solana alle Instruktionen innerhalb einer Transaktion in der Reihenfolge verarbeitet und die atomare Ausführung der Transaktion garantiert. Das bedeutet, dass entweder alle Instruktionen erfolgreich verarbeitet werden oder die gesamte Transaktion fehlschlägt. Es wird nicht vorkommen, dass einige Instruktionen verarbeitet und andere nicht.
🧐 Solana-Transaktionen in Solana Scans anzeigen
Wir verwenden einen weiteren Solana-Explorer, um die Transaktion anzuzeigen, die den Programm-Account zuvor erstellt hat. Im Abschnitt "Overview" können Sie die Solana-Transaktionssignatur, den zuletzt verwendeten Blockhash und andere Informationen sehen:
Im Abschnitt "Account Input" sind alle an der aktuellen Transaktion beteiligten Accounts aufgeführt, zusammen mit ihren Merkmalen in der Transaktion. Wir sehen, dass neben dem Absender und den Programm-Account-Adressen auch zwei Native Programs und ein Sysvar-Account enthalten sind.
Da es sich um eine einfache Transaktion zur Programm-Erstellung handelt, enthält sie nur zwei Instruktionen. Der Empfänger der ersten Instruktion ist das Systemprogramm, das für die Erstellung des Programm-Accounts zuständig ist. Der Empfänger der zweiten Instruktion ist der BPF Loader, der einen Daten-Account erstellt, um den bereitgestellten eBPF-Code zu speichern und seine Adresse in das Datenfeld des Programm-Accounts zu schreiben.
Schlussfolgerung
Smart Contracts auf Solana werden in Rust entwickelt und laufen auf der eBPF-virtuellen Maschine. Solana folgt dem Account-Modell, bei dem On-Chain-Accounts eine ausreichende Miete aufrechterhalten müssen, um die Entfernung von Daten zu vermeiden. Eine Transaktion besteht aus einer oder mehreren Instruktionen, die alle benötigten Accounts definieren und so die parallele Verarbeitung und die Erhöhung des Durchsatzes bei gleichzeitiger Reduzierung der Latenz ermöglichen. Diese Funktionen zusammen haben zur schnellen Entwicklung von Solana beigetragen und es zu einer der bevorzugten Blockchains gemacht.
