Förra veckan skickade @redacted_noah en rant om hur Zero Copy™️ på @anchorlang är den perf alfa för varje @solana dev Jag trodde att zero copy bara användes för mycket stora konton Jag insåg att jag inte hade någon aning om varför jag ibland använde den Jag bestämde mig för att göra en djupdykning, låt mig ta dig med 👇

@SuperteamFRANCE @SuperteamJapan För det första, varför pratar vi ens om analys av nollkopieringsdata? Standarddatatolken för Anchor kallas Borsh. När du anropar en Anchor-instruktion kommer Borsh att kopiera dina kontodata till en Borsh-struktur (till en minnesplats som kallas "heapen", mer om detta senare)

När du inkluderar ett konto i din instruktion använder du ett format som ser ut så här.

När du använder noll kopia kommer din kod att se ut så här.

Så vad är det egentligen som händer där? Det är inte självklart från början! Först måste vi förstå hur Solana använder sina Rust-appdata: heapen, stacken och utrymmet för "noll kopia".

1. Stack: Det är här vi lagrar lokala och enkla datatyper. Du får 4KiB utrymme för varje stack, varje funktionsanrop får sin egen 4KiB-allokering. "Åtkomstfel i stackram X på adressen XXXXX med storlek X." är den typ av fel du får när du överskrider den maximala stackstorleken. I Anchor är den första korrigeringen för det här felet att använda en "Box" för att flytta data från stacken till "heapen" 👇

2. Högen i Solana: Program körs på en virtuell BPF-dator med en heap på 32 kB som standard. Det här är en engångsallokering för ett helt anrop. Det är här du skulle lagra mer dynamiska datatyper (Vec, String) Deserialisera konton med Borsh kopierar data till högen och äter snabbt upp utrymme

3. Noll kopia: Om du måste kringgå heapen och stacken på grund av att din fulla databudget överskrids (många CPI:er, med stora konton) kommer du att använda Zero copy. Med noll kopiering kan du arbeta med data utan att behöva allokera eller kopiera dem först genom att hoppa över deserialisering.

När är det meningsfullt att inte kopiera någon? 1. Stora datamängder 2. Arbeta med många KPI:er Låt oss fortsätta:

1. Stora datamängder Låt oss säga att du vill spåra en lista med plånböcker direkt in i ditt tillstånd för att kunna köra helt onchain-kontroller (om du behöver göra detta, titta på merkle-träd 😅, det här är inte sättet att göra det) Som i en tombola, att lagra varje deltagares adress innan du kör den slutliga dragningen och väljer en vinnare. Detta kommer lätt att gå utöver 32 kb minne. En deltagare = 32 byte, så om du planerar att bli framgångsrik och tilldela utrymme för 1000 deltagare, äter detta redan upp hela högstorleken (32 000 byte) I den här situationen kan du gå Zero copy för att kringgå begränsningen och göra det möjligt att arbeta med mycket större konton utan att nå heap- eller stackgränserna.

HUR MAN FIXAR? Enkel! Använd bara Zero Copy överallt. Så enkelt är det (👇 lägg till makroattributet #[account("zero_copy)] i RootEscrow-kontot) MEN Zero copy kommer med en annan utmaning, anledningen till att Anchor valde Borsh från första början: bytejustering.

Bytejustering är en lågnivåteknik som varje Solana-utvecklare bör förstå med noll kopia eller inte Det kräver att structs är säkra med noll kopiering via bytemuck (bytejustering kan orsaka panik om det inte hanteras korrekt) Jag kommer att publicera en annan tråd om detta * spännande * ämne snart 🔥

Under tiden kan du kolla in @legendsdotfun produkten jag har byggt sedan mitten av september och delta i @colosseum Cypherpunk hackathon Registrera din produkt, rösta upp till lovande nya team Låt oss få varje Solana-legend att lysa 🤝

Stort tack till getterna: - @redacted_noah - @blockiosaurus - @0xIchigo För korrekturläsning av denna live upptäckt tråd!