Einführung
Im Jahr 2024 erlebte Solana einen dramatischen Aufschwung, wobei der Total Value Locked (TVL) von einer Milliarde US-Dollar zu Jahresbeginn auf fast fünf Milliarden US-Dollar anstieg und damit zur viertgrößten öffentlichen Blockchain wurde.
Im Vergleich zu Ethereum bietet Solana den Nutzern ein überlegenes Erlebnis mit schnelleren Geschwindigkeiten und geringeren Kosten. Der auf Proof of History basierende Konsensmechanismus und das asynchrone Transaktionsverarbeitungsmodell bieten Entwicklern einen hohen Transaktionsdurchsatz und 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 dieser Serie wird dieser Text auf die Schlüsselkonzepte innerhalb des Solana-Netzwerks eingehen, einschließlich seiner Betriebsmechanismen, seines Account-Modells und seiner Transaktionen, um die Grundlage für das Schreiben korrekter und effizienter Smart Contracts in Solana zu legen.
eBPF: Der Eckpfeiler der Solana-Transaktionsausführung
Um Smart Contracts zu schreiben und auszuführen, benötigen Blockchains typischerweise 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 für die Erweiterung von Linux-Kernel-Funktionen entwickelt wurde, wurde von Solana ausgewählt, um als zugrundeliegende Ausführungsumgebung zu dienen.
Welche Vorteile bietet eBPF gegenüber der EVM?
Im Gegensatz zur EVM, die auf die interpretierte Ausführung beschränkt ist, unterstützt eBPF Just-In-Time (JIT)-Kompilierung, wodurch Bytecode in Maschinencode übersetzt werden kann, den der Prozessor direkt ausführen kann. Diese Fähigkeit erhöht die Programmeffizienz erheblich.
Darüber hinaus verfügt eBPF über einen effizienten Befehlssatz 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, kann alles, was sich auf Solana befindet, als eine riesige Schlüssel-Wert-Datenbank konzeptualisiert werden. Die Schlüssel in dieser Datenbank sind die Account-Adressen. Für "Wallet"-Accounts (d. h. Accounts, die direkt von Solana-Nutzern über öffentliche/private Schlüsselpaare gesteuert werden) sind diese Adressen öffentliche Schlüssel, die mit dem Ed25519-Signatursystem generiert werden. 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 zu jedem:
-
Data-Feld: Dieses Feld speichert die Daten, die mit dem Account zusammenhängen. Wenn der Account ein Programm (d. h. ein Smart Contract) ist, speichert es den eBPF-Bytecode. Andernfalls wird das Datenformat im Allgemeinen vom Account-Ersteller definiert. -
Executable-Feld: Dieses Feld gibt an, ob der Account ein Programm ist. Es ist wichtig zu beachten, dass Programme auf Solana im Gegensatz zu Ethereum aktualisiert werden können. -
Lamports-Feld: Dieses Feld speichert den Saldo von Solana-Tokens im Account. Lamports sind tatsächlich die kleinste Einheit des SOL-Tokens (1 SOL = 1 Milliarde Lamports). -
Owner-Feld: 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 der Einzige, der Account-Daten ändern und Lamports vom Guthaben abziehen kann (jeder kann jedoch Lamports erhöhen, indem er Gelder an den Account überweist).
Vordefinierte Solana-Accounts
Solana hat eine Reihe von vordefinierten ausführbaren Programmen, die als Native Programs bekannt sind und an festen Adressen bereitgestellt werden. Wenn das Solana-Netzwerk aktualisiert wird, können auch diese vordefinierten Programme aktualisiert werden. Sie dienen als APIs und Bibliotheksfunktionen und bieten spezifische Funktionalitäten im Solana-Netzwerk.
Innerhalb der Native Programs ist das System Program eines, mit dem Entwickler häufig interagieren. Das Systemprogramm bietet Entwicklern eine Reihe von Anweisungen, von denen jede eine unabhängige Aufgabe ausführt. Entwickler können beispielsweise die CreateAccount-Anweisung verwenden, um neue Accounts zu erstellen, oder die Transfer-Anweisung, um Lamports an andere Accounts zu übertragen.
Ein weiteres gängiges Native Program ist das BPF Loader-Programm. Es ist der Eigentümer aller anderen Programm-Accounts und verantwortlich für die Bereitstellung, Aktualisierung und Ausführung benutzerdefinierter Programme. 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 im Zusammenhang mit dem aktuellen Zustand des Solana-Netzwerks zur Verfügung, wie z. B. die aktuelle Uhr und den letzten Blockhash.
Account-Miete
Auf der Solana-Blockchain muss jeder Account einen Mindestbetrag an Lamports als Mindestguthaben halten, der als Miete bezeichnet wird. Im Gegensatz zur Miete im wirklichen Leben ist die Miete auf Solana erstattungsfähig. Um sicherzustellen, dass die Daten in einem Account in 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 Daten ab, die der Account einnimmt.
Jede Transaktion, die versucht, das Account-Guthaben unter den Mietbetrag zu senken, schlägt fehl, es sei denn, sie senkt das Guthaben auf genau Null. Das Senken des Guthabens auf Null bedeutet, dass die Miete des Accounts zurückerstattet wurde, und am Ende der Transaktion bereinigt Solana die Daten des entsprechenden Accounts im Rahmen der Garbage Collection.
🧐 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 über den Blockchain-Explorer von Solana, Solscan, angezeigt werden kann.
Wie im obigen Bild gezeigt, sehen wir zuerst, dass der Account als "Program" gekennzeichnet wurde. Ein Teil der Lamports wurde vom Guthaben 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 Yes gesetzt.
Sie sind vielleicht verwirrt, dass das Feld Executable Data eine Adresse anstelle eines eBPF-Programms 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 zunächst nicht zulässig 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.
Immer wenn ein Programm-Update benötigt wird, muss nur das Datenfeld des Daten-Accounts geändert werden. Bei der Ansicht des Daten-Accounts mit Solscan stellen wir fest, dass er als "Program Executable Data Account" gekennzeichnet ist und sein Data-Feld das eigentliche Programm enthält.
Das Feld Owner im Abschnitt "More Info" ist der BPF Loader, was mit dem zuvor Gesagten übereinstimmt.
Jemand bemerkt vielleicht, dass das letzte Feld von "Overview" Upgrade Authority lautet, das in der AccountInfo nicht vorhanden ist. Was bedeutet das?
Wie bereits erwähnt, delegiert der "Wallet"-Account Programm-Updates an den BPF Loader. Vor der Aktualisierung 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 auf den BPF Loader gesetzt ist, hat er keinen Platz, um diese Informationen zu speichern. Daher legt Solana sie 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 Anweisungen auf Solana
Auf Solana führen Benutzer Programme durch Ausgabe von Transaktionen aus. Ein einzigartiges Merkmal von Solana ist seine Fähigkeit, diese Transaktionen parallel auszuführen, was ein Hauptgrund für seine blitzschnellen Transaktionsgeschwindigkeiten ist. Nun werfen wir einen genaueren Blick darauf, wie Transaktionen auf 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 einer 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 fungiert als Zeitstempel für die Transaktion. Wenn der Blockhash einer Transaktion 150 Blöcke älter ist als der neueste Blockhash, 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 Anweisungen. Eine Anweisung löst im Wesentlichen die Ausführung einer Routine aus, die von einem Programm-Account bereitgestellt wird. Jede Anweisung besteht aus drei Feldern, wie unten dargestellt.
Das erste Feld, Program ID Index, gibt den Empfänger der Anweisung an, d. h. das On-Chain-Programm, das die Anweisung verarbeiten muss. Anstatt eine 32-Byte-Adresse zu speichern, wird diese Adresse in das Compact Array of Account Addresses der Transaktionsnachricht eingefügt, und das Feld speichert nur einen u8-Index, der auf die Adresse im Array verweist.
Ähnlich wie das erste Feld speichert das zweite Feld Account-Adressen-Indizes, bekannt als Compact Array of Account Address Indexes. Dieses Array gibt alle an dieser Anweisung beteiligten Accounts an.
Das letzte Feld ist ein Byte-Array, das die zusätzlichen Daten enthält, die das Programm zur Verarbeitung der Anweisung benötigt, wie z. B. Funktionsargumente.
Es ist wichtig zu beachten, dass Solana alle Anweisungen innerhalb einer Transaktion in der Reihenfolge verarbeitet und die atomare Ausführung der Transaktion garantiert. Das bedeutet, sie wird entweder vollständig abgeschlossen, wobei alle Anweisungen erfolgreich verarbeitet werden, oder sie schlägt insgesamt fehl. Es wird keine Situation geben, in der einige Anweisungen verarbeitet werden und andere nicht.
🧐 Solana-Transaktionen in Solana Scans anzeigen
Wir verwenden einen anderen Solana-Explorer, um die Transaktion anzuzeigen, die den Programm-Account zuvor erstellt hat. Im Abschnitt "Overview" sehen Sie die Solana-Transaktionssignatur, den aktuellen Blockhash und andere Informationen:
Im Abschnitt "Account Input" werden alle an der aktuellen Transaktion beteiligten Accounts mit ihren Eigenschaften in der Transaktion aufgelistet. 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 Erstellung eines Programms handelt, enthält sie nur zwei Anweisungen. Der Empfänger der ersten Anweisung ist das Systemprogramm, das für die Erstellung des Programm-Accounts zuständig ist. Der Empfänger der zweiten Anweisung 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 schreibt.
Fazit
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 genügend Miete aufrechterhalten müssen, um zu verhindern, dass Daten entfernt werden. Eine Transaktion besteht aus einer oder mehreren Anweisungen, die alle erforderlichen Accounts definieren und die parallele Verarbeitung ermöglichen, den Durchsatz erhöhen und gleichzeitig die Latenz reduzieren. Diese Funktionen zusammen haben zur schnellen Entwicklung von Solana beigetragen und es zu einer der bevorzugten Blockchains gemacht.
