Uma Denetimi – Aşama 6

Giriş

UMA kullanıcıların Ethereum blok zincirinde güveni en aza indirilmiş finansal sözleşmelere girmelerine olanak tanıyan bir platformdur. Daha önce denetlemiştik merkezi olmayan kehanet, belirli bir mali sözleşme şablonu, bazı geçici çekme istekleri, Sürekli Çok Partili şablonu, daha uzun bir etkileşimde çeşitli artan çekme istekleri ve sigortalı köprü.

Bu denetimde yeni bir yönetim teklifi sözleşmesini, UMA ekosistemini birden fazla zincire genişletmeye yönelik bir mekanizmayı, zincir dışı spesifikasyona uygun olarak ERC721 token sahiplerine ödülleri dağıtmaya yönelik bir mekanizmayı ve WETH'i desteklemek için sigortalı köprüye yönelik bir güncellemeyi inceledik. İyimserlik zincirinde.

Denetlenen taahhüt 0c4cea3c3d5e48da6f8984b8ba3afdfea4ce47cc kapsamına aşağıdaki sözleşmeler girmektedir:

• oracle/implementation/Proposer.sol
• cross-chain-oracle/* (test ve Poligon sözleşmeleri hariç)
• financial-templates/optimistic-rewarder/* (test sözleşmeleri hariç)

Sağlamlık dosyalarında yapılan değişiklikleri de inceledik. Çekme İsteği 3611.

Tüm harici kod ve sözleşme bağımlılıklarının belgelendiği şekilde çalıştığı varsayılmıştır.

Sistem görünümü

Akım Governance Sözleşme, Risk Labs Foundation'ın UMA token sahipleri tarafından onaylanabilecek yeni yönetişim eylemleri önermesine olanak tanır. Yeni Proposer Sözleşme, teklif veren rolünü üstlenerek, teklifin başarısız olması durumunda feda edilecek bir teminat sağladığı sürece herkesin yeni tekliflerde bulunmasına olanak tanıyacak şekilde tasarlanmıştır. Teklif vermenin özel bir teşviki yoktur. Amaç, yalnızca kabul edilme olasılığı yüksek olan eylemlerin önerilmesini sağlamaktır.

Yeni zincirler arası mekanizma, yönetim teklifinin Ethereum ana ağından Optimism ve Arbitrum zincirlerine aktarılmasına olanak tanıyor. Bu şekilde, katman 1'deki UMA yönetişim mekanizması, desteklenen katman 2 zincirlerindeki UMA sözleşmelerini yönetmek için kullanılabilir. Mekanizma aynı zamanda fiyat taleplerinin ve çözümlerin katmanlar arasında iletilmesine de olanak tanır; böylece katman 2 zincirlerindeki Optimistic Oracle'lar, katman 1 Optimistic Oracle'ın DVM tarafından güvence altına alınmasıyla aynı şekilde ana ağ Veri Doğrulama Mekanizması tarafından güvence altına alınabilir.

Bu mesajların yerel köprü mekaniği kullanılarak gönderildiğini, yani ilgili katman 2 zincirlerinin özellikleriyle sınırlı olduklarını belirtmekte fayda var. Özellikle katman 2'den katman 1'e iletilerin köprüden geçmesi bir hafta veya daha uzun sürebilir. Dahası, UMA yönetişim mekanizması birden fazla sıralı işlem içeren teklifleri destekler, ancak bu yalnızca bunların köprüye eklenebileceği sırayı kısıtlar. Bu işlemlerden bazılarının katman 2'de farklı bir sırada yürütülmesi veya hiç yürütülmemesi mümkündür.

Optimistic Rewarder sözleşmesi, talep eden herkes için ERC721 tokenlarını basıyor. Ayrıca herkesin rastgele verileri herhangi bir token ile ilişkilendirmesine ve ödül olarak dağıtılmak üzere çeşitli ERC20 tokenlerini yatırmasına olanak tanır. Keyfi verilerin yorumlanması ve ödüllerin token sahipleri arasında beklenen dağılımı, belirtilmemiş bir zincir dışı prosedür kullanılarak belirlenir. Tahvil yatırmaya istekli olan herkes, belirli bir ERC721 tokeninin bir dizi ödüle borçlu olduğunu iddia edebilir. Standart Optimistic Oracle mekanizması, DVM tarafından çözülecek olan hak talebine başka birinin itiraz etmesine izin vermek için kullanılır. Zamanında itiraz edilmeyen taleplerin geçerli olduğu varsayılır ve sözleşme ödülleri buna göre dağıtır. Tek kısıtlama (muhasebeyi basitleştirmek için), oracle tahvil tokeninin bir ödül tokeni olarak kullanılamamasıdır.

Son olarak PR3611, desteklenmeyen Optimism token köprüsü üzerinden WETH gönderilmesini önlemek için sigortalı köprü mekanizmasını değiştirir. Bunun yerine, Optimism emanet kasasına yatırılan herhangi bir L2 WETH, köprüden geçmeden önce L2 ETH'ye paketlenir. 1. katmanda ETH, WETH köprü havuzuna iletilmeden önce WETH'ye dönüştürülür.

Kritik şiddet

[C01] Geçersiz ödüle itiraz edilemez

Bir ödül talebine itiraz ederken, OptimisticRewardBase önce sözleşme bir teklifi tetikler üzerinde SkinnyOptimisticOracle ve sonra bu öneriye itiraz ediyor. Ancak teklif son kullanma süresini ayarlar mevcut (anlaşmazlık) zamanından bir sapma olarak, anlaşmazlık ise son kullanma tarihini belirtir orijinal ödül talebi zamanından bir mahsup olarak. Çoğu durumda bu tutarsızlık, oracle'ın itiraz edilecek teklifi tanımlamasını engelleyecektir; bu, geçerli anlaşmazlıkların işleme alınmayacağı ve geçersiz ödül taleplerinin kabul edileceği anlamına gelir.

İtiraz edilecek teklifi doğru şekilde belirtmek için itiraz çağrısını güncellemeyi düşünün.

Güncelleme: Taahhütten itibaren düzeltildi 9e15557 in PR3690.

[C02] Teklifleri tekrar tekrar çözüme kavuşturma

The resolveProposal işlevi Proposer sözleşme basitçe doğrular kahinin çözdüğünü ancak tahvilin dağıtılıp dağıtılmadığını kontrol etmediğini. Bu, aynı teklifin birden çok kez çözülebileceği ve bunun da mükerrer tahvil ödemeleriyle sonuçlanabileceği anlamına gelir. Çözümlendiklerinde mevcut teklifleri işaretlemeyi veya silmeyi düşünün.

Güncelleme: Taahhütten itibaren düzeltildi b152718 in PR3689.

Yüksek şiddet

Yok.

Orta önem

[M01] Yanlış olay parametreleri

The OptimisticRewarderBase sözleşme bir şeyi tanımlar Requested olay hangisinden yayılır requestRedemption geri ödeme istendiğinde işlev görür. Bu olay şunu yaymak için tanımlanır: itfanın sona erme süresi son parametresi olarak. Fakat, olay yayınlandığında, son parametresi yanlış olarak ayarlanmış şimdiki zaman.

Benzer şekilde Redeemed olay kayıt silindikten sonra sona erme süresini okur, bu nedenle yanlışlıkla sıfıra ayarlanacaktır.

Bu olayın zincir dışı hesaplamaları tetiklemek için kullanılabileceği göz önüne alındığında, yayılan değeri uygun şekilde güncellemeyi düşünün.

Güncelleme: Taahhütten itibaren düzeltildi f04eef9 in PR3694.

Düşük önem derecesi

[L01] Bir ödemeye itiraz ettikten sonra etkinlik yayımının olmaması

The OptimisticRewarderBase sözleşme bir şeyi tanımlar Disputed olay bir geri ödemeye itiraz edilmesi durumunda tetiklenmesi amaçlanmaktadır. Ancak bu olay, içinde veya dışında yayılmaz. OptimisticRewarderBase sözleşme.

Etkinliği, hassas değişiklikler meydana geldikten sonra yayınlamayı düşünün. dispute işlev, sözleşmelerin faaliyetlerini takiben zincir dışı müşterilerin takibini kolaylaştırmak ve bilgilendirmek için.

Güncelleme: Taahhütten itibaren düzeltildi c275e92 in PR3695.

[L02] Tutarsız yeniden giriş koruması

The Optimism_ParentMessenger ve Arbitrum_ParentMessenger sözleşmeler tutarsız bir şekilde uygulanır nonReentrant değiştirici. Bunu tüm kamusal işlevlere dahil etmeyi düşünün.

Güncelleme: Taahhütten itibaren düzeltildi 6275c39 in PR3677.

[L03] Yanıltıcı yorumlar

İncelememiz sırasında tespit ettiğimiz bazı yanıltıcı yorumlar şunlardır:

• ChildMessengerConsumerInterface.sol:
  • Hat 5 “Çocuk elçisi” yerine “ebeveyn elçisi” diyor
• GovernorSpoke.sol:
  • 49-51 Satırları bir bağlantı Gnosis Yorumda pasajın kopyalandığı söylenmesine rağmen dosya Governor.sol. Ek olarak, snippet'teki ile aynı değil Governor.sol

Güncelleme: Taahhütten itibaren düzeltildi cc350f9 in PR3678.

[L04] Eksik yardımcı veri damgası

Fiyat talep ederken OracleSpoke sözleşme, sağlanan yardımcı veriler damgalanmış alt zincir tanımlayıcıyla. Ancak hasPrice ve getPrice işlevler, fiyat talebini tanımlarken yardımcı verileri damgalamaz. Bu, çağrı sözleşmelerini damgayı kendileri uygulamaya zorlar ve bu da fiyat talebi ile fiyat alma mekanizmaları arasında tutarsızlığa neden olur. Damgayı şuraya uygulamayı düşünün: hasPrice ve getPrice fonksiyonlar.

Güncelleme: Taahhütten itibaren düzeltildi fdb845d in PR3668.

[L05] NatSpec parametresi eksik

Birçok fonksiyon OptimisticRewarderBase sözleşme eksik @return Doğal Spesifikasyon yorumlarındaki parametre. Bütünlük için bunu eklemeyi düşünün.

Güncelleme: Taahhütten itibaren düzeltildi 8920f38 in PR3679.

[L06] Kalan ödenek

İyimser Kahin'i çağırmak için, OptimisticRewarderBase sözleşme ona bir jeton ödeneği veriyorBöylece tahvil ödemelerini çekebilir. Teklif başarısız olursa, ödül kullanımı iptal edildi ancak ödenek sıfırlanmaz. Bu nedenle, İyimser Kahin, bir dahaki sefere bir anlaşmazlık tetiklenene kadar gereksiz bir kalan ödeneği elinde tutacaktır. Teklif başarısız olursa ödeneği iptal etmeyi düşünün.

Güncelleme: Taahhütten itibaren düzeltildi c2d444b in PR3698.

[L07] Geçersiz geri ödeme adresi

İade L2 adresi Arbitrum_ParentMessenger başlatıldı L1 Valisi olması gereken sözleşme sahibine. Benzer şekilde, setRefundL2Address bir yorumu var bunun valiliğe bırakılması gerektiğini ifade etti. Ancak mesajları köprü üzerinden geçirirken bu değer L2 kullanıcısı olarak ayarlaBu, Arbitrum'da bilet çözümlendikten sonra fazla parayı alan adrestir. L1 guvernör adresine Arbitrum'da erişilemeyeceği için bu adrese gönderilen paralar kaybolacaktır.

Geçerli bir L2 adresine ayarlamayı düşünün.

Güncelleme: Taahhütten itibaren düzeltildi b3f2dd1 in PR3687.

[L08] Çocuk habercileri değiştirme mekanizması

The GovernorSpoke ve OracleSpoke sözleşmelerin her biri yapıcıdaki alt elçiyi güncelleyecek bir mekanizma olmaksızın başlatır. Bu şu anlama gelir: çocuk messenger değiştirildi, her iki jant teli sözleşmesi de geçerliliğini yitirir.

Sözlü sözleşme, büyük olasılıkla habercilerden daha kararlı olduğundan, konuşmacıyı konuşmacılara güncellemek için bir mekanizma eklemeyi düşünün.

Güncelleme: Taahhütten itibaren düzeltildi 7c9e061 in PR3688.

Notlar ve Ek Bilgiler

[N01] Tahvil jetonunu değiştir

The Proposer sözleşme içerir bir mekanizma malikin teklif bonosunun boyutunu değiştirmesi için. Tahvil tokenini de değiştirip değiştiremeyeceklerini düşünün. Bunun, mevcut teklifler çözüme kavuşturulduğunda doğru tahvil para birimini belirleyecek bir mekanizma gerektireceğini unutmayın.

Güncelleme: Problem değil. UMA'nın bu konuyla ilgili açıklaması:

N01, teklif sahibi sözleşmesinin tahvil tokenını UMA dışında bir şeye değiştirmesine izin verilmesini önerir. Bu işlev için $UMA dışında herhangi bir tokenı destekleme niyetimiz yok ve bu nedenle bu sorunla ilgili herhangi bir değişiklik yapmamayı seçtik. Üstelik sözleşme başına tek bir token bu mantığı olabildiğince basit tutuyor. Son olarak, eğer bir değişiklik gerekiyorsa (örneğin token geçişi durumunda), diğer token ile yeni bir teklif sahibi sözleşmesi dağıtabilir ve sistemi bunu kullanacak şekilde taşımak için bir teklif başlatabiliriz.

[N02] Eksik arayüz

The ChildMessengerInterface bir belirtmez processMessageFromCrossChainParent ebeveyn haberciler tarafından var olduğu varsayılmasına rağmen. Bütünlük için bunu eklemeyi düşünün.

Güncelleme: Sabit değil. UMA'nın bu konuyla ilgili açıklaması:

Polygon'un diğer zincirlerden gelen mesajları işleme yöntemi biraz özel mantık gerektirdiğinden, bunu ChildMessengerInterface içinde uygulamak Polygon_ChildMessenger ile uyumluluğu bozduğu için bu arayüzü tutarsız bırakmayı kasıtlı olarak seçtik; burada dahili bir yöntem _processMessageFromRoot olarak adlandırılır.

[N03] Yanlış arayüz

The GovernorSpoke yanlış sözleşme kullanır ChildMessengerConsumerInterface tip onu tarif etmek messenger değişken. kullanmayı düşünün ChildMessengerInterface yerine.

Güncelleme: Taahhütten itibaren düzeltildi f31a527 in PR3680.

[N04] Jetonları Depolamaya Çekin

İçinde önceki denetim amacını sorguladık Store kontrat payOracleFeesErc20 işlev (L19 sayısında). UMA ekibi işlevi korumayı seçti gelecekteki potansiyel değişiklikler için arayüzü standartlaştırmak. Fonksiyonun amacı tam olarak belirtilmediğinden, tetiklendiğinde tetiklenip tetiklenmeyeceği belli değildir. Proposer sözleşme bir tahvile el koyuyor. Muhtemelen şu durumlarda kullanılmalıdır: OracleHub fiyat talebi için ödeme yapar. Fonksiyonun her iki senaryoda da kullanılması gerekip gerekmediğini düşünün.

Güncelleme: Kabul edildi. UMA'nın bu konuyla ilgili açıklaması:

N04, Mağaza kullanımıyla tutarlı olması amacıyla hem Teklif Veren hem de OracleHub sözleşmelerindeki ücretlerin ödenmesi için Mağazanın payOracleFeeErc20 yönteminin kullanılmasını önerir. Ek bir arayüz (mağaza için) içe aktarma ve tahvil miktarının bir Sabit Noktaya aktarılmasını gerektirme anlamına geleceğinden (bu da ek bir içe aktarma gerektirir) bu işlevi kullanmamayı tercih ettik. Kodu basit ve temiz tutmak için Nisan 20'de denetim aşaması 1'de payOracleFeeErc2020 ile ilgili OZ'nin geri bildirimi, bu yöntemin gerçekten kullanışlı olmadığı yönündeydi ve bu tür bir entegrasyonun akıl yürütmesini zorlaştırıyordu.

[N05] Koddaki YAPILACAKLAR

Kod tabanında, projenin sorun biriktirme listesinde izlenmesi gereken "TODO" yorumları bulunmaktadır. Örneğin:

• çizgi 37 of Arbitrum_ParentMessenger sözleşme
• çizgi 25 of Optimism_ChildMessenger sözleşme
• çizgiler 83 ve 146 of OracleHub sözleşme.

Geliştirme sırasında "TODO" yorumlarının iyi tanımlanmış olması, bunların takip edilmesi ve çözülmesi sürecini kolaylaştıracaktır. Bu bilgi olmadan, bu yorumlar çürümeye yüz tutabilir ve sistemin güvenliği açısından önemli bilgiler, üretime sunulduğunda unutulabilir.

Bu TODO yorumlarında, yapılmayı bekleyen görevin kısa bir açıklaması ve proje havuzundaki ilgili soruna bir bağlantı bulunmalıdır.

Bu bilgiyi eklemek için TODO yorumlarını güncellemeyi düşünün. Tamlık ve izlenebilirlik için bir imza ve zaman damgası eklenebilir. Örneğin:

// TODO: point this at an interface instead.

// https://github.com/UMAprotocol/protocol/issues/XXXX

// --mrice32 - 20211209

Güncelleme: Taahhütten itibaren düzeltildi 5d57b5b in PR3684.

[N06] Yazım hataları

Kod tabanı aşağıdaki yazım hatalarını içeriyor:

• içinde Admin_ChildMessenger sözleşme impleenting olmalı implementing
• içinde OptimisticRewarderBase sözleşme timestap olmalı timestamp.
• içinde OptimisticRewarderBase sözleşme liveness liveness olmalı liveness.
• içinde GovernorSpoke sözleşme only called olmalı only be called.
• içinde Optimism_ChildMessenger sözleşme:

Güncelleme: Taahhütten itibaren düzeltildi 9b92b0b in PR3681.

[N07] Kullanılmayan içe aktarmalar

Kodun okunabilirliğini artırmak için aşağıdaki kullanılmayan içe aktarmaları kaldırmayı düşünün:

Güncelleme: Taahhütten itibaren düzeltildi 40b7221 in PR3682.

[N08] L2 işlem siparişi

The Governor olmasını sağlar Teklif dahilindeki işlemler sırasıyla gerçekleştirilir. Ancak bu işlemler zincirler arası işlemleri içerdiğinde, bu yalnızca L1 köprü sözleşmesine doğru sırayla varmalarını garanti eder. Arbitrum durumunda, L2'de sonuçlandırılmadan önce yeniden sıralanabilirler. Bu nedenle yönetim önerileri, L2 işlemlerinin yeniden sıralanması olasılığına izin verecek şekilde oluşturulmalıdır.

Güncelleme: Taahhütten itibaren düzeltildi 0fb2e7b in PR3703. GovernorHub artık bir dizi L2 işlemini aktarabilir.

Sonuç

Kod tabanında iki kritik sorun bulundu. Orta şiddette bir sorun ve birkaç küçük güvenlik açığı bulundu ve düzeltme önerileri önerildi.

Kaynak: https://blog.openzeppelin.com/uma-audit-phase-6/?utm_source=rss&utm_medium=rss&utm_campaign=uma-audit-phase-6