Einleitung
Im Jahr 2024 erlebte Solana einen dramatischen Aufschwung: Der Total Value Locked (TVL) stieg von einer Milliarde USD zu Jahresbeginn auf fast fünf Milliarden USD, was Solana zur viertgrößten öffentlichen Blockchain machte.
Im Vergleich zu Ethereum bietet Solana den Nutzern eine überlegene Erfahrung mit höheren Geschwindigkeiten und geringeren Kosten. Der auf „Proof of History“ basierende Konsensmechanismus und das asynchrone Transaktionsverarbeitungsmodell bieten Entwicklern einen hohen Transaktionsdurchsatz und eine niedrige Latenz, was sie 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 befasst sich dieser Text mit den Schlüsselkonzepten innerhalb des Solana-Netzwerks, einschließlich seiner Betriebsmechanismen, des Kontomodells und der Transaktionen, um das Fundament für das Schreiben korrekter und effizienter Smart Contracts in Solana zu legen.
eBPF: Der Grundpfeiler der Solana-Transaktionsausführung
Um Smart Contracts zu schreiben und auszuführen, 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 sich Solana dafür entschieden, bestehende fortschrittliche Technologien voll auszuschöpfen. Die eBPF- (extended Berkeley Packet Filter) virtuelle Maschine, die ursprünglich für die Erweiterung von Linux-Kernel-Funktionalitäten entwickelt wurde, wurde von Solana als zugrunde liegende Ausführungsumgebung gewählt.
Welche Vorteile bietet eBPF gegenüber der EVM?
Im Gegensatz zur EVM, die auf interpretierte Ausführung beschränkt ist, unterstützt eBPF die Just-In-Time (JIT)-Kompilierung, wodurch Bytecode in Maschinenbefehle übersetzt werden kann, die der Prozessor direkt ausführen kann. Diese Fähigkeit erhöht die Programmeffizienz erheblich.
Darüber hinaus zeichnet sich eBPF durch einen effizienten Befehlssatz und eine ausgereifte Infrastruktur aus. Entwickler können Smart Contracts unter Verwendung 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 Kontomodell
Aufbau von Solana-Konten
Daten werden auf Solana in Form von Konten gespeichert. Wie unten dargestellt, kann man sich alle Daten innerhalb von Solana als eine riesige Key-Value-Datenbank vorstellen. Die Schlüssel in dieser Datenbank sind die Kontoadressen. Bei „Wallet“-Konten (d. h. Konten, die direkt von Solana-Nutzern über öffentliche-private Schlüsselpaare gesteuert werden) sind diese Adressen öffentliche Schlüssel, die unter Verwendung des Ed25519-Signatursystems generiert werden. Die Werte in der Datenbank bestehen aus spezifischen Details jedes Kontos, einschließlich des Guthabens und anderer relevanter Informationen.
Solana verwendet die folgende Struktur namens AccountInfo, um ein Konto zu beschreiben.
Die AccountInfo für jedes Konto enthält vier Felder. Hier ist eine Erläuterung der einzelnen Felder:
-
Data-Feld: Dieses Feld speichert die Daten, die sich auf das Konto beziehen. Wenn das Konto ein Programm ist (d. h. ein Smart Contract), speichert es den eBPF-Bytecode. Andernfalls wird das Format der Daten im Allgemeinen vom Kontoersteller definiert. -
Executable-Feld: Dieses Feld gibt an, ob das Konto ein Programm ist. Es ist wichtig anzumerken, dass Programme in Solana im Gegensatz zu Ethereum aktualisiert werden können. -
Lamports-Feld: Dieses Feld zeichnet das Guthaben der Solana-Token auf dem Konto auf. Lamports sind 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 "Eigentümer". Zum Beispiel ist der Eigentümer aller "Wallet"-Konten das Systemprogramm, ein spezielles Konto im Solana-Netzwerk, das für Funktionen wie die Kontoerstellung verantwortlich ist. Der Kontoeigentümer ist der Einzige, der Kontodaten ändern und Lamports vom Guthaben abziehen kann (jeder kann jedoch Lamports durch Überweisungen auf das Konto erhöhen).
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. Während das Solana-Netzwerk aktualisiert wird, können auch diese vordefinierten Programme 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 CreateAccount-Anweisung verwenden, um neue Konten zu erstellen, oder die Transfer-Anweisung, um Lamports auf andere Konten zu übertragen.
Ein weiteres gängiges Native Program ist das BPF Loader-Programm. Es ist der Eigentümer aller anderen Programmkonten und für die Bereitstellung, Aktualisierung und Ausführung eigener Programme verantwortlich. Wenn ein "Wallet"-Konto ein bereitgestelltes Programm aktualisieren muss, geschieht dies durch Delegierung 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 eine Reihe von Konten an, die als Sysvars bekannt sind. Diese Konten stellen Programmen auf Solana Informationen und globale Variablen zur Verfügung, die sich auf den aktuellen Status des Solana-Netzwerks beziehen, wie z. B. die aktuelle Uhrzeit und der letzte Block-Hash.
Kontomiete (Rent)
Auf der Solana-Blockchain muss jedes Konto eine bestimmte Anzahl von Lamports als Mindestguthaben vorhalten, was als Miete bezeichnet wird. Im Gegensatz zur Miete im echten Leben ist die Miete auf Solana rückforderbar. Um sicherzustellen, dass die Daten eines Kontos in der Chain verfügbar sind, muss das Konto eine angemessene Menge an Lamports halten. Die Höhe der Miete hängt von der Größe der vom Konto belegten Daten ab.
Jede Transaktion, die versucht, das Kontoguthaben unter den Mietbetrag zu senken, schlägt fehl, es sei denn, sie senkt das Guthaben auf genau Null. Das Senken des Guthabens auf Null zeigt an, dass die Miete des Kontos zurückgefordert wurde, und am Ende der Transaktion bereinigt Solana die Daten des entsprechenden Kontos im Garbage-Collection-Prozess.
🧐 Betrachten von Solana-Konten in Solana Scans
Um die oben genannten Konzepte besser zu verstehen, haben wir Solanas "Hello World"-Projekt verwendet, um ein Programmkonto bereitzustellen, das mit dem Blockchain-Explorer von Solana, Solscan, eingesehen werden kann.
Wie in der Abbildung oben zu sehen ist, können wir zunächst feststellen, dass das Konto als "Program" gekennzeichnet wurde. Ein Teil der Lamports wurde vom Guthaben des Absenders als Miete für dieses Konto abgezogen, daher ist das Feld SOL Balance nicht leer. Da es sich bei dem von uns erstellten Konto zudem um ein Programm handelt, ist sein Feld Executable auf Yes gesetzt.
Sie könnten verwirrt sein, dass das Feld Executable Data eine Adresse speichert und kein eBPF-Programm. Wie bereits erwähnt, erlaubt Solana Programm-Updates, und dies wird tatsächlich durch ein "Proxy"-Muster implementiert. Da direkte Änderungen am Programmkonto zunächst nicht zulässig sind, erstellt Solana ein separates Datenkonto, um das eBPF-Programm zu speichern, während das Data-Feld im Programmkonto nur die Adresse dieses Datenkontos speichert.
Wann immer eine Aktualisierung des Programms erforderlich ist, muss nur das Data-Feld des Datenkontos geändert werden. Wenn man Solscan verwendet, um das Datenkonto einzusehen, kann man feststellen, dass es als "Program Executable Data Account" markiert ist und sein Data-Feld das eigentliche Programm speichert.
Das Feld Owner im Abschnitt "More Info" ist der BPF Loader, was mit dem oben Erwähnten übereinstimmt.
Manchem könnte auffallen, dass das letzte Feld der "Overview" Upgrade Authority ist, welches in der AccountInfo nicht vorhanden ist. Was bedeutet das?
Wie zuvor erwähnt, delegiert das "Wallet"-Konto Programm-Updates an den BPF Loader. Vor der Aktualisierung überprüft der BPF Loader, ob der Delegierende das Konto ist, das das Programm ursprünglich bereitgestellt hat. Da der Eigentümer des Programmkontos bereits auf BPF Loader gesetzt ist, gibt es keinen Platz, um diese Information zu speichern. Daher legt Solana sie in das Data-Feld des Datenkontos. Deshalb gibt es ein Upgrade Authority-Feld in der "Overview", und es ist tatsächlich die Wallet-Adresse, die das Programm bereitgestellt hat.
Das Bild unten zeigt die Beziehung zwischen dem Programmkonto und dem Datenkonto. Beachten Sie, dass das Data-Feld des Datenkontos sowohl aus der Wallet-Adresse als auch aus dem eBPF-Code besteht.
Transaktionen und Anweisungen in Solana
In Solana führen Benutzer Programme aus, indem sie Transaktionen ausgeben. Ein einzigartiger Aspekt von Solana ist die Fähigkeit, diese Transaktionen parallel auszuführen, was ein Hauptgrund für die 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 spezifizieren alle an einer Transaktion beteiligten Konten und ihre Eigenschaften während der Transaktion, 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 verifizieren und Transaktionen parallel verarbeiten, solange diese Transaktionen keine Konten enthalten, die in denselben Status 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 Programmkonto bereitgestellt wird. Jede Anweisung besteht aus drei Feldern, wie unten dargestellt.
Das erste Feld, Program ID Index, spezifiziert den Empfänger der Anweisung, 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 spezifiziert alle an dieser Anweisung beteiligten Konten.
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 angegebenen Reihenfolge verarbeitet und die atomare Ausführung der Transaktion garantiert. Das bedeutet, sie wird entweder vollständig abgeschlossen, wobei alle Anweisungen erfolgreich verarbeitet wurden, oder sie schlägt vollständig fehl. Es wird keine Situation geben, in der einige Anweisungen verarbeitet werden und andere nicht.
🧐 Betrachten von Solana-Transaktionen in Solana Scans
Wir verwenden einen weiteren Solana-Explorer, um die Transaktion anzusehen, die das Programmkonto früher erstellt hat. Im Abschnitt Overview können Sie die Signatur der Solana-Transaktion, 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 aufgelistet. Wir können sehen, dass neben den Adressen des Absenders und des Programmkontos auch zwei Native Programs und Sysvar-Konten einbezogen wurden.
Da es sich um eine einfache Programm-Erstellungstransaktion handelt, enthält sie nur zwei Anweisungen. Der Empfänger der ersten Anweisung ist das Systemprogramm, das für die Erstellung des Programmkontos verantwortlich 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 Data-Feld des Programmkontos schreibt.
Fazit
Smart Contracts auf Solana werden in Rust entwickelt und auf der eBPF-virtuellen Maschine ausgeführt. Solana folgt dem Kontomodell, bei dem On-Chain-Konten genügend Miete vorhalten müssen, um zu verhindern, dass Daten gelöscht 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 gleichzeitig die Antwortlatenz reduziert wird. Diese Funktionen haben zusammen zur schnellen Entwicklung von Solana beigetragen und es zu einer der bevorzugten Blockchains gemacht.
