Vitalik: Yerel düğümlere odaklanan bir ölçeklenme yol haritası optimizasyon önerisi

robot
Abstract generation in progress

Yazar: Vitalik, Ethereum'un kurucusu; Çeviri: Jinse Finansı xiaozhou

L1 Gas üst sınırını artırmaya yönelik en yaygın eleştirilerden biri, ağ güvenliği endişelerinin yanı sıra bunun tam düğüm çalıştırmayı daha zor hale getireceğidir. Özellikle "tam düğümün bağlanmaması" ile ilgili bir yol haritası bağlamında, bu sorunu çözmek için öncelikle tam düğümlerin varlık amacını anlamak gerekir.

Geleneksel kanı, zincir üstü verileri doğrulamak için tam düğümlerin kullanılmasıdır. Tek sorun buysa, ZK-EVM L1 ölçeklendirmesinin kilidini açar: tek sınırlama, rekabetçi bir pazar yaratırken blok oluşturma maliyetini ve kanıtı, 1 n sansür direncini koruyacak kadar düşük tutmaktır.

Ancak gerçekte bu tek düşünce değil. Başka bir önemli faktör ise: Tam düğüm çalıştırmak, yerel bir RPC sunucusuna sahip olmanızı sağlar, böylece zincir üzerindeki verileri güvene ihtiyaç duymadan, sansüre karşı dayanıklı ve gizliliği koruyarak okuyabilirsiniz. Bu makale, mevcut L1 genişletme yol haritasının nasıl ayarlanacağını tartışacaktır.

1, Neden ZK-EVM+PIR ile sağlanan güvenilmezlik ve gizlilikle yetinmiyorsunuz?

Geçen ay yayımladığım gizlilik yol haritası, kısa vadede TEE'ler + ORAM çözümünün benimsenmesini, uzun vadede ise PIR teknolojisine geçişi savunuyor. Helios ve ZK-EVM doğrulamasıyla birleştirildiğinde, kullanıcıların dış RPC'ye bağlandıklarında tamamen emin olmalarını sağlıyor: (i) elde edilen zincir verilerinin doğru olduğu, (ii) veri gizliliğinin korunduğu. Bu bir soruyu gündeme getiriyor: Neden burada duralım? Bu yüksek düzeydeki kriptografik çözümler, kendi kendine barındırılan düğümleri geçersiz mi kılıyor?

Buna dair birkaç yanıtım var:

--Tamamen güvenilmez kriptografik çözümler (örneğin, tek sunucu PIR) maliyetli. Mevcut masraflar gerçekçi olmayan bir seviyede yüksek, birçok verimlilik optimizasyonuna rağmen hala yüksek fiyatlar sürdürülebilir.

--Meta veri gizliliği sorunları. IP adresinin istek zamanı, istek modeli gibi meta veriler, kullanıcı bilgilerini büyük ölçüde açığa çıkarabilir.

--Zayıflıkları İnceleme: Az sayıda RPC sağlayıcısı tarafından domine edilen piyasa yapısı, güçlü kullanıcı yasakları veya sansür baskısı ile karşı karşıya kalacaktır. Birçok RPC sağlayıcısı, belirli ülkeleri tamamen engellemeye başlamıştır.

Bu nedenle, kişisel düğümlerin çalışma kolaylığını sağlamaya devam etmenin önemi devam etmektedir.

2、Kısa Vadeli Öncelikler

EIP-4444'ü öncelikli olarak kapsamlı bir şekilde uygulayın, her düğümün yalnızca yaklaşık 36 gün veri saklamasını nihayet gerçekleştirin. Bu, sabit disk alanı gereksinimlerini önemli ölçüde azaltacaktır - şu anda insanların düğüm çalıştırmasını engelleyen en büyük engel. Bundan sonra düğüm saklama gereksinimi yalnızca şunları içerecektir: (i) durum verisi, (ii) durum merkle dalı, (iii)36 günlük tarihî veriler.

Her düğümün az miktarda süresi dolmuş geçmiş veriyi depolaması için dağıtılmış bir geçmiş depolama çözümü oluşturun. Silme kodlama teknolojisi ile güvenilirliği en üst düzeye çıkarın. Bu, merkezi satıcılara güvenmeden veya düğüm operatörlerine ağır bir yük getirmeden "blok zinciri kalıcılığı" özelliğini sağlar.

Gas fiyatlandırma stratejisini ayarlayın, depolama maliyetlerini artırın, yürütme maliyetlerini düşürün. Aşağıdaki işlemlerin Gas maliyetini artırmaya odaklanın: (i) yeni depolama yuvası (storage slot) için SSTORE gerçekleştirmek, (ii) sözleşme kodu oluşturmak, (iii) sıfır bakiye/sıfır nonce hesabına ETH transferi yapmak.

3, Orta Vadeli Hedef: Durumsuz Doğrulama

Durum dışı doğrulama gerçekleştirildikten sonra, RPC'yi destekleyen düğümleri (yani durumu depolayan düğümler) durum merkle dalını saklamaya gerek kalmayacaktır. Bu, depolama gereksinimini yaklaşık %50 daha azaltabilir.

4, Yeni Düğüm: Kısmi Durumsuz Düğümler

Bu yenilikçi fikir, L1 Gas üst sınırının 10-100 kat artırılmasından sonra kişisel düğümlerin çalışmasını sürdürmenin anahtarı olacaktır.

Yeni bir düğüm türü ekledik: blokları durumsuz bir şekilde doğrulamak, tüm zinciri durumsuz doğrulama veya ZK-EVM yoluyla doğrulamak, ancak durum verilerinin yalnızca bir kısmını korumak. RPC isteği için gereken veriler durumun bu alt kümesinde olduğu sürece, düğüm yanıt verebilir; Diğer istekler başarısız olur (veya harici olarak barındırılan bir şifreleme çözümüne geri dönmesi gerekir - geri dönüş kullanıcı tarafından seçilmelidir).

qWmAn09ZE4jt0rEyydlCshCydJI7aVcg5fEeT5qk.png

Hangi durumların bakımının yapılacağı, kullanıcı yapılandırmasına bağlıdır, örneğin:

--Bilinen çöp sözleşmelerinin dışındaki tüm durumları hariç tut.

--Tüm EOA, SCW hesapları ve yaygın ERC20/ERC721 tokenleri ve uygulamalarıyla ilgili durum.

--Son iki yılda aktif EOA/SCW hesap durumu + bazı yaygın ERC20 token durumu + seçilmiş swap/DeFi/gizlilik uygulama durumu.

Yapılandırma, zincir üzerindeki sözleşmelerle yönetilebilir: Kullanıcı düğüm çalıştırırken "--save_state_by_config 0x12345...67890" parametresini kullanır, bu adres belirli bir dilde düğümün kaydetmesi ve gerçek zamanlı olarak güncellemesi gereken adres listelerini, depolama alanlarını (storage slot) veya durum filtreleme kurallarını tanımlar. Kullanıcının yalnızca orijinal değeri saklaması gerektiğini, Merkle dalını saklamasının gerekmediğini unutmayın.

Bu tür düğümler, hem kritik durumlara yerel doğrudan erişim avantajı sağlamakta hem de tam erişim gizliliği garanti etmektedir.

View Original
The content is for reference only, not a solicitation or offer. No investment, tax, or legal advice provided. See Disclaimer for more risks disclosure.
  • Reward
  • Comment
  • Share
Comment
0/400
No comments
  • Pin