Protocol DAO (pDAO)
Rocket Pool Protocol DAO (pDAO), protokolün yönünü şekillendirmekten sorumludur ve RPL yönetişimi tarafından yönetilir. Üyeleri ve oy güçleri, küçük büyük demeden protokolde doğrudan katılan node operatörlerinden oluşur. rETH sahipleri, Node Operatörleri ve RPL sahipleri dahil olmak üzere genel Rocket Pool topluluğuna hizmet eder. pDAO, Rocket Pool protokolünün güvenliğine ve Ethereum Ağının sağlığına öncelik verir. pDAO'nun kim ve ne olduğunun açık bir tanımı için pDAO charter'a göz atmaktan çekinmeyin.
Houston'daki yeni pDAO özellikleri
pDAO sorumluluklarının zincir üstünde yürütülmesi
Houston Yükseltmesi, pDAO yönetişim sisteminin yürütme sürecine zincir üstü bir alternatif sunar. Herhangi bir node operatörünün "pDAO protokol parametrelerini" ayarlamak ve hazine fonlarını harcamak için teklifler sunmasına ve tekliflere oy kullanmasına olanak tanıyan iyimser bir dolandırıcılık kanıtı sistemi kullanır. pDAO kontrolündeki parametrelerin kapsamlı bir listesini görmek için buraya tıklayın. Houston öncesinde, çekirdek ekip topluluk yönetişim sürecinin emriyle pDAO görevlerini yerine getirmekten sorumluydu. Örneğin, ekip yönetişim oylanan ödeme programlarına göre aylık IMC ve GMC ödemelerini gerçekleştirir. Plan, bu gücün geçici olarak ekipte kalması ve bu sorumlulukları devralacak yeni bir güç yapısı kurulana kadar devam etmesiydi. Houston bu ekibe olan bağımlılığı ortadan kaldırarak protokolü daha merkeziyetsiz ve güvensiz hale getirir.
Güvenlik Konseyi
Houston yükseltmesi ayrıca protokoldeki herhangi bir potansiyel sorun durumunda hızlı tepki vermeye yardımcı olmak için yeni bir güvenlik konseyi içerir. Bu üyeler pDAO tarafından seçilebilir ve gecikmeden değişiklik önerme ve yürütme yeteneğine sahiptir. pDAO, güvenlik konseyinden üyeleri seçme ve çıkarma gücüne sahiptir. Bu ciddi bir roldür ve pDAO, eski üyeleri temizlemek için güçlü giriş gereksinimleri ve süreçler geliştirmelidir. pDAO koruyucusu, Houston'ın başlangıcında güvenlik konseyinin tek üyesi olacaktır.
Yinelenen Hazine Harcamaları
RPL'nin %5 enflasyon oranı vardır. Bu enflasyonun %22'si RPIP-25'te tanımlandığı gibi pDAO'ya yönlendirilir. pDAO bu fonları çeşitli amaçlar için kullanabilir. Örneğin, likidite sağlayıcı (LP) bonusları gibi teşvikler, 3. taraf iyileştirmeler ve projeler için hibeler ve ödüller ve Rocket Pool protokolünün geliştirilmesinin finanse edilmesi. Houston yükseltmesi ayrıca her ödül döneminde belirli bir yararlanıcıya yapılan yinelenen hazine ödemelerini etkinleştiren yeni bir özellik sunar.
Protocol DAO (pDAO) teklifleri
Sıfır olmayan bir oy gücüne sahip herhangi bir node, herhangi bir zamanda bir pDAO teklifi sunabilir veya katılabilir. Teklifler aşağıdaki türlerden biri olabilir:
- pDAO ayarlarını değiştirme
- Tek seferlik hazine harcamaları
- Tekrarlayan hazine harcamaları (yönetim komiteleri)
- Güvenlik konseyi üyeliği
Daha fazla ayrıntı ve gerekçe için teklif türlerine bakın. Bir pDAO teklifinin, protokol düzeyinde değişiklikleri yürütmek için var olan zincir üstü bir varlık olduğunu anlamak önemlidir.
Bir pDAO teklifinin yaşam döngüsü
Bir teklif, zincir üstünde yer almadan önce yönetişim süreci tarafından öngörülmelidir. pDAO kontrolündeki parametreler olan 4 Dönemden oluşur:
- Vote Delay Period:
proposal.vote.delay.time - Vote Phase 1:
proposal.vote.phase1.time - Vote Phase 2:
proposal.vote.phase2.time - Execution:
proposal.execute.time
Vote Delay Period
Bir teklifin sonucuna karar verebilmek için protokol, gerekli çoğunluğu bilmelidir. Bir teklif sahibi bu değeri zincir dışında hesaplar ve teklifiyle birlikte gönderir. Değer iyimser olarak kabul edilir, ancak dolandırıcılık durumunda doğrulayıcılar değerin yanlış olduğunu kanıtlamak için bir meydan okuma/yanıt süreci gerçekleştirebilir. Geçersiz teklifler daha sonra atılır.
Teklif sahiplerinin ve meydan okuyanların RPL kilitlemesinin gerekli olmasının birkaç nedeni vardır.
proposal.bondgeçerli teklifleri teşvik eder ve spam'i caydırır.proposal.challenge.bondgeçersiz/kötü niyetli tekliflerin kaldırılmasını teşvik eder.
Meydan okuyanlar, yanlış olduğunu iddia ettikleri Merkle-toplam ağacına bir dizin sağlar. Herhangi bir node operatörü sahte tekliflere meydan okumaya katılabilir (ve bunu yaparken ödül kazanabilir). İlgileniyorsanız pDAO Meydan Okuma Süreci hakkında bilgi edinin. Oy gecikmesi döneminin sonunda bir meydan okumada yenilmeyen bir teklif, oylama aşamalarına girecektir.
proposal.vote.delay.time süresi dolduğunda, teklife artık meydan okunamaz veya yenilemez.
Vote Period 1
Bir oylama döneminde, Node Operatörleri ve Delegeler dört seçenekten biriyle oy kullanabilir:
Oy güçleri seçtikleri seçeneğe dahil edilecektir.
Bu aşağıdaki komut kullanılarak yapılabilir:
Veto çoğunluğu (proposal.veto.quorum parametresi tarafından tanımlandığı gibi) karşılanırsa, teklif hemen yenilir ve teklif sahibi bonusunu kaybeder. Bu, spam'i, düşük kaliteli teklifleri veya önce zincir dışı süreçlerden geçmemiş teklifleri caydırmak içindir. Smartnode komutu rocketpool pdao proposals finalize, veto edilen bir teklifi, teklif sahibinin kilitli RPL bonusunu yakarak sonlandırmak için kullanılır.
- dönemin süresi
proposal.vote.phase1.timeparametresi tarafından belirlenir. Teklif,proposal.quorum'a ulaşılıp ulaşılmadığına bakılmaksızın 2. aşamaya geçecektir.
Vote Period 2
Delegeler oy dönemi 2'de oy kullanabilir, ancak oyları yalnızca yerel oy güçleri kadar değerlidir. 1. dönemde oy kullanmayanlar, 2. dönemde hala oy kullanabilecektir. Delegelerinin seçimine katılmayan node operatörleri, delegelerinin oyunu geçersiz kılma fırsatına sahip olacaktır.
Bir oyu geçersiz kılma süreci oldukça basittir, oy dönemi 2'de rocketpool pdao proposals vote komutunu çağırın ve istemleri takip edin. Delegenin oy gücü, delege edenin oy gücü tarafından geçersiz kılınacaktır.
Bir teklifin sonucu, oy dönemi 2 bittiğinde sonuçlanır. Bir sonucun belirlenmesi (ve yürütülmesi) için, proposal.vote.phase2.time'ın sonuna kadar proposal.quorum toplam oy gücüne ulaşılması gerekir. Çoğunluk karşılanır ve uzlaşma sağlanırsa, teklif oylama dönemlerini geçecek ve başarılı olarak işaretlenecektir.
proposal.quorum'a ulaşılamazsa başka bir eylem gerçekleştirilemez. Çoğunluğa ulaşılamazsa bir teklif sonuçlanmış ve kesinleşmiş sayılır.
Execution
Her iki oylama dönemi de geçtikten ve teklif başarılı olduktan sonra, teklif yürütülebilir ve değişiklik (payload tarafından tanımlanan) Rocket Pool protokolüne uygulanır. Bir teklifi yürütmek için aşağıdaki komutu kullanın:
Yürütülecek bir teklif seçmeniz istenecek, bu adımdan sonra teklif protokole uygulanacak!
Teklif oylama dönemlerini geçtikten sonra, teklif sahibi meydan okuma tarafından yenilmedikçe veya veto edilmedikçe kilitli RPL bonusunu talep edebilir.
Bir teklifin yürütülebileceği bir proposal.execute.time penceresi vardır. Bu zamanlayıcı sonuna ulaşırsa bir teklif sona erer.
İşte bu kadar! Yukarıda bahsedilen tüm değişkenlerin pDAO kontrolündeki parametreler olduğunu unutmayın. pDAO'nun zincir üstü teklifler kullanarak değiştirme yetkisine sahip olduğu her parametrenin kapsamlı bir listesi için buraya tıklayın.
Meydan Okuma Süreci
Tam ağ oy gücü ağacı, gas sınırları nedeniyle zincir dışında depolanır. Bir kullanıcı yeni bir teklif gönderdiğinde, hedef blok numarasında ağ oylama ağacını oluşturmaktan sorumludur. Bu ağaç zincir dışında oluşturulur ancak zincir üzerinde gönderilen Merkle kökleri aracılığıyla doğrulanabilir. Protokol, teklif sahibi tarafından gönderilen ayrıntıları kontrol etmek için doğrulayıcılara güvenir.
Herhangi bir node, tekliflerin doğruluğunu izleme ve doğrulamaya katılabilir. Bu sorumluluğa katılmak için rocketpool service config komutunu kullanın, Smartnode and TX Fee Settings menüsüne gidin ve Enable PDAO Proposal Checker kutusunu işaretleyin.
Bu ayar etkinleştirildiğinde, node yeni teklifleri kontrol edecek, doğruluklarını doğrulayacak ve geçersiz tekliflere meydan okumaları gönderecektir. Tek ön koşul RPL Locking'in etkinleştirilmiş olmasıdır.
Bu kontrol, diğer birkaç node ile ilgili görevle birlikte her 5 dakikada bir çalışır. Sahte bir teklife meydan okumanın nasıl göründüğüne dair bir örnekten geçeceğiz. İlerlemeyi izlemek için smartnode komutu rocketpool service logs node kullanabiliriz:
Node'umuzun sahte bir teklifi yakaladığını ve meydan okuma sürecini başlattığını görebiliriz. Blok 1283202, teklif 177'nin sunulduğu bloktur, bu da bu teklif için oy gücünün blok 1283202'de hesaplanacağı anlamına gelir. Bu Voting Info Snapshots'un nasıl göründüğünü görmekle ilgileniyorsanız, bunları bu dizinde bulabilirsiniz: ~/.rocketpool/data/voting
Teklif sahibi yanlış oylama bilgisi gönderirken yakalandığı için, node'umuz teklif 177'de indeks 5'te Function: createChallenge sözleşme çağrısı yapar ve teklif sahibinin meydan okumaya yanıt vermesini bekler.
Teklif sahibinin oylama bilgisi yanlış olduğu için, zamanında meydan okumaya yanıt veremeyecektir (proposal.challenge.period tarafından belirlenir). Teklif bu noktada yenilmiş sayılır. Teklif yenildiğinde, node'umuz otomatik olarak teklifi sonlandırmak için teklif 177'de indeks 5'te defeatProposal sözleşme çağrısını yapar.
Teklifi yenmeye katılan meydan okuyanlar, yanlış olduğu kanıtlanan bir dizin gönderirlerse teklif sahibinin bonusunun orantılı bir miktarını alırlar. Diğer tüm meydan okuyanlar sadece bonuslarını geri alır.
Artık teklif yenildiğine göre, node'umuz (meydan okuyan) orijinal RPL bonuslarını ve sahte bir teklifi yenmek için ödül olarak teklif sahibinin RPL bonusunu talep edebilir.
pDAO teklif ve meydan okuma sisteminin ayrıntılarını incelemek isterseniz teknik spesifikasyonlara göz atın. Düşük seviye ayrıntılara giren bir örneği incelemekle ilgileniyorsanız meydan okuma süreci ile ilgili bu bölüme geçmekten çekinmeyin.