Hesap Soyutlaması ile Maceralar – __validate__’deki Riskler ve Azaltmalar

Starknet, hesap soyutlamasını doğrudan protokole dahil ederek bu konuda ön plana çıkmıştır.

Hesap soyutlamanın en büyük faydalarından biri, işlemlerin biyometrik olarak doğrulanması ve günlük para çekme limitleri gibi bir kullanıcının hesabında özel doğrulama mantığı sağlama yeteneğidir.

Bunun çalışma şekli, bir işlem ağa gönderildiğinde, gönderen hesap sözleşmesinin __validate__ giriş noktası ile doğrulanması ve diğer şeylerin yanı sıra imzanın doğrulanmasıdır.

Doğrulama başarıyla geçtikten sonra, __execute__ giriş noktası çağrılır ve gerçek işlemi çalıştırır.

validate__ ile ilgili riskler

İdeal olarak, keyfi doğrulama mantığını __validate__ kodunun bir parçası olarak uygularsınız, ancak bu potansiyel DOS saldırı vektörlerine yol açar.

Doğrulamayı geçemeyen işlemler yürütülmeden önce REDDEDİLDİĞİ için herhangi bir ücrete tabi değildir. Bu, bir saldırganın çok fazla kaynak harcayan ve ardından başarısız olan çok pahalı bir __validate__ uygulaması kullanabileceği anlamına gelir – buna bağlı hiçbir ücret olmadan yüksek hesaplama maliyetine neden olur.

Risklerin azaltılması

Starknet yukarıdaki DOS vektörünü hafifletmek için çeşitli karşı önlemler alır.

Limit hesaplama

En basit ve sezgisel önlem, __validate__ içindeki hesaplamayı sınırlamaktır. Özellikle, işlem doğrulamasının çalışabileceği adım sayısını sınırlamak için.

Bu sınıra ulaşıldığında doğrulama başarısız olur. Bu sınırlama, ücret alınmadan gerçekleştirilebilecek potansiyel hesaplama miktarını sınırlar.

REDDET ağ geçidindeki işlemler

Bir başka karşı önlem de __validate__’i geçemeyen işlemleri sıralayıcı kuyruğuna bile dahil etmemektir. Aslında, bu değişiklik Starknet 0.12.1 sürümünde uygulanmıştır.

Bir işlem gönderildiğinde, düzenleyen hesap sözleşmesinin __validate__ giriş noktası ağ geçidinde çağrılacaktır. Doğrulama başarısız olursa, işlem daha fazla işleme tabi tutulmadan derhal reddedilir.

Bu faydalıdır çünkü bir işlem ağ geçidi doğrulama kontrolünü geçtikten sonra, hesaplama kapasitesi ağ geçidinin hesaplama kapasitesinden çok daha kıt bir kaynak olan sıralayıcı tarafından işlenecektir.

Ancak bekleyin: Ağ geçidi işlemin gerçekten geçersiz olduğundan nasıl emin olabilir? İşlem doğrulaması bazı harici durumlara bağlıysa ne olur?

Önlemek call_contract

Daha az önemsiz olan bir başka sınırlama da call_contract sistem çağrılarını __validate__ içinden engellemektir.

Şimdi kendinize şu soruyu sorabilirsiniz: Hesaplama sınırlandırıldıktan ve geçersiz işlemler ağ geçidinde reddedildikten sonra neden bu sınırlamaya ihtiyacımız var?

Bu sınırlamayı açıklamak için şunu varsaymamız gerekir:

1. call_contract sistem çağrısına __validate__ içinde izin verilir
2. Starknet’te MEV mümkündür (yazım sırasında, işlemler sıralı olarak işlendiğinden Starknet 0.12.1 sürümünde henüz böyle bir durum söz konusu değildir).
3. İşlemleri reddetmek ağ geçidinde sıralayıcıya göre çok daha ucuzdur.

Bu varsayımlar göz önüne alındığında, aşağıdaki saldırıyı düşünün:

• Bir saldırgan, tümü izin verilen hesaplama sınırında olan bir __validate__ işlevi uygulayan N hesap sözleşmesi kullanır.
• Kötü niyetli __validate__ mantığının sonuna doğru, saldırgan call_contract kullanarak başka bir sözleşmedeki bazı durumları sorgular. Bu, __validate__’in sırasıyla true / false yanıtına göre başarılı veya başarısız olmasına neden olur.
• Şimdi saldırgan kötü niyetli N hesap sözleşmesinin her birinden T işlem gönderir, bu da toplamda NxT işlem anlamına gelir. Saldırgan işlem gönderimleri sırasında call_contract’ın true döneceğinden emin olduğu için hepsi ağ geçidini geçer.
• Bunun hemen ardından saldırgan call_contract yanıtını false olarak değiştiren bir işlem göndererek MEV’i kullanmaya çalışır, böylece bu işlem kötü niyetli Hesap Sözleşmelerinden gelen NxT işlemlerinden önce yürütülür.
• Saldırgan başarılı olursa ve NxT işlemlerinden önce durumu true’dan false’a değiştirebilirse, saldırgan tek bir işlemle maksimum hesaplamayı kullanarak NxT REJECTed işlemleri oluşturabilecek ve işlemler yürütme sırasında __validate__ başarısız olduğu için herhangi bir ücret ödemeyecektir. REJECT, belirtildiği gibi ağda daha sınırlı ve kıt bir kaynak olan sıralayıcıda gerçekleşecektir.

Yani, tarafından REDDETağ geçidi seviyesinde işlemlerin gerçekleştirilmesinin yanı sıra, ağ geçidinin __validate__ aracılığıyla harici bir durum üzerinde call_contractbir saldırganın ağ geçidinden geçen çok sayıda işlemi sıraya koyabilmesi riskini azaltıyoruz ve REDDET sıralamada, herhangi bir ücret tahakkuk etmeden ağ üzerinde çok fazla ek yüke neden olur.

Bu serinin bir sonraki bölümünde, bu sınırlamaları dikkate alarak, hesap soyutlamasının bir başka önemli olasılığı olan Çoklu Sahip Hesabının son teknoloji doğrulama akışını nasıl uygulayacağınızı göstereceğiz. Bir sonraki AA maceramızda bize katılın.

Yoav Gaziel, Starknet için özel olarak tasarlanmış ilk cüzdan olan Braavos’un kurucu ortağıdır ve daha önce 10 yıl boyunca İsrail’in önde gelen iki girişiminde CTO olarak çalışmıştır.

Hesap soyutlama hakkında daha fazla bilgi edinmek istiyorsanız, buradaki özel kılavuzumuzu ziyaret edin. Kodumuzun daha derinlerine inmek istiyorsanız GitHub profilimizi ziyaret edin.