Einleitung
Im Jahr 2024 erlebte Solana einen dramatischen Aufschwung, wobei der Total Value Locked (TVL) von einer Milliarde US-Dollar zu Beginn des Jahres auf fast fünf Milliarden US-Dollar anstieg, was es zur viertgrößten öffentlichen Blockchain macht.
Im Vergleich zu Ethereum bietet Solana den Nutzern eine überlegene Erfahrung mit schnelleren Geschwindigkeiten und geringeren Kosten. Der auf Proof of History basierende Konsensmechanismus und das asynchrone Transaktionsverarbeitungsmodell bieten Entwicklern einen hohen Transaktionsdurchsatz und niedrige Latenzzeiten, was es zu einer bevorzugten Plattform für alle Arten von dezentralen Anwendungen macht.
BlockSec hat speziell die Serie "Solana Simplified" 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 sich dieser Text mit den Schlüsselkonzepten innerhalb des Solana-Netzwerks befassen, einschließlich seiner Betriebsmechanismen, seines Kontomodells und seiner Transaktionen, um die Grundlage für das Schreiben korrekter und effizienter Smart Contracts in Solana zu schaffen.
eBPF: Der Eckpfeiler 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 normalerweise 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 zugrunde liegende 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. Eine solche 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 Rust-Sprache erstellen. Durch die Nutzung des eBPF-Backends des LLVM-Compiler-Frameworks können die Rust-Programme direkt in eBPF-Bytecode kompiliert werden.
Solanas Kontenmodell
Solanas Kontostruktur
Daten werden auf Solana in Form von Konten 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 Kontoadressen. Für "Wallet"-Konten (d.h. Konten, die direkt von Solana-Nutzern über öffentliche/private Schlüsselpaare gesteuert werden) sind diese Adressen öffentliche Schlüssel, die mit dem Ed25519-Signatursystem generiert wurden. Die Werte in der Datenbank bestehen aus spezifischen Details jedes Kontos, einschließlich des Saldos und anderer relevanter Informationen.
Solana verwendet die folgende Struktur, bekannt als AccountInfo, um ein Konto zu beschreiben.
Die AccountInfo für jedes Konto enthält vier Felder. Hier ist eine Erklärung für jedes:
-
Data-Feld: Dieses Feld speichert die Daten, die mit dem Konto zusammenhängen. Wenn das Konto ein Programm (d.h. ein Smart Contract) ist, speichert es den eBPF-Bytecode. Andernfalls wird das Datenformat in der Regel vom Kontenersteller definiert.
-
Executable-Feld: Dieses Feld wird verwendet, um anzuzeigen, ob das Konto ein Programm ist. Es ist wichtig zu beachten, dass Programme in Solana, im Gegensatz zu Ethereum, aktualisiert werden können.
-
Lamports-Feld: Dieses Feld speichert den Saldo der Solana-Token auf dem Konto. Lamports sind eigentlich die kleinste Einheit des SOL-Tokens (1 SOL = 1 Milliarde Lamports).
-
Owner-Feld: Dieses Feld gibt den Eigentümer des Kontos an. In Solana hat jedes Konto einen "Owner". Zum Beispiel ist der Eigentümer aller "Wallet"-Konten das Systemprogramm, ein spezielles Konto im Solana-Netzwerk, das für Funktionen wie die Kontoerstellung zuständig ist. Der Kontoeigentümer ist der einzige, der Kontodaten ändern und Lamports vom Saldo abziehen kann (jeder kann jedoch Lamports erhöhen, indem er Gelder auf das Konto überweist).
Vordefinierte Solana-Konten
Solana verfügt über eine Reihe vordefinierter ausführbarer Programme, 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 oft 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 Konten zu erstellen, oder die Anweisung Transfer, um Lamports auf andere Konten zu übertragen.
Ein weiteres häufiges Native Program ist das BPF Loader-Programm. Es ist der Eigentümer aller anderen Programm-Konten und für die Bereitstellung, Aktualisierung und Ausführung benutzerdefinierter Programme zuständig. Wenn ein "Wallet"-Konto ein von ihm bereitgestelltes Programm aktualisieren muss, wird dies tatsächlich durch Delegation an das BPF Loader-Programm durchgeführt, da nur der Eigentümer eines Programms die direkte Befugnis hat, Daten zu ändern.
Neben den Native Programs bietet Solana auch eine Reihe von Konten, die als Sysvars bekannt sind. Diese Konten versorgen Programme auf Solana mit Informationen und globalen Variablen, die sich auf den aktuellen Zustand des Solana-Netzwerks beziehen, wie z. B. die aktuelle Uhrzeit und den letzten Blockhash.
Kontomiete (Account Rent)
Auf der Solana-Blockchain muss jedes Konto einen bestimmten Betrag an Lamports als Mindestsaldo aufrechterhalten, 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 Konto in der Kette verfügbar sind, muss das Konto einen angemessenen Betrag an Lamports halten. Die Höhe der Miete hängt von der Größe der vom Konto belegten Daten ab.
Jede Transaktion, die versucht, den Kontostand 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 Kontos erstattet wurde, und am Ende der Transaktion wird Solana die Daten des entsprechenden Kontos im Rahmen der Garbage Collection löschen.
🧐 Solana-Konten in Solana Scans anzeigen
Um die oben genannten Konzepte besser zu verstehen, haben wir das "Hello World"-Projekt von Solana verwendet, um ein Programm-Konto bereitzustellen, das mit dem Solana-Blockchain-Explorer Solscan eingesehen werden kann.
Wie in der obigen Abbildung gezeigt, können wir zunächst sehen, dass das Konto als "Program" gekennzeichnet wurde. Ein Teil der Lamports wurde vom Saldo des Absenders als Miete für dieses Konto abgezogen, daher ist das Feld SOL Balance nicht leer. Darüber hinaus ist, da das von uns erstellte Konto ein Programm ist, sein Feld Executable auf Ja gesetzt.
Sie könnten verwirrt sein, dass das Feld Executable Data eine Adresse und keinen eBPF-Programmcode speichert. Wie bereits erwähnt, erlaubt Solana Programmaktualisierungen, und dies wird tatsächlich über ein "Proxy"-Muster implementiert. Da direkte Änderungen am Programm-Konto zunächst nicht erlaubt sind, erstellt Solana ein separates Datenkonto zur Speicherung des eBPF-Programms, während das Datenfeld im Programm-Konto nur die Adresse dieses Datenkontos speichert.
Immer wenn eine Aktualisierung des Programms erforderlich ist, muss nur das Datenfeld des Datenkontos geändert werden. Bei der Ansicht des Datenkontos mit Solscan stellen wir fest, dass es 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 früheren Ausführungen übereinstimmt.
Jemand bemerkt möglicherweise, dass das letzte Feld von "Overview" Upgrade Authority ist, das nicht in AccountInfo vorhanden ist. Was bedeutet das?
Wie bereits erwähnt, delegiert das "Wallet"-Konto Programmaktualisierungen an den BPF Loader. Vor der Aktualisierung verifiziert der BPF Loader, ob der Delegator das Konto ist, das das Programm ursprünglich bereitgestellt hat. Da der Owner des Programm-Kontos bereits auf BPF Loader gesetzt ist, hat er keinen Platz mehr, um diese Informationen zu speichern. Daher legt Solana sie in das Datenfeld des Datenkontos. 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-Konto und dem Datenkonto. Beachten Sie, dass das Datenfeld des Datenkontos sowohl die Wallet-Adresse als auch den eBPF-Code enthält.
Transaktionen und Anweisungen in Solana
Auf Solana führen Benutzer Programme durch die 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. Schauen wir uns nun genauer an, 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 setzt sich aus vier Teilen zusammen, wie unten dargestellt.
Der Header und das Compact Array of Account Addresses legen alle an einer Transaktion beteiligten Konten und deren Eigenschaften während der Transaktion fest, einschließlich der Frage, ob das Konto ein Unterzeichner ist und ob es während der Ausführung beschreibbar ist. Mit diesen Informationen kann Solana die von den Unterzeichnerkonten bereitgestellten Signaturen überprüfen und Transaktionen parallel verarbeiten, solange diese Transaktionen keine Konten 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-Konto 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 im Compact Array of Account Addresses der Transaktionsnachricht platziert, und das Feld speichert nur einen u8-Index, der auf die Adresse im Array verweist.
Ähnlich wie das erste Feld speichert das zweite Feld Kontoadressen-Indizes, bekannt als Compact Array of Account Address Indexes. Dieses Array gibt alle an dieser Anweisung beteiligten Konten 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, dass sie entweder vollständig mit allen erfolgreich verarbeiteten Anweisungen abgeschlossen wird oder vollständig fehlschlägt. Es wird keine Situation geben, in der einige Anweisungen verarbeitet und andere nicht.
🧐 Solana-Transaktionen in Solana Scans anzeigen
Wir verwenden einen weiteren Solana-Explorer, um die Transaktion anzuzeigen, die zuvor das Programm-Konto erstellt hat. Im Abschnitt "Overview" können Sie die Solana-Transaktionssignatur, den aktuellen Blockhash und andere Informationen sehen:
Im Abschnitt "Account Input" sind alle an der aktuellen Transaktion beteiligten Konten zusammen mit ihren Eigenschaften in der Transaktion aufgeführt. Wir sehen, dass neben dem Absender- und Programm-Konto-Adressen auch zwei Native Programs und Sysvar-Konten enthalten sind.
Da es sich um eine einfache Transaktion zur Programmerstellung handelt, enthält sie nur zwei Anweisungen. Der Empfänger der ersten Anweisung ist das Systemprogramm, das für die Erstellung des Programm-Kontos zuständig ist. Der Empfänger der zweiten Anweisung ist der BPF Loader, der ein Datenkonto erstellt, um den bereitgestellten eBPF-Code zu speichern und dessen Adresse in das Datenfeld des Programm-Kontos zu schreiben.
Schlussfolgerung
Smart Contracts auf Solana werden in Rust entwickelt und laufen auf der eBPF-virtuellen Maschine. Solana folgt dem Kontenmodell, bei dem On-Chain-Konten über ausreichende Miete verfügen müssen, um zu verhindern, dass Daten entfernt werden. Eine Transaktion besteht aus einer oder mehreren Anweisungen, die alle erforderlichen Konten definieren, was eine parallele Verarbeitung ermöglicht und den Durchsatz erhöht, während die Latenzzeiten reduziert werden. Diese Funktionen haben zusammen zur rasanten Entwicklung von Solana beigetragen und es zu einer der bevorzugten Blockchains gemacht.
