Resmi doğrulama, mükemmel bir akıllı sözleşmeyi nasıl sağlar?
Akıllı sözleşmelerin güvenliği çok önemlidir. Daha önce, Ethereum bayt kodunda sık karşılaşılan güvenlik sorunları hakkında makaleler yazmıştım, ancak bunun gibi genel tespit sadece yüzeyseldir. İdeal olarak, akıllı sözleşmemizin% 100 doğru olmasını sağlamak istiyoruz. Resmi doğrulama, belirli bir yanlış durumun meydana gelmediğinden emin olmamızı sağlar.
Ethereum sanal makinesinin anlamsal modeli ve farklı çerçeveler kullanarak akıllı sözleşmelerin resmi doğrulaması üzerine birçok akademik çalışma yapılmıştır. Bu yazıda, sembolik yürütme ve Z3 teorem kanıtlamasına dayanan bir yöntemi açıklayacağım ve bu yöntemin Solidity bellek adresleme mekanizmasının neden olduğu küçük hataları tespit edebileceğini kanıtlayacağım.
Örnek olarak Sahiplenebilir'i seçiyoruz Bu çok yaygın olarak kullanılan temel bir sözleşmedir. Yazarın durumu kurucu, düzenleyici ve dönüşüm yazarının rolü olarak tanımlanabilir.
Hesaplama durum alanı
İlk adım, kodu sembolik olarak yürütmek ve olası tüm program durumlarını göstermektir. Her bir durum bir dizi belirli veya sembolik değerden oluşur ve buna ayrıca sözleşme faturaları (depolama, kalan değer ...), sanal makine ortamı (program sayacı, çağrı verileri, vb.) Ve bir dizi Yol kısıtlamaları, yani yalnızca bu gereksinimler karşılandığında o belirli duruma ulaşabileceğimiz anlamına gelir.
Mythril'in sembolik yürütme motoru, durum uzayını tam otomatik bir şekilde hesaplar. Bu kodlar aracılığıyla olası yolları görselleştirmek için, efsane komut aracı aracılığıyla bir kontrol akış diyagramı çizebiliriz.
Son olarak, tüm program akışına genel bir bakış içeren bir diyagram elde edebilirsiniz. Grafikteki her düğüm, temel bir kod bloğunu temsil eder ve kenarlar, yol koşullarını temsil eder.
Tam olarak eşlenmiş bir durum alanı her zaman mevcut değildir: Sınırsız döngüler ve özyinelemeli sözleşmeler gibi komutlar, durum sayısının katlanarak artmasına neden olur. Ancak Ethereum'un yakıt konsepti nedeniyle bu uygulamanın her zaman duracağından emin olabiliriz. Sonra, bunun hakkında daha fazla yazacağım, şimdi en basit örneğe odaklanacağız.
parametre
Sahip Olunabilir sözleşme derlendikten sonra bir kod bölümü varsa, Sahip Olunabilir'in aşağıdaki güvenlik özelliklerine göre doğru olduğunu kanıtlamaya çalışabiliriz.
"Mülkiyet yalnızca sözleşme sahibi tarafından devredilebilir."
Ethereum Sarı Kitap'ın şartlarını kullanırsanız, bu güvenlik özelliği şu şekilde tanımlanabilir: tüm ağın durumu ile, makinenin durumu ile temsil edilir ve benzeri. Bu işaretlerden bazıları aşağıdaki şekilde açıklanacaktır ancak çok aşina değilseniz önce Ethereum'un sarı kağıdına bir göz atabilirsiniz.
Solidity derleme protokolüne göre, sahip parametresi 0 depolama yuvasındadır (bu, derlenen kod kontrol edilerek doğrulanabilir). Bu nedenle, sadece = > alt kümesi ilgi çekicidir ve yuva 0'daki içerik de şu nedenlerle değişecektir:
Ethereum sanal makine dilinin tanımına göre, yalnızca SSTORE komutu genel durumu değiştirebilir. Bu nedenle, ilgili başlangıç durumunu ve makine durumunu (, ) genel durumdan seçim yaparak daha kolay elde edebiliriz:
Aşağıdaki mantık formülü karşılanabilirse, bir hata durumu görünecektir.
Layman'ın terimleriyle, tüm programda bir anlam olmadığını kanıtlamaya çalışıyoruz.Bu noktada, farklı sahipler geçiş yapabilir, ancak msg.sender komutu mevcut sahiple eşleşmiyor.
Bu parametreleri Python programına yazın
Aşağıdaki program, yukarıdaki formülü çözmek için kapsamlı bir arama yöntemi gerçekleştirecektir. Bu formül Sahip olunabilir durum uzayında karşılanabilirse, parametrelerden farklı olacak bir dizi belirli değer (durum ve giriş parametreleri) elde ederiz. Tersine, eğer bu formül sonunda doğru çıkmazsa, bu sözleşmenin verilen parametreler altında güvenli olduğu sonucuna varabiliriz.
Analizi Sahip Olunabilir üzerinde çalıştırın ve aşağıdaki sonuçları alacaksınız:
Herhangi bir karşı örnek bulamadığımız için, Sahiplik Durumu parametresini değiştirirken Sahip Olunabilir'in güvenli olduğu sonucuna varabiliriz, ancak birkaç ek koşul vardır:
-Ethereum sanal makinesinin her zaman doğru çalıştığını varsayarsak -Bu sonuç yalnızca kapalı durumlarda Sahip Olunabilir sözleşmeler için geçerlidir, bunlardan türetilen sözleşmeler için geçerli değildir.
Açık olmayan bir hatayı tespit edin
Yukarıda çizilen sonuçlar gerçekten şaşırtıcı değil: Solidity koduna bakıldığında, bu parametrelerin her zaman orada olduğu açıktır. Ancak ilginç bir şekilde, analiz araçlarımız, küçük hatalar da dahil olmak üzere, yazar tarafından keşfedilemeyecek her türlü hatayı tespit edebilir. Pwnable.sol kullanmayı düşünün, değiştirilmiş Pwnable.sol dinamik bir dizi ekler.
Aşağıdaki sonuç o kadar kötü görünmüyor: Sonuçta, transferOwnership hala ana değişkenleri yazma işlevidir ve yalnızca Sahip düzenleyicisidir. Ancak bu sefer analiz aracı şikayet etmeye başladı:
Açıkçası, bazı girdiler ana değişkenin üzerine yazılmasına neden oldu. Nihai sonuç, dinamik boyut dizisinin üzerine yazıldığını kanıtladı:
-Dizinin uzunluğu 1. depolama yuvasında saklanır. -Veri keccak (1) + ofset adresinde saklanır.
Uzaklık (MAX_UINT - keccac (1)) olarak ayarlandığında, bu sıfıra kadar ekler, böylece verileri sıfır depolama yuvasında alırız. Bunun yalnızca a1.length yapıcıda olması nedeniyle olmadığını unutmayın. Ancak ara sıra aynı sorun ortaya çıkar: Solidity'de dizi uzunluğu değişkenleri genellikle yönetim tarafından çözümlenir ve dizi.length yaygın olarak kullanılan bir semboldür.
Geliştirme
Bu sorunu çözmek için tek yapmamız gereken, çıktıyı bir analiz aracı olarak kullanabilen işlevsel bir talimat oluşturmaktır.
-calldata_0: Fonksiyon imza karması eğlencelidir (uint256, adres) -calldata_4: Çözücü, 2 ** 256 - keccak256 (1) 'ı karşılaması gereken ofseti bulur
Çözücü tarafından elde edilen bu ofset değeri kullanılabilir. Ancak açıklığa kavuşturmak için, işte Python'da nasıl hesaplandığının kodu.
Aşağıdaki fonksiyon komutu ile bitiriyoruz.
Bunun gerçekten çalıştığını doğrulamak için, Pwnable.sol'u remix üzerinde dağıtabilir ve bu işlevsel komutu UI aracılığıyla çalıştırabilirsiniz. Çalıştırdıktan sonra, ana bilgisayar içeriği okunduktan sonra yeni adresi döndürmelidir.
sonuç olarak
Bu makalede, sembolik bir yürütme motoru ve SAT kod çözücüsü kullanarak akıllı bir sözleşmenin doğruluğunun resmi olarak nasıl doğrulanacağını gösterdim. Bu tür bir analiz, jetonun belirli özelliklerini kanıtlayabilir ve bazı küçük hataları kontrol edebilir.
Gönderme sırasındaki Bitcoin fiyatı 65736,99
Orijinal: https://media.consensys.net/how-formal-verification-can-ensure-flawless-smart-contracts-cbda8ad99bd1
Yazar: Bernhard Mueller
Derleme: nuszjj
Makale kaynağı (çeviri): Babbitt Information ( Telif hakkı bildirimi:
Yazar hakkını saklı tutar. Makale, yazarın bağımsız bakış açısıdır ve Babbitt'in görüşünü temsil etmez.
