Minggu lalu @redacted_noah mengirim kata-kata kasar tentang bagaimana Zero Copy™️ di @anchorlang adalah alfa perf untuk setiap pengembang @solana Saya pikir salinan nol hanya digunakan untuk akun yang sangat besar Saya menyadari bahwa saya tidak tahu mengapa saya terkadang menggunakannya Aku memutuskan untuk menyelam dalam-dalam, izinkan aku membawamu bersama 👇

@SuperteamFRANCE @SuperteamJapan Pertama, mengapa kita berbicara tentang penguraian data salinan nol? Parser data default Anchor disebut Borsh. Saat memanggil instruksi Anchor, Borsh akan menyalin data akun Anda ke dalam struktur Borsh (ke slot memori yang disebut "tumpukan", lebih lanjut tentang ini nanti)

Saat Anda menyertakan akun dalam instruksi Anda, Anda menggunakan format yang terlihat seperti ini.

Saat menggunakan salinan nol, kode Anda akan terlihat seperti ini.

Jadi apa yang sebenarnya terjadi di sana? Itu tidak jelas sejak awal! Pertama, kita perlu memahami bagaimana Solana menggunakan data aplikasi Rust-nya: tumpukan, tumpukan, dan ruang "salinan nol".

1. Tumpukan: Di sinilah kami menyimpan tipe data lokal dan sederhana. Anda mendapatkan ruang 4KiB untuk setiap tumpukan, setiap panggilan fungsi mendapatkan alokasi 4KiB sendiri. "Pelanggaran akses dalam bingkai tumpukan X di alamat XXXXX ukuran X." adalah jenis kesalahan yang Anda dapatkan ketika Anda melebihi ukuran tumpukan maksimum. Di Anchor, perbaikan pertama untuk kesalahan ini adalah menggunakan 'Box' untuk memindahkan data dari tumpukan ke "heap" 👇

2. Tumpukan di Solana: Program berjalan di VM BPF dengan tumpukan 32KB secara default. Ini adalah alokasi satu kali untuk satu seluruh doa. Di sinilah Anda akan menyimpan tipe data yang lebih dinamis (Vec, String) Deserialisasi akun dengan Borsh menyalin data ke tumpukan, memakan ruang dengan cepat

3. Salinan nol: Jika Anda harus melewati tumpukan dan tumpukan karena anggaran data penuh Anda terlampaui (banyak CPI, dengan akun besar), Anda akan menggunakan salinan Nol. Salinan nol memungkinkan Anda untuk bekerja dengan data tanpa harus mengalokasikan atau menyalinnya terlebih dahulu dengan melewati deserialisasi.

Kapan salinan Nol masuk akal? 1. Data besar 2. Bekerja dengan banyak CPI Mari kita lanjutkan:

1. Data besar Katakanlah Anda ingin melacak daftar dompet langsung ke negara bagian Anda untuk dapat menjalankan pemeriksaan onchain sepenuhnya (jika Anda perlu melakukan ini, lihat pohon 😅 merkle, ini bukan cara untuk melakukannya) Seperti dalam undian, menyimpan alamat setiap peserta sebelum menjalankan undian akhir dan memilih pemenang. Ini akan dengan mudah melampaui memori 32kb. Satu peserta = 32 byte, jadi jika Anda berencana untuk berhasil dan mengalokasikan ruang untuk 1000 peserta, ini sudah memakan seluruh ukuran tumpukan (32.000 byte) Dalam situasi ini, Anda dapat melakukan salinan nol untuk melewati batasan dan memungkinkan bekerja dengan akun yang jauh lebih besar tanpa mencapai batas tumpukan atau tumpukan.

BAGAIMANA CARA MEMPERBAIKINYA? Sederhana! Cukup gunakan Zero Copy di mana-mana. Semudah ini 👇 (tambahkan atribut makro #[account("zero_copy")] ke akun RootEscrow) TAPI salinan Zero hadir dengan tantangan lain, alasan mengapa Anchor memilih Borsh sejak awal: penyelarasan byte.

Penyelarasan byte adalah teknik tingkat rendah yang harus dipahami oleh setiap pengembang Solana menggunakan salinan nol atau tidak Ini membutuhkan struktur untuk aman tanpa salinan melalui bytemuck (penyelarasan byte dapat menyebabkan kepanikan jika tidak ditangani dengan benar) Saya akan segera menerbitkan utas lain tentang topik 🔥 *menarik* ini

Sementara itu, periksa @legendsdotfun produk yang telah saya bangun sejak pertengahan September dan mengambil bagian dalam hackathon @colosseum Cypherpunk Daftarkan produk Anda, berikan suara positif kepada tim baru yang menjanjikan Mari kita buat setiap legenda solana bersinar 🤝

Terima kasih banyak kepada kambing: - @redacted_noah - @blockiosaurus - @0xIchigo Untuk menguji pembacaan penemuan langsung ini!