Um von EVM zu SVM (Solana) zu wechseln, müssen Sie mehrere wichtige Unterschiede zwischen den virtuellen Maschinen verstehen. In diesem Artikel werden einige dieser Unterschiede erläutert, darunter Konten, Gebühren, Transaktionen, Smart Contracts (Programme) und mehr. Außerdem wird die Einrichtung für Entwickler einschließlich Tools und SDKs erläutert.

Am Ende verfügen die Entwickler über das erforderliche Wissen, um ihre Solana-Reise zu beginnen.

Die wesentlichen Unterschiede verstehen 

Sehen wir uns zunächst den wichtigsten Unterschied zwischen EVM und SVM an: das Design des Kontomodells.

Kontomodell

Im Gegensatz zu Ethereum wurde Solana so konzipiert, dass es mehrere Kerne nutzt und parallele Transaktionen unterstützt. Um dies zu erreichen, verwendet Solana ein Kontomodell.

Ein Konto bei Solana ist ein Datensatz im Solana-Ledger, der entweder Daten enthält (ein Datenkonto) oder ein ausführbares Programm ist (ein Smart Contract oder Programm bei Solana).

Wie bei Ethereum hat jedes Konto eine Adresskennung. Im Gegensatz zu Ethereum, wo jeder Smart Contract ein Konto ist, bei dem die Ausführungslogik und der Speicher miteinander verknüpft sind, sind die Smart Contracts von Solana jedoch vollständig zustandslos. Der Status muss an die Konten übergeben werden, damit sie ausgeführt werden können.

Schauen wir uns ein Codebeispiel an. Im Solidity-Code unten ist der Status mit der Zeile int private count = 0 an den Smart Contract gebunden.

Bei Rust (Solana) gibt es im Smart Contract eine Struktur mit der Angabe „initialize_counter“. Dieser erste Zähler erstellt ein Konto mit einem Zählerstand von 0. Das Konto wird an diesen Zähler übergeben, um den Zählerstand zu erhöhen. Dadurch wird verhindert, dass der Status im Smart Contract selbst gespeichert wird.

Bei Solana werden Daten in separaten Konten außerhalb des Programms gespeichert. Um die Logik in einem Programm auszuführen, übergeben Sie das Konto, auf dem die Logik ausgeführt werden soll.

Bei diesem Zählerprogramm wird beim Aufruf der Inkrementfunktion dem Programm ein Zählerkonto übergeben, welches anschließend den Wert auf dem Zählerkonto hochzählt.

Vorteile des Account-Modell-Designs

Einer der Hauptvorteile dieses Kontomodells ist die Wiederverwendbarkeit des Programms.

Mit der ERC20-Schnittstelle auf Ethereum muss ein Entwickler jedes Mal, wenn er ein neues Token erstellt, den ERC20-Smart Contract mit seinen angegebenen Werten erneut auf Ethereum bereitstellen. Diese erneute Bereitstellung verursacht hohe Kosten.

Mit Solana ist es jedoch nicht erforderlich, einen neuen Smart Contract zu erstellen und bereitzustellen, um ein neues Token zu erstellen. Erstellen Sie stattdessen mithilfe des Solana-Token-Programms ein neues Konto, das sogenannte Mint-Konto, und geben Sie Details wie die Anzahl der Token, Dezimalstellen, wer prägen darf und mehr an.

Und das geht ganz einfach, indem man eine Transaktion an das Token-Programm sendet. Mit der Solana Program Library CLI ist das beispielsweise nur ein einziger Befehl:

Lokale Gebührenmärkte

Ein weiterer Vorteil des Kontomodells besteht darin, dass die Gebührenmärkte lokal pro Konto sind.

Auf Ethereum sind die Gebührenmärkte global. Wenn eine NFT-Sammlung viral geht und jeder sie prägt, steigen die Gebühren für alle. Aber auf Solana sind die Gebührenmärkte lokal pro Konto, sodass nur diejenigen, die diese NFT-Sammlung prägen, die erhöhten Gebühren zahlen. Benutzer, die nicht teilnehmen, sind davon nicht betroffen.

Gebühren

Lassen Sie uns tiefer in die Gebühren eintauchen. Bei Solana werden die Gebühren in drei Kategorien unterteilt: Grundgebühr, Prioritätsgebühr und Miete. Sehen wir uns jede einzelne an.

• Die Grundgebühr wird anhand der Anzahl der Signaturen in einer Transaktion berechnet. Jede Signatur kostet 5000 Lamports (0,000000001 Sol = 1 Lamport). Wenn eine Transaktion 5 Signaturen hat, beträgt die Grundgebühr 25000 Lamports.

• Die Prioritätsgebühr ist eine optionale Gebühr, die einer Transaktion hinzugefügt werden kann, um ihr Priorität zu verleihen. Diese Gebühr basiert auf der Anzahl der in der Transaktion verwendeten Recheneinheiten. Ähnlich wie Ethereum-Gas ist diese Gebühr ein einfaches Maß für die für die Transaktion erforderlichen Rechenressourcen.

• Die letzte Gebühr, die Miete, ist eher eine Kaution. Wenn Entwickler Konten erstellen oder Speicherplatz im Netzwerk zuweisen, müssen sie SOL hinterlegen, damit das Netzwerk ihr Konto behält. Die Miete wird auf Grundlage der Anzahl der im Netzwerk gespeicherten Bytes berechnet, und für die Speicherplatzzuweisung wird eine zusätzliche Grundgebühr erhoben.

Transaktionen

Auf Solana beginnt die Programmausführung mit der Übermittlung einer Transaktion an den Cluster. Jede Transaktion auf Solana besteht aus vier Teilen:

1. Eine oder mehrere Anweisungen. Anweisungen sind die kleinste Ausführungslogik auf Solana. Man kann sie sich wie Funktionsaufrufe auf einem Ethereum-Smart-Contract vorstellen. Sie rufen Programme auf, die Aufrufe an die Solana-Laufzeit vornehmen, um den Status zu aktualisieren (z. B. Aufruf des Token-Programms, um Token von einem Konto auf ein anderes zu übertragen).

2. Eine Reihe von Konten zum Lesen oder Schreiben

3. Eine oder mehrere Unterschriften

4. Ein aktueller Blockhash oder Nonce. Anstatt einen inkrementellen Nonce wie bei Ethereum zu verwenden, wird bei Solana ein aktueller Blockhash aus dem Cluster gezogen. Mit diesem Blockhash ist die Transaktion nur für 150 Blöcke gültig, wodurch verhindert wird, dass langlebige Transaktionssignaturen zu einem viel späteren Zeitpunkt ausgeführt werden.

Ein weiterer wesentlicher Unterschied zwischen Ethereum und Solana besteht darin, dass Transaktionen bei Solana mehrere Anweisungen (Funktionsaufrufe bei Ethereum) enthalten können. Das bedeutet, dass es nicht notwendig ist, benutzerdefinierte Smart Contracts zu erstellen, um Funktionen in einer einzigen Transaktion zu verketten. Jede Anweisung kann ein separater Funktionsaufruf sein, der in der Transaktion der Reihe nach ausgeführt wird. Transaktionen sind außerdem atomar: Wenn eine Anweisung fehlschlägt, schlägt die gesamte Transaktion fehl.

Transaktionsbeschränkungen

Wie bei den Ethereum-Gasbeschränkungen gibt es auch bei Solana-Transaktionen Beschränkungen bei der Recheneinheit.

Zu den weiteren Einschränkungen gehören:

• Für jedes referenzierte Konto dürfen maximal 12.000.000 Recheneinheiten pro Block verwendet werden.

• Anweisungen können nur in einer Tiefe von 4 aufgerufen werden, bevor die Transaktion rückgängig gemacht wird.

Merkliste

Im Gegensatz zu Ethereum hat Solana keine Mempools. Solana-Validatoren leiten stattdessen alle Transaktionen an bis zu vier Leader im Leader-Zeitplan weiter. Das Fehlen eines Mempools zwingt die Transaktionen dazu, von Leader zu Leader zu springen, bis der Blockhash abläuft, reduziert aber auch den Overhead von Gossip im gesamten Cluster.

Die Solana-Entwicklerumgebung

Sehen wir uns nun einige der Entwicklertools von Solana an.

Programmiersprachen

Während Ethereum hauptsächlich Solidity zum Schreiben von Smart Contracts verwendet, nutzt Solana Rust. Wenn Sie von Ethereum umsteigen, sollten Sie das Anchor-Framework oder Neon in Betracht ziehen. Beide können Entwicklern den Einstieg erleichtern, indem sie ihnen das Erstellen in Solana mit vertrauten EVM-Tools ermöglichen.

Wie für Ethereum stehen clientseitige SDKs für viele der beliebtesten Programmiersprachen zur Verfügung, darunter JavaScript, Python und Java.

Entwickler-Tools

Solana hat derzeit kein Äquivalent zu Foundry, aber es verfügt über eine breite Palette an Tools, die denen für Solidity entsprechen.

Wenn Sie tiefer in die Materie eintauchen möchten, finden Sie hier eine ausführlichere Liste mit Entwicklerressourcen.

Erstellen von Smart Contracts

Beim Erstellen von Programmen auf Solana (oder beim Migrieren vorhandener Ethereum-Smart-Contracts) gibt es mehrere grundlegende Unterschiede – zu viele, um sie hier zu behandeln. Aber schauen wir uns einige der häufigsten an:

• Auf Solana gibt es kein direktes Mapping. Verwenden Sie stattdessen programmabgeleitete Adressen. Wie beim Mapping ermöglichen programmabgeleitete Adressen, eine Zuordnung von einem Schlüssel oder Konto zu einem in der Chain gespeicherten Wert zu erstellen.

• Auf Solana sind Programme standardmäßig aktualisierbar. Ein Smart Contract kann mit einem einfachen CLI-Befehl aktualisiert werden: solana program deploy <program_filepath>.

• Beim Schreiben eines Solidity-Smart-Contracts ist es üblich, entweder nach msg.sender oder tx.origin zu suchen. Auf Solana gibt es dazu kein Äquivalent. Jede Transaktion kann mehrere Unterzeichner haben, und die Person, die die Transaktion sendet, ist nicht unbedingt diejenige, die die Transaktion unterzeichnet hat.

Weitere Informationen zu Programmen und der Bereitstellung finden Sie in diesem Handbuch.

Erfahren Sie mehr

Dies sind einige der wichtigsten Unterschiede zwischen der Entwicklung auf Ethereum und Solana. Natürlich gibt es noch viel mehr zu lernen. Und der beste Weg, um anzufangen, ist, direkt loszulegen! Hier sind einige Ressourcen für die nächsten Schritte:

• Der Solana Playground, wo Entwickler Solana-Programme vom Browser aus schreiben, erstellen und bereitstellen können

• Eine Einführung in die Solana-Entwicklung mit dem Solana Playground

• Ein genauerer Blick auf die Unterschiede zwischen der Entwicklung auf Ethereum und Solana 

• Das Solana Bootcamp