Yalnızca belirli işlevler için gerekli ifadeler yazmayın; protokolleriniz için gerekli ifadeler yazın. İşlev uyumluluğu kontrolleri (gereksinimler) - etki (Etkiler) - etkileşim (Etkileşimler) + protokol değişmezliği (Başlangıçlar) veya FREI-PI modu, geliştiricileri işlev düzeyinde güvenliğe odaklanmaya zorladığından sözleşmenizin daha güvenli olmasına yardımcı olabilir. protokol düzeyinde değişmezler.
motivasyon
Mart 2023'te Euler Finance saldırıya uğradı ve 200 milyon dolar kaybetti. Euler Finance, kullanıcıların teminat yatırabilecekleri ve buna karşı borçlanabilecekleri bir borç verme piyasasıdır. Bazı benzersiz özelliklere sahiptir, aslında Compound Finance ve Aave ile karşılaştırılabilir bir borç verme piyasasıdır.
Bu hack hakkında bir postmortem'i buradan okuyabilirsiniz. Ana içeriği, kullanıcıların borç verme piyasasının temel değişmezliğini kırmalarına izin veren belirli bir işlevde sağlık kontrollerinin olmamasıdır.
Temel Başlangıçlar
Çoğu DeFi protokolünün temelinde, program durumunun her zaman doğru olması beklenen bir özelliği olan değişmezlik bulunur. Birden çok değişmeze sahip olmak da mümkündür, ancak genel olarak bunlar bir çekirdek fikir etrafında inşa edilir. İşte bazı örnekler:
Borç verme piyasasında olduğu gibi: kullanıcılar, herhangi bir hesabı güvenli olmayan veya daha az güvenli bir teminat konumuna yerleştirmek için herhangi bir işlem yapamaz ("daha az güvenli", zaten minimum güvenlik eşiğinin altında olduğu ve bu nedenle daha fazla geri çekilemeyeceği anlamına gelir).
AMM DEX'te: x * y == k, x + y == k, vb.
Likidite madenciliğinde staking: kullanıcılar yalnızca yatırdıkları stake token miktarını çekebilmelidir.
Euler Finance'te ters giden şey, özellikler eklemeleri, testler yazmamaları veya geleneksel en iyi uygulamaları takip etmemeleri değildi. Yükseltmeyi denetlediler ve testler yaptılar, ancak yine de çatlaklardan sıyrıldı. Temel sorun, borç verme piyasasının temel bir değişmezini unutmalarıdır (denetçiler gibi!).
*Not: Euler'i hedef almaya çalışmıyorum, onlar yetenekli bir takım ama bu yeni bir durum. *
Sorunun özü
Muhtemelen "Doğru. Bu yüzden saldırıya uğradılar; bir gereklilik ifadesini unuttular" diye düşünüyorsunuz. Evet ve hayır.
Ama neden gerekli ifadeyi unutsunlar?
kontrol et - onayla - etkileşim yeterince iyi değil
Sağlamlık geliştiricileri için önerilen yaygın bir model, Kontroller-Etkiler-Etkileşimler modelidir. Yeniden girişle ilgili hataları ortadan kaldırmak için çok yararlıdır ve genellikle bir geliştiricinin yapması gereken girdi doğrulama miktarını artırır. _Ama_, ağaçlar için ormanı görememe problemine eğilimlidir.
Geliştiriciye öğrettiği şey şudur: "Önce gereksinim ifademi yazarım, sonra doğrulama yaparım, sonra belki herhangi bir etkileşim yaparım, sonra güvendeyim". Sorun şu ki, çoğu zaman kontrollerin ve etkilerin bir karışımı haline geliyor -- fena değil, değil mi? Etkileşimler hala nihaidir, bu nedenle yeniden giriş bir sorun değildir. Ancak kullanıcıları, küresel, daha geniş bağlam yerine daha spesifik işlevlere ve bireysel durum geçişlerine odaklanmaya zorlar. Bu şu demek:
Yalnızca kontrol et-doğrula-etkileşim modeli, geliştiricilerin protokollerinin temel değişmezlerini unutmasına neden olur.
Bu, geliştiriciler için hala mükemmel bir modeldir, ancak protokol değişmezleri her zaman sağlanmalıdır (cidden, hala CEI kullanıyor olmalısınız!).
Doğru yapın: FREI-PI modu
Örneğin, borç verme piyasası ve kaldıraçlı ticaret sözleşmesi olan dYdX'in SoloMargin sözleşmesinden (kaynak kodu) bu pasajı alın. Bu, İşlev Gereksinimleri-Etkiler-Etkileşimler + Protokol Başlatma modeli veya FREI-PI modeli dediğim şeye iyi bir örnek.
Bu itibarla, erken aşamadaki borç verme piyasasında piyasayla ilgili herhangi bir kırılganlığı olmayan tek borç verme piyasasının bu olduğuna inanıyorum. Bileşik ve Aave'nin doğrudan sorunları yok, ancak çatallarının var. Ve bZx birçok kez saldırıya uğradı.
Aşağıdaki kodu inceleyin ve aşağıdaki soyutlamalara dikkat edin:
Giriş parametrelerini kontrol edin (_verifyInputs).
Eylem (veri dönüştürme, durum değiştirme)
Son durumu kontrol edin (_verifyFinalState).
Olağan Kontroller-Etkiler-Etkileşimler hala gerçekleştirilir. Ek kontrollerle kontrol doğrulama etkileşiminin FREI-PI ile eşdeğer olmadığını, benzer olduklarını ancak temel olarak farklı amaçlara hizmet ettiklerini belirtmekte fayda var. Bu nedenle, geliştiriciler bunları farklı düşünmelidir: Daha yüksek bir soyutlama olarak FREI-PI, protokol güvenliğini hedeflerken, CEI işlevsel güvenliği amaçlar.
Bu sözleşmenin yapısı gerçekten ilginç - kullanıcılar istedikleri eylemleri (para yatırma, ödünç alma, ticaret yapma, aktarma, tasfiye etme vb.) bir eylemler zinciri içinde gerçekleştirebilirler. 3 farklı jeton yatırmak, 4'ünü çekmek ve bir hesabı tasfiye etmek mi istiyorsunuz? Bu tek bir arama.
Bu, FREI-PI'nin gücüdür: Görüşmenin sonunda çekirdek borç verme piyasasının değişmezleri geçerli olduğu sürece, kullanıcılar protokol içinde istediklerini yapabilirler: tek bir kullanıcı, herhangi bir hesabı güvensiz hale getirecek herhangi bir işlem yapamaz. veya daha fazla Güvensiz teminat pozisyonu. Bu sözleşme için bu, _verifyFinalState içinde gerçekleştirilir ve sözleşmenin işlemin başlatıldığı zamandan daha iyi olduğundan emin olmak için etkilenen her hesabın teminatı kontrol edilir.
Bu işleve dahil edilen, temel değişmezleri tamamlayan ve piyasaları kapatmak gibi yan işlevlere yardımcı olan bazı ek değişmezler vardır, ancak protokolü gerçekten güvende tutan temel kontrollerdir.
Varlık merkezli FREI-PI
FREI-PI ile ilgili bir başka sorun da varlık merkezli kavramdır. Örnek olarak bir borç verme piyasasını ve varsayılan temel değişmezleri ele alalım:
Teknik olarak, bu tek değişmez değildir, ancak kullanıcı varlığı içindir (hala bir çekirdek protokol değişmezidir ve genellikle kullanıcı değişmezleri temel protokol değişmezleridir). Borç verme piyasalarında ayrıca tipik olarak 2 ek varlık bulunur:
Kahin
Yönetim / Yönetişim
Her ek değişmezlik, protokolün garanti edilmesini zorlaştırır, yani ne kadar azsa o kadar iyidir. Bu aslında Dan Elitzer'in şu başlıklı makalesinde söylediği şey: DeFi neden bozuk ve nasıl düzeltilir #1 kehanetsiz protokol (ipucu: makale aslında sorunun kehanetler olduğunu söylemiyor).
kehanet
Kahinler için, 130 milyon dolarlık Cream Finance istismarını ele alalım. Oracle varlıklarının temel değişmezliği:
Görünen o ki, çalışma zamanında kehanetleri FREI-PI ile doğrulamak zor, ancak biraz öngörüyle yapılabilir. Genel olarak konuşursak, Chainlink, değişmezliğin çoğunu tatmin eden, çoğunlukla güvenmek için iyi bir seçimdir. Nadir görülen manipülasyon veya şaşırtma durumlarında, doğruluğun lehine esnekliği azaltan önlemlere sahip olmak faydalı olabilir (bilinen son değerin mevcut değerden yüzde birkaç daha yüksek olduğunun kontrol edilmesi gibi). Ayrıca, dYdX'in SoloMargin sistemi, DAI kehaneti ile harika bir iş çıkarıyor, işte kod (söyleyemiyorsanız, bence şimdiye kadar yazılmış en iyi karmaşık akıllı sözleşme sistemi).
Kehanet değerlendirmesi hakkında daha fazla bilgi almak ve Euler ekibinin yeteneklerini vurgulamak için, Uniswap V3 TWAP kehanet fiyatlarının hesaplamalı olarak manipüle edilmesi hakkında iyi bir makale yazdılar.
Yönetim / Yönetişim
Yönetilen varlıklar için değişmezler oluşturmak en zor olanıdır. Bunun başlıca nedeni, rollerinin çoğunun mevcut diğer değişmezleri değiştirmek olmasıdır. Bununla birlikte, yönetici rollerini kullanmaktan kaçınabiliyorsanız, yapmalısınız.
Temel olarak, yönetilen bir varlığın temel değişmezleri şunlar olabilir:
Yorum: Yöneticiler, kullanıcıların fonlarını korumak için bazı şeyleri büyük ölçüde değiştirmedikçe (örneğin: varlıkları bir kurtarma sözleşmesine taşımak, değişmezlerin kaldırılmasıdır), değişmezleri bozmaması gereken şeyler yapabilir. Yöneticiler de bir kullanıcı olarak düşünülmelidir, bu nedenle temel borç verme piyasasının kullanıcı değişmezliği onlar için de geçerli olmalıdır (yani, diğer kullanıcılara veya protokollere saldıramazlar). Şu anda, bazı yönetici eylemlerinin çalışma zamanında FREI-PI aracılığıyla doğrulanması imkansızdır, ancak başka yerlerde yeterince güçlü değişmezlerle, umarız sorunların çoğu hafifletilebilir. Şu anda söylüyorum, çünkü sözleşmenin tüm durumunu (kullanıcı başına, kehanet başına, vb.) Kontrol edebilecek bir zk ispat sistemi kullanmayı hayal edebilirsiniz.
Değişmezliği bozan bir yönetici örneği olarak, Ağustos 2022'de cETH piyasasını sarsan Bileşik yönetişim eylemini ele alalım. Temel olarak, bu yükseltme Oracle'ın değişmezliğini kırar: Oracle, doğru ve (nispeten) gerçek zamanlı bilgiler sağlar. Eksik işlevsellik nedeniyle, Oracle yanlış bilgi sağlayabilir. Etkilenen Oracle'ın gerçek zamanlı bilgi sağlayıp sağlayamayacağını kontrol eden çalışma zamanı FREI-PI doğrulaması, yükseltme ile bunun olmasını engelleyebilir. Bu, tüm varlıkların gerçek zamanlı bilgileri alıp almadığını kontrol etmek için _setPriceOracle'a dahil edilebilir. Yönetici rolleri için FREI-PI ile ilgili güzel şey, yönetici rollerinin fiyata karşı nispeten duyarsız olmasıdır (ya da en azından öyle olmalıdır), bu nedenle daha fazla gaz kullanımı büyük bir sorun olmamalıdır.
Karmaşıklık Tehlikelidir
Dolayısıyla, en önemli değişmezler protokolün temel değişmezleri olsa da, çekirdek değişmezler tarafından tutulması gereken bazı varlık merkezli değişmezler de olabilir. Bununla birlikte, en basit (ve en küçük) değişmezler kümesi muhtemelen en güvenli olanıdır. Basit iyidir Parlayan bir örnek Uniswap…
Neden Uniswap hiç hacklenmedi (muhtemelen)
AMM'ler, herhangi bir DeFi ilkelinin en basit temel değişmezliğine sahip olabilir: tokenBalanceX * tokenBalanceY == k (ör. sabit ürün modeli). Uniswap V2'deki her işlev şu basit değişmezin etrafında döner:
Nane: k'ye eklendi
Yakma: k'den çıkarma
Değiştirin: x ve y'yi aktarın, ancak k'yi koruyun.
Gözden Geçirme: tokenBalanceX * tokenBalanceY'yi k'ye eşitleyecek şekilde yeniden ayarlayın ve gereksiz kısmı çıkarın.
Uniswap V2'nin güvenlik sırrı: çekirdek basit bir değişmezliktir ve tüm işlevler onun hizmetindedir. Tartışılabilecek diğer tek varlık, temel değişmezliğe dokunmayan, yalnızca token bakiyesi sahipliğinin dağılımına dokunmayan bir ücret anahtarını açabilen yönetişimdir. Güvenlik beyanlarındaki bu basitlik, Uniswap'in neden hiç saldırıya uğramadığını açıklıyor. Sadelik aslında Uniswap'in akıllı kontratlarının mükemmel geliştiricileri için bir küçümseme değildir, aksine, sadeliği bulmak için mükemmel mühendisler gerekir.
Gaz sorunu
Twitter'ım zaten bu kontrollerin gereksiz ve verimsiz olduğuna dair optimizasyonist korku ve acı çığlıklarıyla dolu. Bu soru hakkında iki şey:
Başka neyin verimsiz olduğunu biliyor musunuz? ~~Laurence~~ Kuzey Koreli bilgisayar korsanlarına etherscan aracılığıyla mesajlar göndermek, ETH kullanarak para aktarmak ve FBI'ın müdahale edeceği tehdidinde bulunmak zorunda kaldım.
Muhtemelen ihtiyacınız olan tüm verileri depolama alanından yüklemişsinizdir, bu nedenle aramanın sonunda sıcak verilere biraz gereklilik denetimi ekleyin. Sözleşmenizin ihmal edilebilir bir ücrete mal olmasını mı yoksa ölmesine izin mi vermek istiyorsunuz?
Maliyet engelleyici ise, temel değişkenleri yeniden düşünün ve basitleştirmeye çalışın.
Bu benim için ne anlama geliyor?
Bir geliştirici olarak, temel değişmezleri geliştirme sürecinin başlarında tanımlamak ve ifade etmek önemlidir. Somut bir öneri olarak: Kendinizi yazmanın ilk işlevi, sözleşmenize yapılan her çağrıdan sonra değişmezlerinizi doğrulamak için _verifyAfter işlevidir. Sözleşmenize koyun ve orada konuşlandırın. Bu değişmezi (ve diğer varlık merkezli değişmezleri), konuşlandırmadan önce kontrol edilen daha geniş değişmez testlerle tamamlayın (Dökümhane kılavuzu).
Geçici depolar, Nascent'in deneyeceği bazı ilginç optimizasyonlar ve iyileştirmeler sunuyor -- Geçici mağazaların, çağrı bağlamlarında daha iyi güvenlik için nasıl bir araç olarak kullanılabileceğini düşünmenizi öneririm.
Bu yazıda, FREI-PI modelinin giriş doğrulamaya tanıtılması için fazla zaman harcanmamıştır, ancak aynı zamanda çok önemlidir. Girdinin sınırlarını belirlemek, taşma ve benzeri durumlardan kaçınmak için zorlu bir iştir. Aracımızın ilerleyişini kontrol etmeyi ve takip etmeyi düşünün: pirometre (şu anda beta sürümünde, lütfen bize bir yıldız verin). Detaya inebilir ve girdi doğrulaması yapmayabileceğiniz yerleri bulmanıza yardımcı olabilir.
Sonuç olarak
Herhangi bir akılda kalıcı kısaltma (FREI-PI) veya şema adının yanı sıra, gerçekten önemli olan bit şudur:
Protokolünüzün temel değişmezliğinde basitliği bulun. Ve asla yok edilmediğinden (veya yok olmadan önce yakalanmadığından) emin olmak için canla başla çalışın.
View Original
This page may contain third-party content, which is provided for information purposes only (not representations/warranties) and should not be considered as an endorsement of its views by Gate, nor as financial or professional advice. See Disclaimer for details.
Yeni Bir DeFi Sözleşme Güvenliği Modeli: Protokol Değişmezliğine Odaklanma
Özet
Yalnızca belirli işlevler için gerekli ifadeler yazmayın; protokolleriniz için gerekli ifadeler yazın. İşlev uyumluluğu kontrolleri (gereksinimler) - etki (Etkiler) - etkileşim (Etkileşimler) + protokol değişmezliği (Başlangıçlar) veya FREI-PI modu, geliştiricileri işlev düzeyinde güvenliğe odaklanmaya zorladığından sözleşmenizin daha güvenli olmasına yardımcı olabilir. protokol düzeyinde değişmezler.
motivasyon
Mart 2023'te Euler Finance saldırıya uğradı ve 200 milyon dolar kaybetti. Euler Finance, kullanıcıların teminat yatırabilecekleri ve buna karşı borçlanabilecekleri bir borç verme piyasasıdır. Bazı benzersiz özelliklere sahiptir, aslında Compound Finance ve Aave ile karşılaştırılabilir bir borç verme piyasasıdır.
Bu hack hakkında bir postmortem'i buradan okuyabilirsiniz. Ana içeriği, kullanıcıların borç verme piyasasının temel değişmezliğini kırmalarına izin veren belirli bir işlevde sağlık kontrollerinin olmamasıdır.
Temel Başlangıçlar
Çoğu DeFi protokolünün temelinde, program durumunun her zaman doğru olması beklenen bir özelliği olan değişmezlik bulunur. Birden çok değişmeze sahip olmak da mümkündür, ancak genel olarak bunlar bir çekirdek fikir etrafında inşa edilir. İşte bazı örnekler:
Euler Finance'te ters giden şey, özellikler eklemeleri, testler yazmamaları veya geleneksel en iyi uygulamaları takip etmemeleri değildi. Yükseltmeyi denetlediler ve testler yaptılar, ancak yine de çatlaklardan sıyrıldı. Temel sorun, borç verme piyasasının temel bir değişmezini unutmalarıdır (denetçiler gibi!).
*Not: Euler'i hedef almaya çalışmıyorum, onlar yetenekli bir takım ama bu yeni bir durum. *
Sorunun özü
Muhtemelen "Doğru. Bu yüzden saldırıya uğradılar; bir gereklilik ifadesini unuttular" diye düşünüyorsunuz. Evet ve hayır.
Ama neden gerekli ifadeyi unutsunlar?
kontrol et - onayla - etkileşim yeterince iyi değil
Sağlamlık geliştiricileri için önerilen yaygın bir model, Kontroller-Etkiler-Etkileşimler modelidir. Yeniden girişle ilgili hataları ortadan kaldırmak için çok yararlıdır ve genellikle bir geliştiricinin yapması gereken girdi doğrulama miktarını artırır. _Ama_, ağaçlar için ormanı görememe problemine eğilimlidir.
Geliştiriciye öğrettiği şey şudur: "Önce gereksinim ifademi yazarım, sonra doğrulama yaparım, sonra belki herhangi bir etkileşim yaparım, sonra güvendeyim". Sorun şu ki, çoğu zaman kontrollerin ve etkilerin bir karışımı haline geliyor -- fena değil, değil mi? Etkileşimler hala nihaidir, bu nedenle yeniden giriş bir sorun değildir. Ancak kullanıcıları, küresel, daha geniş bağlam yerine daha spesifik işlevlere ve bireysel durum geçişlerine odaklanmaya zorlar. Bu şu demek:
Yalnızca kontrol et-doğrula-etkileşim modeli, geliştiricilerin protokollerinin temel değişmezlerini unutmasına neden olur.
Bu, geliştiriciler için hala mükemmel bir modeldir, ancak protokol değişmezleri her zaman sağlanmalıdır (cidden, hala CEI kullanıyor olmalısınız!).
Doğru yapın: FREI-PI modu
Örneğin, borç verme piyasası ve kaldıraçlı ticaret sözleşmesi olan dYdX'in SoloMargin sözleşmesinden (kaynak kodu) bu pasajı alın. Bu, İşlev Gereksinimleri-Etkiler-Etkileşimler + Protokol Başlatma modeli veya FREI-PI modeli dediğim şeye iyi bir örnek.
Bu itibarla, erken aşamadaki borç verme piyasasında piyasayla ilgili herhangi bir kırılganlığı olmayan tek borç verme piyasasının bu olduğuna inanıyorum. Bileşik ve Aave'nin doğrudan sorunları yok, ancak çatallarının var. Ve bZx birçok kez saldırıya uğradı.
Aşağıdaki kodu inceleyin ve aşağıdaki soyutlamalara dikkat edin:
Olağan Kontroller-Etkiler-Etkileşimler hala gerçekleştirilir. Ek kontrollerle kontrol doğrulama etkileşiminin FREI-PI ile eşdeğer olmadığını, benzer olduklarını ancak temel olarak farklı amaçlara hizmet ettiklerini belirtmekte fayda var. Bu nedenle, geliştiriciler bunları farklı düşünmelidir: Daha yüksek bir soyutlama olarak FREI-PI, protokol güvenliğini hedeflerken, CEI işlevsel güvenliği amaçlar.
Bu sözleşmenin yapısı gerçekten ilginç - kullanıcılar istedikleri eylemleri (para yatırma, ödünç alma, ticaret yapma, aktarma, tasfiye etme vb.) bir eylemler zinciri içinde gerçekleştirebilirler. 3 farklı jeton yatırmak, 4'ünü çekmek ve bir hesabı tasfiye etmek mi istiyorsunuz? Bu tek bir arama.
Bu, FREI-PI'nin gücüdür: Görüşmenin sonunda çekirdek borç verme piyasasının değişmezleri geçerli olduğu sürece, kullanıcılar protokol içinde istediklerini yapabilirler: tek bir kullanıcı, herhangi bir hesabı güvensiz hale getirecek herhangi bir işlem yapamaz. veya daha fazla Güvensiz teminat pozisyonu. Bu sözleşme için bu, _verifyFinalState içinde gerçekleştirilir ve sözleşmenin işlemin başlatıldığı zamandan daha iyi olduğundan emin olmak için etkilenen her hesabın teminatı kontrol edilir.
Bu işleve dahil edilen, temel değişmezleri tamamlayan ve piyasaları kapatmak gibi yan işlevlere yardımcı olan bazı ek değişmezler vardır, ancak protokolü gerçekten güvende tutan temel kontrollerdir.
Varlık merkezli FREI-PI
FREI-PI ile ilgili bir başka sorun da varlık merkezli kavramdır. Örnek olarak bir borç verme piyasasını ve varsayılan temel değişmezleri ele alalım:
Teknik olarak, bu tek değişmez değildir, ancak kullanıcı varlığı içindir (hala bir çekirdek protokol değişmezidir ve genellikle kullanıcı değişmezleri temel protokol değişmezleridir). Borç verme piyasalarında ayrıca tipik olarak 2 ek varlık bulunur:
Her ek değişmezlik, protokolün garanti edilmesini zorlaştırır, yani ne kadar azsa o kadar iyidir. Bu aslında Dan Elitzer'in şu başlıklı makalesinde söylediği şey: DeFi neden bozuk ve nasıl düzeltilir #1 kehanetsiz protokol (ipucu: makale aslında sorunun kehanetler olduğunu söylemiyor).
kehanet
Kahinler için, 130 milyon dolarlık Cream Finance istismarını ele alalım. Oracle varlıklarının temel değişmezliği:
Görünen o ki, çalışma zamanında kehanetleri FREI-PI ile doğrulamak zor, ancak biraz öngörüyle yapılabilir. Genel olarak konuşursak, Chainlink, değişmezliğin çoğunu tatmin eden, çoğunlukla güvenmek için iyi bir seçimdir. Nadir görülen manipülasyon veya şaşırtma durumlarında, doğruluğun lehine esnekliği azaltan önlemlere sahip olmak faydalı olabilir (bilinen son değerin mevcut değerden yüzde birkaç daha yüksek olduğunun kontrol edilmesi gibi). Ayrıca, dYdX'in SoloMargin sistemi, DAI kehaneti ile harika bir iş çıkarıyor, işte kod (söyleyemiyorsanız, bence şimdiye kadar yazılmış en iyi karmaşık akıllı sözleşme sistemi).
Kehanet değerlendirmesi hakkında daha fazla bilgi almak ve Euler ekibinin yeteneklerini vurgulamak için, Uniswap V3 TWAP kehanet fiyatlarının hesaplamalı olarak manipüle edilmesi hakkında iyi bir makale yazdılar.
Yönetim / Yönetişim
Yönetilen varlıklar için değişmezler oluşturmak en zor olanıdır. Bunun başlıca nedeni, rollerinin çoğunun mevcut diğer değişmezleri değiştirmek olmasıdır. Bununla birlikte, yönetici rollerini kullanmaktan kaçınabiliyorsanız, yapmalısınız.
Temel olarak, yönetilen bir varlığın temel değişmezleri şunlar olabilir:
Yorum: Yöneticiler, kullanıcıların fonlarını korumak için bazı şeyleri büyük ölçüde değiştirmedikçe (örneğin: varlıkları bir kurtarma sözleşmesine taşımak, değişmezlerin kaldırılmasıdır), değişmezleri bozmaması gereken şeyler yapabilir. Yöneticiler de bir kullanıcı olarak düşünülmelidir, bu nedenle temel borç verme piyasasının kullanıcı değişmezliği onlar için de geçerli olmalıdır (yani, diğer kullanıcılara veya protokollere saldıramazlar). Şu anda, bazı yönetici eylemlerinin çalışma zamanında FREI-PI aracılığıyla doğrulanması imkansızdır, ancak başka yerlerde yeterince güçlü değişmezlerle, umarız sorunların çoğu hafifletilebilir. Şu anda söylüyorum, çünkü sözleşmenin tüm durumunu (kullanıcı başına, kehanet başına, vb.) Kontrol edebilecek bir zk ispat sistemi kullanmayı hayal edebilirsiniz.
Değişmezliği bozan bir yönetici örneği olarak, Ağustos 2022'de cETH piyasasını sarsan Bileşik yönetişim eylemini ele alalım. Temel olarak, bu yükseltme Oracle'ın değişmezliğini kırar: Oracle, doğru ve (nispeten) gerçek zamanlı bilgiler sağlar. Eksik işlevsellik nedeniyle, Oracle yanlış bilgi sağlayabilir. Etkilenen Oracle'ın gerçek zamanlı bilgi sağlayıp sağlayamayacağını kontrol eden çalışma zamanı FREI-PI doğrulaması, yükseltme ile bunun olmasını engelleyebilir. Bu, tüm varlıkların gerçek zamanlı bilgileri alıp almadığını kontrol etmek için _setPriceOracle'a dahil edilebilir. Yönetici rolleri için FREI-PI ile ilgili güzel şey, yönetici rollerinin fiyata karşı nispeten duyarsız olmasıdır (ya da en azından öyle olmalıdır), bu nedenle daha fazla gaz kullanımı büyük bir sorun olmamalıdır.
Karmaşıklık Tehlikelidir
Dolayısıyla, en önemli değişmezler protokolün temel değişmezleri olsa da, çekirdek değişmezler tarafından tutulması gereken bazı varlık merkezli değişmezler de olabilir. Bununla birlikte, en basit (ve en küçük) değişmezler kümesi muhtemelen en güvenli olanıdır. Basit iyidir Parlayan bir örnek Uniswap…
Neden Uniswap hiç hacklenmedi (muhtemelen)
AMM'ler, herhangi bir DeFi ilkelinin en basit temel değişmezliğine sahip olabilir: tokenBalanceX * tokenBalanceY == k (ör. sabit ürün modeli). Uniswap V2'deki her işlev şu basit değişmezin etrafında döner:
Uniswap V2'nin güvenlik sırrı: çekirdek basit bir değişmezliktir ve tüm işlevler onun hizmetindedir. Tartışılabilecek diğer tek varlık, temel değişmezliğe dokunmayan, yalnızca token bakiyesi sahipliğinin dağılımına dokunmayan bir ücret anahtarını açabilen yönetişimdir. Güvenlik beyanlarındaki bu basitlik, Uniswap'in neden hiç saldırıya uğramadığını açıklıyor. Sadelik aslında Uniswap'in akıllı kontratlarının mükemmel geliştiricileri için bir küçümseme değildir, aksine, sadeliği bulmak için mükemmel mühendisler gerekir.
Gaz sorunu
Twitter'ım zaten bu kontrollerin gereksiz ve verimsiz olduğuna dair optimizasyonist korku ve acı çığlıklarıyla dolu. Bu soru hakkında iki şey:
Maliyet engelleyici ise, temel değişkenleri yeniden düşünün ve basitleştirmeye çalışın.
Bu benim için ne anlama geliyor?
Bir geliştirici olarak, temel değişmezleri geliştirme sürecinin başlarında tanımlamak ve ifade etmek önemlidir. Somut bir öneri olarak: Kendinizi yazmanın ilk işlevi, sözleşmenize yapılan her çağrıdan sonra değişmezlerinizi doğrulamak için _verifyAfter işlevidir. Sözleşmenize koyun ve orada konuşlandırın. Bu değişmezi (ve diğer varlık merkezli değişmezleri), konuşlandırmadan önce kontrol edilen daha geniş değişmez testlerle tamamlayın (Dökümhane kılavuzu).
Geçici depolar, Nascent'in deneyeceği bazı ilginç optimizasyonlar ve iyileştirmeler sunuyor -- Geçici mağazaların, çağrı bağlamlarında daha iyi güvenlik için nasıl bir araç olarak kullanılabileceğini düşünmenizi öneririm.
Bu yazıda, FREI-PI modelinin giriş doğrulamaya tanıtılması için fazla zaman harcanmamıştır, ancak aynı zamanda çok önemlidir. Girdinin sınırlarını belirlemek, taşma ve benzeri durumlardan kaçınmak için zorlu bir iştir. Aracımızın ilerleyişini kontrol etmeyi ve takip etmeyi düşünün: pirometre (şu anda beta sürümünde, lütfen bize bir yıldız verin). Detaya inebilir ve girdi doğrulaması yapmayabileceğiniz yerleri bulmanıza yardımcı olabilir.
Sonuç olarak
Herhangi bir akılda kalıcı kısaltma (FREI-PI) veya şema adının yanı sıra, gerçekten önemli olan bit şudur:
Protokolünüzün temel değişmezliğinde basitliği bulun. Ve asla yok edilmediğinden (veya yok olmadan önce yakalanmadığından) emin olmak için canla başla çalışın.