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

Ethereum protokol tasarımında birçok "detay" başarısı için kritik öneme sahiptir. Aslında, içeriğin yaklaşık yarısı farklı türde EVM iyileştirmeleriyle ilgilidir, geri kalanı ise çeşitli niş konulardan oluşmaktadır, işte bu "refah" anlamına gelir.

Refah: Ana Hedef

• 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 pratik bir hesap deneyimi yaşamalarını sağlamak
• İşlem ücretleri ekonomisini optimize et, ölçeklenebilirliği artırırken riski azalt.
• Gelişmiş kriptografi keşfetmek, Ethereum'un uzun vadede önemli ölçüde iyileşmesini sağlamak

EVM iyileştirmesi

Hangi sorunu çözdü?

Şu anda EVM'nin statik analiz yapılması zor, bu da verimli uygulamalar oluşturmayı, resmi olarak kodu doğrulamayı ve daha fazla genişletmeyi zorlaştırıyor. Ayrıca, EVM'nin verimliliği düşüktür, birçok yüksek düzeyde kriptografi biçiminin gerçekleştirilmesi 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)'dir ve bunun bir sonraki sert çatallamada dahil edilmesi planlanmaktadır. EOF, birçok benzersiz özelliğe sahip yeni bir EVM kodu versiyonunu tanımlayan bir dizi EIP'dir, en belirgin olanı:

• ( numaralı kod yürütülebilir, ancak EVM'den ) ile veriler arasında ayrım yapılamaz, ( okunabilir, ancak yürütülemez.
• 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 sonunda eski sözleşmelerin )'in kademeli olarak terk edilmesi ve hatta EOF koduna ( zorunlu dönüşümü söz konusu olabilir. Yeni sözleşmeler, EOF'un getirdiği verimlilik artışından faydalanacak - öncelikle alt rutin özellikleri ile biraz küçültülen byte kodu, ardından ise EOF'ya özgü yeni işlevler veya azaltılmış gaz maliyetleri.

EOF'un tanıtılmasından sonra, sonraki yükseltmeler daha kolay hale geldi; şu anda en gelişmiş olanı EVM modülü aritmetik genişlemesi ) EVM-MAX (. EVM-MAX, modüler işlemlere özel yeni bir dizi işlem oluşturur ve bunları diğer işlem kodlarıyla erişilemeyen yeni bir bellek alanına yerleştirir, bu da Montgomery çarpımı gibi optimizasyonların kullanılmasını mümkün kılar.

![Vitalik'in Ethereum'un Olası Geleceği (Altı): The Splurge])https://img-cdn.gateio.im/webp-social/moments-8930b556d169a2bc7168ddc2e611d3df.webp(

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, birçok kriptografi biçimini hızlandırmak için kullanılabilir, bunlar arasında hash fonksiyonları, 32 bit STARK'lar ve ızgara tabanlı kriptografi bulunmaktadır. EVM-MAX ve SIMD'nin birleşimi, bu iki performans odaklı genişlemenin doğal bir eşleşme olmasını sağlamaktadır.

Bir EIP kombinasyonunun yaklaşık tasarımı EIP-6690'dan başlayacak ve 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 3 doğrudan sayı x, y, z kullanmak yerine 7 doğrudan sayı kullanacaktır: x_start, x_skip, y_start, y_skip, z_start, z_skip, count. Python kodunda, bu opcode'ların işlevi benzer şekilde:

python 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)'yi ekleyebiliriz, döngüsel ve döngüsel olmayan(, en azından 2'nin kuvvet modül sayıları için. Ayrıca ISZERO) eklemek, EVM ana yığınına( çıktı yollayacak, 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 dikkat çekmiştir.

)# Kalan işler ve denge

Şu anda, EOF'un bir sonraki sert çatala dahil edilmesi planlanıyor. Her ne kadar son dakikada kaldırılması her zaman mümkün olsa da - önceki sert çatallarda bazı işlevler geçici olarak kaldırıldı - bunu yapmak büyük zorluklarla karşılaşacaktır. EOF'un kaldırılması, gelecekte EVM için yapılacak herhangi bir güncellemenin EOF olmadan gerçekleştirilmesi gerektiği anlamına geliyor, bu mümkün olsa da daha zor olabilir.

EVM'nin ana dengesi L1 karmaşıklığı ile altyapı karmaşıklığı arasındadır, EOF, EVM uygulamasına eklenmesi gereken çok sayıda koddur, statik kod kontrolü de oldukça karmaşıktır. Ancak, bunun karşılığında, yüksek seviyeli dilleri sadeleş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 bunu içermelidir.

Yapılması gereken önemli bir iş, EVM-MAX ile SIMD benzeri işlevlerin uygulanmasıdır ve çeşitli kripto işlemlerinin gaz tüketiminin karşılaştırmalı testlerinin yapılmasıdır.

Harita yolunun diğer bölümleriyle nasıl etkileşim kurabilirim?

L1, EVM'sini L2'nin de daha kolay bir şekilde gerekli ayarlamaları yapabilmesi için uyarladı. 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 gaz maliyetlerini düşürebilir ve böylece L2'yi daha verimli hale getirebilir. Aynı görevleri yerine getiren EVM kodları ile daha fazla önceden derlenmiş kodun değiştirilmesi daha kolay hale gelir ve bu, verimliliği büyük ölçüde etkilemeyebilir.

![Vitalik'in Ethereum'un Olası Geleceği (6): The Splurge]###https://img-cdn.gateio.im/webp-social/moments-ec1638a809393a6ed42724fb08f534da.webp(

) Hesap Abstraksiyonu

Hangi sorunu çözdü?

Şu anda, işlemler yalnızca bir şekilde doğrulanabilir: ECDSA imzası. Başlangıçta, hesap soyutlaması bunu aşmayı amaçlıyordu ve hesapların 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 şifrelemeye geç
• Eski anahtarları döndürmek ### 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 protokollerinin aracı olmadan çalışmasına izin vererek karmaşıklığını önemli ölçüde azaltır ve merkezi bir bağımlılık noktasını ortadan kaldırır.

2015'te hesap soyutlama gündeme geldiğinden beri, hedefi "kolaylık hedefleri" dahil olmak üzere genişletilmiştir, örneğin, ETH'si olmayan ancak bazı ERC20'leri olan bir hesabın ERC20 ile gaz ödeyebilmesidir.

MPC) çok taraflı hesaplama (, anahtarları birden fazla parçaya bölmek ve bunları birden fazla cihazda depolamak için kullanılan, 40 yıllık bir geçmişe sahip bir teknolojidir, kriptografi tekniklerini kullanarak imza oluşturur ve bu anahtar parçalarını doğrudan birleştirmeden.

EIP-7702, bir sonraki hard fork'ta tanıtılması planlanan bir öneridir. EIP-7702, EOA kullanıcıları da dahil olmak üzere tüm kullanıcıların yararına hesap soyutlama kolaylığı sağlama konusundaki artan farkındalığın bir sonucudur ). Amacı, tüm kullanıcıların deneyimini kısa vadede iyileştirmek ve iki ekosisteme bölünmeyi önlemektir.

Bu çalışma EIP-3074 ile başladı ve sonunda EIP-7702'ye dönüştü. EIP-7702, hesap soyutlamasının "kolaylık işlevlerini" tüm kullanıcılara sunuyor, bu da günümüzün EOA( dışarıdan sahip olunan hesapları, yani ECDSA imzası ile kontrol edilen hesapları ) kapsıyor.

Bazı zorluklar ( özellikle "rahatlık" zorluğu ) çok taraflı hesaplama veya EIP-7702 gibi kademeli teknolojilerle çözülebilirken, hesap soyutlama önerisinin başlangıçta ortaya konan ana güvenlik hedefi, akıllı sözleşme kodunun işlem doğrulamasını kontrol etmesine izin vermek için orijinal sorunu geri alıp çözmekle gerçekleştirilebilir. Şu ana kadar uygulanamamasının nedeni, bunu güvenli bir şekilde gerçekleştirmektir; bu, bir zorluktur.

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

Hesap soyutlamasının özü basittir: akıllı sözleşmelerin işlemlere başlamasına izin vermek, yalnızca 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 hesabın doğrulama fonksiyonu belirli bir tekil S değerine bağımlıysa ve mevcut S değeri bellek havuzundaki tüm işlemleri geçerli kılıyorsa, o zaman 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şlemleri göndermesini sağlayarak ağ düğümlerinin kaynaklarını tıkamasına neden olabilir.

Yıllarca süren çabaların ardından, işlevselliği genişletirken hizmet reddi ) DoS ### riskini sınırlamayı hedefleyen bir çözüm geliştirildi: "İdeal Hesap Soyutlaması"nı gerçekleştiren 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ğrulama önce işlenir, tüm yürütme daha sonra işlenir. Bellek havuzunda, kullanıcı işleminin doğrulama aşaması yalnızca kendi hesabını içeriyor ve ortam değişkenlerini okumuyorsa, o zaman 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 kısıtlamaları zorunlu olarak uygulanır.

ERC-4337, ek bir protokol standardı olarak tasarlandı (ERC), çünkü o dönemde Ethereum istemci geliştiricileri (Merge)'e odaklandılar ve diğer işlevleri ele almak için ek bir enerjiye sahip değillerdi. Bu nedenle, ERC-4337, geleneksel işlemler yerine kullanıcı işlemleri adı verilen bir nesne kullandı. Ancak, son zamanlarda bunun en azından bir kısmını protokole yazmamız gerektiğini fark ettik.

İki ana neden aşağıdaki gibidir:

1. EntryPoint'in sözleşmenin doğasında var olan verimsizliği: Her paket için yaklaşık 100,000 gazlık sabit bir maliyet ve her kullanıcı işlemi için ek olarak binlerce gaz.
2. Ethereum özelliklerinin gerekliliğini sağlamak: İçerik listesinde oluşturulan garantilerin hesap soyut kullanıcıya aktarılması gerektiğini içerir.

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, doğrulama aşamasında yalnızca gönderen hesabına erişim kurallarıyla çelişmektedir, bu nedenle ödeme aracı mekanizmasının güvenliğini sağlamak için özel işlemler getirilmiştir.
• Agregatör ( 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.

(# Kalan işler ve denge

Şu anda ana ihtiyaç, hesap soyutlamasını protokole tamamen entegre etmenin nasıl olacağını çözmektir. Son zamanlarda popüler olan yazma protokolü hesap soyutlama EIP'si EIP-7701'dir. Bu öneri, EOF'un üzerinde hesap soyutlamayı gerçekleştirir. Bir hesabın doğrulama için ayrı bir kod bölümü olabilir; eğer hesap bu kod bölümünü ayarlarsa, bu kod o hesaptan gelen işlemlerin doğrulama aşamasında yürütülecektir.

Bu yöntemin cazibesi, 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 ekleyin
2. Yeni bir EOA türü, burada imza algoritması EVM kodu yürütme.

Eğer doğrulama süresi boyunca yürütülebilir kod karmaşıklığına sıkı sınırlar koyarak başlarsak - dış duruma erişime izin verilmez, hatta başlangıçta belirlenen gaz sınırı, 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 açıktır: sadece ECDSA doğrulamasını benzer süreye ihtiyaç duyan EVM kodu yürütmesi ile değiştirmek.

Ancak, zamanla bu sınırları gevşetmemiz gerekiyor, çünkü gizlilik koruma uygulamalarının aracısız çalışmasına izin vermek ve kuantum direnci ç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ı bulmamız gerekiyor.