Web3 Akıllı Sözleşme Güvenliği için Test ve Resmi Doğrulama

Okuma zamanı: 9 dakika

Hava dalışı yaptığınızı hayal edin. Uçaktan atlamadan önce yüzlerce kez paraşütünüzü kontrol edeceksiniz değil mi? Kontrol etme ve test etme, güvenliğin ayrılmaz bir parçasıdır; güvenlikle ilgili herhangi bir şeyi düşünün. İster CCTV kurulumu ister okuldaki yazılı bir sınavdan önce kalemin mürekkebinin kontrol edilmesi olsun, sonrasında muhtemelen bir test mekanizması olacaktır, hepimiz güvenlik önlemlerini alıyoruz. İlgili risk ne kadar yüksek olursa, şeyleri o kadar çok test ederiz. Ve akıllı sözleşmelerden bahsettiğimizde, risk BÜYÜK. Akıllı sözleşme güvenliği söz konusu olduğunda dikkatsiz olamazsınız.

1. Güvenlik her zaman gereklidir.

Kapıyı iki kez veya üç kez kilitleyebilirsiniz, fark etmez. Siz yokken evinizin soyulmayacağından emin misiniz? Yapamazsınız çünkü hırsızın eve girmek için ne yapabileceğini bilmiyorsunuz - aynısı aldığımız her güvenlik önlemi için geçerli. Güvenliği garanti edecek tamamen güvenli bir yöntem yoktur. Yine de hızlı bir şekilde yaptığımız eylem, güvende olma şansımızı artırıyor, oyun da bu. Farklı önlemler alarak güvende olma ihtimalini artırmak istiyoruz.

Web3 dünyası farklı değil. Kendinizi kurtarmanın güvenli bir yöntemi yoktur, ancak QuillAudits'ten deneyimli denetçilere sahip olmak, protokolünüzün güvence altına alınma olasılığını büyük ölçüde artırabilir ve güncel güvenliğinizi garanti eder. Web3'te, protokolünüz üzerinde bazı testler yaparak ne kadar güvende olduğunuzu anlamanıza yardımcı olan iki önemli mekanizma vardır:-

1. Akıllı Sözleşme Testi
2. Akıllı Sözleşmelerin Resmi Doğrulaması

Bunları ayrıntılı olarak anlayalım ve sözleşmelerimizin zayıf noktalarını veya güvenlik açıklarını bilmemize nasıl yardımcı olduklarını öğrenelim.

2. Akıllı Sözleşme Testi

Deneyimli bir geliştirici, işi bir makineye kodla anlatabilir. Yine de bazen makine, koddaki bir kusur veya mantıksal bir hata nedeniyle geliştiricinin aklındaki mekanizmayı tam olarak tasvir etmez. Test etme, kodumuzun nerede başarısız olduğunu ve gerçekleştirmesini istediğimiz eyleme karşılık gelmesi için neler yapılabileceğini belirlemeye yardımcı olan süreçtir.

Akıllı sözleşme testi sözleşmelerimizin ayrıntılı bir analizini yaptığımız ve kodumuzun nerede ve neden başarısız olduğunu bulmaya çalıştığımız geliştirme döngüsündeki bir aşamadır. Neredeyse tüm akıllı sözleşmeler bu aşamadan geçer. Akıllı sözleşme testinin yapılmasının iki yolu vardır. Onları keşfedelim.

2.1 Otomatik

Adından da anlaşılacağı gibi, akıllı sözleşmeleri test etmeye yönelik bu yöntem, komut dosyası testi yapmak için kullanılır. Akıllı sözleşmelerdeki herhangi bir güvenlik açığını ve kusuru bulmak için tekrarlanan testleri yürüten otomatikleştirilmiş yazılımı içerir. Bu otomatik test araçları, test verileri ve beklenen sonuçlarla yapılandırılabilir. Ardından, sözleşmenin düzgün çalışıp çalışmadığını kontrol etmek için fiili sonuç beklenen sonuçlarla karşılaştırılır. Otomatik testler ayrıca üç kategoriye ayrılabilir.

2.1.1. Fonksiyonel Test

Diyelim ki iki sayıyı, a ve b'yi alacak ve sonra her iki sayının toplamını döndürecek bir program yazdığınızı varsayalım. Yani o programı kontrol etmek için 2 ve 8 veriyorsunuz ve beklenen sonucu 10 olarak veriyorsunuz. Şimdi program çalıştığında 10 da döndürmeli. değilse, o zaman kodumuzda bir hata var. 

İşlev testi, sözleşmenizin belirli koşullarda nasıl davranması gerektiğini anlamayı gerektirir. Seçilen değerlerle bir hesaplama yaparak ve döndürülen çıktıyı karşılaştırarak test edebiliriz. İşlevsel Testin üç sınıfı vardır: -

1. Birim testi:- Bu, akıllı sözleşmenin bireysel bileşenlerinin doğruluk açısından test edilmesiyle ilgilidir. İddialıdır veya değişkenler hakkında ifadeler gerektirir.

2. Bütünleşme testi- Bunlar, birkaç ayrı bileşenin birlikte test edilmesiyle ilgilidir. Entegrasyon testi, hiyerarşide birim testinden daha yüksek bir seviyedir. Diğer akıllı sözleşmelerin parçası olabilecek farklı fonksiyonların etkileşiminden kaynaklanan hataları belirlememize yardımcı olur.

3. sistem Metinleri- Bu, hiyerarşideki en yüksek seviyedir. Burada, ihtiyaçlarımıza göre performans gösterip göstermediğini görmek için tüm sözleşmeyi tam entegre tek bir sistem olarak test ediyoruz. Kullanıcının bakış açısından yapılır ve bunu yapmanın en iyi yolu onu test ağlarına yerleştirmektir.

2.1.2. Statik Analiz

Programı çalıştırmadan bile Statik Analiz yapılabilir. Uygulamadan önce akıllı sözleşmenin kaynak kodunun veya bayt kodunun analizini içerir. Adını bu şekilde veren statik analiz, bazı yaygın güvenlik açıklarının saptanmasına neden olabilir.

2.1.3. Dinamik Analiz

Statik analizden farklı olarak, koddaki sorunları belirlemek için akıllı sözleşmelerin çalışma süresi boyunca dinamik analiz gerçekleştirilir. Dinamik kod çözümleyicileri, sözleşmenin çalışma durumunu gözlemler ve güvenlik açıkları ile özellik ihlallerine ilişkin ayrıntılı bir rapor oluşturur. Fuzzing, DYnamic analizi kapsamına girer. Fuzzing, istenmeyen kod yürütülmesine neden olmak için yanlış veya kötü amaçlı girdi besliyor.

2.2 Kılavuzu

Adından da anlaşılacağı gibi, bu akıllı sözleşme testi yöntemi, bir insan geliştiriciyle düzenli etkileşimi içerir. Geliştiricilerin kod satırlarından geçtiği kod denetimleri, akıllı sözleşme testinin Manuel modu kapsamına girer.

Manuel mod önemli ölçüde zaman, beceri, para ve çaba gerektirir. Yine de, sonuç genellikle buna değer çünkü bununla otomatik testte fark edilmeyebilecek güvenlik açıklarını tespit ediyoruz. İki temel manuel test türü vardır: -

2.2.1 Kod Denetimleri:- 

Güvenlik önleminizin düzgün çalışıp çalışmadığını test etmenin en iyi yolu, onu kırmaya çalışmaktır. Örneğin, arabanızın kilidinin düzgün çalışıp çalışmadığını kontrol etmek istiyorsanız, onu kırmaya çalışın. Şimdi, yetenekli bir araba hırsızının arabama kolayca girmesini isteyebilirsiniz. Etmeyebilirim, bu yüzden çözüm, size rehberlik etmesi için izinsiz girme konusunda usta birini işe almaktır!

 Evet, QuillAudits'ten bahsediyorum. Size rehberlik edebilecek yetenekli denetçilerden oluşan bir ekibiz. Kod denetimleri, kaynak koddaki tüm olası güvenlik açıklarını bulmak için bir saldırgan zihniyeti gerektirir. Kod denetimi, potansiyel güvenlik açıklarını ve kusurları ortaya çıkarmak için bir akıllı sözleşme kodunun ayrıntılı bir değerlendirmesidir.

2.2.2 Hata Ödülü:-

Kaynak kodunuzda (çoğunlukla) bazı güvenlik açıkları olabileceğini düşünüyorsanız ve bulamıyorsanız, bir ödül sistemi oluşturarak bu işi serbest çalışanlara yaptırabilirsiniz. Daha çok, akıllı sözleşmenizi hackleyebilen herkes için bir ödül duyurmak gibidir. Bunu yaparak, akıllı sözleşmenizde bulunan güvenlik açığını öğrenirsiniz, böylece onu daha iyi koruyabilir ve kullanıcılarınızı kayıptan kurtarabilirsiniz.

3. Akıllı Sözleşmelerin Resmi Olarak Doğrulanması

Resmi doğrulama, resmi şartnamelere dayalı olarak bir sözleşmenin doğruluğunu değerlendirme sürecidir. Bu, resmi doğrulamanın, kodun amaçlanan şeyi yapıp yapmadığını değerlendirdiği anlamına gelir. Resmi doğrulama, programların belirlenmesi, tasarlanması ve doğrulanması için resmi yöntemler kullanır.

3.1 Resmi şartname nedir?

Akıllı sözleşmeler bağlamında, resmi spesifikasyonlar, olası her koşulda aynı kalması gereken özellikleri ifade eder. Bunlar “değişmez” özelliklerdir çünkü değiştiremezler ve sözleşmenin yürütülmesiyle ilgili mantıksal iddiaları temsil ederler.

Resmi belirtim, resmi dilde yazılmış ifadelerin bir koleksiyonudur. Spesifikasyonlar, farklı özellikleri kapsar ve sözleşmenin özelliklerinin diğer durumlarda nasıl davranması gerektiğini açıklar. Resmi spesifikasyonlar kritiktir, çünkü sözleşmelerin değişmez değişkenleri yoksa veya uygulama sırasında özellikler değişirse, bu durum mülkün kötüye kullanılmasına yol açabilir ve bu da büyük bir kayba yol açabilir.

Bir akıllı sözleşmenin spesifikasyonları karşılayıp karşılamadığını veya beklenmedik davranışlara sahip olup olmadığını belirlememize yardımcı olabilir. Resmi doğrulamanın üç bileşeni vardır: bir özellik, bir model ve bir doğrulama motoru.

3.1.1 Özellikler

Spesifikasyon, bir akıllı sözleşme için gereksinimlerin açık, net ve eksiksiz bir açıklamasıdır. Sözleşmenin ne yapması ve ne yapmaması gerektiğini açıklamalıdır. İki sayı ekleyen basit, akıllı bir sözleşme için örnek bir belirtimi burada bulabilirsiniz:

// Specification: Adds two numbers
// Inputs: a, b (uint)
// Outputs: the sum of a and b (uint) function add(uint a, uint b) public view returns (uint) {
// Implementation details are not relevant to the specification
// …
}

3.1.2 Modeli

Bir model, davranışı hakkında akıl yürütmek için kullanılabilecek akıllı sözleşmeyi resmi olarak temsil eder. Akıllı sözleşmeler için popüler bir model, Solidity programlama dilidir. Aşağıda, yukarıda açıklanan toplama işlevi için bir örnek model verilmiştir:

// Model: Adds two numbers
// Inputs: a, b (uint)
// Outputs: the sum of a and b (uint) function add(uint a, uint b) public view returns (uint) {
return a + b;
}

3.1.3 Doğrulama Motoru

Doğrulama motoru, bir modeli analiz edebilen ve belirli bir spesifikasyona ilişkin doğruluğunu doğrulayabilen bir araçtır. Akıllı sözleşmeler için aşağıdakiler de dahil olmak üzere çeşitli doğrulama motorları mevcuttur:

Mitril: Solidity akıllı sözleşmelerindeki çok çeşitli güvenlik açıklarını tespit edebilen açık kaynaklı bir sembolik yürütme aracı.

IDE'yi yeniden karıştırın: akıllı sözleşmelerin doğruluğunu doğrulayabilen resmi bir doğrulama aracı içeren entegre bir geliştirme ortamı.

Sertora Kanıtlayıcı: otomatik matematiksel muhakeme kullanarak akıllı sözleşmelerin doğruluğunu doğrulayabilen ticari bir araç. Certora Prover kullanarak bir akıllı sözleşmenin doğruluğunu doğrulamak için resmi doğrulamanın nasıl kullanılabileceğinin bir örneğini burada bulabilirsiniz:

pragma solidity 0.7.6; // Model: Adds two numbers
// Inputs: a, b (uint)
// Outputs: the sum of a and b (uint)
function add(uint a, uint b) public pure returns (uint) {
return a + b;
} // Model: Adds two numbers
// Inputs: a, b (uint)
// Outputs: the sum of a and b (uint) function add(uint a, uint b) public pure returns (uint) {
return a + b;
} // Specification: Adds two numbers
// Inputs: a, b (uint)
// Outputs: the sum of a and b (uint) function test_add(uint a, uint b) public pure returns (bool) {
uint expected = a + b;
uint actual = add(a, b);
return expected == actual;
} // Verification: Verify the correctness of the add function contract TestAdd {
function test_add(uint a, uint b) public view returns (bool) {
return CertoraProver.verify(test_add, a, b);
}
}

Yukarıdaki örnekte, ekleme işlevinin bir modelini, işlev için bir belirtimi ve işlevin doğruluğunu doğrulayabilen bir doğrulama motorunu (Certora Prover) içeren bir Solidity akıllı sözleşmesi tanımlıyoruz. Ayrıca, işlevin doğruluğunu doğrulamak için kullanılabilecek bir test işlevi (test_add) tanımlarız.

3.2 Resmi Doğrulamaya Karşı Test Etme

Tartıştığımız gibi, üzerinde test edilmediği veriler hakkında bir şey söyleyemediğimiz için test, eksik olduğu bazı girdi verileri botu için beklenen sonucu verir. Mümkün olan her girdide kontrol etmek neredeyse imkansızdır. Dolayısıyla “işlevsel doğruluğundan” emin değiliz. Resmi doğrulamanın devreye girdiği yer burasıdır. Resmi doğrulama yöntemleri, yazılımları veya akıllı sözleşmeleri belirlemek ve doğrulamak için titiz matematiksel teknikler kullanır.

3.3 Resmi doğrulama teknikleri

Resmi doğrulama, iyileştirme için geniş bir teknik yelpazesine sahiptir. akıllı sözleşme güvenliği. Blogun bu bölümünde, birkaç tanesini tek tek inceleyeceğiz.

3.3.1 Model Kontrolü

Resmi bir spesifikasyonun ne olduğunu tartıştığımız gibi, bu resmi doğrulama tekniğinde akıllı sözleşmeyi spesifikasyonuna göre kontrol ediyoruz. Bu akıllı sözleşmeler durum geçiş sistemleri olarak temsil edilir ve özellikler zamansal mantık kullanılarak tanımlanır. 

Bu teknik, öncelikle akıllı sözleşmelerin zaman içindeki davranışını gösteren geçici özellikleri değerlendirmek için kullanılır. Erişim kontrolü özelliği (yönetici çağrısı kendini imha) biçimsel mantık olarak yazılabilir. Ardından, model kontrol algoritması, sözleşmenin bu resmi doğrulamayı karşılayıp karşılamadığını doğrulayabilir.

Model kontrolü, temel olarak akıllı sözleşmemizin içinde olabileceği tüm olası durumları deneyen ve ardından bunlardan herhangi birinin bir mülk ihlaliyle sonuçlanıp sonuçlanmadığını kontrol eden Durum Uzayı araştırması adlı bir teknik kullanır. Ancak bu, sonsuz sayıda duruma yol açabilir; bu nedenle model denetleyicileri, akıllı sözleşmelerin verimli bir analizini mümkün kılmak için soyutlama tekniklerine güvenir.

3.3.2 Teorem Kanıtlama

Teorem kanıtlama, programların doğruluğuna ilişkin matematiksel akıl yürütme ile ilgilidir. Sözleşme sistemi ve özellikleri hakkında mantıksal bir izlenim yaratmak ve ifadeler arasındaki “mantıksal denkliği” doğrulamakla ilgilenir. Mantıksal eşdeğerlik, A ifadesinin ancak ve ancak B ifadesi doğruysa doğru olduğunu söyleyen matematiksel bir ilişkidir.

Model kontrol tekniğinde öğrendiğimiz gibi sözleşmeleri sonlu durumlu geçiş sistemleri olarak modelliyoruz. Teorem kanıtlama, sonsuz durum sistemlerinin analizini gerçekleştirebilir. Bununla birlikte, otomatik bir teorem ispatlayıcı, bir mantıksal problemin karar verilebilir olup olmadığını her zaman bilemez; bu nedenle, doğruluk kanıtlarını türetmede teorem kanıtlayıcıya rehberlik etmek için genellikle insan yardımı gerekir.

4. Sonuç

Test etme ve resmi doğrulama, akıllı sözleşme geliştirmenin ayrılmaz parçalarıdır. Bunlar, akıllı sözleşmeleri güvenli hale getirmek ve sözleşmelerin kullanıma hazır hale getirilmesine yardımcı olmak için kullanılan yöntemlerdir. Ama bildiğiniz gibi güvenlik hiçbir zaman yeterli olmuyor. Pek çok akıllı sözleşme, uygun test yapılmadığı için saldırıya uğruyordu. Artık web3 topluluğunun her zamankinden daha fazla daha güvenli protokollere ihtiyacı var. 

QuillAudits olarak, protokollerinizi korumaya yardımcı olma görevimiz var. Yetenekli ve tecrübeli ekibimizle tek bir zafiyetin dahi gözden kaçmamasını sağlıyoruz. Web sitemizi ziyaret edin ve Web3 projenizi güvenceye alın!

28 Görünümler

• SEO Destekli İçerik ve Halkla İlişkiler Dağıtımı. Bugün Gücünüzü Artırın.
• Plato blok zinciri. Web3 Metaverse Zekası. Bilgi Güçlendirildi. Buradan Erişin.
• Kaynak: https://blog.quillhash.com/2023/02/16/testing-and-formal-verification/