Akıllı sözleşme denetim raporu nasıl değerlendirilir

Bir akıllı sözleşme denetim raporunu değerlendirmek için raporun gerçek olduğunu ve denetçi tarafından yayımlandığını doğrulayın, kapsamının gerçekten dağıtılmış sözleşmeleri içerdiğini kontrol edin, kritik ve yüksek önem dereceli bulguları ve her birinin düzeltilip düzeltilmediğini okuyun ve denetimin açıkça kapsamadığı noktaları not edin. Denetim, belirli bir kodun anlık görüntüsüdür; bir projenin güvenli ya da dürüst olduğunun garantisi değildir.

Projeler “denetlendi” ifadesini sıklıkla bir güven rozeti gibi tanıtır. Bazı denetimler kapsamlı ve anlamlıdır; diğerleri dar, eskimiş ya da sahtedir. Raporu nasıl okuyacağınızı bilirseniz farkı yaklaşık on beş dakikada görebilirsiniz.

Akıllı sözleşme denetimi nedir

Akıllı sözleşme denetimi, uzmanların bir projenin kodunu okuduğu, test ettiği ve reentrancy, erişim kontrolü hataları, matematik hataları ve mantık kusurları gibi güvenlik açıklarını aradığı bir güvenlik incelemesidir. Ardından neler bulduklarını, her sorunun ne kadar ciddi olduğunu ve ekibin nasıl yanıt verdiğini listeleyen bir rapor yayımlarlar. İlgili okuma: Akıllı sözleşme istismarları.

Denetimler değerlidir, çünkü akıllı sözleşmeler dağıtıldıktan sonra zor değiştirilir ve çoğu zaman büyük miktarda para tutar. Ancak denetçiler zaman sınırları içinde çalışır, yalnızca kendilerine verileni inceler ve ince sorunları gözden kaçırabilir. Saldırıya uğrayan pek çok protokol daha önce denetlenmişti.

Tipik bir denetim raporunun bölümleri

Adım adım: Rapor nasıl değerlendirilir

1. Raporun gerçek olduğunu doğrulayın

Sahte denetimler bilinen bir dolandırıcılık taktiğidir. Raporu, kendi başınıza ulaştığınız denetçinin resmî web sitesinde veya GitHub hesabında arayın. Denetçi projeyi hiç duymamışsa ya da rapor yalnızca projenin sitesinde bir PDF olarak varsa, onu doğrulanmamış kabul edin. Sahte denetimler rehberimiz yaygın hileleri listeler.

2. Kapsamı dağıtılmış olanla eşleştirin

Rapor bir kod commit’i veya sözleşme adresleri belirtmelidir. Dağıtılmış sözleşmelerin eşleştiğini bir blok gezgininde kontrol edin. Yaygın boşluklar:

• Denetim daha eski bir sürümü kapsadı ve kod sonradan değişti.
• Yalnızca token sözleşmesi denetlendi; kullanıcı fonlarını tutan staking, vault veya köprü sözleşmeleri denetlenmedi.
• Sözleşmeler yükseltilebilir, yani kod daha sonra değiştirilebilir.

3. Önce ciddi bulguları okuyun

Doğrudan kritik ve yüksek önem dereceli sorunlara gidin. Her biri için şunu sorun:

• Çözüldü olarak işaretlenmiş mi ve denetçi düzeltmeyi doğrulamış mı?
• Düzeltilmek yerine “kabul edildi” ise, ekibin gerekçesi nedir?
• Token basma, transferleri durdurma veya fon çekme yeteneği gibi yönetici ayrıcalıklarıyla ilgili mi?

Kabul edilmiş merkezileşme sorunları, yatırımcılar için çoğu zaman kod hatalarından daha önemlidir. Sınırsız token basabilen bir sahip, kod kusursuz çalışsa bile bir risktir.

4. Tarihleri kontrol edin

Denetimin ne zaman yapıldığını not edin ve bunu dağıtım tarihi ve sonraki yükseltmelerle karşılaştırın. Sık yükseltilen bir protokolün eski bir denetimi, bugünkü kod hakkında pek bir şey söylemez.

5. Denetçiyi değerlendirin

Herkese açık bir geçmişe, ayrıntılı yayımlanmış raporlara ve isimleri belli güvenlik araştırmacılarına sahip denetçileri tercih edin. Ayda yüzlerce token denetleyen bir firmadan gelen, ayrıntı içermeyen tek sayfalık bir rapor daha az ağırlık taşır.

6. Sorumluluk reddini ve sınırlamaları okuyun

Sorumluluk reddi metinleri genellikle denetimin ekonomik tasarımı, zincir dışı bileşenleri, oracle’ları, ön yüz kodunu veya gelecekteki değişiklikleri kapsamadığını belirtir. Gerçek dünyadaki pek çok kayıp tam da bu alanlarda yaşanır.

Önem seviyelerini anlamak

Tanımlar firmadan firmaya değişse de çoğu denetçi benzer bir ölçek kullanır:

Çok sayıda bulgu içeren bir rapor mutlaka kötü haber değildir. Denetçinin titiz olduğu ve ekibin sorunları lansmandan önce düzelttiği anlamına gelebilir. Önemli olan, çözülmeden kalanların ne kadar ciddi olduğu ve ekibin nasıl yanıt verdiğidir. Her bulguya itiraz eden ya da ciddi olanları sessizce görmezden gelen bir ekip, güvenlik kültürü hakkında size bir şey söyler.

Denetim raporlarındaki uyarı işaretleri

• Kapsam ayrıntısı, commit hash’i veya sözleşme adresi yok.
• Düzeltilmeden “kabul edildi” olarak listelenmiş kritik sorunlar.
• Projenin önemsiz gösterdiği, sahip ayrıcalıklarıyla ilgili bulgular.
• Yalnızca projenin barındırdığı rapor.
• “%100 güvenli” veya “denetimle tamamen güvence altında” gibi pazarlama iddiaları.
• Büyük kod değişikliklerinden çok önceye tarihlenen denetim.

Bir denetimin size söylemedikleri

Güçlü bir denetim bile şu sorulara yanıt vermez:

• Ekibin gerçek ve güvenilir olup olmadığı; bkz. bir kripto ekibinin gerçek olup olmadığı nasıl kontrol edilir.
• Likiditenin kilitli olup olmadığı veya çekilip çekilemeyeceği.
• Tokenin arzının ve kilit açılımlarının adil olup olmadığı.
• Protokolün ekonomik tasarımının baskı altında çökebilip çökemeyeceği.

Denetimi; herkese açık bir bug bounty programı, birden fazla bağımsız denetim, olaysız geçen üretim süresi ve şeffaf yönetici kontrolleri gibi diğer kontrollerle birleştirin.

Sonuç

Bir denetim raporu yalnızca gerçek, güncel ve gerçekten kullandığınız sözleşmeleri kapsıyorsa yararlı bir kanıttır. Kaynağı doğrulayın, kapsamı eşleştirin, ciddi bulguları ve nasıl çözüldüklerini okuyun ve dışarıda bırakılanlara dikkat edin. Onu araştırmanızın girdilerinden biri olarak kullanın, asla bir projenin güvenli olduğunun kanıtı olarak değil.