Bazı şeyler tek bir kategoriye yerleştirilmesi zor, Ethereum protokol tasarımında birçok "detay" Ethereum'un başarısı için çok önemlidir. 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 "refah"ın anlamı budur.
Refah: Ana Hedefler
EVM'yi yüksek performanslı ve stabil "nihai durum" haline getirmek
Hesap soyutlamasını protokole dahil etme, tüm kullanıcıların daha güvenli ve pratik bir hesap deneyimi yaşamasına olanak tanır.
İşlem ücretleri ekonomisini optimize etmek, ölçeklenebilirliği artırırken riski azaltmak
Gelişmiş kriptografiyi keşfedin, Ethereum'un uzun vadede önemli ölçüde iyileşmesini sağlayın
EVM iyileştirmesi
Hangi sorunu çözdü?
Mevcut EVM, statik analiz yapmakta zorluk çekiyor, bu da verimli uygulamalar oluşturmayı, resmi olarak kodu doğrulamayı ve daha fazla genişlemeyi zorlaştırıyor. Ayrıca, EVM'nin verimliliği düşüktür ve birçok ileri düzey kriptografi biçimini gerçekleştirmek zordur, ancak önceden derlenmiş destekle açık bir şekilde desteklenmedikçe.
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 kodu versiyonunu belirten bir dizi EIP'dir; en belirgin olanı:
Kod ( yürütülebilir, ancak EVM'den ) ile veri ( arasında okunamıyor, ancak ) yürütülemiyor.
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
Refah:EVM İyileştirme(devam)
Eski sözleşmeler var olmaya devam edecek ve oluşturulabilecektir, ancak nihayetinde eski sözleşmelerin ( kademeli olarak terk edilmesi ve hatta EOF koduna ) zorunlu olarak dönüştürülmesi muhtemeldir. Yeni sözleşmeler, EOF'un getirdiği verimlilik artışından yararlanacaktır ------ ilk olarak alt rutin özellikleri sayesinde biraz küçültülen bayt kodu, ardından ise EOF'ya özgü yeni işlevler veya azalan gaz 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 aritmetik işlemleri için özel olarak tasarlanmış yeni bir komut seti oluşturur ve bunları diğer opcode'larla erişilemeyen yeni bir bellek alanına yerleştirir, bu da Montgomery çarpması gibi optimizasyonların kullanılmasını mümkün kılar.
Daha yeni bir fikir, EVM-MAX'i tek komut çoklu veri (SIMD) özelliği ile birleştirmektir. SIMD, Ethereum'un bir konsepti olarak uzun zamandır var, ilk olarak Greg Colvin'in EIP-616'sında önerilmiştir. SIMD, hash fonksiyonları, 32 bit STARKs ve ızgara tabanlı kriptografi dahil olmak üzere birçok kriptografi biçimlerini hızlandırmak için kullanılabilir. EVM-MAX ve SIMD'nin birleşimi, bu iki performansa dayalı genişlemenin doğal bir eşleşmesi olmasını sağlar.
Bir EIP kombinasyonunun genel tasarımı EIP-6690'ı başlangıç noktası olarak alacak ve ardından:
(i) herhangi bir tek sayı veya (ii) en fazla 2768 olan 2'nin kuvveti modül olarak izin verilir.
Her EVM-MAX opcode ( toplama, çıkarma, çarpma ) için bir versiyon ekleyin, bu versiyon artık 3 immediates x, y, z kullanmıyor, bunun yerine 7 immediat kullanıyor: x_start, x_skip, y_start, y_skip, z_start, z_skip, count. Python kodunda, bu opcode'ların etkisi 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( dahil olmak üzere döngüsel ve döngüsel olmayan ), en azından 2'nin kuvvetleri modül sayısı için eklenebilir. Aynı zamanda ISZERO(, çıktının EVM ana yığınına) itmesini sağlayacak, 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 şimdiye kadar daha az ilgi görmüştür.
Kalan işler ve denge
Şu anda, EOF'un bir sonraki hard fork'ta dahil edilmesi planlanıyor. Ancak, bunu son dakikada kaldırmak her zaman mümkün; önceki hard fork'larda bazı işlevlerin geçici olarak kaldırıldığı olmuştur, ancak böyle bir adım büyük zorluklarla karşılaşacaktır. EOF'un kaldırılması, EVM üzerindeki gelecekteki herhangi bir yükseltmenin EOF olmadan yapılması gerektiği anlamına gelir. Bunu yapmak 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 görece karmaşıktır. Ancak, bunun karşılığında, yüksek düzeydeki 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 edilmelidir.
Gerçekleştirilmesi gereken önemli bir iş, EVM-MAX ve SIMD benzeri işlevlerin uygulanması ve çeşitli kriptografik işlemlerin gaz tüketiminin karşılaştırmalı testini yapmaktır.
Yol haritasının diğer bölümleriyle nasıl etkileşimde bulunulur?
L1, EVM'sini L2'nin de kolayca uygun şekilde ayarlayabilmesi için düzenler. Eğer her iki taraf senkronize bir şekilde ayarlama yapmazsa, uyumsuzluklar ortaya çıkabilir ve olumsuz etkiler doğurabilir. Ayrıca, EVM-MAX ve SIMD, birçok doğrulama sisteminin gaz maliyetlerini düşürerek L2'yi daha verimli hale getirebilir. Aynı görevleri yerine getirebilen EVM kodlarıyla daha fazla önceden derlenmiş kodu değiştirmeyi kolaylaştırır, bu da 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 soyutlaması bunun ötesine geçmeyi amaçlıyordu ve hesapların doğrulama mantığının herhangi bir EVM kodu için olmasına izin veriyordu. Bu, bir dizi uygulamanın etkinleştirilmesini sağlayabilir:
Kuantum direncili şifrelemeye geç
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 aracı olmadan çalışmasına izin vermek, karmaşıklığını önemli ölçüde azaltır ve merkezi bir bağımlılık noktasını ortadan kaldırır.
2015 yılında hesap soyutlaması önerildiğinden beri, hedefi birçok "kolaylık hedefini" de kapsayacak şekilde genişledi; örneğin, ETH'si olmayan ancak bazı ERC20'leri bulunan bir hesap, gas ödemek için ERC20 kullanabilir.
MPC( çok taraflı hesaplama ), anahtarları birden fazla parçaya bölmek ve bunları birden fazla cihazda saklamak 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 imza oluşturmak için kriptografik teknikler kullanır.
EIP-7702, bir sonraki hard fork'ta tanıtılması planlanan bir öneridir. EIP-7702, tüm kullanıcıların, ( dahil olmak üzere, EOA kullanıcılarının ) faydalanabilmesi için hesap soyutlama rahatlığı sağlama konusundaki artan farkındalığın bir sonucudur. Kısa vadede tüm kullanıcıların deneyimini geliştirmek ve iki ekosisteme bölünmeyi önlemek amacı gütmektedir.
Bu çalışma EIP-3074 ile başladı ve nihayetinde EIP-7702'yi oluşturdu. 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ıyla kontrol edilen hesapları ) içeriyor.
Grafikten görülebilir ki, bazı zorluklar ( özellikle "kolaylık" zorluğu ) çoklu taraflı hesaplama veya EIP-7702 gibi ilerici teknolojilerle çözülebilirken, hesap soyutlama önerisinin başlangıçta öne sürdüğü ana güvenlik hedefi yalnızca orijinal sorunu geri alarak ve çözerek gerçekleştirilebilir: akıllı sözleşme kodunun işlem doğrulamasını kontrol etmesine izin vermek. Şu ana kadar gerçekleştirilememesinin nedeni, bunu güvenli bir şekilde uygulamaktır, bu da bir zorluktur.
Bu nedir, nasıl çalışır?
Hesap soyutlamasının temelinde basit bir kavram yatıyor: 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şı koruma sağlamakla ilgilidir.
Tipik bir anahtar zorluk, çoklu arıza sorunudur:
Eğer 1000 hesap doğrulama fonksiyonu belirli bir tek değer S'ye bağımlıysa ve mevcut değer S, bellek havuzundaki işlemlerin hepsinin 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öndermesini sağlayarak ağ düğümlerinin kaynaklarını tıkamasına neden olur.
Yıllarca süren çabaların ardından, işlevselliği genişletirken hizmet reddi ( DoS ) riskini sınırlamayı amaçlayan, nihayetinde "ideal hesap soyutlama"yı 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, ardından tüm yürütmeler işlenir. Bellek havuzunda, kullanıcı işleminin doğrulama aşaması yalnızca kendi hesabını içeriyorsa ve çevre değişkenlerini 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 kılınmıştır.
ERC-4337, Ethereum istemci geliştiricilerinin o sırada birleştirmeye (Merge) odaklandığı için ek bir protokol standardı olarak tasarlandı ve diğer işlevlerle ilgilenmek için ek bir enerjiye sahip değildi. Bu yüzden ERC-4337, normal işlemler yerine kullanıcı işlemleri olarak adlandırılan nesneleri kullandı. Ancak, yakın zamanda bunun en azından bir kısmını protokole yazma ihtiyacını fark ettik.
İki ana neden aşağıdaki gibidir:
EntryPoint'in sözleşmenin doğasında var olan verimsizliği: Her bir paket yaklaşık 100.000 gazlık sabit bir maliyete ve her bir kullanıcı işlemi için ek binlerce gaz maliyetine sahiptir.
Ethereum özelliklerinin gerekliliğini sağlamak: Listeyi içeren garantilerin hesap soyut kullanıcıya aktarılması gerektiği gibi oluşturulması.
Ayrıca, ERC-4337 iki özelliği daha genişletmiştir:
Ödeme aracısı (Paymasters): Bir hesabın başka bir hesabın ücretlerini ödemesine izin veren bir işlevdir, bu durum doğrulama aşamasında yalnızca gönderen 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örler ( Aggregators ): BLS birleşimi veya SNARK tabanlı birleşim gibi imza birleştirme 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 nasıl entegre edeceğidir. Son zamanlarda popüler olan yazım 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 olması mümkündür; eğer hesap bu kod parçasını ayarladıysa, bu kod, o hesaptan gelen işlemlerin doğrulama adımında yürütülecektir.
Bu yöntemin çekiciliği, yerel hesap soyutlamasının iki eşdeğer perspektifini açıkça göstermesidir:
EIP-4337'yi protokolün bir parçası olarak kullanın
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 koyarak başlarsak------dış duruma erişime izin verilmez, hatta başlangıçta belirlenen gaz 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 net hale gelir: ECDSA doğrulamasını benzer süre gerektiren EVM kodu yürütmesi ile değiştirmekten ibarettir.
Ancak, zamanla bu sınırları gevşetmemiz gerekiyor, çünkü gizlilik koruma uygulamalarının ortada olmadan izin verilmesine ihtiyaç var.
This page may contain third-party content, which is provided for information purposes only (not representations/warranties) and should not be considered as an endorsement of its views by Gate, nor as financial or professional advice. See Disclaimer for details.
Ethereum protokolünün geleceği: EVM yükseltmeleri ve hesap soyutlamasıyla gelen yeni fırsatlar
Ethereum protokolünün olası geleceği(altı): refah
Yazan: Vitalik Buterin
Bazı şeyler tek bir kategoriye yerleştirilmesi zor, Ethereum protokol tasarımında birçok "detay" Ethereum'un başarısı için çok önemlidir. 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 "refah"ın anlamı budur.
Refah: Ana Hedefler
EVM iyileştirmesi
Hangi sorunu çözdü?
Mevcut EVM, statik analiz yapmakta zorluk çekiyor, bu da verimli uygulamalar oluşturmayı, resmi olarak kodu doğrulamayı ve daha fazla genişlemeyi zorlaştırıyor. Ayrıca, EVM'nin verimliliği düşüktür ve birçok ileri düzey kriptografi biçimini gerçekleştirmek zordur, ancak önceden derlenmiş destekle açık bir şekilde desteklenmedikçe.
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 kodu versiyonunu belirten bir dizi EIP'dir; en belirgin olanı:
Refah:EVM İyileştirme(devam)
Eski sözleşmeler var olmaya devam edecek ve oluşturulabilecektir, ancak nihayetinde eski sözleşmelerin ( kademeli olarak terk edilmesi ve hatta EOF koduna ) zorunlu olarak dönüştürülmesi muhtemeldir. Yeni sözleşmeler, EOF'un getirdiği verimlilik artışından yararlanacaktır ------ ilk olarak alt rutin özellikleri sayesinde biraz küçültülen bayt kodu, ardından ise EOF'ya özgü yeni işlevler veya azalan gaz 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 aritmetik işlemleri için özel olarak tasarlanmış yeni bir komut seti oluşturur ve bunları diğer opcode'larla erişilemeyen yeni bir bellek alanına yerleştirir, bu da Montgomery çarpması gibi optimizasyonların kullanılmasını mümkün kılar.
Daha yeni bir fikir, EVM-MAX'i tek komut çoklu veri (SIMD) özelliği ile birleştirmektir. SIMD, Ethereum'un bir konsepti olarak uzun zamandır var, ilk olarak Greg Colvin'in EIP-616'sında önerilmiştir. SIMD, hash fonksiyonları, 32 bit STARKs ve ızgara tabanlı kriptografi dahil olmak üzere birçok kriptografi biçimlerini hızlandırmak için kullanılabilir. EVM-MAX ve SIMD'nin birleşimi, bu iki performansa dayalı genişlemenin doğal bir eşleşmesi olmasını sağlar.
Bir EIP kombinasyonunun genel tasarımı EIP-6690'ı başlangıç noktası olarak alacak ve ardından:
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.
Kalan işler ve denge
Şu anda, EOF'un bir sonraki hard fork'ta dahil edilmesi planlanıyor. Ancak, bunu son dakikada kaldırmak her zaman mümkün; önceki hard fork'larda bazı işlevlerin geçici olarak kaldırıldığı olmuştur, ancak böyle bir adım büyük zorluklarla karşılaşacaktır. EOF'un kaldırılması, EVM üzerindeki gelecekteki herhangi bir yükseltmenin EOF olmadan yapılması gerektiği anlamına gelir. Bunu yapmak 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 görece karmaşıktır. Ancak, bunun karşılığında, yüksek düzeydeki 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 edilmelidir.
Gerçekleştirilmesi gereken önemli bir iş, EVM-MAX ve SIMD benzeri işlevlerin uygulanması ve çeşitli kriptografik işlemlerin gaz tüketiminin karşılaştırmalı testini yapmaktır.
Yol haritasının diğer bölümleriyle nasıl etkileşimde bulunulur?
L1, EVM'sini L2'nin de kolayca uygun şekilde ayarlayabilmesi için düzenler. Eğer her iki taraf senkronize bir şekilde ayarlama yapmazsa, uyumsuzluklar ortaya çıkabilir ve olumsuz etkiler doğurabilir. Ayrıca, EVM-MAX ve SIMD, birçok doğrulama sisteminin gaz maliyetlerini düşürerek L2'yi daha verimli hale getirebilir. Aynı görevleri yerine getirebilen EVM kodlarıyla daha fazla önceden derlenmiş kodu değiştirmeyi kolaylaştırır, bu da 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 soyutlaması bunun ötesine geçmeyi amaçlıyordu ve hesapların doğrulama mantığının herhangi bir EVM kodu için olmasına izin veriyordu. Bu, bir dizi uygulamanın etkinleştirilmesini sağlayabilir:
Gizlilik protokolünün aracı olmadan çalışmasına izin vermek, karmaşıklığını önemli ölçüde azaltır ve merkezi bir bağımlılık noktasını ortadan kaldırır.
2015 yılında hesap soyutlaması önerildiğinden beri, hedefi birçok "kolaylık hedefini" de kapsayacak şekilde genişledi; örneğin, ETH'si olmayan ancak bazı ERC20'leri bulunan bir hesap, gas ödemek için ERC20 kullanabilir.
MPC( çok taraflı hesaplama ), anahtarları birden fazla parçaya bölmek ve bunları birden fazla cihazda saklamak 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 imza oluşturmak için kriptografik teknikler kullanır.
EIP-7702, bir sonraki hard fork'ta tanıtılması planlanan bir öneridir. EIP-7702, tüm kullanıcıların, ( dahil olmak üzere, EOA kullanıcılarının ) faydalanabilmesi için hesap soyutlama rahatlığı sağlama konusundaki artan farkındalığın bir sonucudur. Kısa vadede tüm kullanıcıların deneyimini geliştirmek ve iki ekosisteme bölünmeyi önlemek amacı gütmektedir.
Bu çalışma EIP-3074 ile başladı ve nihayetinde EIP-7702'yi oluşturdu. 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ıyla kontrol edilen hesapları ) içeriyor.
Grafikten görülebilir ki, bazı zorluklar ( özellikle "kolaylık" zorluğu ) çoklu taraflı hesaplama veya EIP-7702 gibi ilerici teknolojilerle çözülebilirken, hesap soyutlama önerisinin başlangıçta öne sürdüğü ana güvenlik hedefi yalnızca orijinal sorunu geri alarak ve çözerek gerçekleştirilebilir: akıllı sözleşme kodunun işlem doğrulamasını kontrol etmesine izin vermek. Şu ana kadar gerçekleştirilememesinin nedeni, bunu güvenli bir şekilde uygulamaktır, bu da bir zorluktur.
Bu nedir, nasıl çalışır?
Hesap soyutlamasının temelinde basit bir kavram yatıyor: 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şı koruma sağlamakla ilgilidir.
Tipik bir anahtar zorluk, çoklu arıza sorunudur:
Eğer 1000 hesap doğrulama fonksiyonu belirli bir tek değer S'ye bağımlıysa ve mevcut değer S, bellek havuzundaki işlemlerin hepsinin 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öndermesini sağlayarak ağ düğümlerinin kaynaklarını tıkamasına neden olur.
Yıllarca süren çabaların ardından, işlevselliği genişletirken hizmet reddi ( DoS ) riskini sınırlamayı amaçlayan, nihayetinde "ideal hesap soyutlama"yı 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, ardından tüm yürütmeler işlenir. Bellek havuzunda, kullanıcı işleminin doğrulama aşaması yalnızca kendi hesabını içeriyorsa ve çevre değişkenlerini 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 kılınmıştır.
ERC-4337, Ethereum istemci geliştiricilerinin o sırada birleştirmeye (Merge) odaklandığı için ek bir protokol standardı olarak tasarlandı ve diğer işlevlerle ilgilenmek için ek bir enerjiye sahip değildi. Bu yüzden ERC-4337, normal işlemler yerine kullanıcı işlemleri olarak adlandırılan nesneleri kullandı. Ancak, yakın zamanda bunun en azından bir kısmını protokole yazma ihtiyacını fark ettik.
İki ana neden aşağıdaki gibidir:
Ayrıca, ERC-4337 iki özelliği daha genişletmiştir:
(# Kalan işler ve denge
Şu anda ana ihtiyaç, hesap soyutlamasını protokole tamamen nasıl entegre edeceğidir. Son zamanlarda popüler olan yazım 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 olması mümkündür; eğer hesap bu kod parçasını ayarladıysa, bu kod, o hesaptan gelen işlemlerin doğrulama adımında yürütülecektir.
Bu yöntemin çekiciliği, yerel hesap soyutlamasının iki eşdeğer perspektifini açıkça göstermesidir:
Eğer doğrulama süresince yürütülebilir kodun karmaşıklığına katı sınırlar koyarak başlarsak------dış duruma erişime izin verilmez, hatta başlangıçta belirlenen gaz 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 net hale gelir: ECDSA doğrulamasını benzer süre gerektiren EVM kodu yürütmesi ile değiştirmekten ibarettir.
Ancak, zamanla bu sınırları gevşetmemiz gerekiyor, çünkü gizlilik koruma uygulamalarının ortada olmadan izin verilmesine ihtiyaç var.