Rust akıllı sözleşmeler yetiştirme günlüğü (9) Sözleşme yükseltmesi

Akıllı sözleşmeler esasen bir programdır ve hatalardan kaçınmak zor olabilir. Yoğun test ve denetimden geçmiş akıllı sözleşmelerin bile hala açıkları olabilir. Sözleşme açıkları bir saldırgan tarafından istismar edildiğinde, kullanıcı varlık kaybına neden olabilir ve sonuçları ciddi olabilir. Açıkların düzeltilmesi genellikle sözleşme güncellemeleri ile gerçekleştirilir. Açıkları düzeltmenin yanı sıra, yeni işlevler eklemek de sözleşmenin güncellenmesini gerektirir. Bu nedenle, sözleşmenin güncellenebilirliği son derece önemlidir. Bu yazıda, Rust sözleşmelerinin güncellenme yöntemleri ele alınacaktır.

1. Solidity akıllı sözleşmeler için yaygın güncelleme yöntemleri

Ethereum akıllı sözleşmeleri değiştirilemez, dağıtıldıktan sonra değiştirilemez. Eğer sözleşmede bir açık varsa veya yeni bir işlev gerekiyorsa, yalnızca yeni bir sözleşme blok zincirine dağıtılabilir.

Bu yöntemin karşılaştığı zorluk, her sözleşme dağıtımından sonra yeni bir adresin atanmasıdır. Bu sözleşmeyi kullanan tüm DApp'lerin yeni sözleşmeye uyum sağlamak için sözleşme adresini değiştirmeleri gerekir. Ayrıca, eski sürüm sözleşmesindeki durumun yeni sürüme taşınması gerekmektedir; karmaşık sözleşmelerin durumunu taşımak büyük bir iş yükü taşır ve hata yapma olasılığı yüksektir.

Bu nedenle, genellikle veri ve mantık ayrımı mimarisi kullanılır; veriler, mantığı işlemeyen bir durum sözleşmesinde saklanır ve tüm mantık başka bir mantık sözleşmesinde uygulanır. Bu şekilde, güncellemeler sırasında yalnızca mantık sözleşmesinin güncellenmesi yeterlidir, durum geçişi ile ilgili düşünmeye gerek yoktur.

Bu sorunu çözmek için bir proxy sözleşmesi (Proxy Contract) kullanılabilir. Proxy sözleşmesi, verileri depolamak için kullanılır ve logic sözleşmesi A'yı çağırmak için deleGatecall kullanır, böylece sözleşme A'nın okuduğu ve yazdığı veriler proxy sözleşmesinde saklanır. Güncelleme sırasında yeni bir sözleşme B dağıtılır ve ardından proxy sözleşmesinin yeni logic sözleşmesi B'ye işaret etmesi için bir işlem gönderilir.

2. NEAR akıllı sözleşmeler güncelleme yaygın yöntemleri

StatusMessage projesini örnek alarak, NEAR akıllı sözleşmelerinin yaygın güncelleme yöntemlerini tanıtın.

2.1 Sözleşme veri yapısı değiştirilmedi

Eğer yalnızca sözleşme mantığını değiştiriyorsanız ve veri yapısını değiştirmiyorsanız, yeni kodu doğrudan near deploy ile dağıtabilirsiniz. Eski sözleşmedeki veriler başarıyla okunabilir.

2.2 Sözleşme veri yapısı değiştirildi

Eğer sözleşmenin veri yapısı değiştirilmişse, doğrudan yeniden dağıtım yapmak sözleşme durumunun tersine serileştirilememesine neden olacaktır. Bunun nedeni, sözleşme durumunun serileştirilmiş veri biçiminde kalıcı olarak depolanmasıdır; yeniden dağıtım yapıldığında koddaki veri yapısı değişir, ancak durum değişmez, yeni veri yapısı eski durumla eşleşemez.

2.3 Migrate akıllı sözleşmeler

NEAR, sözleşmeleri yükseltmeye yardımcı olmak için Migrate yöntemini sağlar. Yeni sözleşmeye migrate yöntemini ekleyin:

pas #[private] #[init(ignore_state)] Self { let old_state: OldStatusMessage = env::state_read().expect('failed'); Kendisi { taglines: old_state.records, bios: LookupMap::new(b'b'.to_vec)((, } }

Sözleşmeyi yeniden dağıtırken migrate yöntemini çağırın:

yakın dağıtım
--wasmFile target/wasm32-unknown-unknown/release/status_message.wasm
--initFunction 'migrate' \ --initArgs '{}' \ --accountId durum mesajı.blocksec_yükseltme.testnet

Bu şekilde yeni akıllı sözleşmeleri başarıyla dağıtabilir ve eski verileri taşıyabilirsiniz.

![])https://img-cdn.gateio.im/webp-social/moments-73f5e5195fa71f1f25f5d35ba1e8b8ec.webp)

3. Akıllı sözleşmelerin yükseltme güvenlik değerlendirmesi

Akıllı sözleşmelerin güvenlik güncellemesi öncelikle yetki kontrolünü dikkate almalıdır, genel sözleşmeler yalnızca geliştirici veya DAO tarafından güncellenebilir. Güncelleme fonksiyonu yalnızca sahibi (only owner) fonksiyonu olmalı ve yalnızca sahip tarafından çağrılmasını sağlamalıdır.

Sözleşmenin sahibi olarak DAO'yu ayarlamanızı öneririm, sözleşmeyi ortaklaşa yönetmek için öneriler ve oylama yoluyla. Bireysel hesapların sahibi olması sözleşmeyi yüksek derecede merkezi hale getirir, sahibi sözleşme verilerini keyfi olarak değiştirebilir ve ayrıca özel anahtar kaybı riski vardır.

Ayrıca, geliştiricilerin sözleşme aktarımı yaparken aşağıdaki önerileri dikkate alması gerekebilir:

• Göç fonksiyonundan önce #[init(ignore_state)] ekleyin, göç fonksiyonu çalıştırılmadan önce durumun yüklenmediğinden emin olun.
• Taşınma tamamlandıktan sonra taşınma fonksiyonunu silin, taşınma fonksiyonunun yalnızca bir kez çağrıldığından emin olun.
• Yeni veri yapısı, taşınma sırasında başlatılır.