L1 Gas üst sınırını artırma konusunda en yaygın eleştirilerden biri, ağ güvenliği endişelerinin yanı sıra, bunun tam düğüm çalıştırmayı daha da zorlaştıracağıdır. Özellikle "tam düğümlerin ayrılması" üzerine kurulu bir yol haritası bağlamında, bu sorunu çözmek için öncelikle tam düğümlerin varlık amacını anlamak gerekmektedir.
Geleneksel görüş, tam düğümlerin zincir üzerindeki verileri doğrulamak için kullanıldığıdır. Eğer bu tek sorun ise, o zaman ZK-EVM L1 genişlemesini açığa çıkarabilir: tek kısıtlama, blok oluşturma ve kanıtlama maliyetlerini yeterince düşük tutmaktır, böylece her ikisi de 1 of n sansüre karşı dayanıklılığını sürdürebilir ve rekabetçi bir piyasa oluşturabilir.
Ancak gerçekte bu tek ölçüt değildir. Diğer önemli bir 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şı koruyarak ve gizliliği koruyarak okuyabilirsiniz. Bu makalede, mevcut L1 genişletme yol haritasını bu hedefe ulaşacak şekilde nasıl ayarlayacağımızı tartışacağız.
Neden ZK-EVM+PIR ile sağlanan güvenilmezlik ve gizlilikle yetinmiyorsunuz?
Geçen ay yayınladığım gizlilik yol haritası şunu savunuyor: kısa vadede TEEs+ORAM çözümünü benimsemek, uzun vadede ise PIR teknolojisine geçiş yapmak. Helios ve ZK-EVM doğrulaması ile birleştiğinde, kullanıcılar dış RPC'ye bağlanırken tamamen emin olabilirler: (i) elde edilen zincir verileri doğrudur, (ii) veri gizliliği korunmaktadır. Bu, bir soruyu gündeme getiriyor: neden burada duralım? Bu yüksek düzeydeki kriptografi çözümleri, kendi kendine barındırılan düğümleri çağdışı hale mi getirdi?
Buna birkaç yanıtım var:
Tamamen güvensiz kriptografik çözümler (örneğin, tek sunucu PIR) yüksek maliyetlidir. Mevcut harcamalar, birden fazla verimlilik optimizasyonuna rağmen hâlâ yüksek fiyatlarda kalabilir.
Meta verileri gizliliği sorunu. IP adresinin istek zamanı, istek modeli gibi meta veriler, büyük miktarda kullanıcı bilgisini açığa çıkarabilir.
Zayıflıkların gözden geçirilmesi: Azınlık RPC tedarikçileri tarafından domine edilen pazar yapısı, güçlü kullanıcı yasakları veya gözden geçirme baskısı ile karşılaşacak. Birçok RPC sağlayıcısı, belirli ülkeleri tamamen engellemeye başladı.
Bu nedenle, bireysel düğümlerin çalışma kolaylığını sağlamaya devam etmek hala değerlidir.
Kısa Vadeli Öncelikler
EIP-4444'ü öncelikle tamamen uygulamak, her bir düğümün yalnızca yaklaşık 36 gün verisi depolamasını sağlamayı amaçlamaktadır. Bu, disk alanı gereksinimlerini büyük ölçüde azaltacaktır - şu anda insanların düğüm çalıştırmasını engelleyen temel engel. Sonrasında düğüm depolama gereksinimleri yalnızca şunları içerecektir: (i) durum verisi, (ii) durum merkle dalı, (iii)36 günlük tarihsel veriler.
Dağıtık tarih saklama çözümleri inşa edin, böylece her düğüm az miktarda geçmiş veri saklar. Güvenilirliği en üst düzeye çıkarmak için silme ve kodlama teknolojisini kullanın. Böylece "blok zincirinin kalıcı saklama" özelliğini garantilemiş olursunuz ve merkezi tedarikçilere bağımlı kalmadan veya düğüm operatörlerine ağır bir yük getirmeden bunu yapabilirsiniz.
Gas fiyatlandırma stratejisini ayarlayın, depolama maliyetlerini artırın, yürütme maliyetlerini düşürün. Aşağıdaki işlemlerin Gas maliyetlerini artırmaya odaklanın: (i) yeni depolama slotu (storage slot) için SSTORE işlemi, (ii) sözleşme kodu oluşturma, (iii) sıfır bakiye / sıfır nonce hesabına ETH transferi.
Orta vadeli hedef: Durumsuz doğrulama
Durum bağımsız doğrulama sağlandıktan sonra, durum saklayan RPC destekli düğümleri (yani durum saklayan düğümler) durum merkle dallarını saklamak zorunda kalmayacaklar. Bu, depolama gereksinimlerini yaklaşık %50 daha azaltacaktır.
4, Yeni düğüm: Kısmi durum bilgisi olmayan düğümler
Bu yenilikçi fikir, L1 Gaz üst sınırının 10-100 kat artırılmasının ardından bireysel düğümlerin çalışmasını sağlamada anahtar olacak.
Yeni bir düğüm türü ekliyoruz: Durumsuz bir şekilde blokları doğrulamak, durumsuz doğrulama veya ZK-EVM ile tüm zinciri doğrulamak, ancak yalnızca kısmi durum verilerini korumak. RPC isteği için gerekli veriler bu durum alt kümesinde bulunduğu sürece, düğüm yanıt verebilir; diğer istekler başarısız olacak (veya harici olarak barındırılan kriptografik çözümüne geri dönmek gerekecek - geri dönme kararı kullanıcı tarafından seçilmelidir).
Hangi durumların bakımının yapılacağı, kullanıcı yapılandırmasına bağlıdır, örneğin:
Bilinen kötü sözleşmeler dışındaki tüm durumları hariç tut.
Tüm EOA, SCW hesapları ile yaygın ERC20/ERC721 tokenleri ve uygulamalarla ilgili durum.
Son iki yılda aktif EOA/SCW hesap durumu + bazı yaygın ERC20 token durumu + seçilmiş swap/DeFi/gizlilik uygulamaları durumu.
Ayarlar, zincir üzerindeki sözleşmeler aracılığıyla 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 kaydedilmesi ve gerçek zamanlı olarak güncellenmesi gereken adres listesini, depolama alanlarını (storage slot) veya durum filtreleme kurallarını tanımlar. Kullanıcının yalnızca orijinal değerleri saklaması gerektiğini, Merkel dalını saklamasına gerek olmadığını unutmayın.
Bu tür düğümler, hem kritik duruma yerel doğrudan erişim avantajı sağlamakta hem de tamamen erişim gizliliğini garanti etmektedir.
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.
Vitalik: Yerel düğümlere odaklanan bir ölçeklenme yol haritası optimizasyon önerisi
Yazı: Vitalik, Ethereum kurucusu
Derleme: Altın Finans xiaozhou
L1 Gas üst sınırını artırma konusunda en yaygın eleştirilerden biri, ağ güvenliği endişelerinin yanı sıra, bunun tam düğüm çalıştırmayı daha da zorlaştıracağıdır. Özellikle "tam düğümlerin ayrılması" üzerine kurulu bir yol haritası bağlamında, bu sorunu çözmek için öncelikle tam düğümlerin varlık amacını anlamak gerekmektedir.
Geleneksel görüş, tam düğümlerin zincir üzerindeki verileri doğrulamak için kullanıldığıdır. Eğer bu tek sorun ise, o zaman ZK-EVM L1 genişlemesini açığa çıkarabilir: tek kısıtlama, blok oluşturma ve kanıtlama maliyetlerini yeterince düşük tutmaktır, böylece her ikisi de 1 of n sansüre karşı dayanıklılığını sürdürebilir ve rekabetçi bir piyasa oluşturabilir.
Ancak gerçekte bu tek ölçüt değildir. Diğer önemli bir 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şı koruyarak ve gizliliği koruyarak okuyabilirsiniz. Bu makalede, mevcut L1 genişletme yol haritasını bu hedefe ulaşacak şekilde nasıl ayarlayacağımızı tartışacağız.
Geçen ay yayınladığım gizlilik yol haritası şunu savunuyor: kısa vadede TEEs+ORAM çözümünü benimsemek, uzun vadede ise PIR teknolojisine geçiş yapmak. Helios ve ZK-EVM doğrulaması ile birleştiğinde, kullanıcılar dış RPC'ye bağlanırken tamamen emin olabilirler: (i) elde edilen zincir verileri doğrudur, (ii) veri gizliliği korunmaktadır. Bu, bir soruyu gündeme getiriyor: neden burada duralım? Bu yüksek düzeydeki kriptografi çözümleri, kendi kendine barındırılan düğümleri çağdışı hale mi getirdi?
Buna birkaç yanıtım var:
Tamamen güvensiz kriptografik çözümler (örneğin, tek sunucu PIR) yüksek maliyetlidir. Mevcut harcamalar, birden fazla verimlilik optimizasyonuna rağmen hâlâ yüksek fiyatlarda kalabilir.
Meta verileri gizliliği sorunu. IP adresinin istek zamanı, istek modeli gibi meta veriler, büyük miktarda kullanıcı bilgisini açığa çıkarabilir.
Zayıflıkların gözden geçirilmesi: Azınlık RPC tedarikçileri tarafından domine edilen pazar yapısı, güçlü kullanıcı yasakları veya gözden geçirme baskısı ile karşılaşacak. Birçok RPC sağlayıcısı, belirli ülkeleri tamamen engellemeye başladı.
Bu nedenle, bireysel düğümlerin çalışma kolaylığını sağlamaya devam etmek hala değerlidir.
EIP-4444'ü öncelikle tamamen uygulamak, her bir düğümün yalnızca yaklaşık 36 gün verisi depolamasını sağlamayı amaçlamaktadır. Bu, disk alanı gereksinimlerini büyük ölçüde azaltacaktır - şu anda insanların düğüm çalıştırmasını engelleyen temel engel. Sonrasında düğüm depolama gereksinimleri yalnızca şunları içerecektir: (i) durum verisi, (ii) durum merkle dalı, (iii)36 günlük tarihsel veriler.
Dağıtık tarih saklama çözümleri inşa edin, böylece her düğüm az miktarda geçmiş veri saklar. Güvenilirliği en üst düzeye çıkarmak için silme ve kodlama teknolojisini kullanın. Böylece "blok zincirinin kalıcı saklama" özelliğini garantilemiş olursunuz ve merkezi tedarikçilere bağımlı kalmadan veya düğüm operatörlerine ağır bir yük getirmeden bunu yapabilirsiniz.
Gas fiyatlandırma stratejisini ayarlayın, depolama maliyetlerini artırın, yürütme maliyetlerini düşürün. Aşağıdaki işlemlerin Gas maliyetlerini artırmaya odaklanın: (i) yeni depolama slotu (storage slot) için SSTORE işlemi, (ii) sözleşme kodu oluşturma, (iii) sıfır bakiye / sıfır nonce hesabına ETH transferi.
Durum bağımsız doğrulama sağlandıktan sonra, durum saklayan RPC destekli düğümleri (yani durum saklayan düğümler) durum merkle dallarını saklamak zorunda kalmayacaklar. Bu, depolama gereksinimlerini yaklaşık %50 daha azaltacaktır.
4, Yeni düğüm: Kısmi durum bilgisi olmayan düğümler
Bu yenilikçi fikir, L1 Gaz üst sınırının 10-100 kat artırılmasının ardından bireysel düğümlerin çalışmasını sağlamada anahtar olacak.
Yeni bir düğüm türü ekliyoruz: Durumsuz bir şekilde blokları doğrulamak, durumsuz doğrulama veya ZK-EVM ile tüm zinciri doğrulamak, ancak yalnızca kısmi durum verilerini korumak. RPC isteği için gerekli veriler bu durum alt kümesinde bulunduğu sürece, düğüm yanıt verebilir; diğer istekler başarısız olacak (veya harici olarak barındırılan kriptografik çözümüne geri dönmek gerekecek - geri dönme kararı kullanıcı tarafından seçilmelidir).
Hangi durumların bakımının yapılacağı, kullanıcı yapılandırmasına bağlıdır, örneğin:
Bilinen kötü sözleşmeler dışındaki tüm durumları hariç tut.
Tüm EOA, SCW hesapları ile yaygın ERC20/ERC721 tokenleri ve uygulamalarla ilgili durum.
Son iki yılda aktif EOA/SCW hesap durumu + bazı yaygın ERC20 token durumu + seçilmiş swap/DeFi/gizlilik uygulamaları durumu.
Ayarlar, zincir üzerindeki sözleşmeler aracılığıyla 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 kaydedilmesi ve gerçek zamanlı olarak güncellenmesi gereken adres listesini, depolama alanlarını (storage slot) veya durum filtreleme kurallarını tanımlar. Kullanıcının yalnızca orijinal değerleri saklaması gerektiğini, Merkel dalını saklamasına gerek olmadığını unutmayın.
Bu tür düğümler, hem kritik duruma yerel doğrudan erişim avantajı sağlamakta hem de tamamen erişim gizliliğini garanti etmektedir.