Ethereum protokolünün gelecekteki olası gelişim yönleri: Refah Bölümü

Ethereum protokolünde başarısı için kritik öneme sahip birçok "detay" bulunmaktadır. Aslında, içeriğin yaklaşık yarısı farklı türdeki EVM iyileştirmeleriyle ilgilidir, geri kalan kısmı ise çeşitli niş konulardan oluşmaktadır, işte bu "refah"ın anlamı budur.

Refah: Ana Hedef

• EVM'yi yüksek performanslı ve stabil bir "son durum" haline getirmek
• Hesap soyutlamasını protokole dahil edin, tüm kullanıcıların daha güvenli ve kullanışlı bir hesap deneyimi yaşamasını sağlayın.
• İşlem ücretlerini optimize et, ölçeklenebilirliği artırırken riski azalt.
• İleri düzey kriptografi keşfederek Ethereum'un uzun vadede önemli ölçüde iyileşmesini sağlamak

EVM iyileştirmesi

Hangi sorunu çözdü?

Mevcut EVM'nin statik analizi yapmak zor, bu da verimli uygulamalar oluşturmayı, resmi olarak kod doğrulamasını ve daha fazla genişleme yapmayı zorlaştırıyor. Ayrıca, EVM'nin verimliliği düşüktür, birçok formda yüksek düzeyde kriptografi gerçekleştirmek zordur, ancak önceden derlenmiş desteği açıkça sağlanmadıkça.

O nedir, nasıl çalışır?

Mevcut EVM iyileştirme yol haritasının ilk adımı EVM nesne formatı ( EOF ), bir sonraki sert çatalla birlikte dahil edilmesi planlanıyor. EOF, birçok benzersiz özelliğe sahip yeni bir EVM kodu versiyonunu tanımlayan bir dizi EIP'dir, en dikkat çekici olanı:

• Kod ( çalıştırılabilir, ancak EVM'den ) ile veri ( arasında okuma yapılamaz, ancak ) arasında ayrım yapılabilir.
• Dinamik yönlendirmeler yasaktır, yalnızca statik yönlendirmelere izin verilir
• EVM kodu artık yakıtla ilgili bilgileri gözlemleyemiyor.
• Yeni bir açık alt rutin mekanizması eklendi

Eski sözleşmeler var olmaya ve oluşturulmaya devam edecek, ancak nihayetinde eski sözleşmelerin ( kademeli olarak terk edilmesi ve hatta EOF koduna ) zorla dönüştürülmesi mümkün olabilir. Yeni sözleşmeler, EOF'un getirdiği verimlilik artışlarından faydalanacak - öncelikle alt rutin özellikleri sayesinde biraz küçülmüş byte kodu, ardından ise EOF'a özgü yeni fonksiyonlar veya azaltılmış gaz maliyetleri.

EOF'un tanıtılmasından sonra, daha fazla yükseltme daha da kolaylaştı, şu anda en gelişmiş olanı EVM modül aritmetik genişlemesi ( EVM-MAX )'dir. EVM-MAX, modüler aritmetik için özel olarak tasarlanmış yeni bir dizi işlem oluşturdu ve bunları diğer işlem kodları ile erişilemeyen yeni bir bellek alanına yerleştirdi, bu da Montgomery çarpımı gibi optimizasyonların kullanılmasını mümkün kıldı.

Yeni bir fikir, EVM-MAX'ı tek komut çok veri ( SIMD ) özelliği ile birleştirmektir. SIMD, Ethereum'un bir konsepti olarak uzun zamandır mevcuttur ve ilk olarak Greg Colvin'in EIP-616'sında önerilmiştir. SIMD, hash fonksiyonları, 32 bit STARK'lar ve ızgara tabanlı kriptografi dahil olmak üzere birçok kriptografi biçimini hızlandırmak için kullanılabilir. EVM-MAX ve SIMD'nin birleşimi, bu iki performansa odaklı genişlemenin doğal bir eşleşmesini sağlar.

Mevcut araştırma bağlantısı

• EOF:
• EVM-MAX:
• SIMD:

Kalan işler ve denge

Şu anda, EOF'un bir sonraki sert çatalda dahil edilmesi planlanıyor. Her ne kadar son anda kaldırılması her zaman mümkün olsa da - önceki sert çatallarda işlevlerin geçici olarak kaldırıldığı olmuştur, ancak bunu yapmak büyük zorluklarla karşılaşacaktır. EOF'un kaldırılması, EVM'nin gelecekteki herhangi bir yükseltmesinin EOF olmadan gerçekleştirilmesi gerektiği anlamına gelir; bu mümkün olsa da, muhtemelen daha zor olacaktır.

EVM'nin ana dengesi L1 karmaşıklığı ile altyapı karmaşıklığıdır, EOF, EVM uygulamasına eklenmesi gereken büyük miktarda koddur, statik kod denetimi de nispeten karmaşıktır. Ancak, bunun karşılığında, yüksek seviyeli dilleri basitleştirebilir, EVM uygulamasını basitleştirebilir ve diğer faydalar elde edebiliriz. Denebilir ki, Ethereum L1'in sürekli iyileştirilmesine öncelik veren bir yol haritası EOF üzerine inşa edilmeli ve bunu içermelidir.

Yapılması gereken önemli bir iş, EVM-MAX ile SIMD benzeri işlevselliğin gerçekleştirilmesi ve çeşitli kripto işlemlerinin gaz tüketiminin karşılaştırmalı testinin yapılmasıdır.

Harita üzerindeki diğer kısımlarla nasıl etkileşim kurabilirim?

L1, EVM'sini L2'nin de buna göre daha kolay ayarlamalar yapabilmesi için düzenliyor. Eğer ikisi senkronize bir şekilde ayarlanmazsa, uyumsuzluklar ortaya çıkabilir ve olumsuz etkilere yol açabilir. Ayrıca, EVM-MAX ve SIMD, birçok kanıt sisteminin gas maliyetlerini düşürebilir, böylece L2'yi daha verimli hale getirir. Aynı görevleri yerine getirebilen EVM kodları ile daha fazla önceden derlenmiş kodun yerini almanın daha kolay hale gelmesini sağlar, bu da verimliliği büyük ölçüde etkilemeyebilir.

Hesap Abstraksiyonu

Hangi sorunu çözdü?

Şu anda, işlemler yalnızca bir şekilde doğrulanabilir: ECDSA imzası. Başlangıçta, hesap soyutlaması bunun ötesine geçmeyi amaçlıyordu ve hesap doğrulama mantığının herhangi bir EVM kodu tarafından gerçekleştirilmesine izin veriyordu. Bu, bir dizi uygulamayı etkinleştirebilir:

• Kuantum dayanıklı şifrelemeye geç
• Eski anahtarların döndürülmesi ( yaygın olarak önerilen bir güvenlik uygulaması olarak kabul edilir )
• Çoklu imza cüzdanı ve sosyal kurtarma cüzdanı
• Düşük değerli işlemler için bir anahtar kullanın, yüksek değerli işlemler için başka bir anahtar ( veya bir anahtar grubu ) kullanın.

Gizlilik protokolünün bir ara bağlantı olmadan çalışmasına izin vermek, karmaşıklığını önemli ölçüde azaltır ve kritik bir merkezi bağımlılığı ortadan kaldırır.

2015'te hesap soyutlaması önerildiğinden beri, hedefi birçok "kolaylık hedefi" içerecek şekilde genişledi; örneğin, ETH'si olmayan ancak bazı ERC20'lere sahip bir hesabın ERC20 ile gaz ödeyebilmesidir.

O nedir, nasıl çalışır?

Hesap soyutlamasının temeli basittir: akıllı sözleşmelerin işlem başlatmasına izin vermek, sadece EOA değil. Tüm karmaşıklık, bunu merkeziyetsiz bir ağı korumaya dost bir şekilde gerçekleştirmek ve hizmet reddi saldırılarına karşı korunmaktan kaynaklanmaktadır.

Tipik bir anahtar zorluk, çoklu arıza sorunudur:

Eğer 1000 hesap doğrulama fonksiyonu belirli bir tekil değere S bağlıysa ve mevcut S değeri, bellek havuzundaki tüm işlemlerin geçerli olmasını sağlıyorsa, S değerini tersine çeviren tek bir işlem, bellek havuzundaki diğer tüm işlemleri geçersiz kılabilir. Bu, saldırganların bellek havuzuna çöp işlemler göndererek ağ düğümlerinin kaynaklarını engellemesine olanak tanır.

Yıllarca süren çabaların ardından, işlevselliği genişletme ve ( DoS) riskini sınırlama amacıyla, "ideal hesap soyutlaması"nı gerçekleştiren çözüm: ERC-4337.

ERC-4337'nin çalışma prensibi, kullanıcı işlemlerinin işlenmesini iki aşamaya ayırmaktır: doğrulama ve yürütme. Tüm doğrulamalar önce işlenir, tüm yürütmeler ise daha sonra işlenir. Bellek havuzunda, yalnızca kullanıcı işleminin doğrulama aşaması kendi hesabını içerdiğinde ve çevresel değişkenleri okumadığında kabul edilir. Bu, çoklu başarısızlık saldırılarını önlemeye yardımcı olur. Ayrıca, doğrulama adımına da katı gaz sınırlamaları zorunlu olarak uygulanır.

ERC-4337, ek bir protokol standardı olarak tasarlanmıştır (ERC), çünkü o sırada Ethereum istemci geliştiricileri birleştirmeye (Merge) odaklanmışlardı ve diğer işlevleri ele almak için ek bir enerjiye sahip değildiler. Bu nedenle ERC-4337, olağan işlemler yerine kullanıcı işlemleri adında bir nesne kullanmaktadır. Ancak, son zamanlarda bunun en azından bir kısmını protokole yazma ihtiyacını fark ettik.

İki ana neden şunlardır:

1. EntryPoint'in sözleşmenin doğuştan düşük verimliliği: Her paket için yaklaşık 100,000 gaz sabit maliyeti ve her kullanıcı işlemi için ek birkaç bin gaz.
2. Ethereum özelliklerinin gerekliliğini sağlamak: Hesap soyut kullanıcıya aktarılması gereken içeren garanti ile oluşturulan içeren liste gibi.

Ayrıca, ERC-4337 iki işlevi daha genişletmiştir:

• Ödeme aracısı ( Paymasters ): Bir hesabın başka bir hesabın ücretlerini ödemesine izin veren bir işlevdir, bu da doğrulama aşamasının yalnızca gönderici hesabına erişim kurallarıyla çelişmektedir, bu nedenle ödeme aracısı mekanizmasının güvenliğini sağlamak için özel işlemler getirilmiştir.
• Agregatörler ( Agregatörler ): BLS agregasyonu veya SNARK tabanlı agregasyon gibi imza agregasyonu işlevlerini destekler. Bu, Rollup üzerinde en yüksek veri verimliliğini sağlamak için gereklidir.

Mevcut araştırma bağlantısı

• Hesap soyutlama tarihi hakkında konuşma:
• ERC-4337:
• EIP-7702:
• BLSWallet kodu (, toplama işlevini ) kullanıyor:
• EIP-7562( yazılı protokolün hesap soyutlama ):
• EIP-7701( EOF tabanlı yazım protokolü hesap soyutlama ):

Kalan işler ve dengeler

Şu anda ana ihtiyaç, hesap soyutlamasını protokole tamamen entegre etmektir. Son zamanlarda popüler olan yazım protokolü hesap soyutlaması EIP-7701'dir. Bu öneri, EOF'un üzerinde hesap soyutlamasını gerçekleştirir. Bir hesap, doğrulama için ayrı bir kod parçasına sahip olabilir; eğer hesap bu kod parçasını ayarlamışsa, bu kod, o hesap tarafından yapılan işlemlerin doğrulama adımında yürütülecektir.

Bu yöntemin büyüleyici yanı, yerel hesap soyutlamasının iki eşdeğer perspektifini net bir şekilde göstermesidir:

1. EIP-4337'yi protokolün bir parçası olarak
2. Yeni bir EOA türü, burada imza algoritması EVM kodu yürütmedir.

Eğer doğrulama süresince yürütülebilir kod karmaşıklığına sıkı sınırlar koymaya başlarsak - dış duruma erişime izin verilmez, hatta başlangıçta belirlenen gaz sınırlaması kuantum direnci veya gizlilik koruma uygulamaları için geçersiz olacak kadar düşükse - o zaman bu yaklaşımın güvenliği oldukça nettir: ECDSA doğrulamasını benzer zamanda EVM kodu yürütmeye ihtiyaç duyan bir şeyle değiştirmek.

Ancak, zamanla bu sınırları genişletmemiz gerekiyor, çünkü aracı olmadan gizlilik koruma uygulamalarının çalışmasına izin vermek ve kuantum direnci oldukça önemlidir. Bunun için, doğrulama adımlarının aşırı basit olması gerekmeksizin, hizmet reddi (DoS) riskini daha esnek bir şekilde çözmenin yollarını bulmalıyız.

Ana denge, "daha az kişiyi memnun eden bir çözümü hızlı bir şekilde yazmak" ile "daha uzun süre beklemek, belki daha ideal bir çözüm elde etmek" arasında görünüyor. İdeal yaklaşım, muhtemelen bir tür karma yöntemdir. Bir karma yöntem, bazı kullanım durumlarını daha hızlı yazmak ve diğer kullanım durumlarını keşfetmek için daha fazla zaman ayırmaktır. Diğer bir yaklaşım ise, L2 üzerinde daha iddialı bir hesap soyutlama versiyonunu öncelikle dağıtmaktır. Ancak bunun karşılaştığı zorluk, L2 ekibinin benimseme önerisinin uygulanmasına gönüllü olabilmesi için bu çalışmaya güven duyması gerektiğidir; özellikle L1 ve/veya diğer L2'lerin gelecekte uyumlu çözümleri benimsemesini sağlamak için.

Bir diğer uygulama ise anahtar depolama hesaplarıdır; bu hesaplar L1 veya özel L2 üzerinde hesapla ilgili durumu depolar, ancak L1 ve herhangi bir uyumlu L2 üzerinde kullanılabilir. Bunu etkili bir şekilde yapmak, L2'nin L1SLOAD veya REMOTESTATICCALL gibi opcode'ları desteklemesini gerektirebilir, ancak bu, L2 üzerindeki hesap soyutlama uygulamasının bu opcode'ları desteklemesini de gerektirir.

Diğer yol haritası bölümleriyle nasıl etkileşimde bulunur?

İçerik listeleri, hesap soyutlama işlemlerini desteklemelidir. Pratikte, içerik listelerinin ihtiyaçları, merkeziyetsiz bellek havuzlarının ihtiyaçlarıyla oldukça benzerlik göstermektedir, ancak içerik listeleri için esneklik biraz daha fazladır. Ayrıca, hesap soyutlama uygulaması L1 ve L2 arasında mümkün olduğunca koordinasyon sağlamalıdır. Gelecekte çoğu kullanıcının anahtar depolama Rollup'larını kullanmasını bekliyorsak, hesap soyutlama tasarımı buna dayanmalıdır.

EIP-1559 iyileştirmesi

Hangi sorunu çözüyor?

EIP-1559, 2021 yılında Ethereum üzerinde etkinleştirildi ve ortalama blok dahil etme süresini önemli ölçüde iyileştirdi.

Ancak, mevcut EIP-1559'un uygulanması birçok açıdan mükemmel değil:

1. Formül hafif bir eksikliğe sahip: Amaç %50'lik bloklar değil, yaklaşık %50-53'lük tam bloklardır, bu da varyansa bağlıdır ( bu matematikçilerin "aritmetik-geometrik ortalama eşitsizliği" olarak adlandırdığıyla ilgilidir.