DeFi ekosisteminin hızla gelişmesiyle birlikte bu alanın öncülerinden biri olan Compound Finance V2, yenilikçi kredilendirme modeliyle çok sayıda kullanıcının ilgisini çekti. Ancak herhangi bir karmaşık dağıtılmış uygulama, özellikle milyonlarca, hatta yüz milyonlarca dolarlık fon akışını içerdiğinde potansiyel güvenlik tehditleriyle karşı karşıya kalır. Bu nedenle Compound Finance V2 ve fork projelerinin kapsamlı ve ayrıntılı bir güvenlik denetiminin yapılması özellikle önemlidir. Bu kılavuz, geliştiricilere, güvenlik araştırmacılarına ve DeFi meraklılarına, herkesin potansiyel riskleri daha etkili bir şekilde tanımlamasına ve önlemesine yardımcı olacak ayrıntılı bir güvenlik denetim kılavuzu sunmayı amaçlamaktadır.

1. Proje Arka Planına Genel Bakış

Compound Finance V2, Ethereum blok zinciri üzerine inşa edilmiş, kullanıcıların çeşitli ERC-20 temel tokenlarını yatırmasına ve bunlardan faiz kazanmasına olanak tanıyan, aynı zamanda kullanıcıların piyasadan faiz ödemeleri şeklinde tokenları ödünç almasına olanak tanıyan açık bir borç verme platformudur. "Faiz oranı piyasası" kavramını tanıtarak, merkezi olmayan sermaye havuzu yönetimini ve otomatik faiz oranı ayarlama mekanizmasını hayata geçirir.

2. Proje yapı analizi

Compound Finance V2'nin temel mimari bileşenleri şunları içerir:

2.1 Denetleyici

Comptroller sözleşmesi, her cToken örneğinin davranışını koordine etmekten sorumlu olan Compound Finance V2'nin merkezi sinir sistemidir. Ana sorumluluklar şunlardır:

2.2 cToken

Desteklenen her ERC-20 tokeni, token ile proje arasındaki tüm etkileşimleri yönetmek için kullanılan karşılık gelen bir cToken örneğine (yani CErc20 / CEther sözleşmesi) sahiptir. Temel token transfer işlevinin uygulanmasına ek olarak, her cToken ayrıca borç verme, faiz biriktirme ve ödülleri dağıtma gibi Bileşik'e özgü bazı işlevler de ekler. Dolayısıyla cToken'i, kullanıcının Compound'a varlık yatırma sertifikası ve kullanıcıların borç verme işlemlerini gerçekleştirme girişi olarak düşünebiliriz.

Kullanıcı dayanak varlık tokenını sözleşmeye yatırdığında karşılık gelen cToken belirteci basılabilir. cToken ile dayanak varlık arasındaki değişim oranı aşağıdaki formüle göre hesaplanır:

Not: Borçlar borçlanma tutarını, nakit fon havuzu bakiyesini, rezervler ise rezervleri temsil etmektedir. Borçlanma faiz oranı kullanım oranına göre, mevduat faiz oranı ise borçlanma faiz oranına göre belirlenmektedir.

Kullanıcılar genellikle farklı cToken sözleşmeleriyle etkileşime girerek farklı pazarlarda token ödünç verme işlemlerini gerçekleştirir:

2.3 Faiz OranıModeli

InterestRateModel sözleşmesi, faiz oranlarının hesaplanmasına yönelik yöntemi tanımlar. Farklı piyasalar, kendi risk iştahlarına ve likidite ihtiyaçlarına uyacak şekilde farklı türde faiz oranı modelleri kullanabilir.

Bileşik V2 piyasasında kullanılan iki ana faiz oranı modeli bulunmaktadır; biri düz çizgi tipi, diğeri ise dönüm noktası tipidir.

Doğrusal modelin borçlanma faiz oranı hesaplama formülü aşağıdaki gibidir:

Fon kullanım oranının hesaplama formülü aşağıdaki gibidir:

Mevduat faiz oranı borçlanma faiz oranıyla doğrusal olarak değişir:

Kullanımın kademeli olarak artması, fon havuzundaki paranın giderek azalması anlamına gelir. Belirli bir zirveye ulaştığında kullanıcıların normal şekilde para yatırma ve borç alamamasına neden olabilir. Bu durumu önlemek için Compound ikinci bir faiz oranı modeli olan dönüm noktası tipini tanıttı.

Dönüm noktası borçlanma faiz oranının hesaplanmasına ilişkin formül aşağıdaki gibidir:

Kullanım oranı belirli bir zirveye ulaştığında, borçlanma oranı ve mevduat faizi anında büyük ölçüde artacak, kullanıcıları daha fazla para yatırmaya ve daha az borç almaya teşvik edecek, böylece kullanım oranı uygun bir aralıkta kontrol edilecektir. Bu zirveye aynı zamanda dönüm noktası da denir. genellikle kullanım oranı %80'e ulaştığında.

2.4 PriceOracle

PriceOracle sözleşmesi, dış piyasa fiyatı bilgilerinin elde edilmesinden ve bu bilgilerin sistem tarafından dahili olarak kullanılan değerlere dönüştürülmesinden sorumludur; bu, kullanıcının pozisyonunun değerinin doğru bir şekilde hesaplanması için çok önemlidir.

2.5 Yönetişim mekanizması ve teşvik modeli

Compound, yönetişim belirteçlerini (COMP) tutan kullanıcıların, belirli parametrelerin değiştirilmesi veya yeni varlık türlerinin eklenmesi gibi önemli kararlarda oylamaya katılmasına olanak tanıyan benzersiz bir yönetim mekanizması sunar. Compound, yönetişim belirteçleri (COMP) düzenleyerek kullanıcıları platform etkinliklerine aktif olarak katılmaya teşvik eder ve katkıda bulunanlara ödüller sağlar. Ayrıntılar için lütfen Compound'un resmi belgelerine ve kod deposuna bakın. (https://docs.compound.finance/v2/; https://github.com/compound-finance/compound-protocol)

3. Etkileşim süreci

Daha sonra, Compound Finance V2'deki genel kullanıcı etkileşimi sürecini göstermek için basit bir örnek kullanıyoruz:

3.1 Para yatırma ve ödeme süreci

Kullanıcı Alice'in Compound'a 1 WBTC yatırması gerekiyorsa, para yatırma işlemini gerçekleştirmek için cWBTC sözleşmesinin nane işlevini arayacaktır. Bu sözleşme, cToken sözleşmesini devralır. Borçlanma ve mevduat faiz oranlarını güncellemek için öncelikle mintInternal işlevi aracılığıyla dahili olarak accuminterest işlevini çağıracak ve ardından belirli döküm işlemlerini gerçekleştirmek için mintFresh'i çağıracaktır.

mintFresh işlevi, mevcut piyasanın para yatırma işlemlerine izin verip vermediğini kontrol etmek için Comptroller sözleşmesinin mintAllowed işlevini harici olarak çağıracak, ardından kullanıcının 1 WBTC'sini doTransferIn işlevi aracılığıyla sözleşmeye aktaracak ve ardından kullanıcı için karşılık gelen sayıda cToken tokenını basacaktır. o zamandaki en son döviz kuru (mevcut en son döviz kurunun 0,1 olduğu varsayılarak Alice 10 cWBTC tokeni alacaktır).

Alice gelecekte depozitosunu kullanmaya karar verirse, redeem fonksiyonunu çağırarak cWBTC'yi WBTC'ye geri kullanabilir. Döviz kuru değişmiş olabilir (0,15 olduğu varsayılır), bu da Alice'in 1,5 WBTC'yi kullanabileceği anlamına gelir. 0,5 WBTC faiz geliridir.

3.2 Borçlanma ve geri ödeme süreci

Alice'in öncelikle cWBTC'sini teminat olarak kullanılabilecek bir duruma ayarlamak için Denetleyici sözleşmesinin enterMarkets işlevini çağırması gerekir ve ardından borç para alabilir.

Alice'in 70 USDC borç vermeyi seçtiğini varsayalım. WBTC'nin teminat faktörü 0,75 olduğundan Alice, WBTC değerinin %75'ine kadar borç verebilir, dolayısıyla bu onun maksimum borçlanma tutarını aşmayacaktır.

Not: Tasfiye riskini önlemek için Alice'in bir tampon tutması ve borçlanma limitini tamamen tüketmemesi gerekir.

Alice, cUSDC sözleşmesinin borç alma işlevini çağırır; bu işlev, borçlanma ve mevduat faiz oranlarını güncellemek için öncelikle borçlanma işlevi içindeki accumulatorInterest işlevini çağırır ve ardından belirli borçlanma işlemlerini gerçekleştirmek için borçlanmaFresh'i çağırır.

Comptroller sözleşmesinin borç Allowed fonksiyonu aracılığıyla kullanıcının pozisyon değeri kontrol edildikten sonra, önce kredi verileri kaydedilir ve ardından tokenlar doTransferOut fonksiyonu aracılığıyla kullanıcıya aktarılır.

Comptroller sözleşmesinin borç Allowed fonksiyonu aracılığıyla kullanıcının pozisyon değeri kontrol edildikten sonra, önce kredi verileri kaydedilir ve ardından tokenlar doTransferOut fonksiyonu aracılığıyla kullanıcıya aktarılır.

Alice'in geri ödeme yapması gerekiyorsa, cUSDC sözleşmesinin repayBorrow işlevini arayarak veya başkalarının onun adına geri ödeme yapmaları için repayBorrowBehalf işlevini çağırmasına izin vererek kendi kendine borcunu ödeyebilir.

3.3 Tasfiye süreci

WBTC'nin fiyatının, Alice'in teminatının değerinin borçlanma tutarının %75'inin altına düşecek kadar önemli ölçüde düşmesi durumunda, Alice'in kredi pozisyonu tasfiye edilecektir.

Harici bir tasfiye memuru (Bob gibi), Alice'in borcunun bir kısmını ödemesine yardımcı olmak için cUSDC sözleşmesinde tasfiye fonksiyonu LiquidateBorrow'u çağırabilir. İlk önce cUSDC'nin faiz oranlarını ve geri ödeme için kullanılan cToken teminatını LiquidateBorrowInternal işlevi aracılığıyla güncelleyecek ve ardından belirli tasfiye işlemlerini gerçekleştirmek için LiquidateBorrowFresh'i çağıracak.

Comptroller sözleşmesinin LiquidateBorrowAllowed işlevi aracılığıyla tasfiyeye izin verilip verilmediğini kontrol ettikten sonra, geri ödeme için USDC'yi sözleşmeye aktarmak ve tasfiye edilen kişinin kredi verilerini güncellemek için ilk olarak repayBorrowFresh işlevi çağrılacaktır. Daha sonra Comptroller sözleşmesinin LiquidateCalculateSeizeTokens fonksiyonu çağrılarak Bob'un Alice'in likidasyon değerine göre alabileceği teminat miktarı hesaplanır. Son olarak belirlenen teminat piyasasında cToken sözleşmesinin (cWBTC gibi) ele geçirme fonksiyonu kullanılır. Bob ve Alice için cToken'ları aktarmak için.

Yukarıdaki görselin yüksek çözünürlüklü versiyonunu görüntülemek için bu bağlantıyı açın. Doğrudan atlamak üzere orijinal metni okumak için tıklayın: https://www.figma.com/board/POkJlvKlWWc7jSccYMddet/Compound-V2?node-id=0-1&node -tip=tuval.

Bob, Alice'in kredisinin bir kısmını öder (örneğin, 20 USDC) ve böylece Alice'in karşılık gelen teminat değerini (WBTC gibi) elde eder. Aynı zamanda Bob, ek bir tasfiye teşviki de alabilir (%5 olduğu varsayılır). Nihai sonuç, Bob'un 21 USDC (20 USDC kredisi + 1 USDC tasfiye teşviki) değerinde WBTC alması oldu.

4. Güvenlik Açığı Kontrol Listesi

4.1 Boş pazarın neden olduğu yuvarlama güvenlik açığı

4. Güvenlik Açığı Kontrol Listesi

4.1 Boş pazarın neden olduğu yuvarlama güvenlik açığı

cToken boş bir piyasa ise (yani, piyasada hiçbir kullanıcı borç vermiyorsa), exchangeRateStoredInternal işlevindeki exchangeRate'in değeri, sözleşmeye karşılık gelen dayanak varlık tokenlerinin sayısına bağlı olduğundan, büyük miktarda dayanak varlık transfer edilebilir cToken fiyatını değiştirmek için cToken sözleşmesine.

Bu nedenle, büyük miktarda başka token ödünç vermek için küçük miktarda cToken kullanabilir ve ardından temel varlık tokenını geri çekmek için cToken'in redeemUnderlying işlevini çağırabilirsiniz. Geri ödemeleri hesaplarken, düşülmesi gereken cToken sayısı, bölümün aşağı yuvarlanması nedeniyle beklenenden çok daha az (neredeyse yarı yarıya) bir sonuçla sonuçlanır.

Şu anda tutulan cToken sayısının 2 (aynı zamanda toplam arz) olduğunu ve manipülasyondan sonra döviz kurunun 25.015.031.908.500.000.000.000.000.000'e yükseltildiğini ve kullanılması gereken temel varlık tokenlarının sayısının 50.030.063.815 olduğunu varsayalım. O zaman düşülmesi gereken beklenen cToken sayısı şöyle olmalıdır:

Ancak hesaplanan gerçek cToken sayısı şöyledir:

Ancak hesaplanan gerçek cToken sayısı şöyledir:

Bu nedenle, diğer pazarlardan ödünç verilen çok sayıda varlık tokenini elde etmek için sonunda yalnızca çok az sayıda cToken'ın tasfiye edilmesi gerekir.

Bu güvenlik açığı nedeniyle Compound fork projesi Hundred Finance'in hacklenen işlemine şu adresten ulaşabilirsiniz: https://optimistic.etherscan.io/tx/0x6e9ebcdebbabda04fa9f2e3bc21ea8b2e4fb4bf4f4670cb8483e2f0b2604f451

Denetim noktaları: Denetim sırasında döviz kuru hesaplama yönteminin kolay manipüle edilip edilemeyeceğine ve yuvarlama yönteminin uygun olup olmadığına dikkat etmeniz gerekir. Aynı zamanda proje ekibine küçük miktarlarda para basmasını önerebilirsiniz. Piyasanın boş kalmasını ve daha sonra manipüle edilmesini önlemek için yeni piyasa oluşturulduktan hemen sonra cToken.

4.2 ERC677/ERC777 belirteçlerinin neden olduğu yeniden giriş güvenlik açığı

ERC677 / ERC777, ERC20 sözleşmesinin bir uzantısıdır ve ERC20 tokenlerinin protokol standardıyla uyumludur. Bu tokenlar, transfer işlemi sırasında, eğer alıcı adres bir sözleşme ise, alıcı adresin geri çağırma fonksiyonunun (transferAndCall veya tokensReceived gibi) tetiklenmesine olanak tanır.

Compound Finance V2 kodunun eski sürümünde, bir kullanıcı cToken piyasasından borç aldığında, önce ödünç alınan tokenlar aktarılacak, ardından kredi verileri kaydedilecektir.

Kullanıcı tarafından ödünç verilen token, geri çağırma işlevine sahip bir ERC677/ERC777 tokeni ise, tokenı alan kötü niyetli bir sözleşme, kullanıcının son dönemde ödünç alması nedeniyle, yeniden ödünç almak için geri çağırma işlevi aracılığıyla ödünç alma işlevine yeniden girmek için oluşturulabilir. borçlanma Veriler henüz hesaba katılmadı, bu nedenle hesabın sağlık kontrolünden başarıyla geçerek tokenler şu anda tekrar ödünç verilebilir.

Bu güvenlik açığı nedeniyle saldırıya uğrayan Compound fork projesi Hundred Finance'in işlemlerine şu adresten ulaşabilirsiniz: https://blockscout.com/xdai/mainnet/tx/0x534b84f657883ddc1b66a314e8b392feb35024afdec61dfe8e7c510cfac1a098

Denetim noktaları: Ödünç alma mantığı, Bileşik V2 kodunun en son sürümünde düzeltildi. Bunun yerine, önce ödünç alma verileri kaydedilir ve ardından ödünç alınan tokenler aktarılır. Denetim sırasında, borç verme fonksiyonunun ilgili kodunun CEI (Kontroller-Etkiler-Etkileşimler) spesifikasyonuna uygun olup olmadığına dikkat edilmesi ve geri çağırma fonksiyonlarına sahip tokenların etkisinin dikkate alınması gerekir.

4.3 Uygunsuz kehanet mekanizmasından kaynaklanan fiyat manipülasyonu riski

4.3 Uygunsuz kehanet mekanizmasından kaynaklanan fiyat manipülasyonu riski

Compound Finance aşırı teminatlandırılmış bir borç verme modelini benimsediğinden, bir kullanıcının ödünç verebileceği token sayısı, teminat değerinin yeterli olup olmadığına bağlıdır.

Bu nedenle, teminatın değerini hesaplarken projenin kullandığı oracle'ın fiyat besleme mekanizması kolayca manipüle edilirse, beklenenden daha fazla token ödünç vermek kolay olacaktır.

Örneğin, Bileşik çatal projesi Lodestar Finance'in saldırıya uğraması durumunda, oracle'ın teminat plvGLP tokeninin fiyatını elde etme yöntemi, öncelikle plvGLP sözleşmesindeki (totalAssets) plsGLP tokenlarının sayısını toplam plvGLP arzına bölmekti. ( totalSupply) döviz kurunu hesaplar ve ardından plvGLP tokeninin fiyatını hesaplamak için döviz kurunu GLP tokeninin fiyatıyla çarpar.

plvGLP, kullanıcıların plvGLP token sözleşmesi için karşılık gelen plsGLP tokenlarını basmak üzere sGLP'yi bağışlamalarına olanak tanıyan bir bağış fonksiyonuna sahiptir.

Bu nedenle, bir saldırgan önce Lodestar Finans piyasasında çok sayıda plvGLP teminat pozisyonu oluşturmak için flaş kredileri kullanabilir, ardından GMX'te büyük miktarda sGLP basmak için flaş kredileri kullanabilir ve ardından GMX için plsGLP tokenleri basmak için bağış işlevini kullanabilir. totalAssets'in değerini artırmak için plvGLP sözleşmesi. Toplam varlıklar arttıkça, plvGLP'nin döviz kuru artacak ve plvGLP tokenlerinin fiyatının anında ve hızlı bir şekilde artmasına neden olacak ve diğer tokenlerin piyasaya beklentilerin ötesinde ödünç verilmesine olanak tanıyacak.

Lodestar Finance'in hacklenen işlemine buradan ulaşabilirsiniz: https://arbiscan.io/tx/0xc523c6307b025ebd9aef155ba792d1ba18d5d83f97c7a846f267d3d9a3004e8c

Ayrıca Compound Finance veya forklu projelerinin teminat fiyatını elde etmek için ChainLink veya CoinBase gibi zincir dışı oracle'ları kullanacağını da belirtmek gerekir. Ciddi piyasa dalgalanmalarıyla karşılaşırsanız, zincir dışı fiyat ile zincir üstü fiyat arasında fiyat farkı oluşabilir ve bu durum projenin finansal güvenliğini tehlikeye atabilir.

Örneğin, LUNA tokenlarının fiyatı piyasa nedenlerinden dolayı hızla düştü ve Compound Finance'in fork protokolleri Venus Protokolü ve Blizz Finance, teminat değerini hesaplamak için Chainlink oracle'larını kullanıyor. Bunlar arasında LUNA tokenlerinin en düşük fiyatı ( minAnswer) 0,10 ABD doları değerinde sabit kodlanmıştır.

LUNA tokeninin fiyatı 0,1 doların (örneğin 0,001 dolar) altına düştüğünde, herkes piyasa fiyatından büyük miktarda LUNA satın alabilir ve bunu platformdan diğer varlıkları ödünç vermek için teminat olarak (0,10 dolar değerinde) kullanabilir.

Denetim noktaları: Denetim sırasında teminatın değerini hesaplarken kullanılan oracle fiyat besleme mekanizmasının dışarıdan kolayca manipüle edilip edilemeyeceğine dikkat etmeniz gerekir. Proje tarafının kapsamlı bir değerlendirme yapabilmesi için birden fazla fiyat kaynağı kullanması önerilir. Tek fiyat kaynağından kaynaklanan risklerden kaçınmak.

4.4 Birden fazla giriş noktası tokenının neden olduğu döviz kuru manipülasyonu riski

Compound'un kodunda, yanlışlıkla sözleşmeye token aktaran kullanıcıların bu tokenları geri çekmesine olanak tanıyan, süpürmeToken adı verilen bir işlev bulunmaktadır. Eski versiyonun kodu aşağıdaki gibidir. Bu fonksiyonun önemli bir güvenlik kontrolü vardır: aktarılan token parametresi, sözleşmenin dayanak varlık token'ı olamaz.

Bununla birlikte, belirli bir cToken piyasasının dayanak varlık tokeni için birden fazla giriş noktası sözleşmesi varsa (aynı temel bakiyeye birden fazla sözleşme adresinden erişilebilir ve harici etkileşimler tüm giriş noktalarının dengesini etkiler), bu erken ajans benzeri bir işlemdir. modeli), saldırgan, temeldekinden farklı bir giriş noktası sözleşmesi ileterek sözleşmedeki temel varlık belirtecini aktarmak için süpürmeToken işlevini çağırabilir.

Aşağıdaki örnekte TUSD'yi ele alalım. İki giriş noktası sözleşmesi vardır. Yardımcı giriş noktası sözleşmesi 0x8dd5fbce, tüm çağrıları (transfer veya bakiye gibi) ana sözleşmeye iletecektir; bu, sözleşmelerden herhangi biriyle etkileşimin her iki sözleşmeyi de etkileyeceği anlamına gelir. Bakiye verileri (yani iki farklı sözleşme aynı bakiye verilerini paylaşır).

Şu anda, piyasada belirlenen temel token adresinin TUSD'nin ana sözleşme adresi olduğunu varsayarak, süpürmeToken işlevini çağırırken gelen token parametresi olarak yardımcı giriş noktası sözleşme adresi 0x8dd5fbce'yi ve adres(token)'i kullanabiliriz. = temel olarak kontrol edilebilirse, sözleşme tüm temel varlık tokenlarını TUSD'yi yönetici adresine aktaracaktır.

TUSD/cTUSD döviz kuru, cTUSD sözleşmesindeki dayanak varlık tokeni TUSD'nin tutarından etkilenecektir. Tüm TUSD yöneticinin adresine aktarıldığında, TUSD/cTUSD döviz kuru anında düşecektir. Şu anda saldırgan, diğer kullanıcıları çok düşük bir döviz kuruyla tasfiye ederek veya borç aldıktan sonra beklenen token sayısından daha azını geri ödeyerek kâr elde edebilir.

Bileşik V2 kodunun en son sürümünün, sözleşmenin yalnızca yönetici rolü tarafından çağrılmasını sağlamak için süpürmeToken işlevine izin doğrulaması eklediğini ve birden fazla giriş noktası belirtecine sahip tüm pazarları kaldırdığını belirtmekte fayda var.

Denetim noktaları: Denetim sırasında, sözleşme kapsamında token aktarma işlevine ilişkin olarak, çoklu giriş noktası tokenleri senaryosunun proje üzerindeki etkisinin dikkate alınması gerekir. Proje tarafının çoklu giriş noktası kullanmaması önerilebilir. Token transferini önce ve sonra doğrulayın veya sözleşmedeki dayanak varlık token sayısının değişip değişmeyeceğini kontrol edin ve ilgili fonksiyonların izinlerini kontrol edin.

4.5 Sözleşme kodunun eski ve yeni sürümleri arasındaki uyumluluk sorunları

Compound Finance V2 çatal projesinde, bir çekirdek sözleşmenin kodu, Compound Finance V2 kodunun yeni bir sürümüyle çatallanırsa ancak onunla etkileşime giren başka bir sözleşme eski bir kod sürümünü kullanıyorsa uyumluluk cinsel sorunlar ortaya çıkabilir.

Örneğin, cToken'in eski sürümü tarafından kullanılan InterestRateModel sözleşmesindeki borçlanma faiz oranını elde eden getBorrowRate işlevinin dönüş değeri iki uint türü değerdir, ancak InterestRateModel işlevinin yeni sürümünde getBorrowRate işlevi yalnızca bir uint döndürür. değeri yazın.

Ancak Compound Finance V2 çatal projesinde Percent Finance, proje ekibi cToken sözleşme kodunun eski bir sürümünü kullanırken, InterestRateModel sözleşmesi yeni bir sürümü kullandı. Bu, cToken'deki accrueInterest işlevinin getBorrowRate işlevini çağırırken başarısız olmasına neden oldu. CollectInterest işlevi hem para çekme hem de borç verme işlemlerinde kullanılır, bu da sonuçta para çekme ve borç verme işlevlerinin normal şekilde ilerleyememesine neden olur ve sözleşmedeki fonlar tamamen kilitlenir.

Denetim noktaları: Denetim sırasında güncellenen koddaki sözleşme arayüzü, durum değişkenleri, fonksiyon imzaları ve olaylardaki değişikliklerin mevcut sistemin normal çalışmasını bozup bozmayacağına dikkat etmeniz, tüm sözleşme kodu sürümünün tutarlılığını sağlamanız gerekir. güncelleyin veya güncellendiğinden emin olun. Kod, kodun eski sürümleriyle uyumludur.

4.6 Çok zincirli kurulumun neden olduğu sabit kodlama sorunları

Compound Finance V2 kodunda, yıllık blok başına sabit, her yıl üretilen tahmini blok sayısını temsil eder. Değeri, faiz oranı modeli sözleşmesinde 2102400 olarak kodlanmıştır. Bunun nedeni, Ethereum'un ortalama blok üretim süresinin 15 saniye olmasıdır.

Ancak farklı zincirlerin blok süreleri mutlaka aynı değildir ve yıl boyunca üretilen yaklaşık blok sayısı da aynı olmayabilir. Bileşik çatal projesinin diğer zincirlere konuşlandırılması ancak sabit kodlanmış değerlerin farklı zincirlerin koşullarına göre değiştirilmemesi durumunda faiz oranının nihai hesaplaması beklentileri aşabilir. Bunun nedeni, BlockPerYear değerinin baseRatePerBlock ve multiplierPerBlock değerlerini etkileyeceği ve baseRatePerBlock ve multiplierPerBlock'un sonuçta borçlanma oranını etkileyeceğidir.

Örneğin, BSC zincirinin blok oluşturma süresi 3 saniyedir, bu durumda tüm yıl için tahmini blok sayısı (blok/Yıl) 10.512.000 olmalıdır. BlockPerYear'ın değeri dağıtımdan önce değiştirilmezse, hesaplanan nihai borçlanma oranı beklenenden beş kat daha yüksek olacaktır.

Denetim noktaları: Denetim sırasında proje sözleşmesindeki sabit kodlanmış sabitlerin veya değişkenlerin farklı zincirlerin özellikleri altında beklenmedik sonuçlara neden olup olmayacağına dikkat edilmelidir. Proje tarafının değerlerini doğru şekilde değiştirmesi önerilir. Farklı zincirlerin koşullarına göre.

diğer

Yukarıda belirtilen ana endişelere ek olarak, Bileşik V2'nin çatallanmış projeleri genellikle, harici üçüncü taraf protokolleriyle etkileşime geçmek için kod eklemek gibi, proje ekibinin tasarımına dayalı olarak iş mantığının bir kısmını değiştirir. Bunun, Compound Finance V2'nin temel kredilendirme modelini ve projelerini etkileyip etkilemeyeceği, özel iş mantığı ve tasarım gereksinimlerine dayalı olarak denetim sırasında değerlendirilmesi gerekir.

sonunda yaz

Compound Finance V2 ve Fork projesine yönelik bu güvenlik denetimi kılavuzunun, denetimler sırasında bu tür karmaşık sistemlerin güvenliğini herkesin daha iyi anlamasına ve değerlendirmesine yardımcı olabileceğini umuyoruz. Teknolojinin yinelenen güncellemesiyle bu kılavuz da güncellenecek ve geliştirilecektir.

[1] https://github.com/YAcademy-Residents/defi-fork-bugs

[1] https://github.com/YAcademy-Residents/defi-fork-bugs

[2] https://medium.com/chainsecurity/trueusd-compound-vulnerability-bc5b696d29e2

[3] https://github.com/code-423n4/2023-05-venus-findings/issues/559

[4] https://learnblockchain.cn/article/2593

[5] https://github.com/compound-finance/compound-protocol

Yazar |

Editör |