Solana

Solana ist ein Layer-1-Netzwerk mit einem Programm- und Account-Modell, das sich von dem von Ethereum unterscheidet. Programme enthalten ausführbare Logik, Accounts speichern Daten und Guthaben. Rust ist eine gängige Sprache für die Entwicklung von Programmen, mit Tools wie Anchor, die beim Formulieren von Schnittstellen und Einschränkungen helfen.

Das Netzwerk versucht, Operationen parallel zu verarbeiten, wenn ihre Zugriffe auf den Zustand dies zulassen. Dieses Design kann für Anwendungen mit häufigen Interaktionen geeignet sein, zwingt aber dazu, zu überlegen, welche Accounts jede Operation teilt. Die Kapazität des Protokolls entspricht nicht automatisch der Leistung jeder beliebigen Anwendung.

Solana kombiniert Proof of Stake und sein Konsensprotokoll mit Proof of History als Mechanismus zur zeitlichen Ordnung. Proof of History allein ist nicht der gesamte Konsens. Die Dauer eines Slots steht auch nicht für die Finalität einer Transaktion: Die Clients unterscheiden Stufen wie processed, confirmed und finalized.

Eine Transaktion gibt an, welche Accounts sie verwendet und welche Zugriffe sie benötigt. Die Runtime kann kompatible Arbeit parallelisieren, während kollidierende Zugriffe diese Nebenläufigkeit begrenzen. Die Anwendung berücksichtigt zudem Compute-Budget, Prioritätsgebühren und die Gültigkeitsdauer der Transaktion.

Ein System für digitale Tickets kann die Datensätze der einzelnen Tickets trennen, um Konflikte zwischen unabhängigen Operationen zu reduzieren. Die Instruktionen prüfen Eigentum, Autorisierung und Nutzungsstatus; der Client bereitet die Accounts vor und zeigt die angeforderte Signatur an. Getestet wird das Design mit gleichzeitiger Einlösung desselben Tickets und mit Versuchen, fremde Accounts zu verwenden.

Der Betrieb umfasst die Bereitstellung von Guthaben für Gebühren und die Speicheranforderungen der Accounts. Die Kosten werden mit der verwendeten Konfiguration und dem verwendeten Programm berechnet. Das Backend bewahrt Referenzen auf und fragt das Ergebnis ab, bevor es eine Aktion erneut sendet, deren Antwort verloren gegangen ist.

Eine Migration von der EVM erfordert in der Regel ein Redesign der Smart Contracts und der Integration, nicht nur den Wechsel der RPC-URL. Geprüft werden Account-Formate, Signaturen, Indizes und Deployment-Tools. Auch die Upgrade-Authority des Programms muss definiert und geschützt werden, denn sie bestimmt, wer sein Verhalten ändern kann.

Die Tests müssen den Ablauf von Transaktionen, Compute-Fehler, Konkurrenz um Accounts und zeitliche Abweichungen zwischen Datenquellen abdecken. Angekündigte Verbesserungen an Clients oder Konsens dürfen nicht als aktivierte Funktionen dargestellt werden, ohne ihren Status zu prüfen. Die Wahl wird mit der tatsächlichen Last und den Wiederherstellungsanforderungen des Produkts begründet.