Playbook3 Abschnitte · 2 Min. LesezeitVon Dezső Mező · Veröffentlicht 3. Oktober 2026.mdSolanaAnchorRustAuditing
Solanas Account-Modell ist wirklich anders: Programme sind zustandslos, Accounts tragen den Zustand, und die Laufzeit vertraut darauf, dass du prüfst, wem was gehört. Diese Checks landen immer wieder in Post-Mortems.
01Owner-Checks sind deine Aufgabe
Das Deserialisieren eines Accounts beweist seine Form, nicht seinen Besitzer. Jedes Programm kann einen Account mit identischem Layout anlegen und ihn deinem übergeben. Anchors owner-Constraint existiert genau dafür; Account<T> macht es implizit, AccountInfo nicht.
02Signer sind nicht implizit
Ein Feld, das admin heißt, ist Daten, keine Signatur. Jede privilegierte Instruktion braucht einen Signer auf dem Authority-Account — der übliche Audit-Fehler ist eine Authority, die aus den Account-Daten gelesen wird, ohne die Signatur dagegen zu prüfen.
03Rent, Realloc und der gewachsene Account
Ein Realloc ändert die Lamport-Anforderung eines Accounts, und das Nachladen der Rent zu vergessen ist ein stiller Ausfall für die eigenen Nutzer. Dimensioniere Accounts auf die Daten, die sie beim ersten Schreiben wirklich halten.
Was bleibt
- Den Owner prüfen, nicht nur die Form.
- Privilegierte Calls brauchen ein Signer-Constraint, kein Admin-Feld.
- Rent beim Realloc einplanen, nicht danach.
- Instruktionsfolgen fuzzen — State-Bugs verstecken sich zwischen den Calls.
Mehr aus dem Lab
Alle Beiträge ansehen
Was Solana-RPC wirklich kostet, sobald der Prototyp läuft
Was Custom Software wirklich kostet
Custom oder von der Stange — der ehrliche Test
Self-hosted n8n oder Zapier — wo die Rechnung wirklich abweicht
Sollen wir das an Ihrem System ansehen?Gespräch beginnen
