13 Minuten Lesezeit

Übersicht

Die Solana-Blockchain ist ein leistungsstarkes Werkzeug, das Tausende von Transaktionen pro Sekunde bei nahezu null Transaktionsgebühren ermöglicht. Wenn Sie neu im Bereich Web3 sind oder bisher auf EVM-basierten Blockchains entwickelt haben, hilft Ihnen dieser Leitfaden dabei, die Grundelemente von Solana zu verstehen und Ihre Reise in die Solana-Entwicklung zu beginnen. Wenn Sie bereits auf Solana entwickeln, nutzen Sie diesen Leitfaden als Nachschlagewerk, um Ihr Verständnis der Grundlagen von Solana weiter zu vertiefen.

In diesem Leitfaden werden wir die grundlegenden Bausteine von Solana behandeln, insbesondere: Konten, Programme, Anweisungen, Transaktionen, RPCs und Abonnements. Los geht’s!

TLDR

• Konten sind wie Dateien in einem herkömmlichen Betriebssystem – fast alles auf Solana ist ein Konto: Benutzer-Wallets, Programme, Datenprotokolle und sogar Systemprogramme
• Programme (die in anderen Blockchains als „Smart Contracts“ bezeichnet werden) sind eine besondere Art von „ausführbaren“ Konten – sie sind zustandslos und führen Code ausschließlich auf der Grundlage von durch den Nutzer eingegebenen Parametern aus. Anstatt sich selbst zu aktualisieren, verfügen Programme über spezifische Befugnisse, um die Daten (oder den Zustand) anderer Konten zu aktualisieren, die ihnen „gehören“.
• Benutzer signieren und senden Transaktionen (Bündel programmspezifischer Anweisungen) über einen RPC an einen Solana-Cluster, um den Programmen mitzuteilen, was sie tun sollen.
• Solana nutzt einen einzigartigen Konsensmechanismus namens „Proof of History“ (PoH), der auf Zeit und Kryptografie basiert, um Transaktionen, die an das Netzwerk gesendet werden, mit einem Zeitstempel zu versehen und zu ordnen.
• Programme und Transaktionsunterzeichner genehmigen Änderungen an bestimmten Datenkonten in der Blockchain, um den Zustand des Netzwerks zu aktualisieren.

Lust auf mehr? Dann lies weiter! 👇

Was ist Solana?

Solana ist eine Open-Source-Blockchain, die auf Geschwindigkeit und Kosteneffizienz optimiert ist und die globale Synchronisierung von Informationen und Zuständen ermöglicht. Solana nutzt eine einzigartige Variante des Proof-of-Stake-Konsensverfahrens namens „Proof of History“, das eine granular verifizierbare Verzögerungsfunktion einsetzt, um an das Netzwerk gesendete Transaktionen effektiv mit einem Zeitstempel zu versehen und zu ordnen. Anatoly Yakovenko schreibt im Solana-Whitepaper: „Es verwendet eine kryptografisch sichere Funktion, die so geschrieben ist, dass die Ausgabe nicht aus der Eingabe vorhergesagt werden kann und vollständig ausgeführt werden muss, um die Ausgabe zu erzeugen“ (3). „Der Leader ordnet die Benutzernachrichten so an, dass sie von anderen Knoten im System effizient verarbeitet werden können, wodurch der Durchsatz maximiert wird“ (2).

*Das war so ziemlich alles, was wir in diesem Artikel über die Laufzeitumgebung von Solana sagen werden; nun wollen wir uns darauf konzentrieren, wie Sie mit Solana interagieren und darauf entwickeln können. Wenn Sie sich eingehender mit der Architektur von Solana und den theoretischen Grundlagen einiger seiner Designmerkmale befassen möchten, finden Sie hier einige hervorragende Ressourcen:

• Solana-Whitepaper
• Anatoly Yakovenkos (Mitbegründer von Solana) Medium-Blog
• Solana.com

Konten

Ähnlich wie Dateien in einem Betriebssystem dienen Konten dazu, das System zu betreiben, Daten oder den Systemzustand zu speichern und Code auszuführen.

Auf Solana gibt es drei Hauptarten von Konten:

1. Datenkonten, die Informationen speichern und den Zustand des Netzwerks verwalten. Es gibt zwei Arten von Datenkonten:
   • Systemeigene Konten (allgemein als „Wallets“ bekannt) [Beispiel: Ein Benutzer-Wallet]
   • Aus Programmen abgeleitete Konten (oft als PDAs bezeichnet) – ein gängiges Beispiel ist das Token-Konto eines Benutzers für ein bestimmtes Token. Es wird vom Solana SPL-Token-Programm abgeleitet. [Beispiel: Das Token-Konto eines Benutzers]
2. Programmkontos, die ausführbaren Code enthalten. Wir werden im folgenden Abschnitt näher darauf eingehen, aber diese Konten sind zustandslos (das heißt, Daten werden durch sie hindurchgeleitet, ohne dass sie dadurch aktualisiert werden) [Beispiel: Programmkonto „Candy Machine v2“]
3. Native Systemkonten (z. B. Systemprogramm, Abstimmung, Staking, BPF-Loader) [Beispiel: Solana-Systemprogramm]

In diesem Artikel geht es vor allem um Punkt 1 und Punkt 2. Wenn Sie mehr über Punkt 3, die nativen Systemkonten, erfahren möchten, besuchen Sie docs.solana.com.

Kurz gesagt: Fast alles auf Solana ist ein Konto. Die häufigste Art von Konto ist die Wallet eines Nutzers, ein Datenkonto, das den Stand des SOL-Guthabens eines Nutzers verwaltet.

Jedes Konto verfügt über eine eindeutige Adresse bzw. einen öffentlichen Schlüssel (ähnlich wie ein Dateipfad) sowie eine Reihe zugehöriger Metadaten:

• Lamports: Die Anzahl der Lamports, die diesem Konto gehören (64-Bit-Ganzzahl ohne Vorzeichen)*
• Eigentümer: Das Programm, dem dieses Konto zugeordnet ist (Zeichenkette mit der Adresse des Eigentümerprogramms). Eigentümerprogramme steuern, wer Schreibzugriff auf Konten hat – andere Programme können die Daten eines anderen Kontos zwar lesen, doch wenn sie versuchen würden, diese Daten zu ändern, würde die Transaktion fehlschlagen.
• executable: Gibt an, ob dieses Konto Anweisungen ausführen kann (Boolescher Wert). Ein Konto mit dem Wert „true“ für „executable“ ist eigentlich ein Programm (oder ein Smart Contract) – darauf gehen wir im nächsten Abschnitt ein.
• data: Alle zusätzlichen Daten, die mit dem Konto verknüpft sind und als Rohdaten-Byte-Array gespeichert werden
• rent_epoch: Die nächste Epoche, in der dieses Konto Miete schuldet (64-Bit-Ganzzahl ohne Vorzeichen)

* Lamports sind die kleinste Einheit von SOL, dem nativen Token von Solana (entsprechen einem Milliardstel SOL)

Die Metadaten eines beliebigen Kontos können durch Ausführen der JSON-RPC-Abfrage „getAccountInfo“ oder durch eine Suche im Solana Explorer abgerufen werden. Mit dem Solana Explorer können Sie nach jedem beliebigen Konto suchen und grundlegende Informationen darüber einsehen, um welche Art von Konto es sich handelt und welchem Programm es zugeordnet ist. Hier ist ein Beispiel für ein systemeigenes Datenkonto (die Wallet eines Benutzers):

Schauen wir uns einmal ein Beispiel für alle Kontotypen an:

Hier ist einiges los, aber alles, was Sie in dieser Abbildung sehen, ist ein Konto. Auf der linken Seite haben wir ein Systemkonto namens „System Program“, das alle Benutzer-Wallets verwaltet. Außerdem gibt es ein ausführbares Programmkonto namens „Solana SPL Token Program“, über das Nutzer SPL-Token prägen, verbrennen und übertragen können. Schließlich gibt es noch vom Programm abgeleitete Konten. In diesem Fall handelt es sich um Token-Konten, die dem Token-Programm gehören und mit dem Konto eines Nutzers verknüpft sind. Beachten Sie, dass eine Nutzer-Wallet mehrere Token-Konten haben kann.

Denken Sie daran: Sie können jede Kontoadresse im Solana Explorer suchen, um deren Metadaten abzurufen und zu erfahren, um welche Art von Konto es sich handelt und mit welchem Programm es verknüpft ist.

Lamports und Miet-Epochen Konten und Kontodaten werden im Speicher des Validators gespeichert; um dort verbleiben zu können, muss eine „Miete“ in Lamports (die im Metadatenfeld „lamports“ des Kontos angegeben ist) gezahlt werden. Je mehr Daten in Ihrem Konto gespeichert sind, desto höher ist die erforderliche Miete (Hinweis: Die derzeitige maximale Kontogröße beträgt 10 MB). Sie können Ihren Mietbedarf mithilfe der JSON-RPC-Methode „getMinimumBalanceForRentExemption“ berechnen. Validatoren sind dafür verantwortlich, alle Konten regelmäßig zu überprüfen und die Miete einzuziehen – die Konten werden zu der in der rent_epochangegebenen Epoche überprüft. Wenn der Saldo eines Kontos auf null Lamports sinkt, wird das Konto vom Netzwerk gelöscht und die Daten gehen verloren. Zum Zeitpunkt der Erstellung dieses Artikels müssen alle neuen Konten den Status „mietfrei“ aufrechterhalten, der durch das Halten von Mietgebühren im Wert von zwei Jahren auf dem Konto gewährt wird. Quelle: https://docs.solana.com/developing/programming-model/accounts Epochen sind eine Zeiteinheit auf Solana und entsprechen derzeit etwa 2,5 Tagen.

Programme

Programme werden bei Solana als „Smart Contracts“ bezeichnet – sie sind der Motor, der Informationen und Anfragen verarbeitet: von Token-Transfers und der Prägung von „Candy Machine“-Token bis hin zu „Hello World“-Protokollen und der Governance von DeFi-Treuhandkonten.

• Denken Sie daran, dass Solana-Programme zustandslose Konten sind, die als „ausführbar“ gekennzeichnet sind: „Programme gelten als zustandslos, da die in einem Programmkonto gespeicherten Primärdaten aus dem kompilierten BPF-Code bestehen.“
• Programme können mithilfe von „programmübergreifenden Aufrufen“ andere Solana-Programme nutzen oder darauf aufbauen. Dies wird oft als Kombinierbarkeit bezeichnet.
• Im Gegensatz zu vielen anderen beliebten Ketten sind die Programme erweiterbar.
• Die meisten Programme werden von Nutzern erstellt, doch Solana Labs hat eine Reihe von On-Chain-Programmen entwickelt und pflegt diese – die sogenannte Solana Program Library.

Im Grunde muss ein Benutzer einem Programm programmspezifische Anweisungen geben; das Programm verarbeitet diese Anweisungen und kann anschließend andere Programme aufrufen und/oder die ihm gehörenden, vom Programm abgeleiteten Konten aktualisieren (mehr zu PDAs weiter unten).

Programmabgeleitete Adresskonten

Eine „Program Derived Address“ (PDA) ist ein Konto, das von einem bestimmten Programm erstellt und verwaltet wird. PDAs:

• Programmen soll es gestattet sein, bestimmte Adressen – sogenannte Programmadressen – zu kontrollieren, sodass kein externer Benutzer gültige Transaktionen mit Signaturen für diese Adressen erstellen kann.
• Programmen soll es ermöglicht werden, Programmadressen, die in Befehlen enthalten sind, die über programmübergreifende Aufrufe (Cross-Program Invocations) aufgerufen werden, programmgesteuert zu signieren. Solana leitet PDAs deterministisch aus den vom Programm definierten Seeds und der Programm-ID ab. Weitere Informationen zu generierten Programmadressen finden Sie unter docs.solana.

Quelle: _https://docs.solana.com/developing/programming-model/calling-between-programs#program-derived-addresses
_

Dadurch können Programme vertrauensunabhängige Dienste wie Treuhandkonten für die sichere Abwicklung von Handelsgeschäften, Wetten oder DeFi-Protokollen anbieten. Beziehen wir uns auf unser obenstehendes Schema, so generiert das SPL-Token-Programm für einen Nutzer einen PDA auf der Grundlage der Wallet des Nutzers und der Mint-Adresse des jeweiligen Tokens. Dieser spezifische PDA speichert den Status bzw. die Daten zur Menge des Tokens, die sich im Besitz des Nutzers befindet.

Schauen wir uns einmal genauer an, wie wir Programme mithilfe von Befehlen und Transaktionen zum Laufen bringen.

Anleitung

Befehle weisen ein Programm im Kern an, etwas zu tun. Solana definiert Befehle als „die kleinste zusammenhängende Einheit der Ausführungslogik in einem Programm“ (Quelle: docs.solana.com/terminology).

Eine Anweisung besteht aus drei Teilen:

1. Der öffentliche Schlüssel des Programms, das Sie aufrufen werden,
2. ein Array von Konten, die es lesen oder ändern wird, und
3. Ein Byte-Array mit allen zusätzlichen Daten, die für die Ausführung des Programms erforderlich sind (programmspezifisch)

Dieser letzte Punkt ist entscheidend –die Anweisungen sind programmspezifisch. Die Transaktion schlägt fehl, wenn Sie eine falsche Programm-ID eingeben oder die erwartete Datenstruktur, die an das Programm übergeben werden muss, nicht kennen.

In JavaScript sieht eine Transaktionsanweisung in etwa so aus:

new TransactionInstruction({
	programId: new PublicKey(PROGRAM_ID),
	keys: [
		{ pubkey: signerKeypair.publicKey, isSigner: true, isWritable: true },
		{ pubkey: pda, isSigner: false, isWritable: true },
		{ pubkey: SystemProgram.programId, isSigner: false, isWritable: false },
	],
	data: Buffer.from(SOME_ENCODED_DATA),
})

An dieser Stelle sei auf die für einen Transaktionsbefehl erforderlichen Kontoinformationen hingewiesen. Wir müssen den öffentlichen Schlüssel des Kontos angeben, ob dieses Konto als Unterzeichner der Transaktion fungiert oder nicht und ob das Konto als Teil der Transaktion geschrieben wird (dies trägt zur schnellen Ausführung von Solana bei). Im obigen Beispiel signiert ein Benutzer die Wallet, und Daten werden auf einen PDA geschrieben. Häufig ist es notwendig, auch Systemprogrammkonten einzubeziehen (z. B. zum Anlegen eines neuen Kontos). Schließlich übergeben wir SOME_ENCODED_DATA. Der erforderliche Datentyp wird innerhalb des Programms definiert. Das Programm muss die Eingabedaten deserialisieren, um sie korrekt verarbeiten zu können.

Transaktionen

Transaktionen dienen dazu, einem Programm im Netzwerk Anweisungen zu übermitteln. Transaktionen können mehrere Anweisungen bündeln, um mehrere Vorgänge gleichzeitig zu verarbeiten. Stellen Sie sich zum Beispiel vor, Sie hätten drei verschiedene Anweisungen: eine Anweisung für Wallet A, 1 $SOL an Wallet B zu senden, eine Anweisung für Wallet B, 33 $USDC an Wallet A zu senden, und eine Anweisung, einen Vermerk zur Transaktion hinzuzufügen, der besagt: „Wallet A tauscht am YYYY-MM-DD 1 $SOL gegen 33 $USDC mit Wallet B.“ Obwohl diese Anweisungen jeweils separat an das Netzwerk gesendet werden könnten, was würde passieren, wenn eine Anweisung fehlschlägt, die anderen jedoch erfolgreich sind? Es käme zu einer Situation, in der eine Person ihre Token erhält, die andere jedoch nicht. Durch das Bündeln von Anweisungen in einem Paket können wir sicherstellen, dass alle unsere Transaktionen gemeinsam erfolgreich sind oder gemeinsam fehlschlagen.

Transaktionen sind derzeit auf 1.232 Bytes begrenzt. Jede Transaktion muss Folgendes enthalten:

• ein Array aus einer oder mehreren Transaktionsanweisungen
• ein Array aller Kontoadressen, mit denen das Programm interagieren wird
• Eine Reihe von Signaturen: Ein Teil der Konten, die wir unserer Transaktion übergeben, muss zudem eine Signatur enthalten. „Diese Signaturen signalisieren On-Chain-Programmen, dass der Kontoinhaber die Transaktion autorisiert hat. In der Regel nutzt das Programm diese Autorisierung, um die Belastung des Kontos oder die Änderung seiner Daten zuzulassen.“ (Quelle: docs.solana.com). Dies könnte beispielsweise auch erforderlich sein, damit ein Urheber die Echtheit eines NFT überprüfen kann.
• Ein aktueller Blockhash: Ein Blockhash ist im Grunde ein PoH-Zeitstempel. Solana verwirft standardmäßig „alte“ Transaktionen, um Doppelzählungen zu vermeiden, damit Validatoren Transaktionen nur anhand eines sehr aktuellen Stapels überprüfen können und um den Nutzern schnell Gewissheit darüber zu geben, ob ihre Transaktion verarbeitet wurde (oder fehlgeschlagen ist, sodass sie es erneut versuchen können). Das Abrufen eines aktuellen Block-Hashs vor dem Absenden einer Transaktion ermöglicht es dem Netzwerk, das Alter unserer Transaktion zu ermitteln und festzustellen, wann sie ablaufen sollte (falls dies jemals erforderlich sein sollte).

Sobald das Netzwerk eine Transaktion empfängt, gibt es eine Transaktions-ID (eine Base-58-kodierte Zeichenfolge) zurück, mit der die Transaktionsdetails abgerufen werden können.

Lassen Sie uns besprechen, wie Sie Ihre Transaktion ins Netzwerk bringen können!

RPC

JSON-RPC ist ein in JSON kodiertes Remote-Procedure-Call-Protokoll, das es Benutzern ermöglicht, Informationen an einen Solana-Cluster zu senden und eine Antwort vom Netzwerk zu erhalten. Solana unterhält derzeit drei Netzwerkcluster:

• Devnet: eine Testumgebung zum Prüfen der Funktionalität von Anwendungen und Methoden
• Testnetz: Eine Entwicklungsumgebung, in der alle geplanten aktuellen System-Upgrades einem Stresstest unterzogen werden
• Mainnet-Beta: Produktionsumgebung

Clients können über einen Solana-Knoten mithilfe von JSON-RPC-Anfragen Lese- oder Schreibanfragen an jeden der drei Cluster stellen. Die Knoten fungieren gewissermaßen als „Flugsicherung“ für die Bearbeitung von Anfragen an das Netzwerk. Clients stellen über die Klasse „Solana Web3 Connection“ eine Verbindung zu Solana-Knoten her:

const HTTP_ENDPOINT = 'https://example.solana-devnet.quiknode.pro/000/'
const SOLANA_CONNECTION = new Connection(HTTP_ENDPOINT)

Im obigen Beispiel ist „HTTP_ENDPOINT“ eine HTTP-URL, die auf einen Solana-Knoten verweist, der Ihre Anfrage schließlich an einen der drei Cluster weiterleitet.

Für jede Anfrage ist ein API-Endpunkt erforderlich, um eine Verbindung zum Netzwerk herzustellen. Und genau hier kommt Quicknode ins Spiel! Sie können gerne öffentliche Knoten nutzen oder Ihre eigene Infrastruktur bereitstellen und verwalten; wenn Sie jedoch achtmal schnellere Antwortzeiten wünschen, können Sie die mühsame Arbeit gerne uns überlassen.

Erfahren Sie, warum sich über 50 % der Projekte auf Solana für Quicknode entscheiden, und registrieren Sie sich hier für ein Konto. Melden Sie sich einfach an und passen Sie den HTTP_ENDPOINT in Ihrer App an den in Ihrem Konto-Dashboard angegebenen Wert an – schon kann es losgehen!

Erfahren Sie, warum sich über 50 % der Projekte auf Solana für Quicknode entscheiden, und registrieren Sie sich hier für ein Konto. Melden Sie sich einfach an und passen Sie den HTTP_ENDPOINT in Ihrer App an den in Ihrem Konto-Dashboard angegebenen Wert an – schon kann es losgehen!

Sobald Sie eine Verbindung zu einem Solana-Cluster hergestellt haben, können Sie zahlreiche Lese- und Schreibvorgänge im Netzwerk durchführen. Eine vollständige Liste der RPC-Methoden sowie die dazugehörige Dokumentation finden Sie in den Quicknode-Dokumenten. Zwar hat jede Methode ihren eigenen Zweck, doch einige davon sind für die bisherigen Ausführungen in diesem Leitfaden besonders relevant:

• sendTransaction – sendet eine Transaktion an das Solana-Netzwerk
• getAccountInfo – ruft die zu einem beliebigen Konto gehörenden Metadaten ab
• getLatestBlockhash – gibt den aktuellsten Block-Hash aus dem Netzwerk zurück

Mit HTTP-Aufrufen können wir das Netzwerk anweisen, bestimmte Aktionen auszuführen (z. B. eine Transaktion und die dazugehörigen Anweisungen zu verarbeiten, aktuelle Statusinformationen zu einem Konto zurückzugeben usw.). Was aber, wenn wir möchten, dass das Netzwerk uns über Änderungen am Kontostatus benachrichtigt?

Abonnements

Abonnements sind eine besondere Art von RPC-Anfragen, bei denen wir anstelle eines HTTP-Endpunkts eine WebSocket-Anfrage (WSS) stellen. Solana Web3 JSON RPC umfasst mehrere Abonnementmethoden (z. B. „accountSubscribe“, das auf Änderungen an den Lamports oder Daten eines Kontos überwacht). Wir können diese Ereignisse dann mit einer Callback-Funktion abonnieren, sodass bei jeder Änderung im Netzwerk eine gewünschte Aktion ausgeführt wird.

Der Konstruktor der Klasse „Connection“ ermöglicht es uns, ein optionales „commitmentOrConfig“-Objekt zu übergeben. Darin können wir ein „wsEndpoint“-Objekt übergeben. Dies ist eine Option, mit der Sie eine Endpunkt-URL für den JSON-RPC-Websocket-Endpunkt des Full Nodes angeben können. Wenn Sie einen Quicknode-Endpunkt erstellt haben, sollte diese Option auf der rechten Seite der Seite Ihres Endpunkts angezeigt werden.

const HTTP_ENDPOINT = 'https://example.solana-devnet.quiknode.pro/000/'
const WSS_ENDPOINT = 'wss://example.solana-devnet.quiknode.pro/000/'
const solanaConnection = new Connection(HTTP_ENDPOINT, {
	wsEndpoint: WSS_ENDPOINT,
})

Was passiert, wenn Sie keinen wsEndpoint übergeben? Nun, Solana berücksichtigt dies mit einer Funktion namens „makeWebsocketUrl“, die in der URL Ihres Endpunkts „https“ durch „wss“ bzw. „http“ durch „ws“ ersetzt (Quelle). Da alle Quicknode-HTTP-Endpunkte über einen entsprechenden WSS-Endpunkt mit demselben Authentifizierungstoken verfügen, können Sie diesen Parameter weglassen, es sei denn, Sie möchten einen separaten Endpunkt für Ihre WebSocket-Abfragen verwenden.

Wenn Sie sich eingehender mit der Erstellung von WebSocket-Abonnements befassen möchten, lesen Sie unseren Leitfaden: So erstellen Sie Solana-WebSocket-Abonnements.

Alles unter einen Hut bringen

Okay! Das sind eine Menge Informationen – wahrscheinlich hast du bereits erste Zusammenhänge zwischen diesen Grundelementen erkannt, aber lass uns noch einmal kurz zusammenfassen, bevor wir alle Teile miteinander verknüpfen:

• Fast alles auf Solana ist ein Konto: Benutzer-Wallets, Programme, Systemprogramme, Programmdaten usw.
• Programme sind zustandslos – sie verarbeiten Befehle, können andere Programme aufrufen und den Zustand der ihnen zugehörigen Datenkonten ändern.
• Anweisungen sind programmspezifisch und geben einem Programm vor, was es tun soll.
• Transaktionen bündeln eine oder mehrere Anweisungen mit einer Signatur, um ein Programm zur Ausführung einer oder mehrerer Aufgaben zu autorisieren.
• Mithilfe von RPC-Protokollen können Clients Lese- und Schreibanfragen über einen Knoten wie Quicknode an einen der drei Cluster von Solana senden.
• Kunden können Netzwerkänderungen über WebSocket-Anfragen mittels des RPC-Anbieters abonnieren.

Schauen wir uns ein anschauliches Beispiel an. Stellen Sie sich ein Programm namens „GM“ vor, das einen Zähler enthält, der jedes Mal protokolliert, wenn ein Benutzer eine „GM“-Nachricht an das Programm sendet.

Im obigen Beispiel erstellt ein Client eine Transaktion, die mehrere Transaktionsanweisungen enthält. Die Anweisungen sind programmspezifisch und müssen daher der erwarteten Struktur des GM-Programms entsprechen. Der Client signiert die Transaktion und sendet sie über einen RPC-Anbieter wie Quicknode mithilfe der Connection-Klasse an einen Solana-Cluster. Der RPC-Anbieter leitet die Anfrage an den Cluster weiter. Das Programmkonto führt die empfangenen Eingabeanweisungen aus und verarbeitet sie. Das Programmkonto ist zustandslos und ändert sich nicht, autorisiert jedoch eine Änderung der Daten des PDA, um den Wert des GM-Zählers zu erhöhen. Ein vom Client erstelltes Abonnement überwacht Änderungen am PDA; anschließend benachrichtigt das Netzwerk den Client, dass das Konto geändert wurde.

Zusammenfassung

Puh! Das war eine Menge an Informationen, die wir gerade durchgenommen haben. Scheuen Sie sich nicht, den Text mehrmals durchzulesen, um sicherzustellen, dass Sie diese Konzepte verstanden haben.

Nachdem Sie nun ein fundierteres Verständnis von Solana haben, ist es an der Zeit, loszulegen! Probieren Sie einige unserer Solana-Entwicklungsanleitungen aus, um den Einstieg zu finden. Hier sind ein paar Beispiele:

• So erstellen und versenden Sie (versionierte) Transaktionen auf Solana
• So prägt man mit Typescript ein NFT auf Solana
• So lassen sich Solana-Transaktionsverläufe anhand von Protokollen nachverfolgen

Hast du Fragen zu einem dieser Konzepte oder möchtest du einfach nur über das Thema fachsimpeln? Melde dich bei uns auf Discord oder Twitter und erzähl uns, woran du gerade arbeitest!

Wir ❤️ Feedback!

Wenn Sie Anregungen oder Fragen zu diesem Leitfaden haben, teilen Sie uns diese bitte mit. Wir freuen uns auf Ihre Rückmeldung!

Literaturverzeichnis und Quellenangaben

• https://solanacookbook.com/core-concepts/accounts.html#deep-dive
• https://www.quicknode.com/guides/solana-development/an-introduction-to-the-solana-account-model
• https://medium.com/@anatolyyakovenko
• https://docs.solana.com/developing/programming-model/accounts
• https://docs.solana.com/developing/clients/jsonrpc-api#getaccountinfo