Yazan: Vitalik Buterin

Derleyen: Glendon, Techub Haberleri

Ethereum'un karşılaştığı zorluklardan biri, varsayılan olarak herhangi bir blockchain protokolünün şişkinliği ve karmaşıklığının zamanla artmasıdır. Bu iki yerde olur:

Ethereum'un uzun vadede sürdürülebilir olması için, her iki eğilime karşı da güçlü bir karşı baskıya ihtiyacımız var, bu da karmaşıklığı ve zaman içinde şişkinliği azaltıyor. Ancak aynı zamanda blockchaini oluşturan önemli özelliklerden birini de korumamız gerekiyor: kalıcılık. İşlem Çağrı Verileri'ne bir NFT, bir aşk mektubu veya zincire bir milyon dolar içeren akıllı bir sözleşme koyabilir, ardından on yıl boyunca bir mağaraya gidebilir ve dışarı çıkıp onun hâlâ orada okumanızı ve etkileşimde bulunmanızı beklediğini görebilirsiniz. DApp'lerin tamamen merkezi olmaması ve yükseltme anahtarlarını kaldırması için, bağımlılıklarının, özellikle de Katman 1'in kendisini bozacak şekilde yükseltilmeyeceğinden emin olmaları gerekir.

Tasfiye, 2023 Yol Haritası

Bu iki ihtiyacı dengelemek ve sürekliliği korurken şişkinliği, karmaşıklığı ve çürümeyi en aza indirmek veya tersine çevirmek, eğer aklımıza koyarsak tamamen mümkündür. Organizmalar bunu yapabilir: Çoğu organizma zamanla yaşlansa da, şanslı birkaçı yaşlanmıyor . Sosyal sistemlerin bile son derece uzun ömürleri olabilir . Bazı durumlarda Ethereum başarılı oldu: iş kanıtı gitti, SELFDESTRUCT işlem kodu esasen gitti ve işaret zinciri düğümleri altı aya kadar eski verileri depoluyor. Ethereum için bu yolu daha genel bir şekilde bulmak ve uzun vadeli istikrarlı bir sonuca doğru ilerlemek, Ethereum'un uzun vadeli ölçeklenebilirliği, teknik sürdürülebilirliği ve hatta güvenliği açısından en büyük zorluktur.

Tasfiye: Temel Hedefler

Hangi sorun çözüldü?

Hangi sorun çözüldü?

Bu yazının yazıldığı an itibariyle, tamamen senkronize edilmiş bir Ethereum düğümü, yürütme istemcisi için yaklaşık 1,1 TB disk alanına ve fikir birliği istemcisi için ek birkaç yüz GB disk alanına ihtiyaç duyuyor. Bunların büyük çoğunluğu tarihi kayıtlardır: çoğu yıllar öncesine ait olan tarihi bloklar, işlemler ve makbuzlarla ilgili veriler. Bu, gas limiti hiç artmasa bile düğüm boyutunun her yıl yüzlerce GB artacağı anlamına geliyor.

Nedir ve nasıl çalışır?

Geçmiş depolama sorununun temel basitleştirici özelliği, her bloğun bir karma bağlantısı (ve diğer yapılar ) yoluyla bir önceki bloğa işaret etmesi nedeniyle, şu anki fikir birliğinin geçmiş üzerinde fikir birliğine varmak için yeterli olmasıdır. Ağ, en son blok üzerinde fikir birliğine vardığı sürece, herhangi bir tarihsel blok veya işlem veya durum (hesap bakiyesi, tek seferlik kod, depolama), herhangi bir katılımcı tarafından, başka birinin doğruluğunu doğrulamasına olanak tanıyan bir Merkle kanıtı ile sağlanabilir. Her ne kadar fikir birliği bir N/2-of-N güven modeli olsa da, tarih bir 1-of-N güven modelidir .

Bu, geçmiş verileri nasıl sakladığımıza ilişkin birçok seçeneğin önünü açar. Doğal bir seçim, her düğümün verinin yalnızca küçük bir bölümünü depoladığı bir ağdır. Torrent ağı onlarca yıldır bu şekilde işliyor: Ağ toplamda milyonlarca dosyayı depolayıp dağıtırken, her katılımcı bunlardan yalnızca birkaçını depolayıp dağıtıyor. Belki de sezgilere aykırı bir şekilde, bu yaklaşım verileri mutlaka daha az sağlam hale getirmez. Düğümlerin çalışmasını daha ucuz hale getirerek, her düğümün geçmişin rastgele %10'unu depoladığı 100.000 düğümden oluşan bir ağ elde edebilirsek, o zaman her veri parçası 10.000 kez kopyalanacaktır; bu, 10.000 düğümden oluşan bir ağla aynıdır. Çoğaltma faktörü tamamen aynıdır ve her düğüm her şeyi saklar.

Günümüzde Ethereum, tüm düğümlerin tüm geçmişi kalıcı olarak sakladığı modelden uzaklaşmaya başladı. Konsensüs blokları (yani Proof of Stake konsensüs ile ilgili kısımlar) yalnızca yaklaşık 6 ay boyunca saklanır. Bloblar yalnızca yaklaşık 18 gün boyunca depolanır. EIP-4444, geçmiş bloklar ve makbuzlar için bir yıllık saklama süresi getirmeyi amaçlamaktadır. Uzun vadeli hedef, her düğümün her şeyi depolamaktan sorumlu olduğu koordineli bir süreye (muhtemelen ~ 18 gün) sahip olmak ve ardından eski verileri dağıtılmış bir şekilde depolamak için eşler arası bir Ethereum düğümleri ağı oluşturmaktır. (Techub News, Blob'un L2 genişletme çözümlerinin işlem maliyetlerini azaltmak için tasarlanmış bir veri depolama konsepti olduğunu belirtiyor.)

Çoğaltma faktörünü aynı tutarken sağlamlığı artırmak için silme kodları kullanılabilir. Aslında veri kullanılabilirliği örneklemesini desteklemek için bloblar zaten silme kodlamasını kullanıyor. En basit çözüm, bu silme kodlamasını yeniden kullanmak ve yürütme ve fikir birliği bloğu verilerini de bloblara koymak olabilir.

Mevcut araştırmalarla bağlantılar nelerdir?

Başka ne yapılması gerekiyor, ne gibi tavizler verilmesi gerekiyor?

Geriye kalan ana iş, geçmişi depolamak için somut bir dağıtılmış çözüm oluşturmayı ve entegre etmeyi içerir - en azından yürütme geçmişi, ancak sonuçta fikir birliği ve lekeler de. Bunun en basit çözümü (i) basitçe mevcut bir torrent kütüphanesini getirmek ve (ii) " Portal Ağı " adı verilen Ethereum'a özgü bir çözümü getirmektir. Bunlardan herhangi biri tanıtıldığında EIP-4444'ü etkinleştirebiliriz. EIP-4444'ün kendisi hard fork gerektirmez ancak yeni bir ağ protokolü sürümü gerektirir. Bu nedenle, bunu tüm istemciler için aynı anda etkinleştirmek değerlidir; aksi takdirde, tam geçmişi indirmeyi bekleyen ancak bunu gerçekte alamayan diğer düğümlere bağlanırken istemcilerin başarısız olma riski olacaktır.

Ana ödünleşme, "eski" tarihsel verileri nasıl kullanılabilir hale getirmeye çalıştığımızı içerir. En basit çözüm, yarın antik tarihi depolamayı bırakmak ve çoğaltma için mevcut arşiv düğümlerine ve çeşitli merkezi sağlayıcılara güvenmektir. Kolaydır ancak Ethereum'un kalıcı bir kayıt yeri olma statüsünü zayıflatır. Daha zor ama daha güvenli bir yaklaşım, öncelikle geçmişi dağıtılmış bir şekilde depolamak için bir torrent ağı oluşturmak ve entegre etmektir. Burada "çaba düzeyimiz"in iki boyutu var:

1. En büyük düğüm kümesinin aslında tüm verileri depolamasını nasıl sağlamaya çalışırız?

2. Geçmiş depolamayı protokole nasıl derinlemesine entegre edebiliriz?

(1) için, en paranoyak yaklaşımlardan biri emanet kanıtını kullanmaktır: her bir hisse kanıtı doğrulayıcısının geçmişin belirli bir yüzdesini saklamasını ve bunu yaptıklarını periyodik olarak kriptografik olarak kontrol etmesini etkili bir şekilde zorunlu kılmak. Daha mütevazı bir yaklaşım, her müşterinin depoladığı geçmişin yüzdesi için gönüllü bir standart belirlemek olacaktır.

(2) için, temel uygulama yalnızca bugün tamamlanan çalışmayı içerir: Portal, Ethereum'un tüm geçmişini içeren ERA dosyasını zaten saklar. Daha kapsamlı bir uygulama aslında bunu senkronizasyon sürecine bağlamayı gerektirir; böylece birisi tam geçmiş depolama düğümünü veya arşiv düğümünü senkronize etmek isterse, çevrimiçi olarak başka bir arşiv düğümü olmasa bile bunu doğrudan Portal ağından senkronize ederek yapabilir. çalıştırın.

Yol haritasının diğer bölümleriyle nasıl etkileşime giriyor?

Yol haritasının diğer bölümleriyle nasıl etkileşime giriyor?

Bir düğümü çalıştırmayı veya başlatmayı son derece kolaylaştırmak istiyorsak, geçmiş depolama gereksinimlerini azaltmak muhtemelen durumsuzluktan daha önemlidir: düğümün gerektirdiği 1,1 TB'nin ~300 GB'ı durum depolamasıdır ve geri kalan ~800 GB'ı Tarihseldir. depolamak. Akıllı saatlerde çalışan ve kurulumu yalnızca birkaç dakika süren Ethereum düğümleri vizyonu, ancak vatansızlık ve EIP-4444'ün her ikisinin de uygulanmasıyla gerçekleştirilebilir.

Geçmiş depolamanın sınırlandırılması, daha yeni Ethereum düğüm uygulamalarının protokolün yalnızca en son sürümünü desteklemesini de kolaylaştırarak onları daha basit hale getirir. Örneğin, 2016 DoS saldırısı sırasında oluşturulan boş depolama yuvalarının tümü kaldırıldığı için artık birçok kod satırı güvenli bir şekilde silinebiliyor. Artık Proof-of-Stake'e geçiş tarih olduğu için müşteriler, Proof-of-Stake ile ilgili tüm kodları güvenli bir şekilde kaldırabilirler.

Hangi sorunu çözüyor?

Müşterilerin geçmişi saklama ihtiyacını ortadan kaldırsak bile, durum büyümeye devam ettikçe müşteri depolama gereksinimleri yılda yaklaşık 50 GB artmaya devam edecektir: hesap bakiyeleri ve hesap bakiyeleri, sözleşme kodu ve sözleşme depolaması. Kullanıcılar tek seferlik bir ücret ödeyerek mevcut ve gelecekteki Ethereum müşterilerine sonsuza kadar yük oluşturabilirler.

Durumun "süresi sona ermek" tarihten daha zordur çünkü EVM'nin tasarımı temel olarak bir durum nesnesi oluşturulduktan sonra sonsuza kadar var olacağı ve herhangi bir zamanda herhangi bir işlem tarafından okunabileceği varsayımı üzerine inşa edilmiştir. Bazıları, durumsuzluğu uygulamaya koyarsak bu sorunun o kadar da kötü olmayabileceğini öne sürüyor: yalnızca özel bir blok oluşturucu sınıfının durumu gerçekten depolaması gerekirken, diğer tüm düğümler ( liste oluşturma dahil ) durumsuz olarak çalışabilir. Bununla birlikte, vatansızlığa çok fazla güvenmek istemediğimiz ve sonunda Ethereum'u merkezi olmayan tutmak için eyaletlerin süresinin dolmasına izin vermek isteyebileceğimiz konusunda ileri sürülmesi gereken bir argüman var.

Nedir ve nasıl çalışır?

Şimdi, yeni bir durum nesnesi oluşturduğunuzda (bu üç yoldan biriyle yapılabilir: (i) yeni hesaba ETH göndermek; (ii) kod kullanarak yeni hesap oluşturmak; (iii) daha önce dokunulmamış bir depolama yuvası ayarlamak ), durum nesnesi sonsuza kadar bu durumda kalacaktır. Bunun yerine nesnelerin zamanla otomatik olarak süresinin dolmasını istiyoruz. Bunu yapmak için temel zorluk aşağıdaki üç hedefe ulaşmaktır:

1. Verimlilik: Vade sonu sürecini yürütmek için çok fazla ek hesaplamaya gerek yoktur;

2. Kullanıcı dostu olma: "Birisi mağaraya girip beş yıl sonra geri dönerse" ETH, ERC20, NFT ve CDP pozisyonlarına erişimi kaybetmemelidir.

3. Geliştirici dostu: Geliştiricilerin tamamen alışılmadık bir zihinsel modele geçmesine gerek yok. Ayrıca, şu anda eski olan ve güncellenmeyen uygulamaların normal şekilde çalışmaya devam etmesi gerekir.

Bu hedeflere ulaşılmadan sorun kolayca çözülür. Örneğin, kullanıcı her bir durum nesnesinin aynı zamanda son kullanma tarihini temsil eden bir sayacı saklamasını sağlayabilir (son kullanma tarihi, okuma veya yazma sırasında otomatik olarak gerçekleşebilen ETH'nin yok edilmesiyle uzatılabilir) ve "durumu çaprazlayan" bir döngüye sahip olabilir. Süresi dolmuş durum nesnelerinin silinmesi işlemi. Ancak bu, ek hesaplama (ve hatta depolama gereksinimleri) getirir ve kesinlikle kullanıcı dostu olma gereksinimlerini karşılamaz. Geliştiricilerin, depolanan değerlerin bazen sıfıra sıfırlanmasını içeren uç durumlar hakkında mantık yürütmesi de zordur. Kullanıcılar sözleşme genelinde sona erme zamanlayıcıları ayarlarsa, bu teknik olarak geliştiricinin işini kolaylaştırır, ancak mali açıdan zorlaştırır: geliştiricilerin devam eden depolama maliyetlerini kullanıcılara nasıl "aktaracağını" düşünmesi gerekir.

Bunlar, " Blockchain Kiralama " ve " Yenilenme " gibi öneriler de dahil olmak üzere, Ethereum çekirdek geliştirme topluluğunun yıllardır boğuştuğu sorunlardır. Sonuçta bu önerilerin en iyi kısımlarını birleştirdik ve "en az bilinen çözümlerin" iki kategorisine odaklandık:

Kısmi durum sona eriyor

Kısmi durum sona eriyor

Kısmi durum süresi dolmuş tekliflerin tümü aynı ilkeleri izler. Devleti parçalara ayırıyoruz. Herkes, boş veya boş olmayan bloklardan oluşan bir "Üst Düzey Haritayı" kalıcı olarak saklar. Her bloktaki veriler yalnızca yakın zamanda erişildiğinde saklanır. Bir bloğun artık saklanmaması durumunda herkesin verinin kanıtını sağlayarak verileri kurtarabileceği bir "Diriliş" mekanizması vardır.

Bu öneriler arasındaki temel farklar şunlardır: (i) "son zamanları" nasıl tanımlayacağız ve (ii) "büyük yığın"ı nasıl tanımlayacağız? Spesifik bir öneri, Verkle ağaçları için tanıtılan "gövde ve yapraklar" tasarımına dayanan EIP-7736'dır (her ne kadar ikili ağaç gibi herhangi bir durum bilgisi olmayan ağaç biçimiyle uyumlu olsa da). Bu tasarımda birbirine bitişik olan başlıklar, kodlar ve yuvalar aynı "kök" altında depolanır. "Stem" altında saklanan maksimum veri miktarı "256 * 31 = 7936 bayt"tır. Çoğu durumda, bir hesabın tüm başlığı ve kodunun yanı sıra birçok anahtar depolama yuvası da aynı "kök" altında depolanacaktır. Belirli bir "taslak" altındaki veriler 6 ay içinde okunmamış veya yazılmamışsa, veriler artık saklanmaz, yalnızca verilere yönelik 32 baytlık bir taahhüt ("saplama") saklanır. Bu verilere erişen gelecekteki işlemlerde, verileri "yeniden canlandırması" ve "saplama"ya göre doğrulama kanıtı sunması gerekecektir.

Benzer fikirleri hayata geçirmenin başka yolları da var. Örneğin, hesap düzeyindeki ayrıntı düzeyi yeterli değilse, "ağacın" her "1/2^32" bölümünün benzer bir "gövde ve yaprak" mekanizması tarafından kontrol edildiği bir şema geliştirebiliriz.

Bu, teşvikler nedeniyle daha da yanıltıcı hale gelir: Bir saldırgan, büyük miktarda veriyi tek bir alt ağaca koyarak ve "ağacı güncellemek" için her yıl tek bir işlem göndererek istemcileri büyük miktarlarda durumu kalıcı olarak depolamaya zorlayabilir. Güncelleme maliyetini "ağaç" boyutuyla orantılı (veya güncelleme süresiyle ters orantılı) yaparsanız, birisi kendisiyle aynı alt ağaca çok fazla veri yerleştirerek diğer kullanıcılara zarar verebilir. Kullanıcı, alt ağaç boyutuna göre ayrıntı düzeyini dinamik hale getirerek her iki sorunu da sınırlamayı deneyebilir: örneğin, ardışık her "2^16" = 65536 durum nesnesi bir "grup" olarak değerlendirilebilir. Ancak bu fikirler daha karmaşıktır; kök tabanlı bir yaklaşım basittir ve teşviklerle uyumludur çünkü genellikle bir kök altındaki tüm veriler aynı uygulama veya kullanıcıyla ilgilidir.

Adres dönemine göre eyalet sona erme önerileri

Peki ya 32 baytlık "taslaklar" için bile kalıcı durum büyümesinden tamamen kaçınmak istiyorsak? Bu, Diriliş Çatışmaları nedeniyle zor bir sorundur: eğer bir durum nesnesi silinirse, daha sonraki bir EVM yürütmesi başka bir durum nesnesini tam olarak aynı konuma yerleştirir, ancak daha sonra orijinal durum nesnesini önemseyen biri geri gelir ve onu geri yüklemeye çalışır. bununla mı yapmalıyım? "Saplamalar", durumun bir kısmının süresi dolduğunda yeni verilerin oluşturulmasını engeller. Tam durumun sona ermesi durumunda, bir "taslak" bile saklayamayız.

Adres döngüsü tabanlı tasarım bu sorunu çözmenin en iyi yoludur. Tüm durumu depolamak için tek bir durum ağacı kullanmak yerine, giderek büyüyen bir durum ağaçları listesine sahibiz ve okunan veya yazılan herhangi bir durum, en son durum ağacına kaydedilir. Her dönem (örneğin 1 yıl) yeni bir boş durum ağacı eklenir. Daha yaşlı eyalet ağaçları sabit kalacaktır. Tam bir düğüm yalnızca en son iki durum ağacını saklamalıdır. Bir durum nesnesine iki döngü boyunca dokunulmadıysa ve bu nedenle süresi dolmuş durum ağacına düşerse, yine de okunabilir veya yazılabilir, ancak işlemin Merkle kanıtını kanıtlaması gerekir - kanıtlandıktan sonra kopya tekrar güncel tutulacaktır. durum ağacında.

Tüm bunları kullanıcı ve geliştirici dostu yapan temel fikir, adres döngüleri kavramıdır. Adres dönemi, adresin bir parçası olan sayıdır. Temel kural, N adres periyoduna sahip bir adresin yalnızca N periyodu sırasında veya sonrasında (yani durum ağacı listesi N uzunluğuna ulaştığında) okunabilmesi veya yazılabilmesidir. Kullanıcı yeni bir durum nesnesi (örneğin, yeni bir sözleşme veya yeni bir ERC20 bakiyesi) kaydetmek isterse, durum nesnesini N veya N-1 adres dönemine sahip bir sözleşmeye yerleştirdiğinizden emin olursanız, bunu kaydedebilirsiniz. hemen sağlamadan Kanıtlar daha önce hiçbir şeyin olmadığını kanıtlıyor. Öte yandan, eski adres döngüsündeki duruma yapılacak herhangi bir ekleme veya düzenleme kanıt gerektirir.

Bu tasarım, Ethereum'un mevcut özelliklerinin çoğunu çok az ek hesaplama ile korur ve uygulamaların neredeyse şu anda olduğu gibi yazılmasına olanak tanır (N adres periyoduna sahip adres bakiyelerinin, N alt adres periyoduna sahip adreslerde saklanmasını sağlamak için ERC20'nin yeniden yazılması gerekir) -sözleşme) ve "beş yıl boyunca mağaraya giren kullanıcılar" sorununu çözüyor. Ancak büyük bir sorunu var: Adres döngüsüne uyum sağlamak için adresin 20 baytın üzerine çıkarılması gerekiyor.

Adres alanı uzantısı

Tekliflerden biri, sürüm numarası, adres dönemi numarası ve genişletilmiş karma değeri içeren yeni bir 32 baytlık adres formatının tanıtılmasıdır.

Kırmızı sürüm numarasıdır. Dört turuncu sıfır, gelecekte parça sayılarını barındırabilecek boş alanı temsil eder. Yeşil, adres döngüsü numarasıdır. Mavi, 26 baytlık karma değeridir.

Buradaki en önemli zorluk geriye dönük uyumluluktur. Mevcut sözleşmeler 20 baytlık adresler etrafında tasarlanmıştır ve adreslerin tam olarak 20 bayt uzunluğunda olduğu açıkça varsayılarak sıklıkla katı bayt paketleme teknikleri kullanılır. Bu sorunu çözmeye yönelik bir fikir , yeni stil adreslerle etkileşime giren eski stil sözleşmelerin yeni stil adresin 20 baytlık karmasını göreceği bir Çeviri Haritası kullanmaktır. Ancak bunun güvenli olmasını sağlamada önemli karmaşıklıklar vardır.

Adres alanı daralması

Başka bir yaklaşım ise ters yönde ilerliyor: "2^128" boyutundaki bazı adres alt aralığını hemen devre dışı bırakıyoruz (örneğin, 0x ffffffff ile başlayan tüm adresler) ve ardından bu aralığı, adres dönemi ve 14 kelimeden oluşan bir adres eklemek için kullanıyoruz. bölümün karma değeri.

Başka bir yaklaşım ise ters yönde ilerliyor: "2^128" boyutundaki bazı adres alt aralığını hemen devre dışı bırakıyoruz (örneğin, 0x ffffffff ile başlayan tüm adresler) ve ardından bu aralığı, adres dönemi ve 14 kelimeden oluşan bir adres eklemek için kullanıyoruz. bölümün karma değeri.

Bu yaklaşımın ana fedakarlığı, karşı-olgusal adresler için güvenlik riskleri ortaya çıkarmasıdır: varlıklara veya izinlere sahip olan ancak kodu henüz zincirde yayınlanmamış adresler. Risk, birisinin (henüz yayınlanmamış) bir kod parçasına sahip olduğunu iddia eden bir adres oluşturması, ancak karma değeri aynı adresi işaret eden başka bir geçerli kod parçasının bulunmasıdır. Böyle bir çarpışmanın hesaplanması şu anda "2^80" karma değerini gerektiriyor; adres alanı daralması bu sayıyı kolayca erişilebilen "2^56" karma değerine düşürecektir.

Temel risk alanı, karşı olgusal adreslerdir, yani tek bir sahibin elinde olmayan cüzdanlardır; bu günümüzde nispeten nadir görülen bir durumdur, ancak çok dilli bir dünyaya geçtikçe muhtemelen daha yaygın hale gelecektir. Tek çözüm, bu riski basitçe kabul etmek, ancak sorunların ortaya çıkabileceği tüm yaygın kullanım durumlarını belirlemek ve etkili geçici çözümler bulmaktır.

Mevcut araştırmalarla bağlantılar nelerdir?

erken teklif

Ethereum durum büyüklüğü yönetimi teorisi

Vatansızlığa ve devletin sona ermesine giden birkaç olası yol

Kısmi Statü Sona Erme Teklifi: EIP-7736

Adres alanı uzantısı belgeleri:

Başka ne yapılması gerekiyor, ne gibi tavizler verilmesi gerekiyor?

Gelecek için dört olası yol olduğunu düşünüyorum:

1. Vatansızlığı uyguluyoruz ve hiçbir zaman devletin sona ermesini uygulamıyoruz. State büyüyor (yavaş da olsa: muhtemelen onlarca yıl boyunca 8 TB'yi aştığını görmeyeceğiz), ancak yalnızca nispeten uzmanlaşmış bir kullanıcı sınıfı tarafından tutulması gerekiyor: PoS doğrulayıcıları bile state'e ihtiyaç duymuyor.

Gelecek için dört olası yol olduğunu düşünüyorum:

1. Vatansızlığı uyguluyoruz ve asla devletin sona ermesini uygulamıyoruz. State büyüyor (yavaş da olsa: muhtemelen onlarca yıl boyunca 8 TB'yi aştığını görmeyeceğiz), ancak yalnızca nispeten uzmanlaşmış bir kullanıcı sınıfı tarafından tutulması gerekiyor: PoS doğrulayıcıları bile state'e ihtiyaç duymuyor.

Durumun bir kısmına erişim gerektiren özelliklerden biri dahil etme listesi oluşturmaktır, ancak bunu merkezi olmayan bir şekilde yapabiliriz: her kullanıcı, durum ağacının kendi hesabını içeren kısmının bakımından sorumludur. Bir işlemi yayınladıklarında, doğrulama adımı sırasında erişilen durum nesnesinin kanıtını yayınlarlar (bu, EOA ve ERC-4337 hesapları için geçerlidir). Vatansız bir doğrulayıcı daha sonra bu kanıtları tüm listeyi içeren bir kanıtta birleştirebilir.

2. Kısmi durum sona ermesini uyguluyoruz ve çok daha düşük ancak yine de sıfır olmayan kalıcı durum boyutu büyüme oranını kabul ediyoruz. Bu sonuç, eşler arası ağları içeren geçmişin sona ermesi önerilerine muhtemelen benzer - her istemcinin geçmiş verilerinin daha düşük ancak sabit bir yüzdesini depolaması gerektiğinden, kalıcı geçmiş depolama için çok daha düşük ancak yine de sıfır olmayan bir büyüme oranının nasıl kabul edileceği.

3. Durum süresinin dolması için adres alanı uzantısını kullanırız. Bu, mevcut uygulamalar da dahil olmak üzere, adres formatı dönüştürme yönteminin etkili ve güvenli olmasını sağlamak için çok yıllı bir süreci içerecektir.

4. Durum süresinin dolması için adres alanı daralmasını kullanırız. Bu, adres çakışmalarını (zincirler arası durumlar dahil) içeren tüm güvenlik risklerinin ele alınmasını sağlamak için çok yıllı bir süreci içerecektir.

Önemli olan nokta, adres formatı değişikliklerine dayanan bir durum sona erme şeması uygulansa da uygulanmasa da, adres alanının genişlemesi ve daralmasıyla ilgili zor sorunların eninde sonunda çözülmesi gerektiğidir. Şu anda, bir adres çakışması oluşturmak için yaklaşık "2 üssü 80" karma değer işlemleri gerekir. Son derece yeterli kaynaklara sahip katılımcılar için bu hesaplama yükü zaten mümkündür: GPU'lar yaklaşık "2 üssü 27" "karma işlemi gerçekleştirebilir. değer işlemi, yani bir yıllık çalışma "2 üssü 27" katını hesaplayabilir, böylece dünyadaki tüm GPU'lar yaklaşık "2 üssü 30" yaklaşık 1/4 yılda bir çarpışmayı hesaplayabilir, FPGA'ler ve ASIC'ler bu süreci daha da hızlandırabilir. Gelecekte bu tür saldırılar giderek daha fazla insana açık olacak. Bu nedenle, bu çok zorlu adres sorununu zaten çözmemiz gerektiğinden, tam durum süresinin dolmasının gerçek maliyeti göründüğü kadar yüksek olmayabilir.

Yol haritasının diğer bölümleriyle nasıl etkileşime giriyor?

Durumun sona ermesini zorunlu kılmak, herhangi bir dönüştürme işlemi gerekmediği için bir durum ağacı formatından diğerine dönüştürmeyi kolaylaştırabilir: yeni formatı kullanarak yeni bir durum ağacı oluşturmaya başlayabilir ve ardından eski ağacı dönüştürmek için hard Fork'u kullanabilirsiniz. Dolayısıyla, statünün sona ermesi karmaşık olsa da yol haritasının diğer yönlerini basitleştirmeye yardımcı olur.

Hangi sorun çözüldü?

Güvenlik, erişilebilirlik ve güvenilir tarafsızlık için temel ön koşullardan biri basitliktir. Protokol güzel ve basitse hata olasılığı azalır. Yeni geliştiricilerin katılma ve herhangi bir bölümünü kullanma şansını artırır. Özel çıkarlara karşı savunmanın adil ve daha kolay olması daha olasıdır. Ne yazık ki, herhangi bir sosyal sistem gibi protokoller de zamanla varsayılan olarak daha karmaşık hale gelir. Ethereum'un giderek karmaşıklaşan bir kara deliğe düşmesini istemiyorsak, iki şeyden birini yapmalıyız: (i) değişiklik yapmayı bırakıp protokolü katılaştırabilmek, (ii) özellikleri gerçekten kaldırabilmek ve karmaşıklığı azaltabilmek. Protokolde daha az değişiklik yapan ve zaman içinde en azından biraz karmaşıklığı ortadan kaldıran bir orta yol da mümkündür. Bu bölümde karmaşıklığın nasıl azaltılacağı veya ortadan kaldırılacağı anlatılmaktadır.

Nedir ve nasıl çalışır?

Protokol karmaşıklığını azaltabilecek tek bir büyük düzeltme yoktur; sorunun doğası gereği birçok küçük çözüm vardır.

Neredeyse tamamlanan bir örnek, SELFDESTRUCT işlem kodunun kaldırılmasıdır ve diğer örneklere nasıl yaklaşılacağı konusunda bir plan görevi görebilir. SELFDESTRUCT işlem kodu, tek bir blok içinde sınırsız sayıda depolama yuvasını değiştirebilen tek işlem kodudur ve istemcilerin DoS saldırılarından kaçınmak için daha yüksek karmaşıklık uygulamasını gerektirir. Bu işlem kodunun asıl amacı, durum boyutunun zaman içinde azaltılmasına olanak tanıyarak gönüllü durum temizliğini mümkün kılmaktı. Pratikte çok az kişi bunu kullanıyor. Dencun hard fork'unda bu işlem kodu, yalnızca aynı işlem içinde oluşturulan kendi kendini imha eden hesaplara izin verecek şekilde zayıflatıldı . Bu, DoS sorunlarını çözer ve istemci kodunun önemli ölçüde basitleştirilmesine olanak tanır. Gelecekte bu işlem kodunun tamamen kaldırılması mantıklı olabilir.

Şu ana kadar belirlenen protokol basitleştirme fırsatlarının bazı önemli örnekleri şunlardır: Birincisi, EVM dışındaki bazı örnekler; bunlar nispeten müdahaleci değildir ve bu nedenle fikir birliğine varılması ve daha kısa bir zaman diliminde uygulanması daha kolaydır.

İşte EVM'nin içinden bazı örnekler:

Mevcut araştırmalarla bağlantılar nelerdir?

Başka ne yapılması gerekiyor, ne gibi tavizler verilmesi gerekiyor?

Bu tür özellik basitleştirmeleri yapmadaki temel değiş-tokuş (i) basitleştirmelerimizin kapsamı ve hızı ile (ii) geriye dönük uyumluluktur. Ethereum'un bir zincir olarak değeri, kullanıcıların uygulamaları dağıtabileceği ve yıllar sonra da çalışacağından emin olabileceği bir platform olmasıdır. Aynı zamanda, William Jennings Bryan'ın sözleriyle "Ethereum'u geriye dönük uyumluluk sınırına çivileyerek" bu idealin çok ileri itilmiş olması da mümkün. Tüm Ethereum'da belirli bir özelliği kullanan yalnızca iki uygulama varsa ve bunlardan birinin yıllardır hiç kullanıcısı yoksa, neredeyse tamamen kullanılmıyorsa ve toplamda 57$ değer almışsa o zaman bu özelliği kaldırmalıyız, ödeme yapmalıyız Bunun için gerekirse mağdura cebinden 57 dolar ödendi.

Daha geniş sosyal sorun, acil olmayan geriye dönük uyumluluğu bozan değişiklikler yapmak için standartlaştırılmış bir süreç yaratmaktır. Bu sorunu çözmenin bir yolu, KENDİNİ YOK ETME süreci gibi mevcut örnekleri incelemek ve genişletmektir. Süreç şöyle görünüyor:

1. ve 4. adımlar arasında, hangi projelerin hangi aşamada olduğuna dair net talimatların yer aldığı, yıllar süren bir süreç olmalıdır. Bu noktada, "özellik kaldırma sürecinin gücü ve hızı" ile "daha muhafazakar olmak ve protokol geliştirmenin diğer alanlarına daha fazla kaynak yatırmak" arasında bir denge olması gerekiyor, ancak biz hala "Pareto"dan uzağız. sınır" Hala uzakta. (Techub Haber notu, Pareto cephesi, çok amaçlı optimizasyon problemlerindeki tüm Pareto optimal çözüm kümesini ifade eder)

EOF

EOF

EVM için önerilen önemli değişikliklerden biri EVM Nesne Formatıdır (EOF) . EOF, Gaz gözlemlenebilirliğini devre dışı bırakmak, kod gözlemlenebilirliğini devre dışı bırakmak (yani CODECOPY yok) ve yalnızca statik atlamalara izin vermek gibi bir dizi değişiklik sunar. Amaç, geriye dönük uyumluluğu korurken EVM'nin daha fazla yükseltilmesinin daha güçlü özelliklere sahip olmasını sağlamaktır (çünkü EOF öncesi EVM'ler hala mevcuttur).

Bunun yararı, yeni EVM özelliklerinin eklenmesi ve daha güçlü garantilerle daha katı bir EVM'ye geçişi teşvik etmek için doğal bir yol oluşturmasıdır. Dezavantajı ise, sonunda eski EVM'yi kullanımdan kaldırmanın ve kaldırmanın bir yolunu bulamazsak, protokolün karmaşıklığını önemli ölçüde arttırmasıdır. Önemli bir soru şudur: Özellikle amaç genel EVM karmaşıklığını azaltmaksa, EVM basitleştirme tekliflerinde EOF'nin rolü nedir?

Yol haritasının diğer bölümleriyle nasıl etkileşime giriyor?

Yol haritasının geri kalanındaki "iyileştirme" önerilerinin çoğu aynı zamanda eski özellikleri basitleştirme fırsatlarıdır. Yukarıdaki bazı örnekleri tekrarlamak gerekirse:

Tek slot kesinliğine geçmek bize komiteleri kaldırma, ekonomiyi yeniden düzenleme ve Hisse Kanıtı ile ilgili diğer basitleştirmeleri yapma fırsatı veriyor.

Hesap soyutlamayı tamamen uygulayarak, mevcut işlem işleme mantığının çoğunu kaldırabilir ve bunu, tüm EOA'ların yerini alabileceği bir "varsayılan hesap EVM kodu" parçasına taşıyabiliriz.

Tüm Ethereum veri yapılarının aynı şekilde karma hale getirilmesi için Ethereum durumunu ikili karma ağacına taşırsak, bu, SSZ'nin yeni sürümleriyle bağdaştırılabilir.

Daha radikal bir yaklaşım: protokolün çoğunu sözleşme koduna dönüştürün

Daha radikal bir Ethereum basitleştirme stratejisi, protokolü aynı tutmak ancak çoğunu protokol işlevselliğinden sözleşme koduna taşımak olacaktır.

En uç versiyon, Ethereum L1'i "teknik olarak" sadece işaret zinciri haline getirmek ve minimum bir VM ( RISC-V , Kahire veya kanıt sistemine adanmış daha basit bir VM gibi) sunarak diğerlerinin kendi Toplamalarını oluşturmalarına olanak tanımaktır. EVM daha sonra bu Toplamaların ilki olacak. İronik bir şekilde bu, 2019-20 yürütme ortamı teklifiyle tamamen aynı sonuçtur, ancak SNARK bunu gerçekten uygulamayı daha uygun hale getirir.

Daha mütevazı bir yaklaşım, işaret zinciri ile mevcut Ethereum yürütme ortamı arasındaki ilişkiyi değiştirmeden tutmak, ancak EVM'nin yerinde değişimini gerçekleştirmektir. Yeni "resmi Ethereum VM" olarak RISC-V, Kahire veya başka bir VM'yi seçebilir ve ardından tüm EVM sözleşmelerini, orijinal kodun mantığını yorumlayan yeni VM koduna (derleme veya yorumlama yoluyla) zorlayabiliriz. Teorik olarak bu, EOF'nin bir sürümü olarak "hedef VM" kullanılarak bile yapılabilir.