So migrierst du von Ethereum zu Solana: Ein Leitfaden für Entwickler

Worum geht es in diesem Artikel?

Ethereum zählt zu den wichtigsten Innovationen der jüngeren Vergangenheit. Zum ersten Mal in der Geschichte verfügen wir über eine dezentrale, globale Plattform für gesellschaftliche Koordination, die zahlreiche Branchen revolutionieren könnte. Trotz dieser Bedeutung ist die Laufzeitumgebung von Ethereum, die Ethereum Virtual Machine (EVM), in ihrem aktuellen Zustand nicht für Anwendungen auf Verbraucherniveau ausgelegt. Das Netzwerk arbeitet mit einem einzelnen Thread und Gas und hat schwankende Gebühren. Solana hingegen ist ein Netzwerk mit hohem Durchsatz und geringer Latenz. Es bietet eine parallelisierte Infrastruktur mit niedrigen und vorhersehbaren Gebühren. Solana behebt die Einschränkungen der EVM direkt und verbessert deren ursprüngliches Design. Damit ist es eine überzeugende Wahl für Entwickler, die skalierbare und effiziente Anwendungen erstellen möchten.

Dieser Artikel ist ein umfassender Migrationsleitfaden für EVM-Entwickler, die auf Solana entwickeln möchten. Er behandelt die grundlegenden Unterschiede zwischen beiden Systemen und untersucht die Konsensmechanismen von Ethereum und Solana, ihre Transaktionsverarbeitung sowie die Sprachen zur Entwicklung von Smart Contracts. Anschließend geht es um das Account-Modell von Solana, das Accounts einheitlicher und vielseitiger behandelt. Der Artikel stellt außerdem Solang und Neon EVM vor, zwei Solidity-freundliche Tools, die die Entwicklung auf Solana verbessern.

Grundlegende Unterschiede

Dieser Abschnitt untersucht die entscheidenden Unterschiede zwischen Ethereum und Solana. Beide Blockchains wollen eine dezentrale Zustandsmaschine für die globale Koordination schaffen. Ihre Konsensmechanismen, Methoden zur Transaktionsverarbeitung und Sprachen für die Entwicklung von Smart Contracts unterscheiden sich jedoch deutlich. Ein genaueres Verständnis dieser grundlegenden Unterschiede verdeutlicht den entscheidenden Vorteil von Solana gegenüber Ethereum als äußerst leistungsfähige globale Zustandsmaschine.

Konsensmechanismen

Konsensmechanismen bilden die Grundlage jedes Blockchain-Netzwerks. Sie bestimmen, wie Transaktionen verifiziert und Blöcke sicher, effizient und dezentral zur Blockchain hinzugefügt werden. Sowohl Ethereum als auch Solana sind Proof-of-Stake-Netzwerke (PoS). Obwohl beide auf PoS basieren, unterscheiden sich ihre Ansätze zur Konsensfindung aufgrund ihrer Bestätigungsregeln.

Ethereum verwendet Gasper, eine Kombination aus Casper the Friendly Finality Gadget (Casper-FFG) und dem LMD-GHOST-Algorithmus zur Fork-Auswahl. Diese Kombination bildet den Konsensmechanismus, der Ethereum absichert.

Casper ist ein PoS-basiertes Finalitätssystem, das den Bestätigungsstatus eines Blocks auf „finalisiert“ hochstuft. Ein Block gilt auf Ethereum als finalisiert, wenn zwei Drittel des gesamten Stakes für seine Aufnahme stimmen und ein weiterer Block darauf aufgebaut wird. Da für die Finalität zwei Drittel des gesamten Stakes zustimmen müssen, dass ein Block kanonisch ist, kann ein Angreifer keine alternative finalisierte Chain erstellen, ohne zwei Drittel des gesamten Stakes zu besitzen oder zu manipulieren und mindestens ein Drittel durch Slashing zu vernichten. Casper ermöglicht es neuen Teilnehmern, sich zuverlässig mit der kanonischen Chain zu synchronisieren. 

LMD-GHOST ist ein Akronym für „Latest Message-Driven Greedy Heaviest Observed Sub-Tree“. Dieser Algorithmus entscheidet, welchem Fork von Ethereum gefolgt wird. Dazu wählt er den Fork aus, der von den Validatoren des Netzwerks die größte Unterstützung, also das höchste „Gewicht“, erhalten hat – daher „greedy heaviest sub-tree“. Anschließend stellt er sicher, dass nur die neueste Nachricht jedes Validators berücksichtigt wird. Jedes Mal, wenn Ethereum ein neuer Block vorgeschlagen wird, entscheiden die Validatoren anhand dieser Regel, ob er Teil der kanonischen Chain werden soll.

Im Vergleich dazu nutzt Solana Proof-of-History-Hashes (PoH), um einen Konsens zu erreichen. Trotz des missverständlichen Namens ist PoH kein Konsensalgorithmus. Es ist eine Methode, um Zeit in einem feindlichen Netzwerk nachzuweisen. Genauer gesagt handelt es sich um eine kryptografische Zeitstempelfunktion, mit der Nodes sich auf eine Reihenfolge von Ereignissen einigen können, ohne miteinander zu kommunizieren. Der Leader, also der Validator, der dem Ledger Einträge hinzufügt, versieht Blöcke mit Zeitstempeln. So weist er nach, dass seit dem letzten Block eine gewisse Zeit vergangen ist. 

Diese Zeitstempel erzeugen eine historische Aufzeichnung, da sie belegen, dass Daten zu einem bestimmten Zeitpunkt existierten. Die historische Aufzeichnung entsteht mithilfe einer sequenziellen, urbildresistenten Hash-Funktion, bei der jeder Hash von seinem Vorgänger abhängt. Verifiable Delay Functions (VDFs) spielen bei der Erzeugung dieser Hashes eine zentrale Rolle. Sie sorgen dafür, dass jeder Hash auf dem vorherigen aufbaut und die seitdem vergangene Zeit berücksichtigt. Durch die Integration von VDFs erhält der Hashing-Prozess eine zeitliche Dimension. Dadurch lässt sich auf Solana eine überprüfbare Folge von Ereignissen mit Zeitstempeln erstellen.

Nachdem wir geklärt haben, wie Solanas Proof-of-History-Mechanismus mithilfe kryptografischer Zeitstempel eine zuverlässige Ereignisfolge erstellt, müssen wir verstehen, wie er mit Solanas Konsensmechanismus Tower BFT zusammenarbeitet. Tower Byzantine Fault Tolerance (BFT) ist Solanas für PoH optimierte Variante des traditionellen Konsensmodells Byzantine Fault Tolerance. Tower BFT verwendet die von PoH erstellte historische Aufzeichnung als Referenzrahmen. So können Validatoren effizient und präzise über den Zustand des Ledgers abstimmen. Bei Tower BFT geben Validatoren Stimmen ab, die für lange Zeit gesperrt sind. Mit jeder weiteren Stimme steigt ihre Bindung. Dank PoH können Validatoren schneller fundierte Entscheidungen über den Zustand des Ledgers treffen, ohne miteinander kommunizieren zu müssen. Die Kombination aus PoH und Tower BFT beschleunigt den Konsens und erhöht die Sicherheit und Zuverlässigkeit des Netzwerks. Das Ergebnis ist eine skalierbare Blockchain-Umgebung mit hohem Durchsatz, in der Transaktionen schnell bestätigt werden.

Transaktionsverarbeitung und Ausführungsumgebungen

Die Effizienz und Skalierbarkeit einer Blockchain hängen hauptsächlich von ihrer Transaktionsverarbeitung und ihrer Ausführungsumgebung ab. Diese Faktoren bestimmen, wie schnell Transaktionen ausgeführt werden und wie kosteneffizient Abläufe im Netzwerk sind. Der Ansatz einer Blockchain zur Transaktionsverarbeitung und die Besonderheiten ihrer Ausführungsumgebungen beeinflussen die Entwicklererfahrung erheblich.

Die Laufzeitumgebung von Ethereum arbeitet als deterministische, Single-Thread-Stackmaschine, die als Ethereum Virtual Machine (EVM) bezeichnet wird. Sie verhält sich wie eine mathematische Funktion. Das heißt: Für eine bestimmte Eingabe erzeugt die EVM eine deterministische Ausgabe. Ethereum lässt sich sinnvoll über eine Zustandsübergangsfunktion definieren: f(S, T) = S’. Ausgehend von einem alten Zustand (S) und einem neuen Satz gültiger Transaktionen (T) erzeugt die EVM einen neuen gültigen Ausgabezustand (S’). Bei demselben Satz von Transaktionen erreicht die EVM immer denselben Endzustand. Das ist entscheidend, um die Konsistenz zwischen den Nodes des Netzwerks zu gewährleisten.

Die EVM verarbeitet Transaktionen sequenziell. Dadurch wird jede Transaktion in einer Umgebung ausgeführt, die den bis zu diesem Zeitpunkt aktuellen Zustand des Netzwerks exakt widerspiegelt. Die sequenzielle Ausführung ermöglicht genaue Berechnungen von Zustandsänderungen und Gas-Kosten. Diese Vorhersehbarkeit vermittelt Entwicklern und Nutzern ein klares Verständnis der Transaktionsergebnisse und -kosten.

Ethereum vereinfacht die Ausführungsumgebung für Smart Contracts durch ein Single-Thread-Ausführungsmodell. Entwickler profitieren von vorhersehbaren Zustandsänderungen, da jede Transaktion sequenziell verarbeitet wird. Dadurch ist die Entwicklungsumgebung von Ethereum für neue Entwickler vergleichsweise zugänglich: Sie können sich stärker auf die Logik ihrer Smart Contracts konzentrieren und müssen sich weniger mit den komplexen Details der Ausführung befassen. Diese Einfachheit erschwert jedoch die Skalierung. Die sequenzielle Verarbeitung begrenzt den Durchsatz des Netzwerks. Bei hoher Nachfrage kann das zu Überlastungen, längeren Wartezeiten für Transaktionen und höheren Gas-Gebühren führen. Da jede Transaktion Gas verbraucht, müssen Entwickler ihre Anwendungen auf effiziente Gas-Nutzung optimieren. Diese Optimierung verbessert die allgemeine Nutzererfahrung und wirkt Überlastungsphasen entgegen, in denen ineffizienter Code Anwendungen für durchschnittliche Nutzer unbrauchbar machen kann.

Solana-Entwickler müssen sich nicht wie Ethereum-Entwickler um die Optimierung der Gas-Nutzung kümmern. Solana ist als Zustandsmaschine mit hohem Durchsatz und geringer Latenz konzipiert, die als Solana Virtual Machine (SVM) bezeichnet wird. Ein wichtiger Bestandteil der SVM ist Sealevel. Diese Laufzeit-Engine verarbeitet Transaktionen parallel. Auf Solana teilt jede Transaktion der Laufzeit mit, welche Teile des Zustands sie bei der Ausführung lesen oder schreiben wird. Die Laufzeit verarbeitet konfliktfreie Transaktionen und Transaktionen, die denselben Zustand lesen, parallel. Sealevel optimiert die Ausführung von Smart Contracts, indem es die Transaktionslast auf mehrere Threads der Validator-Hardware verteilt. Während der Validator eine Transaktion auf einem Kern verarbeitet, kann er gleichzeitig eine weitere auf einem anderen Kern verarbeiten.

Die inhärente Parallelität von Solana senkt die Transaktionskosten erheblich. Solana-Transaktionen haben zwei Gebühren: eine Grundgebühr und eine Prioritätsgebühr. Die Grundgebühr ist auf 5000 Lamports pro Signatur festgelegt. Die meisten Transaktionen haben nur eine Signatur. Die Prioritätsgebühr ist optional und ermöglicht es, Transaktionen gegenüber anderen Transaktionen zu priorisieren. Der Scheduler priorisiert Transaktionen mit einer höheren Prioritätsgebühr nicht deterministisch. Transaktionsgebühren liegen häufig unter 0,001 USD. Die durchschnittliche Gebühr für Transaktionen ohne Abstimmung liegt zwischen 0,000005 und 0,00007 SOL. Die Obergrenze ist aufgrund der zuletzt gestiegenen Nutzung von Prioritätsgebühren höher als üblich. Beim aktuellen SOL-Preis von ~98,96 USD entspricht das ungefähr 0,000494 bis 0,006968 USD. 

Diese Gebühren sind außerdem vorhersehbar. Solana nutzt lokalisierte Gebührenmärkte, um die Nachfrage zu steuern. Der Blockspace ist so strukturiert, dass kein einzelner Aktivitätsschwerpunkt, etwa ein gehypter NFT-Mint, den Blockspace dominieren und die Gebühren im gesamten Netzwerk erhöhen kann. Höhere Gebühren betreffen nur Transaktionen, die auf einen bestimmten stark nachgefragten Bereich zugreifen wollen. Lokalisierte Gebührenmärkte ermöglichen Prioritätsgebühren, ohne umfassende Gas-Kriege auszulösen. Diese Lokalisierung unterscheidet sich von Gas-basierten Netzwerken wie Ethereum, in denen Transaktionen sequenziell verarbeitet werden und globale Überlastungen zu schwankenden Gebühren führen.

Ethereum ist eine Single-Thread-Laufzeitumgebung, die jeweils nur einen Contract verarbeitet. Moderne Multi-Core-Hardware wird derzeit nicht genutzt, wodurch die Validator-Hardware nicht vollständig ausgelastet ist. Der Wunsch, die Hardwareanforderungen für Nodes niedrig zu halten, schränkt die Transaktionsverarbeitung von Ethereum zusätzlich ein. Dank der parallelen Verarbeitung kann Solana dagegen mehr Transaktionen verarbeiten, indem es alle verfügbaren Kerne eines Validators nutzt. Zusammen mit lokalisierten Gebührenmärkten ist Solana eine wesentlich leistungsfähigere globale Zustandsmaschine. 

Sprachen für Smart Contracts

Die wichtigste Sprache für die Entwicklung von Smart Contracts auf Ethereum ist Solidity. Diese statisch typisierte Sprache mit geschweiften Klammern wurde für Smart Contracts entwickelt, die auf der EVM ausgeführt werden. Sie ist stark von JavaScript, C++ und Python beeinflusst. Entwickler, die mit diesen Sprachen vertraut sind, können sie daher leicht erlernen.

Yul ist eine hardwarenahe Zwischensprache, die für EVM-kompatible Blockchains optimiert ist. Yul gibt Entwicklern mehr Kontrolle über die Ausführung von Bytecode und eignet sich hervorragend zur Feinabstimmung des Gas-Verbrauchs und zur Verwaltung anderer Low-Level-Operationen. Entwickler können effizientere Contracts erstellen, indem sie direkt in Yul programmieren oder Yul als Kompilierungsziel verwenden.

Vyper ist eine beliebte Python-ähnliche Sprache, die Einfachheit und Sicherheit in den Mittelpunkt stellt. Sie bietet bewusst weniger Funktionen als Solidity, um Komplexität und potenzielle Sicherheitslücken zu reduzieren. Die Designphilosophie von Vyper priorisiert Lesbarkeit und Prüfbarkeit. Dieser Ansatz hat die Entwicklung ähnlicher Sprachen wie Fe sowie von Sprachen inspiriert, die zu Vyper kompiliert werden, etwa Dasy.

Rust ist die Lingua franca für die Entwicklung von Smart Contracts, die umgangssprachlich als Programme bezeichnet werden, auf Solana. Die Sprache ist schnell und speichereffizient und erreicht eine mit C++ vergleichbare Leistung. Diese Eigenschaften machen sie für die Entwicklung von Anwendungen in einem Netzwerk mit hohem Durchsatz und geringer Latenz geeignet. Das umfangreiche Typsystem und das Ownership-Modell von Rust gewährleisten Speicher- und Thread-Sicherheit. Dadurch müssen Entwickler zuverlässige und sichere Anwendungen erstellen. 

Rust hat für Entwickler ohne Erfahrung in der Systemprogrammierung zwar eine steile Lernkurve, ermöglicht dafür aber robusten und effizienten Code. Die meisten Entwickler nutzen für Rust Anchor. Anchor ist ein Framework mit klaren Konventionen, das die Programmentwicklung vereinfacht. Es reduziert Boilerplate-Code, führt verschiedene standardmäßige Sicherheitsprüfungen durch und optimiert die (De-)Serialisierung. Daher brauchst du für den Einstieg weniger fortgeschrittene Rust-Kenntnisse. Zur Einordnung: Die Anchor-Dokumentation empfiehlt, dass Nutzer mit den ersten neun Kapiteln des Rust Book vertraut sind, also die Grundlagen von Rust kennen. Solana Playground bietet mehrere Anchor-Tutorials für den Einstieg.

Rust ist zwar die bevorzugte Sprache, aber Entwickler sind nicht darauf beschränkt. Du kannst C, C++ und jede Sprache verwenden, die auf das BPF-Backend von LLVM abzielt, also jede Sprache, die zu BPF-Bytecode kompiliert werden kann. Entwickler, die mit Python-ähnlichen Sprachen wie Vyper vertraut sind, können mit Seahorse Lang Programme in Python schreiben. So profitieren sie von der einfachen Nutzung von Python und erhalten gleichzeitig dieselben Sicherheitsgarantien wie bei Rust. Für deinen Einstieg in die Programmierung auf Solana stehen mehrere hilfreiche Seahorse-Tutorials zur Verfügung, darunter die Seahorse University und das Seahorse Cookbook.

Entwickler, die von Ethereum zu Rust migrieren, sind nicht auf Rust beschränkt. Frameworks wie Anchor und Seahorse sind aufgrund ihrer Beliebtheit und Sicherheitsgarantien zwar empfehlenswert, aber nicht immer eine praktikable Option. Dank der jüngsten Entwicklungen von Solang und Neon Labs können Entwickler Solidity für die Programmentwicklung verwenden. Dafür stehen ein Compiler und eine EVM-kompatible Entwicklungsumgebung bereit. Solidity hat auf Solana ein Zuhause. Bevor wir mit der Programmentwicklung in Solidity beginnen, müssen wir uns genauer mit den Besonderheiten des Programmiermodells von Solana befassen. Das Account-Modell von Solana bildet die Grundlage für Programmentwicklung und Interaktionen im Netzwerk. Deshalb müssen Entwickler, die diesen Wechsel vollziehen, es verstehen.

Das Account-Modell verstehen

Ethereum unterteilt Accounts in zwei Hauptkategorien: extern kontrollierte Accounts (EOAs) und Contract-Accounts. EOAs sind der Standard-Accounttyp für Nutzer. Sie werden durch private Schlüssel kontrolliert und können Ether-Guthaben halten, Transaktionen senden und mit Contract-Accounts interagieren. Die Abläufe von Contract-Accounts werden dagegen durch den darin eingebetteten Smart-Contract-Code gesteuert. Sie können keine Transaktionen selbstständig initiieren und nur auf Transaktionen reagieren, die sie von EOAs oder anderen Contract-Accounts erhalten.

Solana verwendet ein einheitlicheres Account-Modell und behandelt Accounts als vielseitige Container, die Daten dauerhaft speichern. In diesem Modell kann jeder Account ein Programm sein. Dadurch verschwimmt die traditionelle Grenze zwischen einem Account und einem Smart Contract. Anders als bei Ethereum, wo Code und Zustand in einem einzigen Account kombiniert sind, sind Solana-Programme zustandslos. Sie speichern intern keinen Zustand. Stattdessen befinden sich alle für ihre Arbeit erforderlichen Daten in einem separaten Account, der mit einer Transaktion als Referenz übergeben wird. Durch die referenzbasierte Übergabe von Accounts kann eine einzige generische Programmbereitstellung mit verschiedenen Accounts interagieren. Das Account-Modell von Solana trennt Code und Daten und schafft so eine effizientere und modularere Entwicklungsumgebung. Das ist für Nutzer von Vorteil, die mit mehreren Protokollen interagieren möchten, ohne Assets zwischen verschiedenen Programmen zu verschieben. Auf Solana ist alles ein Account. 

Solana-Accounts lassen sich allgemein in ausführbare und nicht ausführbare Accounts einteilen. Vereinfacht gesagt können ausführbare Accounts Code ausführen. Nicht ausführbare Accounts dienen zur Datenspeicherung und können keinen Code ausführen, da sie keinen Code enthalten.

Ausführbare Accounts enthalten Programme. Programme können zusätzliche Accounts besitzen, aus anderen Accounts lesen oder ihnen Guthaben hinzufügen, Daten ändern oder ihre eigenen Accounts belasten. Ausführbare Accounts lassen sich weiter in On-Chain-Programme und native Programme unterteilen. On-Chain-Programme sind von Nutzern geschriebener Code, der im Netzwerk bereitgestellt wird. Ihre Upgrade Authority kann sie aktualisieren. Dabei handelt es sich normalerweise um den Account, der sie bereitgestellt hat. Native Programme sind eine spezielle Untergruppe ausführbarer Accounts. Sie entsprechen in etwa den vorkompilierten Contracts von Ethereum, bieten aber einen größeren Funktionsumfang. Diese Programme sind in den Kern von Solana integriert und stellen die Funktionen bereit, die Validatoren für ihren Betrieb benötigen. Ein Beispiel für ein natives Programm ist das System Program. Dieses Programm erstellt neue Accounts, weist Account-Daten Speicherplatz zu, ordnet Accounts Programmen zu, überträgt Lamports aus den von ihm kontrollierten Accounts und bezahlt Transaktionsgebühren. Eine vollständige Liste der nativen Programme findest du hier.

Unabhängig davon, ob sie ausführbar oder nicht ausführbar sind, haben alle Accounts dieselben Felder: 

• Ein lamports-Feld, das das native Guthaben eines Accounts in SOL erfasst
• Ein Datenfeld für das vom Account gespeicherte rohe Daten-Byte-Array
• Ein Owner-Feld, das angibt, welches Programm diesen Account ändern kann
• Ein Signer-Feld, das bei Transaktionen angibt, ob der Account Transaktionen genehmigen kann
• Ein Writable-Feld, das angibt, ob die Daten eines Accounts geändert werden können. Es ermöglicht die parallele Verarbeitung, indem in Transaktionen enthaltene Accounts als schreibgeschützt oder beschreibbar markiert werden
• Ein Executable-Feld, das angibt, ob ein Account ein Programm speichert
• Ein Rent-Epoch-Feld, das die nächste Epoche angibt, in der der Account Rent schuldet

Rent sind Speicherkosten, die Accounts auf Solana aktiv halten und dafür sorgen, dass sie im Speicher der Validatoren verbleiben. Accounts müssen dafür ein Mindestguthaben aufweisen. Rent reduziert eine übermäßige Aufblähung des Zustands, indem das Netzwerk ungenutzte oder unzureichend finanzierte Accounts letztlich zurückgewinnt. Aufgrund neuerer Änderungen gibt es im Mainnet keine Accounts mehr, die Rent bezahlen. Stattdessen müssen alle Accounts bei ihrer Erstellung von Rent befreit sein. Ein Account ist von Rent befreit, wenn sein Mindestguthaben den Rent-Zahlungen für zwei Jahre entspricht. Mit Tools wie Test Drive und dem Rent-Unterbefehl der Solana CLI kannst du schätzen, wie viel SOL ein Account benötigt, um von Rent befreit zu sein. Das unterscheidet sich vom System zur Ressourcenzuweisung bei Ethereum, wo gespeicherte Daten bestehen bleiben, sofern sie nicht ausdrücklich gelöscht werden. Der Ansatz von Solana bietet eine besser vorhersehbare Kostenstruktur für die Zustandsspeicherung und reduziert zugleich die Aufblähung des Zustands.

Adressen und Program Derived Addresses (PDAs)

Alle Accounts werden durch ihre Adresse identifiziert, einen eindeutigen öffentlichen Schlüssel mit 32 Byte. Das unterscheidet sich vom Datenmodell von Ethereum, in dem Adressen 20 Byte lang sind. Solana verwendet ed25519, also ein EdDSA-Signaturverfahren mit SHA-512 und der elliptischen Kurve Curve22519, um Adressen zu erzeugen. Damit ein Account über ein gültiges Schlüsselpaar verfügt, muss er ein Punkt auf der ed25519-Kurve sein. 

Program Derived Addresses (PDAs) sind Accounts, die mithilfe eines Bumps außerhalb der Kurve erzeugt werden. Ein Bump ist ein Wert, der die Ausgabe von der Kurve wegbewegt. PDAs benötigen drei Hauptbestandteile: die Adresse ihres übergeordneten Programms, einen Satz Seeds und einen Bump. Die Seeds sind ein Array aus Strings mit beliebigen Werten. Die meisten Entwickler erstellen jedoch spezifische Seeds, die sich auf Zustandsvariablen des übergeordneten Programms beziehen, um Hashmap-ähnliche Datenstrukturen zu erzeugen. Eine PDA entsteht somit, indem die Programm-ID, die Seeds und der Bump mit der SHA-512-Hash-Funktion gehasht werden.

PDAs liegen außerhalb der Kurve, damit nur das Programm, von dem eine PDA abgeleitet ist, in ihrem Namen signieren kann. Dadurch wird der Transaktionsablauf vereinfacht: Transaktionssignaturen werden programmgesteuert erzeugt, sodass vertrauenslose dApps ohne Eingriffe reibungslos funktionieren können.

Mit einem Account interagieren

Eine Ethereum-Transaktion ist eine zustandsverändernde Aktion, die von einem EOA initiiert wird. Smart Contracts können Transaktionen nicht selbstständig initiieren, sondern nur darauf reagieren. Der Code des Contracts bestimmt diese Reaktionen. Die Kosten der Transaktionsausführung werden in Gas gemessen. Nutzer müssen genügend Ether bereitstellen, um diese Gas-Gebühr zu bezahlen.

Ethereum-Transaktionen führen normalerweise einen einzelnen Vorgang aus, etwa den Aufruf einer bestimmten Smart-Contract-Funktion. Eine einzelne Transaktion kann zwar mehrere Zustandsänderungen in einem Contract auslösen, aber alle Änderungen bleiben auf den Geltungsbereich dieses einzelnen Contract-Aufrufs beschränkt.

Auf Solana besteht eine Transaktion aus einem Array von Accounts, aus denen gelesen oder in die geschrieben wird, einer oder mehreren Signaturen und einer oder mehreren Anweisungen. Eine Anweisung ist eine Direktive für den einmaligen Aufruf eines Programms. Sie ist die kleinste Einheit der Ausführungslogik und die grundlegendste operative Einheit. Anweisungen geben das auszuführende Programm, alle beteiligten Accounts und die operativen Daten an. Programme interpretieren die Daten einer Anweisung und führen Operationen auf den angegebenen Accounts aus. Dank dieser Struktur kann eine einzelne Transaktion atomar mehrere Aktionen über verschiedene Programme hinweg ausführen. Das bedeutet, dass entweder alle Anweisungen erfolgreich sind oder alle fehlschlagen. Der Transaktionsablauf von Solana unterscheidet sich vom Ethereum-Modell, bei dem eine Transaktion normalerweise mit einem einzelnen Smart Contract oder einer EOA-Aktion verknüpft ist.

Cross-Program Invocations (CPIs) ermöglichen einem Programm, während derselben Transaktion ein anderes Programm aufzurufen. Die Anzahl der bei einem CPI pro Compute Unit berechneten Account-Datenbytes beträgt 250. Bei 200.000 Einheiten entspricht das ungefähr 50 MB. CPIs ermöglichen die Verwendung programmgesteuert erzeugter Signaturen bei Aufrufen zwischen Programmen. Das ähnelt einem Ethereum Smart Contract, der einen anderen Contract effizient und atomar aufruft. Das aufrufende Programm wird jedoch angehalten, bis das aufgerufene Programm die Verarbeitung der Anweisung abgeschlossen hat. Reentrancy ist auf direkte Selbstrekursion mit einer festen maximalen Tiefe von 4 beschränkt. Dies verhindert Situationen, in denen ein Programm ein anderes aus einem Zwischenzustand heraus aufruft, ohne zu wissen, dass es später möglicherweise selbst erneut aufgerufen wird.

Für Solana-Transaktionen gilt aus Effizienzgründen eine Größenbeschränkung, vergleichbar mit dem Gas-Limit von Ethereum. Der Schwerpunkt liegt jedoch auf der Datengröße. Solana-Transaktionen entsprechen den Standards der IPv6 Maximum Transmission Unit (MTU), um eine zuverlässige Datenübertragung zu gewährleisten. Nach Abzug des erforderlichen Platzes für den Header bleiben 1232 Byte für Paketdaten verfügbar. Solana führte versionierte Transaktionen ein, um mehrere Transaktionsformate zu unterstützen und Größenbeschränkungen zu umgehen. Zusätzlich zum Legacy-Format, also dem ursprünglichen Transaktionsformat, wurde Version 0 veröffentlicht, um Address Lookup Tables (ALTs) zu unterstützen. ALTs speichern Adressen on-chain in einer tabellenähnlichen Datenstruktur, in der jede Adresse über einen 1 Byte großen u8-Index indiziert wird. Dadurch sinkt die Transaktionsgröße erheblich, da jeder Account nur noch 1 Byte statt 32 Byte benötigt.

Solang

Solang ist ein Solidity-Compiler für Solana und Polkadot. Er soll mit Quelldateien der Version 0.8 des Solidity-Compilers der EVM kompatibel sein. Einige Abweichungen berücksichtigen jedoch die Architekturen von Solana und Polkadot. Ein wichtiger Bestandteil von Solang ist LLVM, eine leistungsfähige Compiler-Infrastruktur. Dank der Flexibilität von LLVM kann Solang künftig weitere Programmiersprachen unterstützen und so Implementierungen und Kompilierungen vereinfachen. Das entspricht dem Ziel von Solang, Entwicklern den Wechsel zu Solana oder Polkadot zu erleichtern und die Möglichkeiten der Solidity-Entwicklung zu erweitern. Solang wird kontinuierlich weiterentwickelt. Der Fokus liegt auf besserer Kompatibilität, Effizienz und Benutzerfreundlichkeit. Ethereum-Entwickler, die ihre Fähigkeiten chainübergreifend einsetzen möchten, sollten Solang und seine Einschränkungen kennen.

Installation

Es gibt mehrere Möglichkeiten, Solang zu installieren. Auf einem Mac kannst du Solang mit Brew über einen privaten Tap herunterladen:

brew install hyperledger/solang/solang

Eine weitere Möglichkeit ist die Verwendung von Solang-Containern. Das ist ideal, wenn du Docker bevorzugst, da neue Images automatisch in diesen Containern bereitgestellt werden. Es gibt ein v.0.3.3-Tag und ein latest-Tag:

docker pull ghcr.io/hyperledger/solang:latest

Eine der einfacheren Möglichkeiten, Solang zu installieren und zu verwenden, führt über Anchor. Stelle zunächst sicher, dass Rust und Node.js auf deinem System installiert sind. Unter Windows musst du außerdem das Windows-Subsystem für Linux einrichten. Installiere nun die Tool-Suite von Solana. Unter Mac und Linux geht das mit folgendem Befehl:

 sh -c "$(curl -sSfL https://release.solana.com/v1.17.13/install)"

Wenn du eine andere Softwareversion bevorzugst, ersetze „v1.17.13“ durch das entsprechende Release-Tag. Alternativ kannst du einen der folgenden symbolischen Kanalnamen verwenden: stable, beta oder edge. Je nach System musst du möglicherweise deine PATH-Umgebungsvariable aktualisieren. Wenn diese Meldung erscheint, kopiere den unten empfohlenen Befehl und führe ihn aus, um PATH zu aktualisieren. Mit solana --version kannst du prüfen, ob die gewünschte Version von solana installiert ist.

Öffne unter Windows die Eingabeaufforderung als Administrator. Kopiere den folgenden Befehl und führe ihn aus, um das Solana-Installationsprogramm in ein temporäres Verzeichnis herunterzuladen:

cmd /c "curl https://release.solana.com/v1.17.13/solana-install-init-x86_64-pc-windows-msvc.exe --output C:\solana-install-tmp\solana-install-init.exe --create-dirs"

Kopiere anschließend den folgenden Befehl und führe ihn aus, um die neueste Version von Solana zu installieren: C:\solana-install-tmp\solana-install-init.exe v1.17.13. Drücke nach Abschluss der Installation die Eingabetaste.

Schließe die Eingabeaufforderung und öffne sie erneut als normaler Benutzer. Führe solana –-version aus, um zu prüfen, ob die gewünschte Version von solana installiert ist.

Installiere als Nächstes Anchor.

Wir empfehlen, Anchor mit dem Anchor Version Manager (avm) zu installieren. Das geht über cargo mit diesem Befehl:

cargo install -git https://github.com/coral-xyz/anchor avm --locked --force.

Installiere und verwende anschließend die neueste Version:

avm install latest
avm use latest

# Verify the installation
avm –version

Mit Anchor Version 0.28 können Entwickler direkt mit Solang bauen. Mit dem Befehl anchor init project_name —solidity kannst du ein neues Solang-Projekt erstellen. Dadurch entstehen ein neues Solang-Programm und eine Testdatei, die zeigt, wie der Client mit dem Programm interagiert.

Wenn du Visual Studio Code verwendest, solltest du die Solang-Erweiterung für die Syntaxhervorhebung installieren. Deaktiviere alle anderen aktiven Solidity-Erweiterungen, damit die Solang-Erweiterung korrekt funktioniert.

Neues Projekt erstellen

Erstelle mit dem Befehl anchor-init project_name –solidity ein neues Projekt. Dadurch wird ein neues Verzeichnis mit dem Namen deines Projekts erstellt. Das Solidity-Flag teilt Anchor mit, dass wir Solang verwenden möchten. Das Verzeichnis ./solidity des Projekts enthält ein Startprogramm. Der Contract sieht folgendermaßen aus:

@program_id("F1ipperKF9EfD821ZbbYjS319LXYiBmjhzkkf5a26rC")
contract test {
    bool private value = true;

    @payer(payer)
    constructor() {
        print("Hello, World!");
    }

    /// A message that can be called on instantiated contracts.
    /// This one flips the value of the stored `bool` from `true`
    /// to `false` and vice versa.
    function flip() public {
            value = !value;
    }

    /// Simply returns the current value of our `bool`.
    function get() public view returns (bool) {
            return value;
    }
}

Dieses Programm besitzt einen constructor, der das Programm erstellt, die Zustandsvariable value mit true initialisiert und „Hello, World!“ in die Programmlogs schreibt. Die Funktion flip aktualisiert bei ihrem Aufruf die Zustandsvariable. Die Funktion get gibt den aktuellen Wert der Zustandsvariable zurück. Das sieht mit einigen Einschränkungen wie ein normaler Solidity-Smart-Contract aus. Der wichtigste Unterschied ist die Verwendung von Annotationen.

Annotationen

Annotationen dienen zur Verwaltung von Accounts. Beachte die Annotation @program_id(“...”). Sie gibt die Onchain-Adresse des Programms an, sofern diese vorab bekannt ist. Wenn du einen Contract über einen externen Aufruf aufrufen möchtest, muss das Programm entweder die Notation @program_id besitzen oder mit dem Argument {program_id: … } aufgerufen werden:

@program_id(“...”);

contract Foo {
	function hello() public pure {
		print(“Hello”);
	}
}

contract Foo2 {
	function bye() public pure {
		print(“Bye”);
	}
}

contract Bar {
	function new_foo() external {
		Foo.new();
	}
}

contract Bar2 {
	function new_foo(address new_foo_id) external {
		Foo2.new{program_id: new_foo_id}();
	}
}

Als wir ein neues Projekt erstellt haben, enthielt der bereitgestellte Beispiel-Contract über dem Konstruktor die Annotation @payer. Diese Annotation definiert den Account, der für die Initialisierung des Daten-Accounts des Programms bezahlt. Die Syntax @payer(payer) deklariert einen Account namens payer, der für jeden Aufruf des Konstruktors erforderlich ist.

Wenn ein Contract instanziiert wird, benötigt er einen Programm-Account für den ausführbaren Code und einen Daten-Account zum Speichern der Zustandsvariablen. Der Daten-Account kann durch clientseitigen Code erstellt und dann an die Transaktion übergeben werden, die den Konstruktor aufruft. Alternativ kann der Konstruktor den Daten-Account erstellen. Mindestens die Annotation @payer muss angegeben werden. Wenn der Daten-Account eine PDA sein soll, musst du einen Seed und einen Bump angeben. Die Annotation @seed legt einen Seed zum Ableiten der PDA fest. Sie kann ein String-Literal oder ein Hex-String im Format hex”1234” sein. Wenn die Seed-Annotation vor einem Argument steht, muss sie auf ein Argument vom Typ bytes, address oder auf ein Byte-Array mit fester Länge verweisen. Die Annotation @bump legt den Wert fest, mit dem eine Off-Curve-Adresse erzeugt wird. Es muss sich um ein einzelnes Byte vom Typ bytes1 handeln. Mit der optionalen Annotation @space kannst du die Größe des Daten-Accounts angeben. Sie ist ein uint64-Ausdruck, der eine Konstante sein oder eines der Konstruktorargumente verwenden kann. Laut der Solang-Dokumentation sollte @space mindestens der Größe entsprechen, die beim Ausführen des Befehls solang -v angegeben wird:

$ solang compile --target solana -v examples/solana/flipper.sol
...
info: contract flipper uses at least 17 bytes account data
…

Wenn ein Programm keinen Konstruktor hat, können diese Annotationen mit einem leeren Konstruktor kombiniert werden. Die Solang-Dokumentation enthält das folgende Beispiel:

@program_id("Foo5mMfYo5RhRcWa4NZ2bwFn4Kdhe8rNK5jchxsKrivA")
contract Foo {

    @space(500 + 12)
    @seed("Foo")
    @payer(payer)
    constructor(@seed bytes seed_val, @bump bytes1 bump_val) {
        // ...
    }
}

Funktionsannotationen deklarieren die erforderlichen Accounts für externe Funktionen:

• @account(foo) deklariert den Account foo als schreibgeschützten Account
• @mutableAccount(bar) deklariert den Account bar als veränderbaren Account
• @signer(fizz) deklariert den Account fizz als schreibgeschützten Signer
• @mutableSigner(buzz) deklariert den Account buzz als veränderbaren Signer

Auf Accounts, die im Konstruktor mit der Annotation @payer deklariert wurden, kannst du innerhalb des Konstruktors zugreifen. Mit Funktionsannotationen deklarierte Accounts sind im Vektor tx.accounts verfügbar. Du würdest beispielsweise tx.accounts.ichigo verwenden, um auf den als @account(ichigo) deklarierten Account zuzugreifen. Dadurch wird das integrierte AccountInfo-Struct zurückgegeben. Dieses Struct entspricht der Struktur, die wir im Abschnitt „Das Account-Modell verstehen“ beschrieben haben. Lediglich die Bezeichnungen unterscheiden sich etwas:

• key: die Adresse oder der öffentliche Schlüssel des Accounts. Der Typ ist address
• lamports: das Lamport-Guthaben des Accounts. Der Typ ist uint64
• data: die Daten des Accounts. Der Typ ist bytes
• owner: der Eigentümer des Accounts. Der Typ ist address
• rent_epoch: die nächste Epoche, in der die Miete des Accounts fällig wird. Der Typ ist uint64
• is_signer: gibt an, ob der Account die Transaktion signiert hat. Der Typ ist bool
• is_writable: gibt an, ob der Account in dieser Transaktion beschreibbar ist. Der Typ ist bool
• executable: gibt an, ob der Account ein Programm ist. Der Typ ist bool

Einschränkungen

Die wichtigsten Inkompatibilitäten zwischen Solang und der klassischen Ethereum-Entwicklung sind:

• msg.sender ist auf Solana nicht verfügbar. Mit dem Account-Modell kann ein Rust-Contract auf verschiedene Daten-Accounts zugreifen. Welchen davon würden wir als Aufrufer betrachten? In vielen Fällen lässt sich kein einzelner Account als Aufrufer identifizieren. Außerdem bietet die Laufzeitumgebung keinen Mechanismus zum Abrufen von Aufrufer-Accounts
• Es gibt keine Funktion ecrecover(), aber eine Funktion signatureVerify() zum Prüfen von ed25519-Signaturen.
• Try-Catch-Anweisungen funktionieren nicht. Die Laufzeitumgebung beendet die Ausführung und macht die gesamte Transaktion rückgängig, wenn ein externer Aufruf oder die Erstellung eines Contracts fehlschlägt.
• Fehlerdefinitionen und Reverts mit Fehlermeldungen funktionieren noch nicht
• Die Übertragung nativer Werte mit einem Funktionsaufruf funktioniert nicht.
• Viele integrierte Yul-Funktionen sind nicht verfügbar. Solang unterstützt die meisten integrierten Funktionen. Speicher- und Chain-Operationen sind jedoch nicht implementiert.
• Das ERC-20-Format wird derzeit nicht unterstützt. SPL-Tokens werden gemäß dem Token Program definiert. Das Token Program ist Solanas nativer Weg, Tokens zu erstellen, zu prägen, zu übertragen und zu verbrennen. Kopiere die Datei spl_token.sol in deinen Quellbaum und importiere sie dort, wo du die Bibliothek SplToken benötigst

Außerdem sind die Register der SVM 64 Bit breit. Daher sind 64-Bit-Ganzzahlen wie uint64 und int64 gegenüber 256-Bit-Ganzzahlen vorzuziehen. Eine Operation mit Typen, die breiter als 64 Bit sind, etwa uint256 oder int256, wird in mehrere Operationen aufgeteilt. Dadurch ist sie langsamer und verbraucht mehr Compute Units.

Für Adressen muss ein Adressliteral mit der Syntax address"36VtvSbE6jVGGQytYWSaDPG7uZphaxEjpJHUUpuUbq4D" angegeben werden. Die Hex-Syntax von Ethereum, beispielsweise 0xE0f5206BBD039e7b0592d8918820024e2a7437b9, wird nicht unterstützt. Alle Guthaben und Werte auf Solana sind 64 Bit breit. Das bedeutet, dass integrierte Adressfunktionen wie .balance(), .transfer() und .send() 64-Bit-Ganzzahlen verwenden.

Solang bietet EVM-Entwicklern einen interessanten Weg in das Solana-Ökosystem, besitzt jedoch mehrere Einschränkungen, die du sorgfältig abwägen solltest. Der Wechsel zum Account-basierten Modell von Solana ist nicht nur eine syntaktische Änderung. Er verändert die Logik von Smart Contracts grundlegend. Bestimmte Funktionen, Programmiermuster und EVM-spezifische Features sind mit Solang nicht verfügbar. Entwickler können einen Ethereum-Smart-Contract nicht einfach nach Solang portieren und erwarten, dass er ohne erhebliche Anpassungen funktioniert. Fehlende Features wie korrekte Fehlerdefinitionen und Reverts mit Fehlermeldungen können gravierende Folgen haben. Solang entwickelt sich jedoch ständig weiter. Jedes Update soll die Erfahrung von Solidity-Entwicklern auf Solana verbessern. Solang bietet mehrere klare Vorteile, die diese Erfahrung zusätzlich verbessern.

Vorteile

Trotz dieser Einschränkungen verbessern zahlreiche integrierte Funktionen und Designentscheidungen die Entwicklererfahrung. In Solang entwickelte Contracts können beispielsweise mit Anchor-Programmen interagieren. Dazu kannst du aus der IDL eines Anchor-Programms eine Solidity-Schnittstelle generieren. IDL steht für „Interface Description Language“. Im Wesentlichen ist das eine JSON-Datei, die alle Spezifikationen eines Programms enthält. Sie umfasst alles, was du für die Interaktion mit einem Anchor-Programm wissen musst. Anchor generiert automatisch eine IDL, wenn du ein Programm mit seinem Framework entwickelst. Das ähnelt stark den ABIs auf Ethereum. Verwende den folgenden Befehl, um aus einer IDL eine Solidity-Schnittstelle zu generieren: solang idl [-output directory] [IDL file]. Anschließend kannst du die Datei mit der Syntax import “...”; importieren.

Solang stellt die Solana-Bibliothek bereit. Diese Bibliotheksreihe ermöglicht Solidity-Contracts die Interaktion mit Solana-spezifischen Anweisungen. Zum Prägen, Verbrennen und Übertragen von Tokens bietet Solang die SPL-Token-Bibliothek. Sie kann als Gegenstück zu ERC-20 und ERC-721 betrachtet werden. Solang stellt außerdem die System-Instructions-Bibliothek bereit, damit Entwickler mit dem System Program von Solana interagieren können.

Solang enthält außerdem integrierte Funktionen, die sich mit solana importieren lassen. Dazu gehören die Structs AccountMeta und AccountInfo. Das Struct AccountMeta legt fest, welche Accounts bei einem externen Aufruf, also einer CPI, an den Aufgerufenen übergeben werden. Das Struct AccountMeta hat folgende Struktur:

• pubkey: die Adresse oder der öffentliche Schlüssel des Accounts. Der Typ ist address
• is_writable: gibt an, ob der Aufgerufene in diesen Account schreiben darf. Der Typ ist bool
• is_signer: gibt an, ob der Aufgerufene davon ausgehen darf, dass dieser Account die Transaktion signiert hat. Der Typ ist bool

Wenn das Argument accounts bei einem externen Aufruf fehlt, erzeugt der Solang-Compiler automatisch ein AccountMeta-Array. Das funktioniert nur, wenn die Funktion als extern deklariert ist. Andernfalls musst du das AccountMeta-Array manuell gemäß der in der IDL festgelegten Account-Reihenfolge erstellen. Wenn ein bestimmter Aufruf keine Accounts benötigt, übergib einen leeren Vektor: {accounts: []}. Die Solang-Dokumentation enthält ein gutes Beispiel für den Aufbau des Arrays AccountMetas:

function build_this() external {
	// When calling a constructor from an external function, the data account for the contract
	// 'BeingBuilt' should be passed as the 'BeingBuilt_dataAccount' in the client code.
	BeingBuilt.new("my_seed");
}

function build_that(address data_account, address payer_account) public {
	AccountMeta[3] metas = [
		AccountMeta({
			pubkey: data_account,
      is_signer: true,
      is_writable: true
		}),
    AccountMeta({
    	pubkey: payer_account,
      is_signer: true,
      is_writable: true
    }),
    AccountMeta({
      pubkey: address"11111111111111111111111111111111",
      is_writable: false,
      is_signer: false
    })
  ];
  BeingBuilt.new{accounts: metas}("my_seed");

	// No accounts are needed in this call, so we pass an empty vector.
	BeingBuilt.say_this{accounts: []}("It's summertime!");
}

Solang bietet außerdem integrierte Funktionen für:

• Berechnung des Mindestguthabens, das zum Erstellen eines bestimmten Accounts erforderlich ist
• Erstellung einer PDA für eine Programmadresse anhand der angegebenen Seeds und des Bumps
• Ermittlung einer PDA für eine Programmadresse anhand der angegebenen Seeds und des Bumps

Solang schließt die Lücke zwischen Solana und Ethereum. Der Compiler bietet umfangreiche Tools, die EVM-Entwicklern den Wechsel erleichtern. Trotz seiner Einschränkungen verbessert Solang die Entwicklererfahrung mit mehreren Features. Dazu gehören die Interaktion mit Anchor-Programmen, der Zugriff auf Solana-spezifische Bibliotheken und integrierte Funktionen. Vertraute Konzepte wie IDLs und Token-Standards senken die Lernkurve zusätzlich. Auch dass du dir keine Gedanken über Gas machen oder darauf optimieren musst, ist eine willkommene Ergänzung. Solang ist ein wichtiger Schritt hin zur Interoperabilität zwischen Solana und Ethereum. Für EVM-Entwickler, die in die leistungsstarke Welt von Solana expandieren möchten, ist Solang ein mögliches Tool.

Neon EVM

Solang ist nicht die einzige Option für Solidity-Entwickler, die auf Solana bauen möchten. Neon EVM bezeichnet sich als weltweit erste parallelisierbare EVM. Sie bietet eine vollständig kompatible Ethereum-Umgebung auf Solana. Das ist eine synergetische Lösung für alle, die Ethereum-dApps entwicklerfreundlich auf Solana skalieren möchten. Entwickler können ihre dApps ohne Neukonfiguration ihrer Smart Contracts bereitstellen. Dabei nutzen sie die bevorzugten Sprachen und Tools.

Architektur

Neon EVM besteht aus drei Hauptkomponenten: dem Neon-EVM-Programm, Neon Proxy und Neon DAO.

Neon EVM ist ein Solana-Programm, das Ethereum-ähnliche Transaktionen annimmt und sie gemäß den Regeln der EVM auf Solana verarbeitet. Diese an Neon EVM gerichteten Ethereum-ähnlichen Transaktionen werden als Neon Transactions bezeichnet. Sie bilden eine Teilmenge der JSON-RPC-Methoden gemäß der Ethereum JSON-RPC API.

Neon Proxy ermöglicht Ethereum-Entwicklern, ihre dApps mit minimalen Änderungen auf Neon zu portieren. Er verpackt EVM-Transaktionen in Solana-Transaktionen und dient Neon Operators als containerisierte Lösung. Diese Betreiber führen Neon-Proxy-Server aus, akzeptieren Zahlungen in NEON und leisten Zahlungen innerhalb des Solana-Ökosystems in SOL. NEON ist sowohl ein Utility- als auch ein Governance-Token: Neon Operators sammeln ihn, um die für die Transaktionsausführung erforderlichen Gas-Gebühren zu bezahlen. Eigentümer können außerdem an Neon DAO teilnehmen.

Neon DAO ist ein gemeinschaftlich gesteuertes Governance-Modell, das NEON-Token-Inhabern Mitspracherecht bei Entscheidungen für Neon EVM gibt. Es umfasst Benutzer, Betreiber, Mitwirkende sowie Core- und Anwendungsentwickler, die gemeinsam über Governance-Regeln und die Weiterentwicklung des Protokolls beraten. Die DAO arbeitet über verschiedene dezentrale Versammlungen, deren Schwerpunkte auf Ökosystem, Entwicklung und Sicherheit liegen. Jede Versammlung ermöglicht gemeinsame Entscheidungen und prüft Vorschläge für ihren jeweiligen Bereich. Die auf das Ökosystem ausgerichtete Versammlung überwacht dessen nachhaltiges Wachstum und verwaltet Mittel für Förderungen und Initiativen. Die Entwicklungsversammlung kümmert sich um technische Upgrades des Neon-Programms und Notfallmaßnahmen. Die Sicherheitsversammlung schützt die Treasury von Neon und das Neon-Programm vor potenziellen Bedrohungen.

EVM-Kompatibilität

Neon EVM ermöglicht EVM-Interaktionen auf Solana durch:

• Implementierung der meisten JSON-RPC-API-Methoden von Ethereum
• Verwendung eines speziellen Proxys zur Verarbeitung von Ethereum-Aufrufen
• Anpassung an die Unterschiede und Einschränkungen der Solana-Architektur

Die Interaktion mit Neon EVM ähnelt der mit jeder anderen EVM. Entwickler können vertraute RPC-API-Methoden an Neon Proxy senden und erhalten so eine nahtlose Entwicklererfahrung. Zu den wichtigsten Features gehören:

• Kompatibilität mit Solidity- und Vyper-Smart-Contracts sowie mit gängigen Ethereum-Entwicklungstools wie Metamask, Foundry und Remix
• Unveränderte Unterstützung der meisten Ethereum-Opcodes
• Annahme von Ethereum-Transaktionsanfragen des Typs 0 beziehungsweise Legacy-Transaktionen. EIP-1559-Transaktionen werden derzeit nicht unterstützt

Natürlich sind bestimmte Anpassungen nötig, damit Neon EVM auf Solana korrekt funktioniert. Zu den wichtigsten Unterschieden gehören:

• Neon EVM unterstützt alle auf evm.code definierten vorkompilierten Contracts. Solidity-Contracts mit den folgenden Aufrufen werden jedoch nicht ausgeführt: bigModExp, bn256Add, bn256ScalarMult und bn256Pairing. Neon EVM muss Solana-Systemaufrufe implementieren, um diese Contracts künftig zu unterstützen
• Die meisten Opcodes werden unverändert unterstützt. Die Opcodes COINBASE, PREVRANDAO (FKA DIFFICULTY), GASLIMIT, BASEFEE und GAS bilden jedoch eine Ausnahme. Sie werden als variierende Opcodes bezeichnet und für die Verwendung in Neon EVM angepasst.
• Gas-Verbrauch und Gebührenberechnung unterscheiden sich von Ethereum. Aufgrund der Rolle von Solana als Settlement-Layer führen sie im Allgemeinen zu niedrigeren Kosten
• Die Solidity-Methoden transfer() und send() sind in Neon EVM aufgrund abweichender Gas-Berechnungen nicht vor Reentrancy geschützt
• Das Account-Modell von Solana wirkt sich auf die Speicherung von Smart Contracts aus. Ausführbare und nicht ausführbare Accounts besitzen unterschiedliche Speicherfunktionen und Zugriffsrechte
• Neon EVM verwendet versionierte Transaktionen. Dadurch ist die maximale Anzahl der in einer einzelnen Transaktion verwendeten Accounts auf 64 begrenzt
• Neon EVM verwendet Solanas Berkeley Packet Filter (BPF) mit einem Heap-Speicherlimit von 256 KB. Das begrenzt die Größe von Contract-Aufrufen und erfordert Optimierungsstrategien, um die Speichernutzung effizient zu verwalten
• Zeitbasierte Funktionen wie block.number und block.timestamp verhalten sich anders. Entwicklern wird dringend davon abgeraten, sie bei der Entwicklung auf Neon EVM zu verwenden

Neon EVM bietet zwar eine vertraute und kompatible Umgebung. EVM-Entwickler müssen die wesentlichen Unterschiede jedoch kennen und berücksichtigen, um erfolgreich zu Solana zu migrieren und darauf zu bauen.

Verbindung mit einem Neon RPC

Über Chainlist kannst du dich einfach mit einem Neon RPC verbinden. Dort kannst du entweder das Neon EVM Mainnet oder das Devnet auswählen. Klicke im Mainnet- oder Devnet-Dialog auf Wallet verbinden und anschließend im eingeblendeten Wallet-Fenster auf Genehmigen.

Wähle den optimalen Betreiber aus, bevor du Transaktionen an Neon EVM sendest. Erweitere die Kartendetails, um die verfügbaren RPC-Endpunkte für jedes Netzwerk anzuzeigen:

Wenn du einen anderen Betreiber als den bei der Wallet-Verbindung voreingestellten auswählst, musst du die Verbindung manuell herstellen. Die Dokumentation von Neon EVM enthält ausführliche Anleitungen zum Verbinden mit einem Proxy über Foundry, Hardhat, Remix und Truffle. Im Abschnitt zur Bereitstellung zeigen wir, wie du die Verbindung mit Foundry herstellst.

Nach dem Verbindungsaufbau kannst du über den Neon Faucet NEON oder andere ERC-20-Test-Tokens beziehen. Du kannst Tokens auch programmgesteuert über den Endpunkt request_neon anfordern:

curl -i -X POST \
	-d '{"wallet": "Your wallet", "amount": 1}' \
	'http://localhost:3333/request_neon'

Dieser Befehl sendet eine POST-Anfrage, um Tokens an der angegebenen Wallet-Adresse zu empfangen.

Transaktionslebenszyklus und Gas-Gebühren

Die Ausführung einer Transaktion von einer Ethereum-dApp auf Solana über Neon EVM umfasst drei Hauptschritte:

• Ein Benutzer initiiert eine signierte Ethereum-ähnliche Transaktion, die an einen Neon-RPC-Endpunkt gerichtet ist
• Die Transaktion wird über die Ethereum-API an Neon Proxy übergeben. Der Proxy schätzt das für die Ausführung erforderliche Gas, startet eine Übertragung, indem er die Ethereum-ähnliche Transaktion in eine Solana-Transaktion verpackt, und sendet die verpackte Transaktion an Neon EVM. Dadurch entstehen ein Solana-Beleg und ein entsprechender Neon-EVM-Transaktionsbeleg. Der Neon-Smart-Contract entpackt die Transaktion, prüft die Signatur des Benutzers und lädt den EVM-Zustand aus dem Solana-Speicher. Die Transaktion wird innerhalb des BPF von Solana ausgeführt
• Solana und Neon EVM aktualisieren ihre Zustände und schließen die Transaktionsanfrage ab

Das ist der vollständige Lebenszyklus einer Transaktion in Neon EVM, von der Initiierung bis zur Ausführung. Auf NeonScan kannst du die neuesten Transaktionen und Blöcke anzeigen sowie Accounts, Tokens, Blöcke oder Transaktions-Hashes abfragen.

Entwickler können auch Transaktionen ohne Gas-Gebühren senden. Diese Funktion unterstützt Benutzer, die nicht genügend NEON-Tokens für ihre anfänglichen Transaktionsgebühren besitzen. Entwickler können unter info@neonevm.org ein Startpaket für gebührenfreie Transaktionen anfordern. Der vom Entwickler gewählte Proxy Operator verarbeitet diese Transaktionen weiterhin, Neon übernimmt jedoch die Transaktionskosten. Pro neuem Neon-Account werden üblicherweise mindestens drei gebührenfreie Transaktionen angeboten.

Der Ablauf für gebührenfreie Transaktionen sieht folgendermaßen aus:

• Ein Endbenutzer initiiert über eine dApp eine Transaktion
• Die dApp fragt den aktuellen Gas-Preis beim gewählten Proxy Operator ab. Wenn der Neon-Account berechtigt ist, markiert der Proxy Operator ihn für eine bestimmte Anzahl gebührenfreier Transaktionen
• Für diese Transaktionen zeigt die dApp Gas-Kosten von null an
• Der Endbenutzer signiert die Transaktion ohne Gas-Gebühr
• Der Proxy Operator führt die Transaktion aus. Die Neon Foundation bezahlt die Gas-Gebühr in SOL

Die Dokumentation von Neon EVM enthält den folgenden Auszug, der zeigt, wie du eine gebührenfreie Transaktion anforderst:

try {
	// Get gasless transaction if user account is eligible
  const rawGasPrice = await axios.post(rpcApiUrl, {
  	method: 'neon_gasPrice',
    params: [{ from: address }],
    jsonrpc: "2.0",
    id: new Date().getTime()
   })

   tx.gasPrice = rawGasPrice.data?.result;
	} catch (e) {
  	//Else, get standard GAS price
   	setError('Can\'t retrieve gas price for transaction')

    const rawGasPrice = await web3.eth.getGasPrice();

    tx.gasPrice = web3.utils.toHex(rawGasPrice);
} finally {
    setTx(tx)
}

NeonPass

NeonPass ist ein Tool zum Übertragen von Tokens zwischen Solana und Neon EVM. Es ermöglicht nahtlose Asset-Übertragungen zwischen den Associated Token Accounts von Solana und den ERC-20-Token-Accounts von Neon EVM. NeonPass verwendet den Schnittstellen-Contract und den spezialisierten Account-Speicher von Neon EVM. Tokens aus der Solana Program Library (SPL) werden innerhalb des Factory-Contracts von Neon EVM in eine ERC-20-Schnittstelle verpackt. Dadurch lassen sich SPLs in ERC-20-Token-Accounts speichern, die mit Solidity-dApps kompatibel sind. NeonPass ermöglicht die bidirektionale Übertragung von Tokens zwischen Solana- und Neon-EVM-Accounts. Anders als klassische Bridges, die Assets sperren und neue prägen, verschiebt NeonPass Tokens direkt zwischen den beiden Account-Typen. Das ermöglicht einen nahtlosen Übergang von Solana- und Neon-EVM-Tokens.

Bereitstellung

Entwickler können mit Hardhat, Foundry, Truffle und Remix auf Neon EVM bereitstellen. Da Solang am einfachsten über Anchor verwendet wird, finden alle Tests in TypeScript statt. Für alle Solidity-Maxis können wir Solidity-dApps nun jedoch über Foundry auf Solana testen und bereitstellen.

Stelle zunächst sicher, dass eine EVM-kompatible Wallet mit dem Neon EVM Devnet verbunden ist. Klone anschließend das Foundry-Beispielprojekt von Neon und wechsle in sein Verzeichnis:

git clone https://github.com/neonlabsorg/neon-tutorials
cd neon-tutorials/foundry

Installiere anschließend Foundryup, das Installationsprogramm für die Foundry-Toolchain. Führe dann foundryup aus, um die neuesten nächtlichen vorkompilierten Binärdateien zu installieren, also force, cast, anvil und chisel:

curl -L https://foundry.paradigm.xyz | bash
foundryup

Installiere die erforderlichen Bibliotheken:

forge install foundry-rs/forge-std --no-commit
forge install openzeppelin/openzeppelin-contracts --no-commit

Rufe nun den privaten Schlüssel deines Wallet-Accounts ab. In Metamask kannst du deinen privaten Schlüssel beispielsweise anzeigen, indem du auf das Hamburger-Menü klickst und zu Account Details > Show Private Key navigierst. Du wirst zur Eingabe deines Passworts aufgefordert. Klicke auf Bestätigen, um auf den privaten Schlüssel deines Accounts zuzugreifen. Gib diesen Schlüssel niemals weiter und ergreife die erforderlichen Maßnahmen, um ihn zu schützen.

Erstelle anschließend eine .env-Datei mit den folgenden Variablen:

RPC_URL_DEVNET=https://devnet.neonevm.org
CHAIN_ID_DEVNET=245022926
RPC_URL_MAINNET=https://neon-proxy-mainnet.solana.p2p.org
CHAIN_ID_MAINNET=245022934
PRIVATE_KEY=
VERIFIER_URL_BLOCKSCOUT=https://neon-devnet.blockscout.com/api

Ersetze <YOUR_PRIVATE_KEY> durch deinen privaten Schlüssel und führe source .env aus.

Wechsle zum Kompilieren der Contracts des Projekts in das Verzeichnis src und führe forge build aus. Die Konsole sollte melden, dass der Compilerlauf erfolgreich war. Du kannst die Contracts auch mit dem Befehl forge test testen. Führe den folgenden Befehl aus, um den Contract des Projekts bereitzustellen:

forge create --rpc-url $RPC_URL_DEVNET --private-key $PRIVATE_KEY src/TestERC20/TestERC20.sol:TestERC20 --constructor-args "Test ERC20 Token" "TERC20" --legacy

Die Ausgabe sollte ungefähr so aussehen:

[⠰] Compiling...
No files changed, compilation skipped
Deployer: 0x4455E84Eaa56a01676365D4f86348B311969a4f4
Deployed to: 0x5537599aa2F97Dd60a66342522a465A7f2e40Ff9
Transaction hash: 0x6de9dab8a526cbac33008056d185b93dff725605efb791bf116b6bece4f0c486

Führe den folgenden Befehl aus, um deinen Contract zu verifizieren:

forge verify-contract --chain-id $CHAIN_ID_DEVNET  src/TestERC20/TestERC20.sol:TestERC20 --verifier-url $VERIFIER_URL_BLOCKSCOUT --verifier blockscout

Ersetze <contract_address> durch die Adresse deines Smart Contracts. Du solltest eine OK-Antwort mit einer URL erhalten, die auf die Adresse des Contracts in BlockScout, dem Devnet-Explorer von Neon, verweist. Du kannst deine .env-Datei auch so konfigurieren, dass sie NeonScan anstelle von BlockScout verwendet. NeonScan unterstützt ebenfalls das Devnet.

Vorteile und Einschränkungen

Entwickler, die eine ähnliche Entwicklererfahrung wie bei Ethereum suchen, sollten Neon EVM wählen. Die EVM-kompatible Umgebung sendet Ethereum-ähnliche Transaktionen und verwendet vertraute Tools. Features wie NeonPass, die Unterstützung der meisten EVM-Opcodes und gebührenfreie Transaktionen erleichtern den Wechsel zu Solana erheblich. Neon EVM ist jedoch nicht perfekt. Zu den Einschränkungen gehören Änderungen an der Smart-Contract-Logik zur Anpassung an die Infrastruktur von Solana, die Vorgaben des Berkeley Packet Filters (BFP) und der Account-Modelle von Solana sowie bestimmte Beschränkungen für Opcodes und vorkompilierte Contracts. Du musst diese Feinheiten verstehen und berücksichtigen, um erfolgreich aus einer EVM-kompatiblen Umgebung auf Solana bereitzustellen.

Frühere Migrationen

Damit ein großes Ethereum-Protokoll auf einer Nicht-EVM-Chain bereitgestellt werden kann, müssen mehrere komplexe Aufgaben bewältigt werden. Dazu gehören die Suche nach Entwicklern ohne Solidity-Schwerpunkt, die die Codebasis von Grund auf neu erstellen, die Auswahl vertrauenswürdiger Audit-Partner, ein erneutes Audit der neuen Codebasis und die Anpassung der Governance-Verträge, um DAO-Entscheidungen durchzusetzen. Das kann Millionen von Dollar kosten und monatelange konzentrierte Arbeit erfordern. Für die meisten ist das nicht machbar. Dennoch ist es bereits gelungen.

Helium ist ein LoRaWAN-Netzwerk, das eine dezentrale drahtlose Infrastruktur für Geräte des Internets der Dinge (IoT) schaffen will. Dazu nutzt es Hotspots: kleine, stromsparende Geräte, die Miniatur-Mobilfunkmasten ähneln und sich über große Entfernungen mit anderen Hotspots verbinden. Helium lief ursprünglich auf einer eigenen Layer-1-Blockchain (L1). Mit HIP 70 schlug das Entwicklerteam jedoch den Wechsel zu Solana vor. Dadurch konnte Helium eine höhere Verfügbarkeit, bessere Kombinierbarkeit und eine schnellere Nutzererfahrung erreichen, ohne Abstriche bei Sicherheit und niedrigen Nutzungskosten zu machen. Die Community stimmte mit überwältigender Mehrheit für den Vorschlag. Im April 2023 migrierte Helium zu Solana. Heliums COO Scott Sigel bezeichnete die Migration als langweiliges Ereignis – weder beim Netzwerk noch bei Heliums Infrastruktur ging etwas schief. Für Entwickler war es ein Traum. Das Team dokumentierte außerdem den gesamten Migrationsprozess in einer Reihe von Anleitungen in seiner Dokumentation. Heliums Migration war ein großer Erfolg und brachte der Community erhebliche Vorteile.

Diese Migration ist kein Einzelfall. The Render Network, die weltweit erste dezentrale GPU-Rendering-Plattform, migrierte seine Kerninfrastruktur im November 2023 erfolgreich von Ethereum zu Solana. Die Community stimmte bei RNP-002 für die Migration zu Solana. Render-Gründer Jules Urbach bezeichnete die Migration als Wendepunkt. Er erklärte: „Solanas unglaubliche Transaktionsgeschwindigkeit, die niedrigen Kosten und das Bekenntnis zu einer Architektur im Webmaßstab machen Solana zur perfekten Wahl für The Render Network, während wir weiter an einer skalierbaren und dezentralen Metaverse-Infrastruktur arbeiten.“

Renders Migration hatte keine übermäßig negativen Auswirkungen auf die Nutzer. Mit Renders Upgrade Assistant können sie Guthaben von Ethereum zu Solana übertragen. Dazu verbinden sie ihre Ethereum-Wallet, geben den zu migrierenden RNDR-Betrag an und warten, bis ihre Token an die angegebene Solana-Wallet gesendet wurden. 

Maker ist ein Ethereum-Projekt wie aus dem Lehrbuch. Mit der Maker-Plattform will das Projekt das Potenzial dezentraler Finanzen erschließen. Diese inklusive Plattform soll die wirtschaftliche Selbstbestimmung stärken und gleichberechtigten Zugang zum globalen Finanzmarkt ermöglichen. Die Plattform besteht aus MakerDAO zur Verwaltung des Maker-Projekts und dem Maker-Protokoll für DAI, „die weltweit erste neutrale Währung und der führende dezentrale Stablecoin“. Rune Christensen, der Gründer von Maker, twitterte über die Verwendung eines Forks der Solana-Codebasis zur Entwicklung einer Maker-Appchain: 

Migrationen sind grundsätzlich komplex. Trotz der finanziellen, zeitlichen und rufschädigenden Risiken, die mit der Migration der gesamten Infrastruktur eines Projekts von Ethereum zu Solana verbunden sind, entscheiden sich Projekte für Solana. Mit Tools wie Solang und Neon EVM müssen Migrationen jedoch nicht zwangsläufig komplex sein. Wie bei Heliums Migration kann der Vorgang unspektakulär verlaufen und, wie bei The Render Network, kaum oder gar keine negativen Auswirkungen auf das Guthaben der Nutzer haben. Solana ist die leistungsfähigste Blockchain auf dem Markt und für den Webmaßstab ausgelegt. Hier solltest du entwickeln. Immer mehr Projekte erkennen das.

Fazit

Solidity ist die lingua franca der Smart-Contract-Entwicklung. Seit ihrer Einführung ist die EVM die dominierende Umgebung für Smart Contracts. Sie hat jedoch Schwächen. Verbrauchertaugliche Anwendungen im Webmaßstab benötigen ein Netzwerk mit hohem Durchsatz und niedriger Latenz. Nur so können sie zuverlässig betrieben werden. Die Single-Thread-Umgebung von Ethereum mit ihren schwankenden Gas-Kosten kann ein Decentralized Physical Infrastructure Network (DePIN)-Projekt mit hohem Durchsatz wie Helium nicht unterstützen. 

Als Antwort auf diese Herausforderungen bietet Solana eine leistungsstarke Alternative. Wenn du die tatsächlichen Vorteile von Solana nutzen willst, solltest du direkt auf Solana entwickeln. Dank neuer Entwicklungen können interessierte EVM-Entwickler mit Tools wie Solang und Neon EVM migrieren und dabei vertraute Werkzeuge und Sprachen verwenden. Dieser Artikel bietet einen umfassenden Leitfaden zur Architektur von Solana, vergleicht sie mit Ethereum und zeigt, wie EVM-Entwickler mit der Entwicklung auf Solana beginnen können. Solana ist die leistungsfähigste Blockchain auf dem Markt. Sie gewinnt an Dynamik und Aufmerksamkeit und zieht renommierte verbrauchertaugliche Anwendungen an. Warum darauf warten, dass Ethereum skaliert, wenn du schon heute die Vorteile einer schnellen, skalierbaren Blockchain nutzen kannst?

Wenn du bis hierhin gelesen hast: Danke, Anon! Trage unten deine E-Mail-Adresse ein, damit du keine Neuigkeiten rund um Solana verpasst. Willst du tiefer einsteigen? Tritt unserem Discord bei und entwickle schon heute die Zukunft auf der leistungsfähigsten Blockchain.

Weitere Ressourcen

• Solana für den Unternehmenseinsatz bewerten: Ein umfassender Leitfaden
• Neon EVM
• Solang-Dokumentation für Solana
• Das Rust-Buch
• Das Solana-Programmiermodell: Eine Einführung in die Entwicklung auf Solana
• Tower BFT: Solanas leistungsstarke Implementierung von PBFT
• Was ist SVM – die Solana Virtual Machine?