Playbook3 rész · 2 percÍrta: Dezső Mező · Megjelent 2026. október 3..mdSolanaAnchorRustAuditing
A Solana account-modellje tényleg más: a programok állapotmentesek, az accountok hordozzák az állapotot, és a runtime megbízik benne, hogy ellenőrzöd, kié mi. Ezek az ellenőrzések azok, amik rendszeresen post-mortemekben kötnek ki.
01Az owner-ellenőrzés a te dolgod
Az account deszerializálása az alakját bizonyítja, nem a tulajdonosát. Bármely program létrehozhat ugyanolyan layoutú accountot és átadhatja a tiédnek. Az Anchor owner-constraintje pont erre való; az Account<T> implicit megteszi, az AccountInfo nem.
02Az aláíró nem magától értetődő
Egy admin-mező adat, nem aláírás. Minden privilegizált instrukcióhoz Signer kell az authority-accounton — a tipikus audit-hiba, hogy az authorityt az account adatából olvassák, és semmi nem veti össze az aláírással.
03Rent, realloc és a megnőtt account
Az account reallocja megváltoztatja a lamport-egyenleg követelményét, és a rent feltöltésének elmulasztása reallocnál csendes kiesés a saját felhasználóidnak. Méretezd az accountot arra az adatra, amit tényleg tartalmazni fog az első íráskor.
Amit érdemes elvinni
- Az ownert ellenőrizd, ne csak az alakot.
- A privilegizált hívásokhoz Signer-constraint kell, nem admin-mező.
- A rentet reallocnál tervezd, ne utána.
- Fuzzold az instrukciósorozatokat — az állapotbugok a hívások közt lapulnak.
Több a laborból
Összes bejegyzés
Mennyibe kerül tényleg a Solana-RPC, amikor a prototípus már működik
Mennyibe kerül tényleg az egyedi szoftver
Egyedi szoftver vagy dobozos — a becsületes teszt
Self-hosted n8n vagy Zapier — hol tér el tényleg a számla
Megnézzük ugyanezt a te rendszereden?Kezdjünk bele
