Geçen hafta @redacted_noah, @anchorlang'daki Zero Copy'nin™️ her @solana geliştiricisi için nasıl mükemmel alfa olduğuna dair bir rant gönderdi Sıfır kopyanın yalnızca çok büyük hesaplar için kullanıldığını sanıyordum Bazen neden kullandığım hakkında hiçbir fikrim olmadığını fark ettim Derin dalmaya karar verdim, seni de yanıma 👇 alayım

@SuperteamFRANCE @SuperteamJapan İlk olarak, neden Sıfır kopya veri ayrıştırma hakkında konuşuyoruz? Anchor'ın varsayılan veri ayrıştırıcısına Borsh adı verilir. Bir Anchor talimatını çağırırken, Borsh hesap verilerinizi bir Borsh yapısına kopyalayacaktır ("yığın" adı verilen bir bellek yuvasına, bu konuya daha sonra değineceğiz)

Talimatınıza bir hesap eklediğinizde, şuna benzer bir biçim kullanırsınız.

Sıfır kopya kullanırken kodunuz aşağıdaki gibi görünecektir.

Peki orada gerçekte neler oluyor? Başından beri belli değil! Öncelikle Solana'nın Rust uygulama verilerini nasıl kullandığını anlamamız gerekiyor: yığın, yığın ve "sıfır kopya" alanı.

1. Yığın: Burası yerel ve basit veri türlerini depoladığımız yerdir. Her yığın için 4 KiB alan elde edersiniz, her işlev çağrısı kendi 4 KiB tahsisini alır. "X boyutundaki XXXXX adresindeki X yığın çerçevesine erişim ihlali." maksimum yığın boyutunu aştığınızda aldığınız türden bir hatadır. Anchor'da bu hatanın ilk düzeltmesi, verileri yığından "yığına" taşımak için bir 'Kutu' 👇 kullanmaktır

2. Solana'da yığın: Programlar varsayılan olarak 32 KB yığınlı bir BPF VM'de çalışır. Bu, bir tam çağrı için tek seferlik bir tahsistir. Burası daha dinamik veri türlerini (Vec, String) depolayacağınız yerdir Borsh ile hesapları seri durumdan çıkarmak, verileri yığına kopyalayarak hızlı bir şekilde yer kaplar

3. Sıfır kopya: Veri bütçenizin tamamı aşıldığı için yığını ve yığını atlamanız gerekiyorsa (büyük hesaplarda çok sayıda CPI) Sıfır kopya kullanacaksınız. Sıfır kopyalama, seri durumdan çıkarmayı atlayarak önce verileri ayırmak veya kopyalamak zorunda kalmadan verilerle çalışmanıza olanak tanır.

Sıfır kopya ne zaman mantıklıdır? 1. Büyük veri 2. Çok sayıda TÜFE ile çalışmak Devam edelim:

1. Büyük veri Diyelim ki tamamen zincir üzerinde kontroller yapabilmek için doğrudan eyaletinize kadar bir cüzdan listesini takip etmek istiyorsunuz (bunu yapmanız gerekiyorsa, merkle ağaçlarına 😅 bakın, bunu yapmanın yolu bu değil) Bir çekilişte olduğu gibi, son çekilişi yapmadan ve kazananı seçmeden önce her katılımcının adresini saklamak. Bu, kolayca 32kb belleğin ötesine geçecektir. Bir katılımcı = 32 bayt, yani başarılı olmayı ve 1000 katılımcı için yer ayırmayı planlıyorsanız, bu zaten tüm yığın boyutunu (32.000 bayt) tüketiyor demektir Bu durumda, sınırlamayı atlamak ve yığın veya yığın sınırlarına ulaşmadan çok daha büyük hesaplarla çalışmayı etkinleştirmek için Sıfır kopyaya geçebilirsiniz.

NASIL DÜZELTILIR? Basit! Her yerde Zero Copy'yi kullanın. Bu 👇 kadar kolay (RootEscrow hesabına #[account("zero_copy")] makro özniteliğini ekleyin) AMA Sıfır kopya başka bir zorlukla birlikte gelir, Anchor'un ilk etapta Borsh'u seçmesinin nedeni: bayt hizalaması.

Bayt hizalama, her Solana geliştiricisinin sıfır kopya kullanarak veya kullanmayarak anlaması gereken düşük seviyeli bir tekniktir Yapıların bytemuck aracılığıyla sıfır kopya güvenli olmasını gerektirir (bayt hizalaması doğru şekilde işlenmezse paniğe neden olabilir) Yakında 🔥 bu *heyecan verici* konuyla ilgili başka bir konu yayınlayacağım

Bu arada, Eylül ortasından beri geliştirdiğim ve @colosseum Cypherpunk hackathon'una katıldığım ürünü @legendsdotfun satın alın Ürününüzü kaydedin, gelecek vaat eden yeni ekiplere olumlu oy verin Her bir solana efsanesinin parlamasını 🤝 sağlayalım

Keçilere çok teşekkürler: - @redacted_noah - @blockiosaurus - @0xIchigo Bu canlı keşif konusunu okumanın kanıtı için!