Ethereum protokolünün olası geleceği(alt): refah

Ethereum protokol tasarımında, Ethereum'un başarısı için birçok "detay" son derece önemlidir. Aslında, içeriğin yaklaşık yarısı farklı türdeki EVM iyileştirmeleri ile ilgilidir, geri kalanı ise çeşitli niş konulardan oluşmaktadır, işte bu "karmaşıklığın" anlamı budur.

Refah: Ana Hedefler

• EVM'yi yüksek performanslı ve stabil bir "nihai durum" haline getirmek
• Hesap soyutlamasını protokole dahil ederek, tüm kullanıcıların daha güvenli ve kullanıcı dostu bir hesap deneyimi yaşamasını sağlamak
• İşlem ücretleri ekonomisini optimize et, ölçeklenebilirliği artırırken riski azalt.
• Gelişmiş kriptografi keşfetmek, Ethereum'u uzun vadede önemli ölçüde iyileştirmek.

EVM geliştirmesi

Hangi sorunu çözdü?

Mevcut EVM, statik analiz yapmayı zorlaştırarak etkili uygulamalar oluşturmayı, resmi doğrulama kodu yapmayı ve daha fazla genişletmeyi zorlaştırıyor. Ayrıca, EVM'nin verimliliği düşüktür, birçok ileri düzey kriptografi biçimini gerçekleştirmek zordur, ancak önceden derlenmiş destek ile mümkündür.

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

Mevcut EVM iyileştirme yol haritasının ilk adımı, EVM nesne formatı (EOF)'in bir sonraki sert çatalla birlikte dahil edilmesidir. EOF, birçok benzersiz özelliğe sahip yeni bir EVM kod versiyonunu tanımlayan bir dizi EIP'dir; en dikkate değer özellikleri şunlardır:

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

Eski sözleşmeler var olmaya devam edecek ve oluşturulabilecek, ancak nihayetinde eski sözleşmelerin ( aşamalı olarak kullanımdan kaldırılması ve hatta EOF koduna ) zorla dönüştürülmesi muhtemeldir. Yeni sözleşmeler, EOF'un sağladığı verimlilik artışından faydalanacaktır - öncelikle alt program özellikleri sayesinde biraz küçülen bytecode ile, ardından ise EOF'a özgü yeni işlevler veya azalan gas maliyetleri ile.

EOF'un tanıtılmasından sonra, daha fazla yükseltme yapmak daha kolay hale geldi, şu anda en gelişmiş olanı EVM modül aritmetik genişletme ( EVM-MAX ). EVM-MAX, modül hesaplamalarına özel yeni bir işlem seti oluşturdu ve bunu diğer işlem kodlarıyla erişilemeyen yeni bir bellek alanına yerleştirdi, bu da Montgomery çarpımı gibi optimizasyonları kullanmayı mümkün kıldı.

Yeni bir fikir, EVM-MAX'ı tek komut çok veri ( SIMD ) özelliği ile birleştirmektir. SIMD, Ethereum'un bir kavramı olarak uzun zamandır mevcuttur, 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 performans odaklı genişlemenin doğal bir eşleşme olmasını sağlar.

Bir kombinasyon EIP'sinin genel tasarımı EIP-6690'ı başlangıç noktası olarak alacak, ardından:

• (i) herhangi bir tek sayı veya (ii) 2768'e kadar olan 2'nin herhangi bir kuvvetini modül olarak izin verir.
• Her EVM-MAX opcode ( toplama, çıkarma, çarpma ) için bir versiyon ekleyin, bu versiyon artık 3 anlık sayı x, y, z kullanmıyor, bunun yerine 7 anlık sayı kullanıyor: x_start, x_skip, y_start, y_skip, z_start, z_skip, count. Python kodunda, bu opcode'ların işlevi şu şekilde benzer:

for i in range(count): mem[z_start + z_skip * count] = op( mem[x_start + x_skip * count], mem[y_start + y_skip * count] )

Gerçek uygulamada, bu paralel bir şekilde işlenecektir.

• XOR, AND, OR, NOT ve SHIFT( ile döngüsel ve döngüsel olmayan ), en azından 2'nin kuvvet modülü için eklenebilir. Ayrıca ISZERO( eklenerek çıkış EVM ana yığınına) itilecektir, bu da eliptik eğri kriptografisi, küçük alan kriptografisi( gibi Poseidon, Circle STARKs), geleneksel hash fonksiyonları( gibi SHA256, KECCAK, BLAKE) ve ızgara tabanlı kriptografi için yeterince güçlü olacaktır. Diğer EVM yükseltmeleri de gerçekleştirilebilir, ancak bugüne kadar daha az ilgi görmüştür.

Kalan işler ve dengeler

Şu anda, EOF'un bir sonraki hard fork'ta dahil edilmesi planlanıyor. Her ne kadar son dakikada çıkarılması her zaman mümkün olsa da - önceki hard fork'larda işlevlerin geçici olarak çıkarıldığı olmuştur, ancak bunu yapmak büyük zorluklar getirecektir. EOF'un çıkarılması, EVM üzerindeki herhangi bir gelecekteki güncellemenin EOF olmadan gerçekleştirilmesi gerektiği anlamına gelir; bu mümkün olsa da, daha zor olabilir.

EVM'nin ana dengesi, L1 karmaşıklığı ile altyapı karmaşıklığıdır. EOF, EVM uygulamasına eklenmesi gereken büyük miktarda koddur ve statik kod kontrolü de görece 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. Denilebilir ki, Ethereum L1'in sürekli iyileştirilmesi için öncelik verilmesi gereken yol haritası, EOF üzerine inşa edilmeli ve onu içermelidir.

Yapılması gereken önemli bir iş, EVM-MAX gibi SIMD işlevselliğini gerçekleştirmek ve çeşitli kripto işlemlerinin gaz tüketimini karşılaştırmalı olarak test etmektir.

Harita ile diğer kısımlar nasıl etkileşimde bulunur?

L1, EVM'sini ayarlayarak L2'nin de gerekli ayarlamaları daha kolay yapmasını sağlıyor. Eğer ikisi senkronize bir şekilde ayarlama yapmazsa, uyumsuzluklar ortaya çıkabilir ve olumsuz etkiler doğurabilir. Ayrıca, EVM-MAX ve SIMD, birçok kanıt sisteminin gas maliyetlerini düşürebilir, böylece L2'yi daha verimli hale getirebilir. Aynı görevleri yerine getirebilen EVM kodları ile daha fazla önceden derlenmiş kodun değiştirilmesi de daha kolay hale gelir ve bu, verimliliği büyük ölçüde etkilemeyebilir.

Hesap soyutlama

Hangi sorunu çözdü?

Şu anda, işlemler yalnızca bir şekilde doğrulanabilir: ECDSA imzası. Başlangıçta, hesap soyutlama bunun ötesine geçmeyi hedefliyordu ve hesap doğrulama mantığının herhangi bir EVM kodu için geçerli olmasına izin veriyordu. Bu, bir dizi uygulamanın önünü açabilir:

• Kuantum direnci kriptografiye geçiş yap
• Eski anahtarların döndürülmesi ( yaygın olarak önerilen bir güvenlik uygulaması olarak kabul edilmektedir )
• Ç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 aracısız çalışmasına izin vererek karmaşıklığını önemli ölçüde azaltır ve kritik bir merkezi bağımlılık noktasını ortadan kaldırır.

2015 yılından beri hesap soyutlaması önerildiğinden beri, hedefleri birçok "kolaylık hedefini" de kapsayacak şekilde genişledi; örneğin, ETH'si olmayan ancak bazı ERC20'leri olan bir hesap, gas ödemek için ERC20 kullanabilir.

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

Hesap soyutlamasının temeli basittir: akıllı sözleşmelerin işlem başlatmasına izin vermek ve sadece EOA ile sınırlı kalmamaktır. Tüm karmaşıklık, bunu merkeziyetsiz bir ağa dost bir şekilde gerçekleştirirken ve hizmet reddi saldırılarına karşı koruma sağlarken ortaya çıkar.

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

Eğer 1000 hesabın doğrulama fonksiyonu belirli bir tekil S değerine bağlıysa ve mevcut S değeri bellek havuzundaki işlemlerin hepsinin geçerli olmasını sağlıyorsa, o zaman S değerini tersine çeviren tekil bir işlem bellek havuzundaki diğer tüm işlemleri geçersiz kılabilir. Bu, saldırganların bellek havuzuna çöp işlemleri göndermesini sağlayarak ağ düğümlerinin kaynaklarını tıkamasına olanak tanır.

Yıllarca süren çabaların sonucunda, işlevselliği genişletirken aynı zamanda ( DoS ) riskini sınırlamayı amaçlayan "ideal hesap soyutlaması"nı gerçekleştiren bir çözüm olan ERC-4337 elde edilmiştir.

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ı yalnızca kendi hesabını içeriyorsa ve çevresel değişkenleri okumuyorsa 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ı uygulanır.

ERC-4337, Ethereum istemci geliştiricilerinin o sırada Merge'ye odaklanması nedeniyle, ek bir protokol standardı olarak tasarlandı, bu yüzden diğer işlevlerle ilgilenmek için ek bir enerji yoktu. Bu nedenle, ERC-4337, normal işlemler yerine kullanıcı işlemleri adı verilen bir nesne kullandı. Ancak, son zamanlarda bunların en azından bir kısmını protokole yazma ihtiyacını fark ettik.

İki ana sebep şunlardır:

1. EntryPoint'ın sözleşmenin doğal verimsizliği olarak: Her bir paket için yaklaşık 100.000 gas'lık sabit bir maliyet ve her bir kullanıcı işlemi için ek binlerce gas.
2. Ethereum özelliklerinin gerekliliğini sağlamak: Listeyi içeren garantinin hesap soyut kullanıcıya aktarılması gerektiği gibi oluşturulması.

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

• Ödeme aracısı ( Paymasters ): Bir hesabın başka bir hesabın masraflarını ödemesine izin veren bir işlevdir, bu da doğrulama aşamasının yalnızca gönderici hesabına erişim kuralını ihlal eder, bu nedenle ödeme aracı mekanizmasının güvenliğini sağlamak için özel işlemler getirilmiştir.
• Agregatör(Agregatör): 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.

(# Kalan işler ve değerlendirmeler

Şu anda ana ihtiyaç, hesap soyutlamasını tamamen protokole entegre etmektir. Son zamanlarda popüler olan yazma protokolü hesap soyutlama EIP'si EIP-7701'dir. Bu öneri, EOF'un üzerinde hesap soyutlamasını gerçekleştirir. Bir hesabın doğrulama için ayrı bir kod parçasına sahip olabilmesi mümkündür; eğer hesap bu kod parçasını ayarlamışsa, bu kod parçası o hesaptan gelen işlemlerin doğrulama aşamasında çalıştırılacaktır.

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

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

Eğer doğrulama süresince yürütülebilir kod karmaşıklığına katı sınırlar koymaya başlarsak - dış duruma erişim izni verilmez, hatta başlangıçta belirlenen gas sınırları, 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 süre gerektiren EVM kodu yürütmesi ile değiştirmektir.

Ancak, zamanla bu sınırları gevşetmemiz gerekiyor çünkü özel veri koruma uygulamalarının aracı olmadan çalışmasına izin vermek ve kuantum dirençli olmak çok önemlidir. Bunun için, doğrulama adımlarının son derece basit olmasını gerektirmeden, hizmet reddi )DoS( riskini daha esnek bir şekilde ele almanın yollarını bulmalıyız.

Ana denge, "daha az insanı memnun eden bir çözümü hızlı bir şekilde yazmak" ile "daha uzun süre beklemek, muhtemelen daha ideal bir çözüm elde etmek" arasında gibi görünüyor; ideal yöntem 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 yöntem ise, L2 üzerinde önce daha iddialı bir hesap soyutlama versiyonunu dağıtmaktır. Ancak bununla karşılaşan zorluk, L2 ekiplerinin benimseme önerisinin uygulanmasına istekli olmaları için güven duymaları gerektiğidir, özellikle de L1 ve/veya diğer L2'lerin gelecekte uyumlu bir çözüm benimsemesini sağlamaları gerektiğinde.

Ayrıca net bir şekilde dikkate almamız gereken bir diğer uygulama, L1 veya özel L2 üzerinde hesapla ilgili durumu depolayan anahtar depolama hesaplarıdır, ancak L1 ve herhangi bir uyumlu L2 üzerinde kullanılabilir. Bunu etkili bir şekilde yapmak, L2'nin L1SLOAD veya REMOTESTATICCALL gibi işlem kodlarını desteklemesini gerektirebilir, ancak bu aynı zamanda L2 üzerindeki hesap soyutlaması uygulamasının bu işlemleri desteklemesini de gerektirir.

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

Hâlâ liste, hesap soyutlama işlemlerini desteklemelidir; pratikte, hâlâ listenin gereksinimi ile merkeziyetsiz bellek havuzunun gereksinimi aslında çok benzer, buna rağmen