Forrige uke sendte @redacted_noah en rant om hvordan Zero Copy™️ på @anchorlang er perf alfa for hver @solana utvikler Jeg trodde at null kopi bare ble brukt til veldig store kontoer Jeg skjønte at jeg ikke hadde noen anelse om hvorfor jeg noen ganger brukte det Jeg bestemte meg for å dykke dypt, la meg ta deg med 👇

@SuperteamFRANCE @SuperteamJapan For det første, hvorfor snakker vi i det hele tatt om Zero copy data parsing? Standard dataparser for Anchor kalles Borsh. Når du ringer en ankerinstruksjon, kommer Borsh til å kopiere kontodataene dine til en Borsh-struktur (til et minnespor kalt "haugen", mer om dette senere)

Når du inkluderer en konto i instruksjonen, bruker du et format som ser slik ut.

Når du bruker null kopi, vil koden din se slik ut.

Så hva skjer egentlig der? Det er ikke åpenbart fra starten! Først må vi forstå hvordan Solana bruker Rust-appdataene sine: haugen, stabelen og "null kopi"-plassen.

1. Stabel: Det er her vi lagrer lokale og enkle datatyper. Du får 4 KiB plass for hver stabel, hvert funksjonskall får sin egen 4 KiB-allokering. "Tilgangsbrudd i stabelramme X på adresse XXXXX av størrelse X." er den typen feil du får når du overskrider den maksimale stabelstørrelsen. I Anchor er den første løsningen for denne feilen å bruke en "boks" for å flytte dataene fra stabelen til "haugen" 👇

2. Haug i Solana: Programmer kjører i en virtuell BPF-maskin med 32 KB heap som standard. Dette er en engangstildeling for en hel påkalling. Det er her du vil lagre mer dynamiske datatyper (Vec, String) Deserialisering av kontoer med Borsh kopierer data til haugen og spiser plass raskt

3. Null kopi: Hvis du må omgå heap og stack fordi hele databudsjettet ditt blir overskredet (mange CPI-er, med store kontoer), vil du bruke Zero copy. Null kopi lar deg jobbe med dataene uten å måtte tildele eller kopiere dem først ved å hoppe over deserialisering.

Når er null kopi fornuftig? 1. Store data 2. Jobber med mange KPIer La oss fortsette:

1. Store data La oss si at du vil spore en liste over lommebøker rett inn i staten din for å kunne kjøre fullstendig onchain-kontroller (hvis du trenger å gjøre dette, se på merkle-trær 😅, dette er ikke måten å gjøre det på) Som i en utlodning, lagre hver deltakers adresse før du kjører den endelige trekningen og velger en vinner. Dette vil lett gå utover 32kb minne. En deltaker = 32 byte, så hvis du planlegger å lykkes og tildele plass til 1000 deltakere, spiser dette allerede opp hele haugstørrelsen (32 000 byte) I denne situasjonen kan du gå Null kopi for å omgå begrensningen og gjøre det mulig å jobbe med mye større kontoer uten å treffe haug- eller stabelgrensene.

HVORDAN FIKSE? Enkel! Bare bruk Zero Copy overalt. Det er så enkelt som dette 👇 (legg til makroattributtet #[account("zero_copy")] i RootEscrow-kontoen) MEN Zero copy kommer med en annen utfordring, grunnen til at Anchor valgte Borsh i utgangspunktet: bytejustering.

Bytejustering er en teknikk på lavt nivå som alle Solana-utviklere bør forstå ved å bruke null kopi eller ikke Det krever at structs er nullkopisikre via bytemuck (bytejustering kan forårsake panikk hvis den ikke håndteres riktig) Jeg publiserer en annen tråd om dette *spennende* emnet snart 🔥

I mellomtiden kan du sjekke ut @legendsdotfun produktet jeg har bygget siden midten av september og deltatt i @colosseum Cypherpunk-hackathonet Registrer produktet ditt, gi oppstemmer til lovende nye team La oss få hver solana-legende til å skinne 🤝

Tusen takk til geitene: - @redacted_noah - @blockiosaurus - @0xIchigo For korrekturlesing av denne live oppdagelsestråden!