Viime viikolla @redacted_noah lähetti paasauksen siitä, kuinka Zero Copy™️ on @anchorlang on jokaisen @solana kehittäjän suorituskyky Luulin, että nollakopiota käytettiin vain erittäin suurille tileille Tajusin, ettei minulla ollut aavistustakaan, miksi käytin sitä joskus Päätin sukeltaa syvälle, anna minun ottaa sinut mukaan 👇

@SuperteamFRANCE @SuperteamJapan Ensinnäkin, miksi edes puhumme nollakopiointitietojen jäsentämisestä? Anchorin oletusarvoinen tietojen jäsennin nimi on Borsh. Kun kutsut Anchor-käskyä, Borsh kopioi tilitietosi Borsh-rakenteeseen (muistipaikkaan nimeltä "keo", tästä lisää myöhemmin)

Kun sisällytät tunnuksen ohjeeseesi, käytät muotoa, joka näyttää tältä.

Kun käytät nollakopiota, koodisi näyttää tältä.

Mitä siellä sitten oikeastaan tapahtuu? Se ei ole selvää alusta alkaen! Ensin meidän on ymmärrettävä, miten Solana käyttää Rust-sovellustietojaan: kasa, pino ja "nollakopio"-tila.

1. Pino: Tänne tallennamme paikallisia ja yksinkertaisia tietotyyppejä. Saat 4 KiB tilaa jokaiselle pinolle, jokainen funktiokutsu saa oman 4KiB-varauksensa. "Pääsyrikkomus pinokehyksessä X osoitteessa XXXXX, jonka koko on X." on sellainen virhe, jonka saat, kun ylität pinon enimmäiskoon. Anchorissa ensimmäinen korjaus tähän virheeseen on käyttää "Boxia" tietojen siirtämiseen pinosta "kekoon" 👇

2. Kasa Solanassa: Ohjelmat suoritetaan BPF-virtuaalikoneella, jossa on oletusarvoisesti 32 kt:n keko. Tämä on kertaluonteinen varaus yhdelle kokonaiselle kutsulle. Tänne tallentaisit dynaamisempia tietotyyppejä (Vec, String) Tilien deserialisointi Borshin avulla kopioi tiedot kasaan ja syö tilaa nopeasti

3. Nolla kopiota: Jos joudut ohittamaan kasan ja pinon, koska koko databudjettisi ylittyy (paljon CPI:itä, suurilla tileillä), käytät nollakopiota. Nollakopion avulla voit käsitellä tietoja ilman, että sinun tarvitsee varata tai kopioida niitä ensin ohittamalla deserialisointi.

Milloin Zero-kopio on järkevää? 1. Suuri data 2. Työskentely monien kuluttajahintaindeksien kanssa Jatketaan:

1. Suuri data Oletetaan, että haluat seurata lompakoiden luetteloa suoraan osavaltioosi, jotta voit suorittaa täysin ketjun sisäisiä tarkistuksia (jos sinun on tehtävä tämä, katso merkle-puita 😅, tämä ei ole oikea tapa tehdä sitä) Kuten arvonnassa, jokaisen osallistujan osoitteen tallentaminen ennen lopullisen arvonnan suorittamista ja voittajan valitsemista. Tämä ylittää helposti 32 kt:n muistin. Yksi osallistuja = 32 tavua, joten jos aiot menestyä ja varata tilaa 1000 osallistujalle, tämä syö jo koko kasan koon (32 000 tavua) Tässä tilanteessa voit mennä Nollakopio ohittaaksesi rajoituksen ja mahdollistaaksesi työskentelyn paljon suurempien tilien kanssa osumatta kasa- tai pinorajoihin.

KUINKA KORJATA? Yksinkertainen! Käytä vain Zero Copy -toimintoa kaikkialla. Se on näin helppoa 👇 (lisää #[account("zero_copy")]-makroattribuutti RootEscrow-tiliin) MUTTA Zero-kopiointiin liittyy toinenkin haaste, syy siihen, miksi Anchor valitsi Borshin alun perin: tavujen kohdistus.

Tavujen kohdistus on matalan tason tekniikka, joka jokaisen Solana-kehittäjän tulisi ymmärtää nollakopiolla vai ei Se edellyttää, että rakenteet ovat nollakopiointiturvallisia bytemuckin kautta (tavujen kohdistus voi aiheuttaa paniikkia, jos sitä ei käsitellä oikein) Julkaisen pian 🔥 toisen ketjun tästä *jännittävästä* aiheesta

Sillä välin tarkista @legendsdotfun tuote, jota olen rakentanut syyskuun puolivälistä lähtien ja osallistunut @colosseum Cypherpunk -hackathoniin Rekisteröi tuotteesi, anna myönteisiä ääniä lupaaville uusille tiimeille Laitetaan jokainen solana-legenda loistamaan 🤝

Suuret kiitokset vuohille: - @redacted_noah - @blockiosaurus - @0xIchigo Oikolukemiseksi tämä live-löytöketju!