Solana mit Rust und Anchor 1.x: So programmieren Sie 2026

In Solana speichert ein Programm keinen eigenen Zustand. Das Programm ist ein ausführbares Konto mit Code, und die Daten, mit denen es arbeitet (Guthaben, Konfigurationen, Nutzerdatensätze), liegen in anderen Konten, die ihm die Transaktion bei jeder Instruktion übergibt, zusammen mit der Angabe, welche davon signiert haben und welche verändert werden dürfen. Als Sprache für diese Programme dient vor allemRustundAnchorist das Framework, das einen Großteil des Codes erzeugt, der diese Konten liest, prüft und zurückschreibt.

Diese Trennung bündelt die Sicherheit an einem Punkt: Da der Client entscheidet, welche Konten er übergibt, muss das Programm prüfen, dass jedes Konto das ist, was es vorgibt zu sein, dass es dem richtigen Inhaber gehört und dass es nicht an unzulässiger Stelle doppelt vorkommt. Anchor 1.x, seit April 2026 stabil, automatisiert standardmäßig mehr Prüfungen als frühere Versionen, darunter die Ablehnung doppelter veränderbarer Konten. Rust ohne Framework und Pinocchio geben Kontrolle über Rechenaufwand und Programmgröße, verlangen dafür aber, jede dieser Prüfungen selbst zu schreiben und zu testen.

Warum ein Solana-Programm die erhaltenen Konten validiert

Jedes Konto hat einen Eigentümer, nämlich das Programm, das seine Daten ändern darf, und jede Instruktion deklariert die Liste der Konten, die sie lesen oder schreiben wird. Die Laufzeitumgebung setzt allgemeine Regeln durch, etwa dass nur das Eigentümerprogramm die Daten eines Kontos schreibt oder dass nur Konten als Signierende gelten, die die Transaktion signiert haben. Die fachliche Bedeutung der einzelnen Konten kennt sie jedoch nicht. Sie weiß nicht, dass ein Einlagekonto dem signierenden Nutzer gehören muss oder dass das Ziel einer Überweisung vom Ursprung verschieden sein muss. Diese Regeln schreibt das Programm, mit oder ohne Hilfe eines Frameworks.

Die vorherige Deklaration der Konten ermöglicht es außerdem, Transaktionen parallel auszuführen, die nicht in dieselben Konten schreiben, und sie wird mit einem Rechenbudget kombiniert. Laut den Konstanten des Clients Agave stehen jeder Instruktion eines Programms standardmäßig 200.000 Compute Units zur Verfügung, und eine Transaktion kann höchstens 1.400.000 anfordern (execution_budget.rs, Version 4.4.1). Jede Prüfung verbraucht einen Teil dieses Budgets, und daraus ergibt sich die Abwägung, ob man das Programm mit Anchor schreibt oder ohne.

Anchor 1.x: was sich seit April 2026 geändert hat

Anchor veröffentlichte am 2. April 2026 mit 1.0.0 seine erste stabile Hauptversion; die aktuelle Version mit Stand 8. November ist1.2.2, erschienen am 28. Oktober. DieVersionshinweisen zu 1.0machen einen Teil der älteren Anleitungen hinfällig: Das TypeScript-Paket wechselt von @coral-xyz/anchor zu @anchor-lang/core, das Framework zielt auf Solana 3.x (empfohlen ist 3.1.10), anchor test und anchor localnet nutzen standardmäßig Surfpool statt solana-test-validator, und anchor init legt die Tests mit einer LiteSVM-Vorlage an, die sie im selben Prozess ausführt, ohne einen Validator zu starten.

Weitere Änderungen betreffen unmittelbar die Sicherheit. Ein innerhalb von #[derive(Accounts)] als AccountInfo deklariertes Konto erzeugt eine Compiler-Warnung, die UncheckedAccount empfiehlt, einen Typ, dessen Name explizit macht, dass Anchor ihn nicht prüft. Der Aufruf von .reload() auf einem Account prüft dessen Eigentümer erneut, und das IDL wird im Program Metadata Program veröffentlicht, sodass alte IDL-Konten geschlossen werden müssen, bevor ein mit 1.0 kompiliertes Programm deployt wird. Version 1.2.1 vom Oktober ergänzte die Kompatibilität mit den Crates von Solana v4. Das Anchor-Team pflegt zudem die älteren Versionslinien: Am 3. November 2026 veröffentlichte es die Versionen 0.30.4, 0.31.3 und 0.32.3.

Dasselbe Konto als Ursprung und Ziel einer Überweisung

Nehmen wir ein hypothetisches Programm, das interne Guthaben in Konten vom Typ Vault führt, und eine Instruktion transfer, die zwei davon erhält, from und to, beide als veränderbare Account<'info, Vault> deklariert, dazu den Signierenden. Der Code zieht den Betrag von from.balance ab und addiert ihn zu to.balance. Die Einschränkung has_one = owner auf from prüft, dass das Feld owner dieses Kontos mit dem Schlüssel des Signierenden übereinstimmt, sodass niemand Guthaben aus einem fremden Vault bewegen kann. Es fehlt eine Regel, die fachlich als selbstverständlich gilt: Ursprung und Ziel sind verschiedene Konten.

Übergibt ein Nutzer sein eigenes Konto als from und als to, deserialisiert Anchor zwei Kopien derselben Daten. Die Subtraktion wird auf die eine Kopie angewendet, die Addition auf die andere, und am Ende der Instruktion werden beide wieder in dasselbe Konto geschrieben. Wie dasIssue #3825im Anchor-Repository beschreibt, überschreibt der Zustand der zweiten Kopie den der ersten: Die Belastung verschwindet, und das Guthaben wächst um den überwiesenen Betrag. In Versionen vor 1.0 ließ sich das nur mit einer expliziten Prüfung verhindern, etwa einer Einschränkung constraint = from.key() != to.key(), an die der Entwickler selbst denken musste.

Seit 1.0.0 lehnt Anchor standardmäßig ab, dass dasselbe Konto in einer Instruktion zweimal als veränderbar auftritt, und lässt dies nur zu, wenn eines davon die Einschränkung dup trägt (CHANGELOG, PR #3946;Referenz der Einschränkungen). Eine spätere Korrektur beschränkte die Prüfung auf die Typen, die am Ende der Instruktion serialisiert werden (Account, LazyAccount, InterfaceAccount und Migration), denn nur diese können sich gegenseitig überschreiben. Mit Anchor 1.x schlägt der obige Fall fehl, ohne etwas zu schreiben. Deklariert eine Instruktion eines dieser Konten als UncheckedAccount, greift der Schutz nicht, und die Prüfung liegt wieder in der Verantwortung des Programms.

Der Abnahmetest deckt beide Seiten ab. Die gültige Überweisung zwischen zwei Konten erhält die Summe der Guthaben; die Überweisung von einem Konto an sich selbst wird abgelehnt; ein Signierender, der nicht Eigentümer des Ursprungskontos ist, erhält einen Fehler, und ein Konto eines anderen Programms mit kompatiblem Datenformat wird nicht akzeptiert, weil Account den Eigentümer vor dem Deserialisieren prüft. Mit der LiteSVM-Vorlage, die anchor init erzeugt, werden diese vier Tests Teil der Continuous Integration, ohne dass ein lokaler Validator nötig ist.

Rust ohne Framework und Pinocchio: Kontrolle über den Rechenaufwand, Prüfungen von Hand

Das Programm ohne Anchor zu schreiben bedeutet, die Konten als Liste zu erhalten und jede Eigenschaft im Code zu prüfen: Signierender, Eigentümer, Datentyp, Beziehung zwischen Konten und Duplikate.Pinocchio, die Bibliothek von Anza, treibt diesen Ansatz weiter. Sie hat außer den Typen des Solana-SDK für Programme keine externen Abhängigkeiten, ist no_std, liest die Eingabedaten ohne Kopie (Zero-Copy) und ist auf Compute Units und Binärgröße optimiert. Ihre Dokumentation erläutert, dass der Standard-entrypoint! Compute Units verbraucht, bevor das Programm überhaupt mit der Ausführung beginnt. Version 0.12.0 erschien am 28. Oktober 2026.

Im Fall der Überweisung erhält ein Programm mit Pinocchio keinerlei Schutz gegen das doppelte Konto: Es muss die beiden Schlüssel selbst vergleichen. Ein IDL erzeugt Pinocchio ebenfalls nicht von sich aus; die Clients erzeugt man mit Werkzeugen wieCodama, das aus der Beschreibung des Programms Clients und Dokumentation generiert. Pinocchio ist sinnvoll, wenn sich eine Instruktion ihrem Rechenbudget nähert, wenn sich mehrere Instruktionen das Maximum von 1.400.000 Compute Units einer Transaktion teilen müssen oder wenn die Größe der Binärdatei eine Einschränkung beim Deployment ist.

Implementierungen vergleichen, ohne Prüfungen zu verlieren

Ein Vergleich des Rechenaufwands zwischen einer Version mit Anchor und einer mit Pinocchio ist nur aussagekräftig, wenn beide dieselben Prüfungen durchführen. Verbraucht die Pinocchio-Variante weniger, weil sie den Eigentümer eines Kontos nicht verifiziert oder Ursprung und Ziel nicht vergleicht, misst man ein anderes Programm. Zuverlässig ist folgendes Vorgehen: zuerst die Ablehnungstests schreiben, dieselben vier wie im vorherigen Beispiel, sie gegen beide Implementierungen ausführen und erst dann die Compute Units vergleichen, die dieselbe Instruktion mit denselben Eingaben verbraucht, so wie die Transaktion sie protokolliert.

Das Ergebnis ist am Budget zu messen. Eine Einsparung, nach der eine Instruktion weit unter ihrem Limit bleibt, rechtfertigt den zusätzlichen Validierungscode nicht, der gepflegt und auditiert werden muss; eine Einsparung, die es erlaubt, mehrere Instruktionen in einer Transaktion zu kombinieren, oder die einen Vorgang auch im ungünstigsten Fall unter dem Limit hält, kann ihn dagegen rechtfertigen.

Anchor oder Pinocchio auf Solana: Nur gemessener Compute-Verbrauch rechtfertigt manuell geschriebene Prüfungen

Anchor 1.x macht aus der Kontovalidierung, die in nativem Rust in jeder Instruktion von Hand geschrieben wird, deklarative Einschränkungen, die jetzt standardmäßig Fälle wie das doppelt übergebene veränderbare Konto abdecken, und generiert das IDL, das Clients benötigen. Geschäftsspezifische Regeln löst es nicht: has_one prüft eine Beziehung, die jemand deklarieren muss, und ein als UncheckedAccount markiertes Konto fällt aus seinen Prüfungen heraus. Wer ein neues Programm mit Anchor 1.x beginnt und misst, überlässt weniger Prüfungen dem Gedächtnis des Teams.

Pinocchio und Rust ohne Framework sind Werkzeuge für ein gemessenes Problem: eine Instruktion nahe an ihrem Rechenlimit oder ein Binärprogramm, das verkleinert werden muss. Wer sie von Anfang an wählt, überträgt dem Team jede Prüfung, die Anchor standardmäßig übernimmt, und diese Verantwortung kostet Tests und Sicherheitsprüfungen.

Die Übersichten zuSolana, RustundAnchorfassen die jeweilige Technologie zusammen, und die Entstehung des Netzwerkdesigns schildert das Profil vonAnatoly Yakovenko. Bei Metlabs entwickeln wirSmart Contractsund Programme für Solana; der Leitfaden zuSolana-Entwicklungsunternehmenerklärt, wie man Anbieter vergleicht. Wenn Sie ein Programm beginnen,erzählen Sie uns davonwelche Instructions es benötigt, und wir sagen Ihnen, welche Prüfungen jede einzelne erfordert.