Ana içeriğe atla

Akıllı sözleşme güvenlik yönergeleri

Solidity
akıllı sözleşmeler
güvenlik
Orta
Trailofbits
6 Eylül 2020
4 dakikalık okuma

Daha güvenli akıllı sözleşmeler oluşturmak için bu üst düzey önerileri izleyin.

Tasarım yönergeleri

Sözleşmenin tasarımı, herhangi bir kod satırı yazılmadan önce önceden tartışılmalıdır.

Belgelendirme ve spesifikasyonlar

Belgelendirme farklı seviyelerde yazılabilir ve sözleşmeler uygulanırken güncellenmelidir:

Zincir içi ve zincir dışı hesaplama

  • Mümkün olduğunca çok kodu zincir dışı tutun. Zincir içi katmanı küçük tutun. Verileri zincir dışı kodla, zincir içi doğrulamanın basit olacağı şekilde önceden işleyin. Sıralı bir listeye mi ihtiyacınız var? Listeyi zincir dışı sıralayın, ardından zincir içinde yalnızca sırasını kontrol edin.

Yükseltilebilirlik

Farklı yükseltilebilirlik çözümlerini blog yazımızda (yeni sekmede açılır) tartıştık. Herhangi bir kod yazmadan önce yükseltilebilirliği destekleyip desteklememe konusunda bilinçli bir seçim yapın. Bu karar, kodunuzu nasıl yapılandıracağınızı etkileyecektir. Genel olarak şunları öneriyoruz:

  • Yükseltilebilirlik yerine sözleşme taşıma (migration) (yeni sekmede açılır) işlemini tercih edin. Taşıma sistemleri, yükseltilebilir sistemlerle aynı avantajların çoğuna sahiptir, ancak onların dezavantajlarını barındırmaz.
  • delegatecallproxy yerine veri ayırma (data separation) modelini kullanın. Projenizin net bir soyutlama ayrımı varsa, veri ayırma kullanarak yükseltilebilirlik yalnızca birkaç ayarlama gerektirecektir. delegatecallproxy, EVM uzmanlığı gerektirir ve hataya oldukça açıktır.
  • Dağıtımdan önce taşıma/yükseltme prosedürünü belgeleyin. Herhangi bir yönerge olmadan stres altında tepki vermek zorunda kalırsanız hata yaparsınız. İzlenecek prosedürü önceden yazın. Şunları içermelidir:
    • Yeni sözleşmeleri başlatan çağrılar
    • Anahtarların nerede saklandığı ve onlara nasıl erişileceği
    • Dağıtımın nasıl kontrol edileceği! Dağıtım sonrası bir betik geliştirin ve test edin.

Uygulama yönergeleri

Basitlik için çabalayın. Her zaman amacınıza uyan en basit çözümü kullanın. Ekibinizin herhangi bir üyesi çözümünüzü anlayabilmelidir.

İşlev kompozisyonu

Kod tabanınızın mimarisi, kodunuzun incelenmesini kolaylaştırmalıdır. Doğruluğu hakkında akıl yürütme yeteneğini azaltan mimari seçimlerden kaçının.

  • Sisteminizin mantığını bölün, bunu ya birden fazla sözleşme aracılığıyla ya da benzer işlevleri bir araya gruplayarak (örneğin; kimlik doğrulama, aritmetik, ...) yapın.
  • Net bir amacı olan küçük işlevler yazın. Bu, incelemeyi kolaylaştıracak ve bireysel bileşenlerin test edilmesine olanak tanıyacaktır.

Kalıtım

  • Kalıtımı yönetilebilir tutun. Kalıtım mantığı bölmek için kullanılmalıdır, ancak projeniz kalıtım ağacının derinliğini ve genişliğini en aza indirmeyi hedeflemelidir.
  • Sözleşmelerin hiyerarşisini kontrol etmek için Slither'ın kalıtım yazıcısını (yeni sekmede açılır) kullanın. Kalıtım yazıcısı, hiyerarşinin boyutunu incelemenize yardımcı olacaktır.

Olaylar

  • Tüm önemli işlemleri günlüğe kaydedin. Olaylar, geliştirme sırasında sözleşmede hata ayıklamaya ve dağıtımdan sonra onu izlemeye yardımcı olacaktır.

Bilinen tuzaklardan kaçının

Bağımlılıklar

  • İyi test edilmiş kütüphaneler kullanın. İyi test edilmiş kütüphanelerden kod içe aktarmak, hatalı kod yazma olasılığınızı azaltacaktır. Bir ERC-20 sözleşmesi yazmak istiyorsanız OpenZeppelin (yeni sekmede açılır) kullanın.
  • Bir bağımlılık yöneticisi kullanın; kodu kopyalayıp yapıştırmaktan kaçının. Harici bir kaynağa güveniyorsanız, onu orijinal kaynakla güncel tutmalısınız.

Test ve doğrulama

Solidity

  • Solidity 0.5'i 0.4 ve 0.6'ya tercih edin. Bize göre Solidity 0.5, 0.4'ten daha güvenlidir ve daha iyi yerleşik uygulamalara sahiptir. Solidity 0.6'nın üretim için çok kararsız olduğu kanıtlanmıştır ve olgunlaşması için zamana ihtiyacı vardır.
  • Derlemek için kararlı bir sürüm kullanın; uyarıları kontrol etmek için en son sürümü kullanın. Kodunuzun en son derleyici sürümüyle bildirilen hiçbir sorunu olmadığını kontrol edin. Ancak Solidity'nin hızlı bir sürüm döngüsü ve derleyici hataları geçmişi vardır, bu nedenle dağıtım için en son sürümü önermiyoruz (Slither'ın solc sürüm önerisine (yeni sekmede açılır) bakın).
  • Satır içi (inline) assembly kullanmayın. Assembly, EVM uzmanlığı gerektirir. Sarı Bülten'e (Yellow Paper) tam anlamıyla hakim değilseniz EVM kodu yazmayın.

Dağıtım yönergeleri

Sözleşme geliştirilip dağıtıldıktan sonra:

  • Sözleşmelerinizi izleyin. Günlükleri takip edin ve sözleşme veya cüzdanın ele geçirilmesi durumunda tepki vermeye hazır olun.
  • İletişim bilgilerinizi blockchain-security-contacts (yeni sekmede açılır) listesine ekleyin. Bu liste, bir güvenlik açığı keşfedildiğinde üçüncü tarafların sizinle iletişime geçmesine yardımcı olur.
  • Ayrıcalıklı kullanıcıların cüzdanlarını güvence altına alın. Anahtarları donanım cüzdanlarında saklıyorsanız en iyi uygulamalarımızı (yeni sekmede açılır) izleyin.
  • Bir olay müdahale planınız olsun. Akıllı sözleşmelerinizin ele geçirilebileceğini göz önünde bulundurun. Sözleşmeleriniz hatasız olsa bile, bir saldırgan sözleşme sahibinin anahtarlarının kontrolünü ele geçirebilir.