Einführung
Im Jahr 2024 erlebte Solana einen dramatischen Aufschwung, wobei der Total Value Locked (TVL) von einer Milliarde USD zu Jahresbeginn auf knapp fünf Milliarden USD anstieg und es zur viertgrößten öffentlichen Blockchain machte.
Im Vergleich zu Ethereum bietet Solana den Nutzern eine überlegene Erfahrung mit höheren Geschwindigkeiten und niedrigeren Kosten. Der auf Proof of History basierende Konsensmechanismus und das asynchrone Transaktionsverarbeitungsmodell bieten Entwicklern einen hohen Transaktionsdurchsatz und niedrige Latenz, was es zu einer bevorzugten Plattform für alle Arten von dezentralisierten Anwendungen macht.
BlockSec hat die Serie „Solana Vereinfacht" speziell geplant, die grundlegende Konzepte von Solana, praktische Leitfäden zur Analyse von Solana-Transaktionen und Tutorials zum Schreiben von Solana-Smart-Contracts umfasst.
Als erster Artikel dieser Serie wird dieser Text die Schlüsselkonzepte im Solana-Netzwerk eingehend beleuchten, einschließlich seiner Betriebsmechanismen, des Kontomodells und der Transaktionen, und damit die Grundlage für das Schreiben korrekter und effizienter Smart Contracts in Solana legen.
eBPF: Der Grundstein der Solana-Transaktionsausführung
Um Smart Contracts schreiben und ausführen zu können, 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 sich dafür entschieden, bestehende fortschrittliche Technologien vollständig zu nutzen. Die eBPF-Virtual-Machine (extended Berkeley Packet Filter), die ursprünglich zur Erweiterung der Linux-Kernel-Funktionalitäten entwickelt wurde, wurde von Solana als zugrunde liegende 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, was es ermöglicht, Bytecode in Maschinenanweisungen zu übersetzen, die der Prozessor direkt ausführen kann. Diese Fähigkeit steigert die Programmeffizienz erheblich.
Darüber hinaus verfügt eBPF über einen effizienten Befehlssatz und eine ausgereifte Infrastruktur. Entwickler können Smart Contracts in der Sprache Rust erstellen. Durch Nutzung des eBPF-Backends des LLVM-Compiler-Frameworks können die Rust-Programme direkt in eBPF-Bytecode kompiliert werden.
Solanas Kontomodell
Solana-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 betrachtet werden. Die Schlüssel in dieser Datenbank sind die Kontoadressen. Bei „Wallet"-Konten (d. h. Konten, die von Solana-Nutzern direkt über öffentlich-private Schlüsselpaare kontrolliert werden) sind diese Adressen öffentliche Schlüssel, die mit dem Ed25519-Signaturverfahren generiert wurden. Die Werte in der Datenbank bestehen aus spezifischen Details jedes Kontos, einschließlich des Guthabens 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 Erläuterung zu jedem:
-
Data-Feld: Dieses Feld speichert die mit dem Konto verbundenen Daten. Wenn das Konto ein Programm ist (d. h. ein Smart Contract), werden darin die eBPF-Bytecodes gespeichert. Andernfalls wird das Datenformat im Allgemeinen vom Kontoersteller definiert. -
Executable-Feld: Dieses Feld gibt an, ob das Konto ein Programm ist. Es ist wichtig zu beachten, dass Programme in Solana, anders als bei Ethereum, aktualisiert werden können. -
Lamports-Feld: Dieses Feld zeichnet das Guthaben der Solana-Token im Konto auf. Lamports sind tatsächlich 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 System Program, 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 (jedoch kann jeder 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. Mit der Aktualisierung des Solana-Netzwerks 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 System Program bietet Entwicklern eine Reihe von Anweisungen, von denen jede eine eigenständige Aufgabe ausführt. Beispielsweise können Entwickler die CreateAccount-Anweisung verwenden, um neue Konten zu erstellen, oder die Transfer-Anweisung, um Lamports an andere Konten zu übertragen.
Ein weiteres häufiges Native Program ist das BPF Loader-Programm. Es ist der Eigentümer aller anderen Programmkonten und verantwortlich für die Bereitstellung, Aktualisierung und Ausführung benutzerdefinierter Programme. Wenn ein „Wallet"-Konto ein von ihm bereitgestelltes Programm aktualisieren muss, erfolgt dies tatsächlich durch Delegation an das BPF Loader-Programm, da nur der Eigentümer eines Programms die direkte Berechtigung zur Datenänderung hat.
Neben Native Programs bietet Solana auch eine Reihe von Konten, die als Sysvars bekannt sind. Diese Konten stellen Programmen auf Solana Informationen und globale Variablen zum aktuellen Zustand des Solana-Netzwerks bereit, wie z. B. die aktuelle Uhrzeit und den neuesten Block-Hash.
Konto-Miete
Auf der Solana-Blockchain muss jedes Konto eine bestimmte Anzahl von Lamports als Mindestguthaben halten, bekannt als Miete. Anders als die Miete im echten Leben ist die Miete auf Solana rückforderbar. Um sicherzustellen, dass die Daten in einem Konto auf 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, es wird auf genau null reduziert. Das Senken des Guthabens auf null zeigt an, dass die Miete des Kontos zurückgefordert wurde, und am Ende der Transaktion löscht Solana die entsprechenden Kontodaten im Garbage-Collection-Prozess.
🧐 Solana-Konten in Solana-Scans anzeigen
Um die oben genannten Konzepte besser zu verstehen, haben wir Solanas „Hello World"-Projekt verwendet, um ein Programmkonto bereitzustellen, das mit dem Solana-Blockchain-Explorer Solscan angezeigt werden kann.
Wie im obigen Bild zu sehen ist, können wir zunächst erkennen, 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 das von uns erstellte Konto ein Programm ist, ist sein Executable-Feld auf „Yes" gesetzt.
Sie könnten verwirrt sein, dass das Feld Executable Data eine Adresse anstelle eines eBPF-Programms enthält. Wie bereits erwähnt, erlaubt Solana Programmaktualisierungen, die tatsächlich durch ein „Proxy"-Muster implementiert werden. Da anfänglich keine direkten Änderungen am Programmkonto erlaubt sind, erstellt Solana ein separates Datenkonto zur Speicherung des eBPF-Programms, 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. Mit Solscan können wir das Datenkonto anzeigen und feststellen, dass es als „Program Executable Data Account" gekennzeichnet ist und sein Data-Feld das eigentliche Programm enthält.
Das Owner-Feld im Abschnitt „More Info" ist der BPF Loader, was mit dem zuvor Erwähnten übereinstimmt.
Jemandem könnte auffallen, dass das letzte Feld von „Overview" Upgrade Authority ist, das in der AccountInfo nicht vorhanden ist. Was bedeutet das?
Wie bereits erwähnt, delegiert das „Wallet"-Konto Programmaktualisierungen an den BPF Loader. Vor der Aktualisierung prü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, hat es keinen Platz, diese Information zu speichern. Daher legt Solana sie in das Data-Feld des Datenkontos. Deshalb gibt es ein Upgrade Authority-Feld in „Overview", das tatsächlich die Wallet-Adresse ist, die das Programm bereitgestellt hat.
Das folgende Bild zeigt die Beziehung zwischen dem Programmkonto und dem Datenkonto. Beachten Sie, dass das Data-Feld des Datenkontos sowohl die Wallet-Adresse als auch den eBPF-Code enthält.
Transaktionen und Anweisungen in Solana
In Solana führen Benutzer Programme durch das Auslösen von Transaktionen aus. Ein besonderes Merkmal von Solana ist seine Fähigkeit, diese Transaktionen parallel auszuführen, was ein wesentlicher Grund für seine blitzschnellen Transaktionsgeschwindigkeiten ist. Lassen Sie uns nun genauer betrachten, wie Transaktionen in Solana gestaltet 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 geben alle an einer Transaktion beteiligten Konten und ihre Eigenschaften während der Transaktion an, einschließlich 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 Zustand schreiben.
Der Recent Blockhash fungiert als Zeitstempel für die Transaktion. Wenn der Blockhash einer Transaktion mehr als 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, gibt den Empfänger der Anweisung an, also 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 abgelegt, und das Feld speichert nur einen u8-Index, der auf die Adresse im Array zeigt.
Ä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. Dies bedeutet, dass sie entweder vollständig abgeschlossen wird, wobei alle Anweisungen erfolgreich verarbeitet werden, oder insgesamt fehlschlägt. 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 das Programmkonto zuvor erstellt hat. Im Abschnitt „Overview" können Sie die Solana-Transaktionssignatur, den neuesten 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 Programmerstellungstransaktion handelt, enthält sie nur zwei Anweisungen. Der Empfänger der ersten Anweisung ist das System Program, 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-Virtual-Machine ausgeführt. Solana folgt dem Kontomodell, bei dem On-Chain-Konten genug Miete aufrechterhalten müssen, um zu verhindern, dass Daten entfernt werden. Eine Transaktion besteht aus einer oder mehreren Anweisungen, die alle erforderlichen Konten definieren und so eine parallele Verarbeitung ermöglichen sowie den Durchsatz steigern und die Antwortlatenz reduzieren. Diese Merkmale haben gemeinsam zur rasanten Entwicklung von Solana beigetragen und es zu einer der bevorzugten Blockchains gemacht.
