Săptămâna trecută @redacted_noah trimis un discurs despre modul în care Zero Copy™️ pe @anchorlang este alfa de performanță pentru fiecare @solana dev Am crezut că zero copy a fost folosit doar pentru conturi foarte mari Mi-am dat seama că habar n-aveam de ce îl foloseam uneori Am decis să mă scufund adânc, lasă-mă să te iau cu tine 👇

@SuperteamFRANCE @SuperteamJapan În primul rând, de ce vorbim despre analiza datelor de copiere zero? Parserul de date implicit al Anchor se numește Borsh. Când apelați o instrucțiune Anchor, Borsh va copia datele contului într-o structură Borsh (într-un slot de memorie numit "heap", mai multe despre asta mai târziu)

Când includeți un cont în instrucțiuni, utilizați un format care arată astfel.

Când utilizați zero copie, codul va arăta astfel.

Deci, ce se întâmplă de fapt acolo? Nu este evident de la început! Mai întâi trebuie să înțelegem cum folosește Solana datele aplicației sale Rust: heap-ul, stiva și spațiul "copie zero".

1. Stivă: Aici stocăm tipuri de date locale și simple. Obțineți 4 KiB de spațiu pentru fiecare stivă, fiecare apel de funcție primește propria alocare de 4 KiB. "Încălcarea accesului în cadrul stivei X la adresa XXXXX de dimensiunea X." este genul de eroare pe care o primești atunci când depășești dimensiunea maximă a stivei. În Anchor, prima soluție pentru această eroare este să utilizați o "casetă" pentru a muta datele din stivă în "heap" 👇

2. Grămadă în Solana: Programele rulează într-o VM BPF cu heap de 32 KB în mod implicit. Aceasta este o alocare unică pentru o invocare întreagă. Aici veți stoca mai multe tipuri de date dinamice (Vec, String) Deserializarea conturilor cu Borsh copiază datele în grămadă, mâncând rapid spațiul

3. Copie zero: Dacă trebuie să ocoliți heapul și stiva pentru că bugetul complet de date este depășit (o mulțime de CPI, cu conturi mari), veți folosi copia zero. Zero copy vă permite să lucrați cu datele fără a fi nevoie să le alocați sau să le copiați mai întâi, sărind peste deserializare.

Când are sens copia Zero? 1. Date mari 2. Lucrul cu o mulțime de IPC Să continuăm:

1. Date mari Să presupunem că doriți să urmăriți o listă de portofele direct în statul dvs. pentru a putea rula verificări complet onchain (dacă trebuie să faceți acest lucru, uitați-vă în arborii 😅 merkle, acesta nu este modul de a face acest lucru) Ca într-o tombolă, stocarea adresei fiecărui participant înainte de a organiza extragerea finală și de a selecta un câștigător. Acest lucru va depăși cu ușurință memoria de 32kb. Un participant = 32 de octeți, deci dacă intenționați să aveți succes și să alocați spațiu pentru 1000 de participanți, acest lucru consumă deja întreaga dimensiune a heap-ului (32 000 de octeți) În această situație, puteți merge la Zero copie pentru a ocoli limitarea și a permite lucrul cu conturi mult mai mari fără a atinge limitele de heap sau stack.

CUM SE REMEDIAZĂ? Simplu! Folosiți Zero Copy peste tot. Este la fel de ușor (👇 adăugați atributul macro #[account("zero_copy")] la contul RootEscrow) DAR copia Zero vine cu o altă provocare, motivul pentru care Anchor a ales Borsh în primul rând: alinierea octeților.

Alinierea octeților este o tehnică de nivel scăzut pe care fiecare dezvoltator Solana ar trebui să o înțeleagă folosind zero copie sau nu Necesită ca structurile să fie sigure pentru copiere zero prin bytemuck (alinierea octeților poate provoca panică dacă nu este manipulată corect) Voi publica un alt subiect pe acest subiect *interesant* în curând 🔥

Între timp, verificați produsul pe care l-am construit @legendsdotfun la mijlocul lunii septembrie și participând la hackathonul @colosseum Cypherpunk Înregistrați-vă produsul, acordați voturi pozitive echipelor noi promițătoare Să facem să strălucească 🤝 fiecare legendă solana

Multe mulțumiri caprelor: - @redacted_noah - @blockiosaurus - @0xIchigo Pentru corectarea acestui fir de descoperire live!