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ş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 "son durum" haline getirmek
Hesap soyutlamasını protokole dahil ederek, tüm kullanıcıların daha güvenli ve kullanışlı bir hesap deneyimi yaşamalarını sağlamak
İşlem ücretlerini 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 iyileştirmesi
Hangi sorunu çözdü?
Mevcut EVM'nin statik analiz yapması zordur, bu da verimli uygulamalar oluşturmayı, resmi olarak kod doğrulamayı ve daha fazla genişletmeyi zorlaştırmaktadır. Ayrıca, EVM'nin verimliliği düşüktür ve birçok yüksek düzeyde kriptografi biçimini gerçekleştirmek zordur, ancak önceden derlenmiş açık 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), bir sonraki sert çatalla birlikte dahil edilmesi planlanıyor. EOF, birçok benzersiz özelliğe sahip yeni bir EVM kod versiyonunu belirten bir dizi EIP'dir, en dikkate değer olanı:
Kod ( yürütülebilir, ancak EVM'den ) ile veriler ( arasında ayrım yapamaz, ancak yürütülemez ) okunabilir.
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 nihayetinde eski sözleşmelerin ( kademeli olarak terk edilmesi ve hatta EOF koduna ) zorunlu olarak dönüştürülmesi mümkün. Yeni sözleşmeler, EOF'un getirdiği verimlilik artışından faydalanacak---ilk olarak alt rutin özelliği ile biraz küçültülmüş bytecode, ardından ise EOF'a özgü yeni işlevler veya azalan gaz maliyetleri.
EOF'un tanıtılmasının ardından, daha fazla yükseltme daha kolay hale geldi; şu anda en gelişmiş olanı EVM modülü aritmetik genişletme ( EVM-MAX ). EVM-MAX, mod alma işlemlerine özel yeni bir işlem seti oluşturdu ve bunu diğer işlem kodları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'ı tek komut çoklu 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 kriptografik biçimi 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şmesini sağlar.
Mevcut araştırma bağlantısı
EOF:
EVM-MAX:
SIMD:
Kalan işler ve denge
Şu anda, EOF'un bir sonraki hard fork'ta dahil edilmesi planlanıyor. Her ne kadar son anda kaldırılması her zaman mümkün olsa da --- önceki hard fork'larda bazı işlevler geçici olarak kaldırılmıştır, bu şekilde 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 geliyor, bu mümkün olsa da daha zor olabilir.
EVM'nin ana dengesi L1 karmaşıklığı ile altyapı karmaşıklığıdır, EOF, EVM uygulamasına eklenmesi gereken çok sayıda koddur, statik kod kontrolü de nispeten karmaşıktır. Ancak, bunun karşılığında, yüksek düzeydeki dilleri basitleştirebilir, EVM uygulamasını basitleştirebiliriz ve diğer faydalar elde edebiliriz. Denilebilir ki, Ethereum L1'in sürekli geliştirilmesine öncelik veren bir 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ı ve çeşitli kriptografik işlemlerin gas tüketiminin karşılaştırmalı testleridir.
Yol haritasının diğer bölümleriyle nasıl etkileşim kurulur?
L1, EVM'sini ayarlayarak L2'nin de ilgili ayarlamaları daha kolay yapabilmesini sağlar. Eğer her iki taraf senkronize bir şekilde ayarlama yapmazsa, uyumsuzluk oluşabilir 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. Bu, aynı görevleri yerine getirebilen EVM kodlarıyla daha fazla önceden derlenmiş kodun yerini almayı da kolaylaştırır; bu durum 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ı bunu aşmayı ve hesabın doğrulama mantığının herhangi bir EVM kodu olmasına izin vermeyi amaçlıyordu. Bu, bir dizi uygulamanın etkinleştirilmesini sağlayabilir:
Kuantum direnci kriptografiye geçiş
Eski anahtarların döndürülmesi ( yaygın olarak önerilen bir güvenlik uygulaması olarak kabul edilmektedir )
Çoklu imza cüzdanı ve sosyal geri yükleme 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 iletim olmaksızın ç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'te hesap soyutlaması önerildiğinden bu yana, hedefi "kolaylık hedefleri" dahil olmak üzere genişledi; örneğin, ETH'si olmayan ancak bazı ERC20'leri olan bir hesabın, gaz için ERC20 ile ödeme yapabilmesi.
MPC( çok taraflı hesaplama ), anahtarın birden fazla parçaya bölünüp birden fazla cihazda saklanması için kullanılan ve bu anahtar parçalarını doğrudan birleştirmeden imza oluşturmak için kriptografi teknolojisini kullanan 40 yıllık bir teknolojidir.
EIP-7702, bir sonraki sert çatalda tanıtılması planlanan bir öneridir. EIP-7702, tüm kullanıcıların ( dahil olmak üzere EOA kullanıcılarının ) yararına hesap soyutlama kolaylığı sağlama konusundaki artan farkındalığın bir sonucudur ve tüm kullanıcıların deneyimini kısa vadede iyileştirmek ve iki ekosisteme bölünmeyi önlemek amacıyla tasarlanmıştır.
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üzdeki EOA( dışarıdan sahip olunan hesapları, yani ECDSA imzası ile kontrol edilen hesapları ) içerir.
Bazı zorluklar ( özellikle "kolaylık" zorluğu ) çok taraflı hesaplama veya EIP-7702 gibi ilerici teknolojilerle çözülebilirken, hesap soyutlama önerisinin başlangıçta ortaya konan ana güvenlik hedefi, orijinal sorunu geri dönerek ve çözerek elde edilebilir: 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 uygulamaktır; bu bir zorluktur.
O nedir, nasıl çalışır?
Hesap soyutlamasının temeli basittir: 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şı önlem almaktan gelmektedir.
Tipik bir anahtar zorluk çoklu başarısızlık sorunudur:
Eğer 1000 hesap doğrulama fonksiyonu belirli bir tekil S değerine bağımlı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şlemlerin geçersiz olmasına neden olabilir. Bu, saldırganın bellek havuzuna çöp işlemler göndermesini sağlayarak ağ düğümlerinin kaynaklarını tıkamasına çok düşük bir maliyetle olanak tanır.
Yıllarca süren çabaların ardından, işlevselliği genişletmeyi ve hizmet reddi ( DoS ) riskini sınırlamayı amaçlayan bir çözüm olarak "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, 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 ç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ımlarına da katı bir gaz limiti zorunlu olarak uygulanır.
ERC-4337, Ethereum istemci geliştiricilerinin o dönemde Merge'ye odaklanması nedeniyle, ek bir protokol standardı olarak tasarlandı; bu nedenle başka işlevleri ele almak için ek bir enerji yoktu. Bu yüzden ERC-4337, normal işlemler yerine kullanıcı işlemleri adı verilen nesneleri kullandı. Ancak, son zamanlarda bunun en azından bir kısmını protokole yazma gereksinimimizi fark ettik.
İki ana neden aşağıdaki gibidir:
EntryPoint'in sözleşmenin doğuştan verimsizliği: Her paket yaklaşık 100.000 gazlık sabit bir maliyete ve her kullanıcı işlemi için ek binlerce gazlık bir maliyete sahiptir.
Ethereum özelliklerinin gerekliliğini sağlamak: İçerik listesinin oluşturduğu garantinin, hesap soyut kullanıcıya aktarılması gerektiğini içermesi.
Ayrıca, ERC-4337 iki işlevi daha genişletmiştir:
Ödeme Aracı ( Paymasters ): Bir hesabın başka bir hesabın ücretlerini ödemesine izin veren bir işlevdir, bu da doğrulama aşamasının yalnızca gönderen hesabın kendisine erişim kurması kuralını ihlal eder, 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.
Şu anda ana sorun, hesap soyutlamasını tamamen protokole nasıl entegre edeceğimizdir; son zamanlarda popüler olan yazma 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 olabilmesi mümkündür; eğer hesap bu kod parçasını ayarlamışsa, bu kod, o hesaptan gelen işlemlerin doğrulama aşamasında çalıştırılacaktır.
Bu yöntemin büyüleyici yanı, yerel hesap soyutlamasının iki eşdeğer bakış açısını net bir şekilde 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ütmedir.
Eğer doğrulama sürecinde yürütülebilir kod karmaşıklığı için katı sınırlar belirlemeye başlarsak - dış duruma erişime izin verilmez, hatta başlangıçta belirlenen gaz limiti kuantum dayanıklılığı veya gizlilik koruma uygulamaları için geçersiz olacak kadar düşükse - bu yaklaşımın güvenliği oldukça nettir: ECDSA doğrulamasını benzer bir zaman 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 aracı olmadan ç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 çözmenin yollarını bulmamız gerekiyor.
Ana ödünç verme, "daha az insanı memnun eden bir çözüm yazmak için hızlı olmak" ile "daha uzun süre beklemek, muhtemelen daha ideal bir çözüm elde etmek" arasında gibi görünüyor; ideal yöntem muhtemelen bir tür karışık yöntemdir. 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 yöntem ise L2 üzerinde daha iddialı bir hesap soyutlama versiyonunu önceki olarak dağıtmaktır. Ancak, bununla karşılaşılan zorluk, L2 ekibinin benimsenen önerinin uygulanmasına istekli olabilmesi için güven duyması gerektiğidir; özellikle L1 ve/veya diğer L2'lerin gelecekte uyumlu çözümleri benimsemesini sağlamak için.
Bir başka uygulama olarak net bir şekilde düşünmemiz gereken, L1 veya özel L2 üzerinde hesapla ilgili durumları depolayan anahtar depolama hesaplarıdır. Ancak bu hesaplar L1 ve her yerde kullanılabilir.
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 refah yol haritası: EVM yükseltmesi, hesap soyutlama ve EIP-1559 optimizasyonu
Ethereum protokolünün gelecekteki olasılıkları: 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ş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 iyileştirmesi
Hangi sorunu çözdü?
Mevcut EVM'nin statik analiz yapması zordur, bu da verimli uygulamalar oluşturmayı, resmi olarak kod doğrulamayı ve daha fazla genişletmeyi zorlaştırmaktadır. Ayrıca, EVM'nin verimliliği düşüktür ve birçok yüksek düzeyde kriptografi biçimini gerçekleştirmek zordur, ancak önceden derlenmiş açık 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), bir sonraki sert çatalla birlikte dahil edilmesi planlanıyor. EOF, birçok benzersiz özelliğe sahip yeni bir EVM kod versiyonunu belirten bir dizi EIP'dir, en dikkate değer olanı:
Eski sözleşmeler var olmaya ve oluşturulmaya devam edecek, ancak nihayetinde eski sözleşmelerin ( kademeli olarak terk edilmesi ve hatta EOF koduna ) zorunlu olarak dönüştürülmesi mümkün. Yeni sözleşmeler, EOF'un getirdiği verimlilik artışından faydalanacak---ilk olarak alt rutin özelliği ile biraz küçültülmüş bytecode, ardından ise EOF'a özgü yeni işlevler veya azalan gaz maliyetleri.
EOF'un tanıtılmasının ardından, daha fazla yükseltme daha kolay hale geldi; şu anda en gelişmiş olanı EVM modülü aritmetik genişletme ( EVM-MAX ). EVM-MAX, mod alma işlemlerine özel yeni bir işlem seti oluşturdu ve bunu diğer işlem kodları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'ı tek komut çoklu 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 kriptografik biçimi 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şmesini sağlar.
Mevcut araştırma bağlantısı
Kalan işler ve denge
Şu anda, EOF'un bir sonraki hard fork'ta dahil edilmesi planlanıyor. Her ne kadar son anda kaldırılması her zaman mümkün olsa da --- önceki hard fork'larda bazı işlevler geçici olarak kaldırılmıştır, bu şekilde 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 geliyor, bu mümkün olsa da daha zor olabilir.
EVM'nin ana dengesi L1 karmaşıklığı ile altyapı karmaşıklığıdır, EOF, EVM uygulamasına eklenmesi gereken çok sayıda koddur, statik kod kontrolü de nispeten karmaşıktır. Ancak, bunun karşılığında, yüksek düzeydeki dilleri basitleştirebilir, EVM uygulamasını basitleştirebiliriz ve diğer faydalar elde edebiliriz. Denilebilir ki, Ethereum L1'in sürekli geliştirilmesine öncelik veren bir 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ı ve çeşitli kriptografik işlemlerin gas tüketiminin karşılaştırmalı testleridir.
Yol haritasının diğer bölümleriyle nasıl etkileşim kurulur?
L1, EVM'sini ayarlayarak L2'nin de ilgili ayarlamaları daha kolay yapabilmesini sağlar. Eğer her iki taraf senkronize bir şekilde ayarlama yapmazsa, uyumsuzluk oluşabilir 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. Bu, aynı görevleri yerine getirebilen EVM kodlarıyla daha fazla önceden derlenmiş kodun yerini almayı da kolaylaştırır; bu durum 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ı bunu aşmayı ve hesabın doğrulama mantığının herhangi bir EVM kodu olmasına izin vermeyi amaçlıyordu. Bu, bir dizi uygulamanın etkinleştirilmesini sağlayabilir:
Gizlilik protokolünün, bir ara iletim olmaksızın ç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'te hesap soyutlaması önerildiğinden bu yana, hedefi "kolaylık hedefleri" dahil olmak üzere genişledi; örneğin, ETH'si olmayan ancak bazı ERC20'leri olan bir hesabın, gaz için ERC20 ile ödeme yapabilmesi.
MPC( çok taraflı hesaplama ), anahtarın birden fazla parçaya bölünüp birden fazla cihazda saklanması için kullanılan ve bu anahtar parçalarını doğrudan birleştirmeden imza oluşturmak için kriptografi teknolojisini kullanan 40 yıllık bir teknolojidir.
EIP-7702, bir sonraki sert çatalda tanıtılması planlanan bir öneridir. EIP-7702, tüm kullanıcıların ( dahil olmak üzere EOA kullanıcılarının ) yararına hesap soyutlama kolaylığı sağlama konusundaki artan farkındalığın bir sonucudur ve tüm kullanıcıların deneyimini kısa vadede iyileştirmek ve iki ekosisteme bölünmeyi önlemek amacıyla tasarlanmıştır.
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üzdeki EOA( dışarıdan sahip olunan hesapları, yani ECDSA imzası ile kontrol edilen hesapları ) içerir.
Bazı zorluklar ( özellikle "kolaylık" zorluğu ) çok taraflı hesaplama veya EIP-7702 gibi ilerici teknolojilerle çözülebilirken, hesap soyutlama önerisinin başlangıçta ortaya konan ana güvenlik hedefi, orijinal sorunu geri dönerek ve çözerek elde edilebilir: 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 uygulamaktır; bu bir zorluktur.
O nedir, nasıl çalışır?
Hesap soyutlamasının temeli basittir: 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şı önlem almaktan gelmektedir.
Tipik bir anahtar zorluk çoklu başarısızlık sorunudur:
Eğer 1000 hesap doğrulama fonksiyonu belirli bir tekil S değerine bağımlı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şlemlerin geçersiz olmasına neden olabilir. Bu, saldırganın bellek havuzuna çöp işlemler göndermesini sağlayarak ağ düğümlerinin kaynaklarını tıkamasına çok düşük bir maliyetle olanak tanır.
Yıllarca süren çabaların ardından, işlevselliği genişletmeyi ve hizmet reddi ( DoS ) riskini sınırlamayı amaçlayan bir çözüm olarak "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, 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 ç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ımlarına da katı bir gaz limiti zorunlu olarak uygulanır.
ERC-4337, Ethereum istemci geliştiricilerinin o dönemde Merge'ye odaklanması nedeniyle, ek bir protokol standardı olarak tasarlandı; bu nedenle başka işlevleri ele almak için ek bir enerji yoktu. Bu yüzden ERC-4337, normal işlemler yerine kullanıcı işlemleri adı verilen nesneleri kullandı. Ancak, son zamanlarda bunun en azından bir kısmını protokole yazma gereksinimimizi fark ettik.
İki ana neden aşağıdaki gibidir:
Ayrıca, ERC-4337 iki işlevi daha genişletmiştir:
(# Mevcut araştırma bağlantısı
(# Kalan işler ve denge
Şu anda ana sorun, hesap soyutlamasını tamamen protokole nasıl entegre edeceğimizdir; son zamanlarda popüler olan yazma 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 olabilmesi mümkündür; eğer hesap bu kod parçasını ayarlamışsa, bu kod, o hesaptan gelen işlemlerin doğrulama aşamasında çalıştırılacaktır.
Bu yöntemin büyüleyici yanı, yerel hesap soyutlamasının iki eşdeğer bakış açısını net bir şekilde göstermesidir:
Eğer doğrulama sürecinde yürütülebilir kod karmaşıklığı için katı sınırlar belirlemeye başlarsak - dış duruma erişime izin verilmez, hatta başlangıçta belirlenen gaz limiti kuantum dayanıklılığı veya gizlilik koruma uygulamaları için geçersiz olacak kadar düşükse - bu yaklaşımın güvenliği oldukça nettir: ECDSA doğrulamasını benzer bir zaman 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 aracı olmadan ç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 çözmenin yollarını bulmamız gerekiyor.
Ana ödünç verme, "daha az insanı memnun eden bir çözüm yazmak için hızlı olmak" ile "daha uzun süre beklemek, muhtemelen daha ideal bir çözüm elde etmek" arasında gibi görünüyor; ideal yöntem muhtemelen bir tür karışık yöntemdir. 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 yöntem ise L2 üzerinde daha iddialı bir hesap soyutlama versiyonunu önceki olarak dağıtmaktır. Ancak, bununla karşılaşılan zorluk, L2 ekibinin benimsenen önerinin uygulanmasına istekli olabilmesi için güven duyması gerektiğidir; özellikle L1 ve/veya diğer L2'lerin gelecekte uyumlu çözümleri benimsemesini sağlamak için.
Bir başka uygulama olarak net bir şekilde düşünmemiz gereken, L1 veya özel L2 üzerinde hesapla ilgili durumları depolayan anahtar depolama hesaplarıdır. Ancak bu hesaplar L1 ve her yerde kullanılabilir.