Bir uygulamanın her bileşeni için ayrı “güvenli” etiketi görmek, toplam akışı açıklamaz. Bir bileşenin sonucu diğerinin girdisiyse, aradaki bağımlılık da incelenmelidir. Risk haritası bu bağlantıları ve araştırmada açık kalan noktaları görünür kılar.
Kurgu uygulamanın akışı
Kullanıcı A ağındaki varlığı köprüyle B ağına taşıyor, oluşan temsili tokeni B ağındaki borç sözleşmesine teminat veriyor. Sözleşme oracle fiyatını okuyor. Yönetim rolü de belirli parametreleri veya uygulama mantığını değiştirebiliyor. Bu senaryo herhangi bir canlı protokolün yapılandırması değildir.
| Bağlantı | Araştırılacak bağımlılık | Olası sonuç |
|---|---|---|
| Cüzdan → sözleşme | İmzalanan çağrı ve token izni | Yanlış hedefe yetki |
| A ağı → köprü → B ağı | Mesaj doğrulaması ve temsil modeli | Transfer/geri dönüş aksaması |
| Teminat → fiyat kaynağı | Doğru varlık, güncellik ve ölçek | Yanlış değerleme |
| Borç sözleşmesi → yönetim | Yükseltme, eşik ve duraklatma rolleri | Kuralların değişmesi |
| Arayüz → RPC | Veri erişimi ve işlem iletimi | Ekranın zincirden farklı görünmesi |
Etiketi kanıta dönüştürün
Ethereum köprü belgesi farklı doğrulama ve güven varsayımlarını ayırır. Chainlink belgesi tüketici uygulamanın güncellik ve olağandışı veri kontrollerini ele alır. OpenZeppelin erişim kontrolü belgesi ise rol ve zaman kilidinin yapılandırmasını açıklar. Bu belgeler yöntem sağlar; kurgu uygulamanın güvenli olduğunu belgelemez.
Ethereum: köprü modelleri ve riskleri
Chainlink: veri tüketicisinin kontrolleri
OpenZeppelin: roller ve zaman kilidi
Arıza senaryosunu bağlantı boyunca izleyin
- Köprü durursa mevcut teminat kullanılabilir mi; temel varlığa dönüş ne olur?
- Oracle eski veri verirse yeni borç ve tasfiye hangi davranışı gösterir?
- Yönetim eşiği değiştirirse mevcut pozisyonlar da etkilenir mi?
- Arayüz kapanırsa belgelenmiş alternatif erişim yolu var mı?
- Aynı sağlayıcı hem RPC hem fiyat altyapısında yer alıyorsa ortak kesinti neyi etkiler?
Bir satırdaki eksik belgeyi başka bileşenin denetim raporuyla kapatmayın. Sözleşme raporu, köprünün mesaj doğrulamasını veya cüzdanın imzaladığı hedefi kapsamıyor olabilir. Her kanıtın sürümü ve kapsamı kendi bağlantısına yazılmalıdır.
Haritanın son sütunu “kanıtlandı”, “belgede beyan edildi” veya “açık soru” olabilir. Bunlar puan değildir. Amaç tek bir toplam risk yüzdesi üretmek yerine, belirli bir arıza yaşandığında hangi varlık, hak veya işlem yolunun etkilenebileceğini açıklayabilmektir.
Yorumlar