Ethereum protokolünün olası geleceği (6): Refah

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

Refah: Ana Hedef

• EVM'yi yüksek performanslı ve stabil bir "son durum" haline getirmek
• Hesap soyutlamasını protokole entegre ederek, tüm kullanıcıların daha güvenli ve pratik hesapların avantajlarından yararlanmasını sağlamak
• İşlem maliyetlerini optimize et, ölçeklenebilirliği artırırken riski azalt.
• İleri düzey kriptografiyi keşfetmek, Ethereum'un uzun vadede önemli ölçüde iyileşmesini sağlamak

EVM iyileştirmesi

Hangi sorunu çözdü?

Mevcut EVM, statik analiz yapmayı zorlaştırıyor, bu da verimli uygulamalar oluşturmayı, resmi olarak kod doğrulamayı ve daha fazla genişleme yapmayı zorlaştırıyor. Ayrıca, EVM'nin verimliliği düşüktür ve birçok ileri düzey kriptografi biçiminin gerçekleştirilmesi zor, ancak önceden derlenmiş destek ile mümkündür.

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

Mevcut EVM geliştirme yol haritasının ilk adımı EVM nesne formatı (EOF), bir sonraki sert çatalda dahil edilmesi planlanıyor. EOF, birçok benzersiz özelliğe sahip yeni bir EVM kodu sürümünü belirten bir dizi EIP'dir, en dikkate değer olanı:

• ( kodu yürütülebilir, ancak EVM'den ) ile ( arasındaki ayrımı okuyamaz ve ) verileri 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 ve oluşturulmaya devam edecektir, ancak nihayetinde eski sözleşmelerin ) aşamalı olarak kullanılmaktan vazgeçileceği ve hatta EOF koduna ( zorunlu olarak dönüştürülebileceği mümkündür. Yeni sözleşmeler, EOF'un getirdiği verimlilik artışından faydalanacaktır - öncelikle alt rutin özellikleri ile hafifçe küçülmüş byte kodu, ardından EOF'ya özgü yeni işlevler veya azalan gas maliyetleri.

EOF'un tanıtılmasından sonra, daha fazla yükseltme daha kolay hale geldi. Şu anda en gelişmiş olanı EVM modülü aritmetik genişlemesi ) EVM-MAX (. EVM-MAX, modüler hesaplamalara özel yeni bir işlem seti oluşturdu ve bunları diğer opcode'lar aracılığıyla 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ı.

Daha yeni bir fikir, EVM-MAX'i 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 şifreleme biçimini hızlandırmak için kullanılabilir; bu, hash fonksiyonları, 32 bit STARK'lar ve ızgara tabanlı şifreleme dahil olmak üzere, EVM-MAX ve SIMD'nin birleşimi bu iki performansa dayalı 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 sabit sayı x, y, z kullanmak yerine 7 sabit sayı kullanır: x_start, x_skip, y_start, y_skip, z_start, z_skip, count. Python kodunda, bu opcode'ların işlevi benzer şekilde:

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( döngü ve döngü olmayanları içerecek şekilde eklenebilir, en azından 2'nin kuvvet modülü için. Aynı zamanda ISZERO), EVM ana yığın çıkışı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 uygulanabilir, ancak şu ana kadar daha az ilgi görmüştür.

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

)# Kalan işler ve denge

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

EVM'nin ana dengesi, L1 karmaşıklığı ile altyapı karmaşıklığı arasındadır; EOF, EVM uygulamasına eklenmesi gereken büyük miktarda koddur ve statik kod incelemesi de nispeten karmaşıktır. Ancak, bunun karşılığında, yüksek dille basitleştirme, EVM uygulamasını basitleştirme ve diğer faydaları elde edebiliriz. Denebilir ki, Ethereum L1'in sürekli iyileştirmelerinin yol haritasını önceliklendirmek, EOF üzerine inşa edilmeli ve bunu içermelidir.

Yapılması gereken önemli bir iş, EVM-MAX ile SIMD benzeri işlevleri gerçekleştirmek ve çeşitli şifreleme işlemlerinin gaz tüketimini karşılaştırmalı test etmektir.

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

L1, EVM'sini L2'nin de daha kolay bir şekilde uyum sağlamasını sağlamak için ayarlıyor. Eğer ikisi senkronize bir şekilde ayarlanmazsa, uyumsuzluk yaratabilir ve olumsuz etkilere yol açabilir. Ayrıca, EVM-MAX ve SIMD, birçok kanıtlama sisteminin gas maliyetlerini düşürerek L2'yi daha verimli hale getirir. Aynı görevleri yerine getirebilen EVM koduyla daha fazla önceden derlenmiş kodun değiştirilmesi de daha kolay hale gelir, bu da verimliliği büyük ölçüde etkilemeyebilir.

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

) Hesap Soyutlama

Hangi sorunu çözdü?

Şu anda, işlemler yalnızca bir yöntemle doğrulanabilir: ECDSA imzası. Başlangıçta, hesap soyutlaması bunu aşmayı amaçlıyordu ve hesap doğrulama mantığının herhangi bir EVM kodu için olmasına izin veriyordu. Bu, bir dizi uygulamayı etkinleştirebilir:

• Kuantum direnci kriptografiye geçiş yap
• Eski anahtarları döndürmek ### 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 ara bağlantı olmadan çalışmasına izin vererek karmaşıklığını önemli ölçüde azaltması ve merkezi bir bağımlılık noktasını ortadan kaldırması.

2015'ten beri hesap soyutlaması önerildiğ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 ayırmak ve bunları birden fazla cihazda depolamak için kullanılan, 40 yıllık bir geçmişi olan bir teknolojidir. Bu teknoloji, bu anahtar parçalarını doğrudan birleştirmeden imza oluşturmak için kriptografi tekniklerini kullanır.

EIP-7702, bir sonraki sert çatalla birlikte tanıtılması planlanan bir öneridir. EIP-7702, hesap soyutlama kolaylıklarının sağlanmasına yönelik artan bir farkındalığın sonucudur ve tüm kullanıcıları, EOA kullanıcılarını da ()) kapsayarak hedeflemektedir. Kısa vadede tüm kullanıcıların deneyimini iyileştirmeyi ve iki ekosisteme bölünmeyi önlemeyi amaçlamaktadır.

Bu çalışma EIP-3074 ile başladı ve nihayetinde EIP-7702'yi oluşturdu. EIP-7702, hesap soyutlamanın "kolaylık işlevlerini" tüm kullanıcılara sunmaktadır, bunlar arasında günümüzdeki EOA( dışarıdan sahip olunan hesaplar, yani ECDSA imzası ile kontrol edilen hesaplar) bulunmaktadır.

Grafikten görülebilir ki, bazı zorluklar ( özellikle "kolaylık" zorluğu ) çok taraflı hesaplama veya EIP-7702 gibi ilerleyen teknolojilerle çözülebilir, ancak hesap soyutlama önerisinin ilk güvenlik hedefi yalnızca geriye dönerek orijinal problemi çözerek gerçekleştirilebilir: akıllı sözleşme kodunun işlem doğrulamasını kontrol etmesine izin vermek. Şimdiye kadar gerçekleştirilememesinin nedeni, güvenli bir şekilde uygulamanın zorluğudur.

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

Hesap soyutlamasının temeli basittir: akıllı sözleşmelerin işlemleri 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şı önlem almakla ilgilidir.

Tipik bir anahtar zorluk çoklu arıza sorunudur:

Eğer 1000 hesabın doğrulama fonksiyonları tek bir S değerine bağımlıysa ve mevcut S değeri, hafıza havuzundaki işlemlerin hepsinin geçerli olmasını sağlıyorsa, o zaman S değerini tersine çeviren tek bir işlem, hafıza havuzundaki diğer tüm işlemleri geçersiz kılabilir. Bu, saldırganın hafıza havuzuna çöp işlemler göndermesini ve böylece ağ düğümlerinin kaynaklarını tıkamasını sağlıyor.

Yıllarca süren çabaların ardından, işlevselliği genişletirken aynı zamanda ) DoS ### riskini sınırlamayı amaçlayan bir çözüm bulundu: "ideal hesap soyutlama"yı 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ğ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 ortam değişkenlerini okumuyorsa kabul edilir. Bu, çoklu başarısızlık saldırılarını önleyebilir. Ayrıca, doğrulama adımına da katı gaz limitleri zorunlu kılınmıştır.

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

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

1. EntryPoint'in sözleşmenin doğasında var olan verimsizliği: Her bir paket için yaklaşık 100.000 gaz sabit maliyeti ve her bir kullanıcı işlemi için ek olarak binlerce gaz.
2. Ethereum özelliklerinin gerekliliğini sağlamak: Listede yer alan garantilerin, hesap soyut kullanıcıya aktarılması gerektiği gibi oluşturulması.

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

• Ödeme aracısı (Paymasters): Bir hesabın başka bir hesabın ücretlerini ödeme işlevine izin verir, bu da doğrulama aşamasında yalnızca göndericinin kendi hesabına erişim kuralını ihlal eder, bu nedenle ödeme aracısı 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 agregasyonunu destekleyen bir işlev. Bu, Rollup üzerinde en yüksek veri verimliliğini sağlamak için gereklidir.

(# Kalan işler ve dengelemeler

Şu anda ana ihtiyaç, hesap soyutlamasını protokole tamamen entegre etmenin yollarını bulmaktır. Son zamanlarda popülerlik kazanan 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ı ayarladıysa, o kod, o hesaptan gelen işlemlerin doğrulama adımında çalıştırılacaktır.

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 kullan
2. Yeni bir EOA türü, burada imza algoritması EVM kodu yürütmesidir.

Eğer doğrulama süresince yürütülebilir kodun karmaşıklığına katı sınırlar koymaya başlarsak - dış duruma erişime izin verilmez, hatta başlangıçta belirlenen gaz limiti kuantum direnci veya gizlilik koruma uygulamaları için geçersiz olacak kadar düşükse - o zaman bu yöntemin güvenliği oldukça açıktır: sadece ECDSA doğrulamasını benzer süre gerektiren 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 sağlamak çok önemlidir. Bunun için, hizmet reddi )DoS### sorununu daha esnek bir şekilde çözmenin yollarını bulmalıyız.