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ştirmeleri ile ilgilidir, geri kalan kısmı ise çeşitli niş konulardan oluşmaktadır, işte bu "bolluk" anlamına gelir.

Refah: Ana Hedef

• EVM'yi yüksek performanslı ve stabil "son durum" haline getirmek
• Hesap soyutlamasını protokole dahil et, tüm kullanıcıların daha güvenli ve kullanım kolaylığı sağlayan bir hesap deneyiminden yararlanmasına izin ver.
• İşlem maliyetlerini optimize et, ölçeklenebilirliği artırırken riski azalt.
• Gelişmiş kriptografi keşfedin, Ethereum'un uzun vadede önemli ölçüde iyileşmesini sağlayın

EVM geliştirmesi

Ne tür bir sorunu çözdü?

Şu anda EVM'nin statik analizi zor, bu da verimli uygulamalar oluşturmayı, resmi olarak kod doğrulamayı ve daha fazla genişletmeyi zorlaştırıyor. Ayrıca, EVM'nin verimliliği düşüktür, pek çok yüksek seviyeli kriptografi biçimini gerçekleştirmek zordur, bu da önceden derlenmiş destek aracılığıyla mümkündür.

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

Mevcut EVM iyileştirme yol haritasının ilk adımı EVM nesne formatı (EOF) olup, bir sonraki sert çatala dahil edilmesi planlanmaktadır. EOF, birçok benzersiz özelliğe sahip yeni bir EVM kod versiyonunu belirten bir dizi EIP'den oluşmaktadır, en dikkat çekici olanı:

• Kod ( yürütülebilir, ancak EVM'den ) ile veri ( arasındaki ayrımı okuyamaz, ancak ) yürütülemez.
• Dinamik atlamalar yasaktır, yalnızca statik atlamalara 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 edecek, ancak sonunda eski sözleşmelerin ( kademeli olarak kullanılmaktan vazgeçilebileceği ve hatta EOF koduna ) zorunlu dönüşüm yapılabileceği ihtimali bulunmaktadır. Yeni sözleşmeler, EOF'un sağladığı verimlilik artışından faydalanacak - önce alt rutin özellikleri ile biraz küçülen bytecode, ardından EOF'a özgü yeni özellikler veya azalan gas maliyetleri ile.

EOF'un getirilmesinden sonra, daha ileri yükseltmeler daha kolay hale geldi, şu anda en iyi gelişen EVM modül aritmetik genişlemesi (EVM-MAX). EVM-MAX, modül işlemleri için özel olarak tasarlanmış yeni bir işlem kümesi 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.

Yeni bir fikir, EVM-MAX'ı tek komut çoklu veri ( SIMD ) özelliği ile birleştirmektir. SIMD, Ethereum'un bir konsepti olarak uzun süredir var; ilk olarak Greg Colvin'in EIP-616'sında önerilmiştir. SIMD, birçok şifreleme biçimini hızlandırmak için kullanılabilir; bunlar arasında hash fonksiyonları, 32-bit STARKs ve ızgara tabanlı şifreleme yer almaktadır. EVM-MAX ve SIMD'nin birleştirilmesi, bu iki performansa yönelik genişlemenin doğal bir eşleşmesini sağlar.

Bir EIP kombinasyonunun genel 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 ver
• Her EVM-MAX işlem kodu için ( toplama, çıkarma, çarpma ), bir versiyon ekleyin, bu versiyon artık 3 anlık sayı x, y, z kullanmayacak, bunun yerine 7 anlık sayı kullanacak: x_start, x_skip, y_start, y_skip, z_start, z_skip, count. Python kodunda, bu işlem kodlarını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 olarak işlenecektir.

• XOR, AND, OR, NOT ve SHIFT( dahil edilebilir, döngüsel ve döngüsel olmayan), en azından 2'nin kuvvet modülleri için. Aynı zamanda ISZERO( eklenerek çıktı EVM ana yığınına) gönderilecektir, 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 mümkün olabilir, ancak şimdiye kadar daha az ilgi görmüştür.

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

• EOF:
• EVM-MAX:
• SIMD:

Kalan işler ve dengesizlikler

Şu anda, EOF'un bir sonraki sert çatalla birlikte dahil edilmesi planlanıyor. Her ne kadar son dakikada kaldırılması her zaman mümkün olsa da - önceki sert çatallarda bazı 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 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 incelemesi 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. Denilebilir ki, Ethereum L1'in sürekli gelişimi için öncelikli yol haritası, EOF üzerine inşa edilmeli ve onu içermelidir.

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

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

L1, EVM'sini L2'nin de daha kolay ayarlamalar yapabilmesi için düzenler. Eğer her iki taraf senkronize bir şekilde ayarlama yapmazsa, uyumsuzluk oluşabilir ve olumsuz etkiler getirebilir. Ayrıca, EVM-MAX ve SIMD, birçok kanıt sisteminin gaz maliyetlerini düşürebilir, böylece L2'yi daha verimli hale getirir. Aynı görevleri yerine getirebilen EVM kodlarıyla daha fazla önceden derlenmiş kodu değiştirmek, verimliliği büyük ölçüde etkilemeden daha kolay hale gelir.

Hesap Soyutlama

hangi sorunu çözdü?

Şu anda, işlemler yalnızca bir yöntemle doğrulanabilir: ECDSA imzası. Başlangıçta, hesap soyutlaması bunun ötesine geçmeyi amaçlıyordu ve hesapların doğrulama mantığını herhangi bir EVM kodu için mümkün kılmaktaydı. Bu, bir dizi uygulamanın önünü açabilir:

• Kuantum direnci kriptografiye geçiş yap
• Eski anahtar ( değiştirmek geniş çapta ö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 aracı olmadan çalışmasına izin vermek, 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 itibaren hesap soyutlaması önerildiğinden beri, hedefi birçok "kolaylık hedefi" içerecek şekilde genişledi, örneğin, ETH'si olmayan ancak bazı ERC20 varlıklarına sahip bir hesabın ERC20 ile gaz ücreti ödeyebilmesidir.

MPC( çok partili 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şe sahip bir tekniktir. Bu teknik, bu anahtar parçalarını doğrudan birleştirmeden, şifreleme teknolojisini kullanarak imzalar oluşturur.

EIP-7702, bir sonraki hard fork'ta tanıtılması planlanan bir öneridir. EIP-7702, hesap soyutlama kolaylığını sağlama konusundaki artan farkındalığın bir sonucudur ve bu tüm kullanıcılar için, ( EOA kullanıcıları ) dahil, fayda sağlamayı amaçlamaktadır. Bu öneri, kısa vadede tüm kullanıcıların deneyimini iyileştirmeyi ve iki ekosisteme bölünmeyi önlemeyi hedeflemektedir.

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

Bazı zorluklar ( özellikle "rahatlık" zorluğu ) çok taraflı hesaplama veya EIP-7702 gibi ilerleyici teknolojilerle çözülebilirken, başlangıçta hesap soyutlama önerisini sunan ana güvenlik hedefi, geri dönerek orijinal sorunu çözmekle gerçekleştirilebilir: akıllı sözleşme kodunun işlem doğrulamasını kontrol etmesine izin vermek. Şu ana kadar başarılmamış olmasının nedeni güvenli bir şekilde uygulanmasıdır, bu da bir zorluktur.

Bu 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ğı koruyucu bir şekilde gerçekleştirmek ve hizmet reddi saldırılarına karşı koruma sağlamaktan kaynaklanmaktadır.

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

Eğer 1000 hesap doğrulama fonksiyonu belirli bir tek değer S'ye bağlıysa ve mevcut S değeri bellek havuzundaki işlemlerin hepsinin geçerli olmasını sağlıyorsa, o zaman S'nin değerini tersine çeviren tek bir işlem bellek havuzundaki tüm diğer işlemleri geçersiz kılabilir. Bu, saldırganların bellek havuzuna çöp işlemler göndermesini ve böylece ağ düğümlerinin kaynaklarını tıkamasını mümkün kılar.

Yıllarca süren çabaların ardından, işlevselliği genişletirken aynı zamanda hizmet reddi ( DoS ) riskini sınırlamayı amaçlayan bir çözüm olarak "ideal hesap soyutlaması"nı gerçekleştiren ERC-4337'ye ulaşıldı.

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, 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ı zorunlu olarak uygulanır.

ERC-4337, ( ERC), Ethereum istemci geliştiricilerinin o sırada birleştirmeye ( Merge) odaklandıkları için ek işlevleri ele almak üzere ek bir enerjiye sahip olmamaları nedeniyle, ek bir protokol standardı olarak tasarlandı. Bu yüzden ERC-4337, geleneksel işlemler yerine kullanıcı işlem adı verilen bir nesne kullandı. Ancak, son zamanlarda protokolün içine en azından bir kısmını yazma ihtiyacını fark ettik.

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

1. EntryPoint'in sözleşmenin doğuştan verimsizliği: her bir paket için yaklaşık 100.000 gazlık sabit bir maliyet ve her kullanıcı işlemi için ek binlerce gaz.
2. Ethereum özelliklerinin gerekliliğini sağlamak: Hesap soyut kullanıcıya transfer edilmesi gereken garantileri içeren listeyle oluşturulan içerik.

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

• Ödeme aracısı ( Paymasters ): Bir hesabın başka bir hesabın masraflarını ödemesine izin veren bir işlev, bu, doğrulama aşamasında yalnızca gönderen hesabının kendisine 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.
• Protokol ( Agregatörler ): BLS agregasyonu veya SNARK tabanlı agregasyon gibi imza agregasyonunu destekleyen bir özelliktir. Bu, Rollup üzerinde en yüksek veri verimliliğini sağlamak için gereklidir.

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

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

Kalan işler ve değerlendirmeler

Şu anda ana ihtiyaç, hesap soyutlamasının protokole tamamen nasıl entegre edileceğini çözmektir. Son zamanlarda popüler olan yazım protokolü hesap soyutlaması EIP, EIP-7701'dir. Bu öneri, EOF'un üzerinde hesap soyutlamasını gerçekleştirmektedir.