Vitalik'in son araştırması: Merkeziyetsizliği iyileştirmek ve konsensüs aşırı yüklenmesini azaltmak için LSDFi protokollerinin ve likiditenin nasıl değişmesi gerekiyor?

Vitalik Buterin tarafından yazıldı, bayemon.eth tarafından derlendi Kaynak: ChainCatcher

Geri bildirimleri ve incelemeleri için Mike Neuder, Justin Drake ve diğerlerine özel teşekkürler. Ayrıca bakınız: Mike Neuder, Dankrad Feist ve arixon.eth benzer konulardaki önceki makaleler.

Ethereum'un mevcut geliştirme durumunun çok sayıda iki katmanlı stake etmeyi içerdiği söylenebilir ve buradaki çift staking, iki tür katılımcıya sahip staking modelini ifade eder.

  1. Düğüm Operatörü: Düğümleri çalıştırır ve itibarı için teminat olarak kendi sermayesinin belirli bir miktarını yaşar
  2. Delege Eden: Temsilciler, minimum miktar olmaksızın ve teminat dışında nasıl katılacakları konusunda herhangi bir ek kısıtlama olmaksızın belirli bir miktarda Ethereum stake eder

Ortaya çıkan bu çifte staking, likidite staking tokenleri (LST) sağlamaya katılan çok sayıda staking havuzu aracılığıyla üretilir. (Hem Rocket Pool hem de Lido bu moddadır.)

Bununla birlikte, mevcut çifte staking'in iki dezavantajı vardır:

  1. Düğüm operatörlerinin merkezileşme riski: Tüm stake havuzlarındaki düğüm operatörlerinin seçim mekanizması hala aşırı merkezileştirilmiştir
  2. Gereksiz konsensüs yükü: Ethereum L1, EPOCH başına yaklaşık 800.000 imzayı doğrular, bu da tek bir yuva için çok büyük bir yüktür. Ek olarak, likidite staking havuzları daha fazla sermaye gerektirir ve ağın kendisi bu yükten tam olarak faydalanmaz. Bu nedenle, Ethereum ağı, her bir staker'ın zaman dilimine göre imzalamasını gerektirmeden makul bir ademi merkeziyetçilik ve güvenlik sağlayabilirse, topluluk böyle bir çözümü benimseyebilir ve böylece zaman dilimi başına imza sayısını etkili bir şekilde azaltabilir.

Bu makale, bu sorunların her ikisine de çözümleri açıklayacaktır, ilk olarak sermayenin çoğunun, stake düğümlerini kişisel olarak yönetmeye, her bir yuva hakkında bilgi imzalamaya, mevduatları kilitlemeye ve fonları mevcut haliyle yeniden dağıtmaya istekli olmayanların elinde olduğunu varsayarsak, o zaman bu insanlar bu durumda nasıl bir rol oynayabilir ve yine de ağın ademi merkeziyetçiliğine ve güvenliğine anlamlı katkılarda bulunabilir?

Mevcut çifte staking nasıl çalışır?

En popüler iki stake havuzu Lido ve RocketPool'dur ve Lido söz konusu olduğunda, ilgili iki taraf şunlardır:

  1. Düğüm operatörü: Lido DAO tarafından oylanır, yani bu aslında LDO sahipleri tarafından seçilir, birisi Lido akıllı sözleşme sistemine ETH yatırdığında, stETH oluşturulur ve düğüm operatörleri bunu stake havuzuna koyabilir (ancak para çekme sertifikası akıllı sözleşme adresine bağlı olduğundan, operatör istediği zaman para çekemez)
  2. Temsilci: Birisi Lido akıllı sözleşme sistemine ETH yatırdığında, stETH oluşturulur ve düğüm operatörü bunu bir stake olarak kullanabilir (ancak para çekme sertifikası akıllı sözleşme adresine bağlı olduğundan, operatör istediği zaman para çekemez)

Roket Havuzu için bunlar:

  1. Düğüm operatörü: Herkes 8 ETH ve belirli miktarda RPL token göndererek düğüm operatörü olabilir.
  2. Temsilci: Birisi Rocket Pool akıllı sözleşme sistemine ETH yatırdığında, düğüm operatörlerinin stake olarak kullanabileceği rETH üretilir (ayrıca para çekme sertifikası akıllı sözleşme adresine bağlı olduğundan, operatör istediği zaman para çekemez).

Ajans rolü

Bu sistemlerde (veya gelecekteki olası protokol değişikliklerinin etkinleştirdiği yeni sistemlerde) sorulması gereken önemli bir soru şudur: Protokol perspektifinden bir aracıya sahip olmanın amacı nedir?

Bu sorunun derin etkilerini anlamak için, önce gönderide bahsedilen protokol değişiklikleri için, yani azaltma cezasının 2ETH ile sınırlı olduğunu, Rocket Pool'un düğüm operatörlerinin stake miktarını da 2ETH'ye düşüreceğini ve Rocket Pool'un pazar payının %100'e yükseleceğini düşünelim (stake edenler ve ETH sahipleri için, rETH risksiz hale geldikçe neredeyse tüm ETH sahipleri rETH sahibi veya düğüm operatörü olacaktır).

rETH sahipleri için %3'lük bir getiri olduğunu varsayarsak (protokol içi ödüller ve öncelik ücretleri + MEV dahil), düğüm operatörleri %4'lük bir getiriye sahip olacaktır. Ayrıca toplam ETH arzının 100 milyon olduğunu varsayıyoruz.

Hesaplama sonucu aşağıdaki gibidir. Hesaplamayı daha da karmaşık hale getirmekten kaçınmak için, kazançları günlük olarak hesaplayacağız:

Şimdi, Rocket Pool'un mevcut olmadığını varsayarsak, staker başına minimum depozito 2 ETH'ye düşürüldü, toplam likidite 6,25 milyon ETH ile sınırlandırıldı ve düğüm operatörü getirisi %1'e düşürüldü. Tekrar hesaplayalım:

Her iki durumu da saldırının maliyeti açısından düşünün. İlk durumda, saldırgan bir ajan olarak kaydolmaz, çünkü ajanın esasen geri çekilme hakkı yoktur, bu yüzden hiçbir anlam ifade etmez. Bu nedenle, tüm ETH'lerini stake etmek ve düğüm operatörü olmak için kullanacaklar. Stake edilen toplam miktarın 1/3'üne ulaşmak için 2,08 milyon Ethereum yatırmaları gerekecek (ki bu adil olmak gerekirse hala oldukça büyük bir rakam). İkinci durumda, saldırganın yalnızca fon yatırması gerekir ve toplam stake havuzunun 1/3'üne ulaşmak için yine de 2,08 milyon Ethereum yatırım yapması gerekir.

Staking ekonomisi ve saldırı maliyeti açısından bakıldığında, her iki durumun da sonucu tamamen aynıdır. Düğüm operatörleri tarafından tutulan toplam ETH arzının payı günde %0,00256 arttı ve düğüm dışı operatörler tarafından tutulan toplam ETH arzının payı günde %0,00017 azaldı. Saldırı maliyeti 2,08 milyon ETH idi. Bu nedenle, bu modelde, ajanlar anlamsız bir Rube Goldberg makinesi gibi görünüyor, rasyonel topluluklar aracıyı kesmeye, stake ödüllerini büyük ölçüde azaltmaya ve stake edilen toplam ETH miktarını 6,25 milyon ile sınırlamaya bile meyillidir.

Elbette bu makale, toplam stake miktarını 6,25 milyon ile sınırlandırırken, stake ödülünün 4 kat azaltılmasını savunmuyor. Bunun yerine, bu makaledeki fikir, iyi işleyen bir stake sisteminin kilit bir özelliğe sahip olması gerektiği, yani aracıların sistem genelinde önemli bir sorumluluk alması gerektiğidir. Ayrıca, temsilcinin doğru eylemi gerçekleştirmesi için topluluk baskısı ve fedakarlık tarafından yoğun bir şekilde motive edilip edilmediği önemli değildir; Ne de olsa, bugün insanları merkezi olmayan, yüksek güvenlikli staking çözümlerini uygulamaya motive eden şey budur.

Temsilcinin sorumlulukları

Temsilciler staking sisteminde anlamlı bir rol oynayabiliyorsa, bu rol ne olabilir?

Bence iki tür cevap var:

  • Temsilci seçimi: Temsilciler, çıkarlarını hangi düğüm operatörlerine emanet edeceklerini seçebilirler. Konsensüs mekanizmasındaki düğüm operatörlerinin "ağırlığı", kendilerine emanet edilen toplam stake ile orantılıdır. Şu anda, temsilci seçim mekanizması hala sınırlıdır, yani rETH veya stETH sahipleri ETH'lerini çekebilir ve farklı bir havuza geçebilir, ancak proxy seçiminin gerçek kullanılabilirliği büyük ölçüde iyileştirilebilir.
  • Konsensüs mekanizması katılımı: Müdür, konsensüs mekanizmasında belirli bir rol oynamayı seçebilir, sorumluluk tam abonelikten "daha hafiftir" ve uzun bir çıkış süresi ve azalma riski olmayacaktır, ancak yine de düğüm operatörlerini dengeleme rolünü oynayabilir.

Gelişmiş proxy seçimi

Delegelerin yetki tercihlerini geliştirmenin üç yolu vardır:

  1. Havuzlardaki oylama araçlarını iyileştirin
  2. Havuzlar arasındaki rekabeti artırın
  3. Temsili düzeltin

Şu anda, bir havuzda oylama yapmak aslında pratik değil: Rocket Pool'da herkes düğüm operatörü olabilir ve Lido'da oylamaya ETH sahipleri değil, LDO sahipleri karar verir. Lido, LDO + stETH'nin ikili yönetişimi için bir teklif sundu ve burada yeni oyların ve dolayısıyla düğüm operatörlerinin eklenmesini veya kaldırılmasını önleyen bir koruma mekanizmasını etkinleştirebilecekler, bu da bir şekilde stETH sahiplerine söz hakkı veriyor. Yine de bu güç sınırlıdır ve daha güçlü olabilir.

Çapraz havuz rekabeti bugün zaten var, ancak nispeten zayıf. Buradaki temel zorluk, daha küçük staking havuzlarında token stake etmenin daha az likit olması, güvenilmesinin daha zor olması ve uygulamalar tarafından daha az desteklenmesidir.

Ceza miktarını 2 veya 4 ETH gibi daha küçük bir miktarla sınırlayarak ilk iki sorunu iyileştirebiliriz. Kalan ETH daha sonra güvenli bir şekilde yatırılabilir ve hemen çekilebilir, bu da iki yönlü borsaların daha küçük stake havuzları için geçerli kalmasına olanak tanır. LST'yi (ERC-4337 ve ERC-6900 tarafından cüzdanlar için kullanılan sözleşmeye benzer) yönetmek için bir ana ihraç sözleşmesi oluşturarak üçüncü sorunu iyileştirebiliriz, böylece bu sözleşme aracılığıyla verilen stake edilen tokenlerin güvenli olduğunu garanti edebiliriz.

Şu anda, anlaşmada somut bir temsil yok, ancak bu tür durumlar gelecek için muhtemel görünüyor. Yukarıdaki fikre benzer bir mantık içerecek, ancak protokol düzeyinde uygulanacaktır. Bir şeyleri sağlamlaştırmanın artıları ve eksileri için bu makaleye bakın.

Bu fikirler statükoya göre iyileştirmelerdir, ancak hepsi sınırlı faydalar sunar. Token oylama yönetişimi ile ilgili sorunlar vardır ve nihayetinde herhangi bir teşvik edici olmayan vekil seçimi sadece bir token oylama biçimidir; Bu her zaman yetkilendirilmiş hisse kanıtı ile ilgili ana şikayetim olmuştur. Bu nedenle, daha güçlü bir konsensüs katılımı sağlamanın yollarını düşünmek de değerlidir.

Konsensüs katılımı

Mevcut likidite stake etme sorunları dikkate alınmadan bile, mevcut bağımsız stake etme yönteminde sınırlamalar vardır. Tek yuvalı kesinlik varsayarsak, ideal olarak her yuva yaklaşık 100.000 ila 1.000.000 BLS imzasını işleyebilir. İmzaları toplamak için özyinelemeli SNARK'lar kullansak da, imza izlenebilirliği için her imzaya bir katılımcı bit alanı verilmesi gerekir. Ethereum küresel ölçekli bir ağ haline gelirse, bit alanlarının tamamen merkezi olmayan depolanması yeterli olmazdı: Slot başına 16 MB yalnızca yaklaşık 64 milyon staker'ı destekleyecektir.

Bu açıdan bakıldığında, staking'i slot başına etkili olacak ancak yalnızca 10.000 katılımcıya sahip olabilecek daha yüksek karmaşıklıktaki yok edilebilir katmanlara ve yalnızca ara sıra katılmaya çağrılan daha düşük karmaşıklıktaki katmanlara bölmenin değeri vardır. Daha düşük karmaşıklıktaki katmanlar kafa kesmeden tamamen muaf tutulabilir veya katılımcılara rastgele birkaç yuvaya para yatırma ve biriktirme için hedef haline gelme fırsatı verilebilir.

Aslında bu, hangi mevcut doğrulayıcıların daha yüksek veya daha düşük karmaşıklık katmanına girdiğini belirlemek için doğrulayıcı bakiye sınırını ve ardından bir bakiye eşiğini (örneğin, 2048 ETH) artırarak yapılabilir.

İşte bu mikro staking rollerinin nasıl çalıştığına dair bazı öneriler:

  1. Her slot için rastgele 10.000 küçük staker seçilecek ve slotu temsil ettiğine inandıkları şeyi imzalayabilecekler. LMD GHOST çatal seçim kuralını girdi olarak küçük bir staker ile çalıştırın. Microstaker tarafından yönlendirilen çatal seçimi ile düğüm operatörü tarafından yönlendirilen çatal seçimi arasında belirli bir farklılık varsa, kullanıcının istemcisi herhangi bir bloğu nihai onay olarak kabul etmeyecek ve bir hata gösterecektir. Bu, topluluğu durumu çözmek için adım atmaya zorlar.
  2. Temsilciler, ağa çevrimiçi olduklarını ve önümüzdeki bir saat içinde küçük staker olarak hareket etmeye istekli olduklarını bildiren işlemler gönderebilirler. Düğüm tarafından gönderilen mesaj (blok veya kanıt) hesaplanır ve hem düğümün hem de rastgele seçilen bir proxy'nin düğümün onayını imzalamasını gerektirir.
  3. Temsilciler, ağa çevrimiçi olduklarını ve önümüzdeki bir saat içinde küçük staker olarak hareket etmeye istekli olduklarını bildiren işlemler gönderebilirler. Her dönemde, 10 rastgele temsilci dahil listesi sağlayıcısı olarak seçilir ve 10.000 temsilci daha seçmen olarak seçilir. Bunlar k-slotundan önce seçilir ve çevrimiçi olduklarını onaylayan zincir içi mesajları yayınlamak için bir k-slot penceresi verilir. Tercih edilen her onaylanmış dahil etme listesi sağlayıcısı bir dahil etme listesi yayınlayabilir ve her bir dahil etme listesi için dahil etme listesindeki işlemleri içermedikçe veya genel olarak seçilen seçmenlerin oylarını içermedikçe, dahil etme listesinin mevcut olmadığını göstermedikçe blok geçersiz sayılacaktır.

Bu küçük stake düğümlerinin ortak noktası, tüm işi yapmak için her yuvaya, hatta hafif düğümlere aktif olarak katılmaları gerekmemesidir. Sonuç olarak, düğüm dağıtımları yalnızca, düğüm operatörlerinin çoğunlukla pasif olan ve çok az bilgi işlem yükü, donanım gereksinimleri veya teknik bilgi ve hatta ZK-EVM gibi gelişmiş teknolojiler gerektiren uygulamalar veya tarayıcı eklentileri aracılığıyla uygulayabilecekleri bir doğrulama konsensüs katmanı gerektirir.

Bu "küçük roller" aynı zamanda ortak bir hedefi paylaşıyor: çoğunluk düğüm operatörlerinin %51'inin işlemleri sansürlemesini önlemek. Birincisi ve ikincisi de çoğunluğun nihai indirime katılmasını engeller. Üçüncüsü daha doğrudan sansüre odaklanır, ancak çoğu düğüm operatörünün seçimine daha duyarlıdır.

Bu fikirler, protokolde bir çift staking çözümü uygulama perspektifinden yazılmıştır, ancak bir staking havuzunun bir işlevi olarak da uygulanabilirler. İşte bazı somut uygulama fikirleri:

  1. Protokol perspektifinden bakıldığında, her doğrulayıcı iki stake anahtarı belirleyebilir: sürekli bir stake anahtarı P ve çağrılabilen bağlı bir Ethereum adresi ve hızlı bir stake anahtarı Q çıktısı verebilir. Düğümün çatal seçimi için imza bilgileri takibi P ile temsil edilir ve imzalanan bilgiler Q ile temsil edilir, eğer PQ depolama sonuçları tutarsızsa, herhangi bir bloğun nihai tespiti kabul edilmez ve likidite havuzu temsilcileri rastgele seçmekten sorumludur.
  2. Protokol büyük ölçüde değişmeden kalabilir, ancak bu süre için kimlik doğrulayıcının açık anahtarı P+Q olarak ayarlanacaktır. Stoktan çıkarma için iki sınırlandırılabilir mesajın farklı Q anahtarlarına sahip olabileceğini, ancak aynı P tuşuna sahip olacaklarını unutmayın; Zayıf tasarımın bu durumla başa çıkması gerekiyor.
  3. Q Anahtarları, protokolde yalnızca bir bloktaki dahil etme listesini imzalamak ve doğrulamak için kullanılabilir. Bu durumda, Q tek bir anahtardan ziyade akıllı bir sözleşme olabilir, bu nedenle stake havuzu onu daha karmaşık oylama mantığı uygulamak, rastgele seçilen bir sağlayıcıdan bir dahil etme listesini veya dahil etme listesinin mevcut olmadığını gösteren yeterli oyu kabul etmek için kullanabilir.

Sonuç

Doğru uygulandığında, proof-of-stake tasarımında ince ayar yapmak iki sorunu bir çırpıda çözebilir:

  1. Bugün bağımsız proof-of-stake yapmak için kaynaklara veya yeteneğe sahip olmayanlara, onlara proof-of-stake'e katılma fırsatı vererek, böylece ellerinde daha fazla güç tutarak bir fırsat sağlar: (i) hangi düğümlerin destekleneceğini seçme gücü ve (ii) tam olarak çalışan proof-of-stake düğümlerinden daha hafif ama yine de anlamlı bir şekilde fikir birliğine aktif olarak katılmak. Tüm katılımcılar bu seçeneklerden birini veya her ikisini de seçmeyecektir, ancak seçeneklerden birini veya her ikisini de seçen herhangi bir katılımcı, statükoya göre önemli bir gelişme olacaktır.
  2. Ethereum konsensüs katmanının, tek yuvalı bir kesinlik rejimi altında bile her yuvada işlemesi gereken imza sayısını yaklaşık 10.000 gibi daha küçük bir sayıya düşürün. Bu aynı zamanda ademi merkeziyetçiliğe de yardımcı olacak ve herkesin doğrulayıcıları çalıştırmasını kolaylaştıracaktır.

Bu çözümler için, soruna yönelik çözümler farklı soyutlama seviyelerinde bulunabilir: proof-of-stake protokolü içinde kullanıcılara verilen izinler, proof-of-stake protokolleri arasında kullanıcı seçimi ve protokol içinde kurulum. Bu seçim dikkatlice düşünülmelidir ve istenen hedeflere ulaşmaya devam ederken, protokolün karmaşıklığını ve anlaşmanın ekonomisindeki değişiklik derecesini en aza indirmek için minimum uygulanabilir bir kuruluş seçmek genellikle en iyisidir.

Kaynak: Golden Finance

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.
  • Reward
  • Comment
  • Share
Comment
0/400
No comments
Trade Crypto Anywhere Anytime
qrCode
Scan to download Gate app
Community
  • 简体中文
  • English
  • Tiếng Việt
  • 繁體中文
  • Español
  • Русский
  • Français (Afrique)
  • Português (Portugal)
  • Bahasa Indonesia
  • 日本語
  • بالعربية
  • Українська
  • Português (Brasil)