Ethereum protokolünün olası geleceği ( altı ): refah
Bazı şeyler tek bir kategoriye sokulması zor, Ethereum protokol tasarımında, birçok "detay" Ethereum'un başarısı için son derece ö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 "büyüme"nin anlamı budur.
Refah: Ana Hedef
EVM'yi yüksek performanslı ve stabil bir "nihai durum" haline getirin
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 maliyetlerini optimize et, ölçeklenebilirliği artırırken riski azalt.
Gelişmiş kriptografi ile Ethereum'un uzun vadede önemli ölçüde iyileşmesini sağlamak
EVM geliştirmesi
Hangi sorunu çözdü?
Mevcut EVM, statik analizi zorlaştırıyor, 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üşük, birçok ileri düzey kriptografi biçimini gerçekleştirmek zor, yalnızca önceden derlenmiş destek ile mümkün.
O nedir, nasıl çalışır?
Mevcut EVM iyileştirme yol haritasının ilk adımı EVM nesne formatı ( EOF ), bir sonraki sert çatalda dahil edilmesi planlanmaktadır. EOF, birçok benzersiz özelliğe sahip yeni bir EVM kodu sürümünü belirten bir dizi EIP'dir, en belirgin olanları şunlardır:
Kod ( çalıştırılabilir, ancak EVM'den ) ile veriler ( arasında okunamaz, ancak ) arasında ayrım yapılamaz.
Dinamik yönlendirmelere izin verilmez, yalnızca statik yönlendirmelere izin verilir.
EVM kodu artık yakıtla ilgili bilgileri gözlemleyemiyor.
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 terk edilmesi ve hatta EOF koduna ( zorunlu olarak dönüştürülmesi mümkün olabilir. Yeni sözleşmeler, EOF'un getirdiği verimlilik artışından faydalanacak - ilk olarak, alt rutin özellikleri sayesinde biraz küçülmüş olan byte kodu, ardından EOF'a ö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 işlemler için özel olarak tasarlanmış yeni bir işlem kümesi oluşturdu ve bunları diğer işlem kodlarıyla erişilemeyen yeni bir bellek alanına yerleştirdi, bu da Montgomery çarpması gibi optimizasyonların kullanılmasını mümkün kıldı.
Yeni bir fikir, EVM-MAX'ı tek talimat çoklu veri )SIMD( özelliği ile birleştirmektir. SIMD, Ethereum'un bir konsepti olarak uzun süredir var ve 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 performansa odaklı ölçeklemenin doğal bir eşleşmesini sağlıyor.
![Vitalik'in Ethereum'un Olası Geleceği Hakkında (Altı): The Splurge])https://img-cdn.gateio.im/webp-social/moments-e607936b4195e92945aa6ebd5f969276.webp(
Bir EIP kombinasyonunun genel tasarımı EIP-6690 ile başlayacak ve sonra:
)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 kullanmıyor, bunun yerine 7 sabit sayı kullanıyor: 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) dahil olmak üzere döngüsel ve döngüsel olmayan (, en azından 2'nin kuvvet modülü için eklenebilir. Aynı zamanda ISZERO), çıktıyı EVM ana yığınında( itmek için yeterince güçlü olacaktır; bu da eliptik eğri kriptografisi, küçük alan kriptografisi) gibi Poseidon, Circle STARKs(, geleneksel hash fonksiyonları) olan SHA256, KECCAK, BLAKE( ve ızgara tabanlı kriptografi için yeterlidir. Diğer EVM yükseltmeleri de uygulanabilir, ancak bugüne kadar daha az ilgi görmüştür.
Kalan işler ve dengeler
Şu anda, EOF'un bir sonraki sert çatallamada 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, bunu yapmak büyük zorluklarla karşılaşacaktır. EOF'un kaldırılması, gelecekte EVM'ye yapılacak herhangi bir yükseltmenin 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 kodu ifade eder, statik kod incelemesi de görece karmaşıktır. Ancak, bunun karşılığında, yüksek seviyeli dilleri basitleştirebilir, EVM uygulamasını sadeleştirebilir ve diğer faydalar elde edebiliriz. Denilebilir ki, Ethereum L1'in sürekli iyileştirilmesine öncelik veren bir yol haritası EOF'un üzerine inşa edilmeli ve onu içermelidir.
Gerçekleştirilmesi gereken önemli bir iş, EVM-MAX ile SIMD benzeri bir işlevsellik sağlamaktır ve çeşitli kriptografik işlemlerin gas tüketimini kıyaslamaktır.
Yol haritasının diğer kısımlarıyla nasıl etkileşimde bulunabilirim?
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 oluşturabilir 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 getirir. Ayrıca, aynı görevleri yerine getirebilen EVM kodları ile daha fazla önceden derlenmiş programları değiştirmek daha kolay hale gelir ve bu da verimliliği büyük ölçüde etkilemeyebilir.
![Vitalik'in Ethereum'un olası geleceği üzerine (Altı): The Splurge])https://img-cdn.gateio.im/webp-social/moments-8930b556d169a2bc7168ddc2e611d3df.webp(
) 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 olmasına izin veriyordu. Bu, bir dizi uygulamanın etkinleştirilmesini sağlayabilir:
Kuantum dirençli şifrelemeye geç
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.
Özellik protokolünün, bir ara sunucu 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'ten beri 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 olan bir hesabın ERC20 ile gaz ödeyebilmesidir.
O nedir, nasıl çalışır?
Hesap soyutlamasının özü basittir: akıllı sözleşmelerin işlem başlatmasına izin vermek, yalnızca 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şı korunmaktan gelmektedir.
Tipik bir anahtar zorluk çoklu arıza sorunudur:
Eğer 1000 hesabın doğrulama fonksiyonu belirli bir tekil değere S 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 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öndermesine ve böylece ağ düğümlerinin kaynaklarını tıkamasına olanak tanır.
Yıllarca süren çabaların ardından, işlevselliği genişletme ve hizmet reddi ) DoS ( riskini sınırlama amacıyla, "ideal hesap soyutlaması"nı 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 sıkı bir gaz limiti uygulanmaktadır.
ERC-4337, Ethereum istemcisi geliştiricilerinin o sırada )Merge( üzerinde yoğunlaşması nedeniyle, başka işlevlerle ilgilenmek için ekstra bir enerjiye sahip olmadıklarından, ek bir protokol standardı olarak tasarlandı )ERC(. Bu yüzden ERC-4337, normal işlemler yerine kullanıcı işlemleri adı verilen nesneleri kullandı. Ancak, son zamanlarda protokolün en azından bir kısmını yazma ihtiyacını fark ettik.
İki ana neden aşağıdadır:
EntryPoint sözleşmenin doğasında bulunan düşük verimlilik: Her bir paket için yaklaşık 100.000 gazlık sabit bir maliyet ve her bir kullanıcı işlemi için ek binlerce gaz.
Ethereum özelliklerinin gerekliliğini sağlamak: Listeyi içeren garantilerin, hesap soyut kullanıcıya aktarılması gerektiğini oluşturması gibi.
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şlev, bu da doğrulama aşamasında yalnızca gönderici hesabının kendisine 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): BLS agregasyonu veya SNARK tabanlı agregasyon gibi imza agregasyonu işlevlerini destekler. Bu, Rollup üzerinde en yüksek veri verimliliğini sağlaması için gereklidir.
Kalan işler ve dengeler
Ş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 soyutlama EIP'si EIP-7701'dir, bu öneri EOF'un üzerinde hesap soyutlamasını gerçekleştirmektedir. Bir hesap, doğrulama için ayrı bir kod kısmına sahip olabilir, eğer hesap bu kod kısmını ayarlarsa, 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 sıkı sınırlar koyarak başlarsak - dış duruma erişime izin verilmez, hatta başlangıçta belirlenen gaz limiti, kuantum dirençli veya gizlilik koruma uygulamaları için etkisiz olacak kadar düşükse - bu yaklaşımın güvenliği oldukça açıktır: ECDSA doğrulamasını, benzer süreye ihtiyaç duyan 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 aracı olmadan çalışmasına izin vermek ve kuantum direnci çok önemlidir. Bunun için, doğrulama adımlarının son derece sade olması gerekmeden, hizmet reddi (DoS) riskini daha esnek bir şekilde çözmenin yollarını bulmamız gerekiyor.
Ana değerlendirme, "daha az kişinin memnun olduğu 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. İdeal yaklaşım, bir tür karışık yöntem olabilir. Bir karışık 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 yaklaşım, L2 üzerinde daha iddialı bir hesap soyutlama sürümünü öncelikle dağıtmaktır. Ancak, bununla ilgili zorluk, L2 ekibinin benimseme önerisinin uygulanabilirliğine güven duyması gerektiğidir, özellikle de L1 ve/veya diğer L2'lerin gelecekte uyumlu çözümleri benimsemesini sağlamak için.
Ayrıca net bir şekilde düşünmemiz gereken bir başka uygulama, anahtar depolama hesaplarıdır; bu hesaplar L1 veya özel L2 üzerinde hesapla ilgili durumu depolar, ancak L1 ve herhangi bir uyumlu L2 üzerinde kullanılabilir. Bunu etkili bir şekilde yapmak, L2'nin L1SLOAD veya REMOTESTATICCALL gibi opcode'ları desteklemesini gerektirebilir, ancak bu, L2 üzerindeki hesap soyutlama uygulamasının bu işlemleri desteklemesini de gerektirir.
Diğer yol haritası bölümleriyle nasıl etkileşimde bulunur?
Havuz listeleri, hesap soyutlama işlemlerini desteklemelidir. Pratikte, havuz listeleri için talepler, merkeziyetsiz bellek havuzlarının talepleriyle oldukça benzerdir, ancak havuz listeleri için esneklik biraz daha fazladır. Ayrıca, hesap soyutlama uygulaması L1 ve L2 arasında mümkün olduğunca koordinasyon sağlamalıdır. Gelecekte çoğu kullanıcının anahtar depolama Rollup'ı kullanmasını bekliyorsak, hesap soyutlama tasarımı buna dayanmalıdır.
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 evrimi yönü: EVM optimizasyonu, hesap soyutlama ve ücret mekanizması yeniliği
Ethereum protokolünün olası geleceği ( altı ): refah
Bazı şeyler tek bir kategoriye sokulması zor, Ethereum protokol tasarımında, birçok "detay" Ethereum'un başarısı için son derece ö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 "büyüme"nin anlamı budur.
Refah: Ana Hedef
EVM geliştirmesi
Hangi sorunu çözdü?
Mevcut EVM, statik analizi zorlaştırıyor, 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üşük, birçok ileri düzey kriptografi biçimini gerçekleştirmek zor, yalnızca önceden derlenmiş destek ile mümkün.
O nedir, nasıl çalışır?
Mevcut EVM iyileştirme yol haritasının ilk adımı EVM nesne formatı ( EOF ), bir sonraki sert çatalda dahil edilmesi planlanmaktadır. EOF, birçok benzersiz özelliğe sahip yeni bir EVM kodu sürümünü belirten bir dizi EIP'dir, en belirgin olanları şunlardır:
Eski sözleşmeler var olmaya ve oluşturulmaya devam edecek, ancak sonunda eski sözleşmelerin kademeli olarak terk edilmesi ve hatta EOF koduna ( zorunlu olarak dönüştürülmesi mümkün olabilir. Yeni sözleşmeler, EOF'un getirdiği verimlilik artışından faydalanacak - ilk olarak, alt rutin özellikleri sayesinde biraz küçülmüş olan byte kodu, ardından EOF'a ö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 işlemler için özel olarak tasarlanmış yeni bir işlem kümesi oluşturdu ve bunları diğer işlem kodlarıyla erişilemeyen yeni bir bellek alanına yerleştirdi, bu da Montgomery çarpması gibi optimizasyonların kullanılmasını mümkün kıldı.
Yeni bir fikir, EVM-MAX'ı tek talimat çoklu veri )SIMD( özelliği ile birleştirmektir. SIMD, Ethereum'un bir konsepti olarak uzun süredir var ve 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 performansa odaklı ölçeklemenin doğal bir eşleşmesini sağlıyor.
![Vitalik'in Ethereum'un Olası Geleceği Hakkında (Altı): The Splurge])https://img-cdn.gateio.im/webp-social/moments-e607936b4195e92945aa6ebd5f969276.webp(
Bir EIP kombinasyonunun genel tasarımı EIP-6690 ile başlayacak ve sonra:
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.
Kalan işler ve dengeler
Şu anda, EOF'un bir sonraki sert çatallamada 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, bunu yapmak büyük zorluklarla karşılaşacaktır. EOF'un kaldırılması, gelecekte EVM'ye yapılacak herhangi bir yükseltmenin 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 kodu ifade eder, statik kod incelemesi de görece karmaşıktır. Ancak, bunun karşılığında, yüksek seviyeli dilleri basitleştirebilir, EVM uygulamasını sadeleştirebilir ve diğer faydalar elde edebiliriz. Denilebilir ki, Ethereum L1'in sürekli iyileştirilmesine öncelik veren bir yol haritası EOF'un üzerine inşa edilmeli ve onu içermelidir.
Gerçekleştirilmesi gereken önemli bir iş, EVM-MAX ile SIMD benzeri bir işlevsellik sağlamaktır ve çeşitli kriptografik işlemlerin gas tüketimini kıyaslamaktır.
Yol haritasının diğer kısımlarıyla nasıl etkileşimde bulunabilirim?
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 oluşturabilir 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 getirir. Ayrıca, aynı görevleri yerine getirebilen EVM kodları ile daha fazla önceden derlenmiş programları değiştirmek daha kolay hale gelir ve bu da verimliliği büyük ölçüde etkilemeyebilir.
![Vitalik'in Ethereum'un olası geleceği üzerine (Altı): The Splurge])https://img-cdn.gateio.im/webp-social/moments-8930b556d169a2bc7168ddc2e611d3df.webp(
) 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 olmasına izin veriyordu. Bu, bir dizi uygulamanın etkinleştirilmesini sağlayabilir:
Özellik protokolünün, bir ara sunucu 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'ten beri 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 olan bir hesabın ERC20 ile gaz ödeyebilmesidir.
O nedir, nasıl çalışır?
Hesap soyutlamasının özü basittir: akıllı sözleşmelerin işlem başlatmasına izin vermek, yalnızca 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şı korunmaktan gelmektedir.
Tipik bir anahtar zorluk çoklu arıza sorunudur:
Eğer 1000 hesabın doğrulama fonksiyonu belirli bir tekil değere S 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 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öndermesine ve böylece ağ düğümlerinin kaynaklarını tıkamasına olanak tanır.
Yıllarca süren çabaların ardından, işlevselliği genişletme ve hizmet reddi ) DoS ( riskini sınırlama amacıyla, "ideal hesap soyutlaması"nı 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 sıkı bir gaz limiti uygulanmaktadır.
ERC-4337, Ethereum istemcisi geliştiricilerinin o sırada )Merge( üzerinde yoğunlaşması nedeniyle, başka işlevlerle ilgilenmek için ekstra bir enerjiye sahip olmadıklarından, ek bir protokol standardı olarak tasarlandı )ERC(. Bu yüzden ERC-4337, normal işlemler yerine kullanıcı işlemleri adı verilen nesneleri kullandı. Ancak, son zamanlarda protokolün en azından bir kısmını yazma ihtiyacını fark ettik.
İki ana neden aşağıdadır:
Ayrıca, ERC-4337 iki işlevi daha genişletmiştir:
Kalan işler ve dengeler
Ş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 soyutlama EIP'si EIP-7701'dir, bu öneri EOF'un üzerinde hesap soyutlamasını gerçekleştirmektedir. Bir hesap, doğrulama için ayrı bir kod kısmına sahip olabilir, eğer hesap bu kod kısmını ayarlarsa, 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 sıkı sınırlar koyarak başlarsak - dış duruma erişime izin verilmez, hatta başlangıçta belirlenen gaz limiti, kuantum dirençli veya gizlilik koruma uygulamaları için etkisiz olacak kadar düşükse - bu yaklaşımın güvenliği oldukça açıktır: ECDSA doğrulamasını, benzer süreye ihtiyaç duyan 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 aracı olmadan çalışmasına izin vermek ve kuantum direnci çok önemlidir. Bunun için, doğrulama adımlarının son derece sade olması gerekmeden, hizmet reddi (DoS) riskini daha esnek bir şekilde çözmenin yollarını bulmamız gerekiyor.
Ana değerlendirme, "daha az kişinin memnun olduğu 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. İdeal yaklaşım, bir tür karışık yöntem olabilir. Bir karışık 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 yaklaşım, L2 üzerinde daha iddialı bir hesap soyutlama sürümünü öncelikle dağıtmaktır. Ancak, bununla ilgili zorluk, L2 ekibinin benimseme önerisinin uygulanabilirliğine güven duyması gerektiğidir, özellikle de L1 ve/veya diğer L2'lerin gelecekte uyumlu çözümleri benimsemesini sağlamak için.
Ayrıca net bir şekilde düşünmemiz gereken bir başka uygulama, anahtar depolama hesaplarıdır; bu hesaplar L1 veya özel L2 üzerinde hesapla ilgili durumu depolar, ancak L1 ve herhangi bir uyumlu L2 üzerinde kullanılabilir. Bunu etkili bir şekilde yapmak, L2'nin L1SLOAD veya REMOTESTATICCALL gibi opcode'ları desteklemesini gerektirebilir, ancak bu, L2 üzerindeki hesap soyutlama uygulamasının bu işlemleri desteklemesini de gerektirir.
Diğer yol haritası bölümleriyle nasıl etkileşimde bulunur?
Havuz listeleri, hesap soyutlama işlemlerini desteklemelidir. Pratikte, havuz listeleri için talepler, merkeziyetsiz bellek havuzlarının talepleriyle oldukça benzerdir, ancak havuz listeleri için esneklik biraz daha fazladır. Ayrıca, hesap soyutlama uygulaması L1 ve L2 arasında mümkün olduğunca koordinasyon sağlamalıdır. Gelecekte çoğu kullanıcının anahtar depolama Rollup'ı kullanmasını bekliyorsak, hesap soyutlama tasarımı buna dayanmalıdır.
![Vitalik Ethereum'in olası geleceği hakkında（