Ethereum protokol tasarımında birçok "detay" başarı için kritik öneme sahiptir. İçeriğin yaklaşık yarısı farklı türde EVM iyileştirmelerini içerirken, geri kalanı çeşitli niş konulardan oluşmaktadır, işte bu "refah" anlamına gelir.
Refah: Ana Hedef
EVM'yi yüksek performanslı ve kararlı "nihai 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şamasını sağlamak
İşlem ücretleri ekonomisini optimize etmek, ölçeklenebilirliği artırırken riski azaltmak
Gelişmiş kriptografi keşfederek, Ethereum'un uzun vadede önemli ölçüde iyileşmesini sağlamak
EVM geliştirmesi
Hangi sorunu çözdü?
Şu anda EVM'nin statik analiz yapılması zor, bu da etkili uygulamalar oluşturmayı, resmi doğrulama kodu yazmayı ve daha fazla genişlemeyi zorlaştırıyor. Ayrıca, EVM'nin verimliliği düşüktür, birçok ileri düzey kriptografinin gerçekleştirilmesi zordur, ancak önceden derlenmiş 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)'dir ve bunun bir sonraki sert çatalda dahil edilmesi planlanmaktadır. EOF, yeni EVM kodu sürümünü belirten ve birçok benzersiz özelliğe sahip bir dizi EIP'dir, en dikkat çekici olanı:
Kod ( çalıştırılabilir, ancak EVM'den ) okumak mümkün değil. Veriler ( okunabilir, ancak )'i çalıştırmak mümkün değil.
Dinamik yönlendirme yasaktır, yalnızca statik yönlendirmeye izin verilir
EVM kodu artık yakıtla ilgili bilgileri gözlemleyemez
Yeni açık örnek prosedürü mekanizması eklendi
Eski sözleşmeler var olmaya ve oluşturulmaya devam edecek, ancak nihayetinde aşamalı olarak terk edilmesi veya ('e zorla dönüştürülmesi mümkün. Yeni sözleşmeler, EOF'un getirdiği verimlilik artışından faydalanacak - öncelikle alt rutin özellikleri ile biraz küçülen byte kodu, ardından ise EOF'a özgü yeni işlevler veya azalan gaz maliyetleri.
EOF'un tanıtılmasının ardından, ek yükseltmeler 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 işlem kümesi oluşturdu ve bunları diğer işlem kodlarıyla erişilemeyecek yeni bir bellek alanına yerleştirdi, bu da Montgomery çarpımı gibi optimizasyonların kullanılmasını mümkün kıldı.
![Vitalik'in Ethereum'un Olası Geleceği Hakkında (Altı): The Splurge])https://img-cdn.gateio.im/webp-social/moments-e607936b4195e92945aa6ebd5f969276.webp(
Yeni bir fikir, EVM-MAX'ı tek komut çok veri ) SIMD( özelliği ile birleştirmektir. SIMD, Ethereum'un bir kavramı olarak uzun süredir mevcuttur 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 yönelik genişlemenin doğal bir eşleşmesini sağlar.
Gerçek uygulamada, bu paralel bir şekilde işlenecektir.
)# Kalan işler ve dengeler
Ş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ş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ı, gelecekte EVM üzerindeki 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 dengelemesi, L1 karmaşıklığı ile altyapı karmaşıklığı arasındadır, EOF, EVM uygulamasına eklenmesi gereken büyük miktarda koddur, statik kod incelemesi de nispeten karmaşıktır. Ancak, bunun karşılığında, üst düzey dilleri basitleştirebilir, EVM uygulamasını basitleştirebilir ve diğer faydalar elde edebiliriz. Denebilir ki, Ethereum L1'in sürekli iyileştirilmesi için öncelikli yol haritası EOF üzerine inşa edilmeli ve bunu içermelidir.
Yapılması gereken önemli bir iş, EVM-MAX ile SIMD benzeri işlevsellik sağlamak ve çeşitli kripto işlemlerinin gaz tüketimini kıyaslamaktır.
Harita ile diğer bölümlerle nasıl etkileşimde bulunulur?
L1, EVM'sini L2'nin de daha kolay uyum sağlaması için ayarlıyor. Eğer ikisi senkronize bir şekilde ayarlanmazsa, uyumsuzluk oluşabilir ve olumsuz etkiler doğurabilir. Ayrıca, EVM-MAX ve SIMD, birçok kanıt sistemi için gaz maliyetlerini düşürerek L2'nin daha verimli olmasını sağlıyor. Bu, aynı görevleri yerine getirebilen EVM kodları ile daha fazla önceden derlenmiş kodun yerini almayı kolaylaştırıyor ve verimliliği büyük ölçüde etkilemeyebilir.
![Vitalik'in Ethereum'un Olası Geleceği Hakkında (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 yöntemle doğrulanabilir: ECDSA imzası. Başlangıçta, hesap soyutlaması bunu aşmayı amaçlıyordu ve hesapların doğrulama mantığının herhangi bir EVM kodu olmasına izin veriyordu. Bu, bir dizi uygulamayı etkinleştirebilir:
Kuantum direnci şifrelemeye geçiş yap
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.
Aracısız çalışmasına izin veren gizlilik protokolleri, 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 beri hesap soyutlaması önerildiğinden beri, hedefi birçok "kolaylık hedefine" de genişledi, örneğin, ETH'si olmayan ancak bazı ERC20'leri olan bir hesabın ERC20 ile gaz ödeyebilmesidir.
MPC) çoklu taraf hesaplama (, anahtarları birden fazla parçaya bölmek ve bu parçaları birden fazla cihazda depolamak için kullanılan, 40 yıllık bir geçmişe sahip bir tekniktir. Bu, bu anahtar parçalarını doğrudan birleştirmeden imza oluşturmak için kriptografik teknikler kullanır.
EIP-7702, bir sonraki sert çatalda tanıtılması planlanan bir teklif olup, EIP-7702, tüm kullanıcılar ) dahil olmak üzere EOA kullanıcıları ( için hesap soyutlama kolaylığı sağlama konusundaki artan bir farkındalığın sonucudur. Amaç, kısa vadede tüm kullanıcıların deneyimini iyileştirmek ve iki ekosisteme bölünmeyi önlemektir.
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, buna bugünün EOA) dışarıdan sahip olunan hesapları, yani ECDSA imzası ile kontrol edilen hesaplar( dahildir.
Bazı zorluklar ), özellikle "rahatlık" zorluğu (, çok taraflı hesaplama veya EIP-7702 gibi ilerici teknolojilerle çözülebilir, ancak hesap soyutlama önerisinin başlangıçta ortaya konan ana güvenlik hedefi, akıllı sözleşme kodunun işlem doğrulamasını kontrol etmesine izin vermek için orijinal sorunu geriye dönük olarak ele almak suretiyle gerçekleştirilebilir. Şu ana kadar gerçekleştirilememesinin nedeni güvenli bir şekilde uygulamaktır, bu da bir zorluktur.
)# O nedir, nasıl çalışır?
Hesap soyutlamasının temeli basit: 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 kaynaklanıyor.
Tipik bir anahtar zorluk, çoklu arıza sorunudur:
Eğer 1000 hesabın doğrulama fonksiyonu belirli bir tekil S değerine bağımlıysa ve mevcut S değeri bellek havuzundaki tüm işlemlerin geçerli olmasını sağlıyorsa, o zaman S değerini tersine çeviren tek bir işlem bellek havuzundaki tüm diğer işlemlerin geçersiz olmasına neden olabilir. Bu, saldırganın bellek 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 hizmet reddi ### DoS ( risklerini sınırlamayı amaçlayan, nihayetinde "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 daha sonra işlenir. Bellek havuzunda, yalnızca kullanıcı işleminin doğrulama aşaması 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ı olabilir. Ayrıca, doğrulama adımına da katı bir gaz sınırlaması uygulanmaktadır.
![Vitalik'in Ethereum'un Olası Geleceği (6): The Splurge])https://img-cdn.gateio.im/webp-social/moments-ec1638a809393a6ed42724fb08f534da.webp(
ERC-4337, Ethereum istemcisi geliştiricilerinin o zamanlarda )Merge( üzerine yoğunlaşması nedeniyle, ek bir protokol standardı olarak tasarlanmıştır. Diğer işlevlerle ilgilenmek için ek bir enerjiye sahip değillerdi. Bu nedenle, ERC-4337, normal işlemlerin yerine kullanıcı işlemleri adı verilen nesneleri kullanmaktadır. Ancak, son zamanlarda 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 için yaklaşık 100.000 gazlık sabit bir maliyet ve her kullanıcı işlemi için ek olarak binlerce gaz.
Ethereum özelliklerinin gerekliliğini sağlamak: Listede belirtilen garantiye sahip olanların, hesap soyut kullanıcılarına transfer edilmesi gerekir.
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ının yalnızca gönderenin kendi hesabına erişim kurallarıyla çelişiyor; 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şlevsellik. Bu, Rollup üzerinde en yüksek veri verimliliğini sağlamak için gereklidir.
)# Kalan işler ve dengeler
Şu anda ana sorun, hesap soyutlamasını protokole tamamen nasıl entegre edeceğimizi çözmektir. Son zamanlarda popüler olan yazım protokolü hesap soyutlama EIP'si EIP-7701'dir, bu öneri EOF'un üzerinde hesap soyutlaması sağlar. Bir hesabın doğrulama için ayrı bir kod bölümüne sahip olması mümkündür; eğer hesap bu kod bölümünü ayarlarsa, o zaman bu kod, o hesaptan gelen işlemlerin doğrulama adımında yürütülecektir.
Bu yönteminin büyüleyici yanı, yerel hesap soyutlamasının iki eşdeğer bakış açısını 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ırı kuantum direnci veya gizlilik koruma uygulamaları için etkisiz olacak kadar düşükse - o zaman bu yöntemin güvenliği oldukça açıktır: ECDSA doğrulamasını, benzer süre gerektiren EVM kodu yürütmesiyle değiştirmekten ibarettir.
Ancak, zamanla bu sınırları gevşetmemiz gerekiyor, çünkü aracısız çalışan gizlilik koruma uygulamalarına izin vermek ve kuantum direnci çok önemlidir. Bunun için, doğrulama adımlarının son derece minimalist olmasını gerektirmeden, hizmet reddi (DoS) riskini daha esnek bir şekilde çözmenin yollarını bulmamız gerekiyor.
Ana denge, "daha az insanı memnun eden hızlı bir çözüm yazmak" ile "daha uzun süre beklemek, belki daha ideal bir çözüm elde etmek" arasında gibi görünüyor; ideal yaklaşım, bir tür karma yöntem olabilir. Karma bir 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ırmak olabilir. Diğer bir yaklaşım, önce L2 üzerinde daha iddialı bir hesap soyutlama versiyonunu dağıtmaktır. Ancak, bununla ilgili zorluk, L2 ekibinin benimsenen önerinin uygulanması konusunda kendine güven duyması gerektiğidir; özellikle L1 ve/veya diğer L2'lerin gelecekte uyumlu çözümleri benimsemesini sağlamak için.
![Vitalik'in Ethereum'un Olası Geleceği (6): The Splurge]###https://img-cdn.gateio.im/webp-social/moments-66bd22f0b53601d0976aa3a2b701c981.webp(
Bir başka dikkate almamız gereken uygulama, anahtar depolama hesaplarıdır. Bu hesaplar, L1 veya özel L2 üzerinde hesapla ilgili durumu depolar, ancak L1 ve uyumlu herhangi bir L2 üzerinde kullanılabilir. Bunu etkili bir şekilde yapmak, L2'nin L1SLOAD veya REMOTESTATICCALL gibi opcode'ları desteklemesini gerektirebilir, ancak bu aynı zamanda L2 üzerindeki hesap soyutlaması uygulamasının bu opcode'ları desteklemesini de gerektirir.
)# Diğer yol haritası bölümleriyle nasıl etkileşiyor?
İçerik listeleri, hesap soyutlama işlemlerini desteklemelidir. Pratikte, içerik listelerinin gereksinimleri, merkeziyetsiz bellek havuzunun gereksinimleri ile oldukça benzerdir, ancak içerik listeleri için esneklik biraz daha fazladır. Ayrıca, hesap soyutlama uygulaması, mümkün olduğunca L1 ve L2 arasında koordinasyon sağlamalıdır. Gelecekte, çoğu kullanıcının anahtar depolama Rollup kullanmasını bekliyorsak, hesap soyutlama tasarımı
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.
11 Likes
Reward
11
7
Share
Comment
0/400
UnluckyMiner
· 4h ago
hala evm boğa
View OriginalReply0
AirdropLicker
· 22h ago
Hoşça kal Pump Gas geldi
View OriginalReply0
ChainWanderingPoet
· 08-05 23:23
Ücretler yine optimize edilmeli, BTC bile yapılamıyor.
View OriginalReply0
LeverageAddict
· 08-03 22:13
shitcoin evm'ye koştu, Eter makineleri hala takılıyor.
Ethereum protokolü gelecekteki görünümü: EVM yükseltmeleri, hesap soyutlaması ve işlem ücreti optimizasyonu
Ethereum protokolünün olası geleceği(alt): refah
Ethereum protokol tasarımında birçok "detay" başarı için kritik öneme sahiptir. İçeriğin yaklaşık yarısı farklı türde EVM iyileştirmelerini içerirken, geri kalanı çeşitli niş konulardan oluşmaktadır, işte bu "refah" anlamına gelir.
Refah: Ana Hedef
EVM geliştirmesi
Hangi sorunu çözdü?
Şu anda EVM'nin statik analiz yapılması zor, bu da etkili uygulamalar oluşturmayı, resmi doğrulama kodu yazmayı ve daha fazla genişlemeyi zorlaştırıyor. Ayrıca, EVM'nin verimliliği düşüktür, birçok ileri düzey kriptografinin gerçekleştirilmesi zordur, ancak önceden derlenmiş 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)'dir ve bunun bir sonraki sert çatalda dahil edilmesi planlanmaktadır. EOF, yeni EVM kodu sürümünü belirten ve birçok benzersiz özelliğe sahip bir dizi EIP'dir, en dikkat çekici olanı:
Eski sözleşmeler var olmaya ve oluşturulmaya devam edecek, ancak nihayetinde aşamalı olarak terk edilmesi veya ('e zorla dönüştürülmesi mümkün. Yeni sözleşmeler, EOF'un getirdiği verimlilik artışından faydalanacak - öncelikle alt rutin özellikleri ile biraz küçülen byte kodu, ardından ise EOF'a özgü yeni işlevler veya azalan gaz maliyetleri.
EOF'un tanıtılmasının ardından, ek yükseltmeler 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 işlem kümesi oluşturdu ve bunları diğer işlem kodlarıyla erişilemeyecek yeni bir bellek alanına yerleştirdi, bu da Montgomery çarpımı gibi optimizasyonların kullanılmasını mümkün kıldı.
![Vitalik'in Ethereum'un Olası Geleceği Hakkında (Altı): The Splurge])https://img-cdn.gateio.im/webp-social/moments-e607936b4195e92945aa6ebd5f969276.webp(
Yeni bir fikir, EVM-MAX'ı tek komut çok veri ) SIMD( özelliği ile birleştirmektir. SIMD, Ethereum'un bir kavramı olarak uzun süredir mevcuttur 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 yönelik genişlemenin doğal bir eşleşmesini sağlar.
Gerçek uygulamada, bu paralel bir şekilde işlenecektir.
)# Kalan işler ve dengeler
Ş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ş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ı, gelecekte EVM üzerindeki 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 dengelemesi, L1 karmaşıklığı ile altyapı karmaşıklığı arasındadır, EOF, EVM uygulamasına eklenmesi gereken büyük miktarda koddur, statik kod incelemesi de nispeten karmaşıktır. Ancak, bunun karşılığında, üst düzey dilleri basitleştirebilir, EVM uygulamasını basitleştirebilir ve diğer faydalar elde edebiliriz. Denebilir ki, Ethereum L1'in sürekli iyileştirilmesi için öncelikli yol haritası EOF üzerine inşa edilmeli ve bunu içermelidir.
Yapılması gereken önemli bir iş, EVM-MAX ile SIMD benzeri işlevsellik sağlamak ve çeşitli kripto işlemlerinin gaz tüketimini kıyaslamaktır.
Harita ile diğer bölümlerle nasıl etkileşimde bulunulur?
L1, EVM'sini L2'nin de daha kolay uyum sağlaması için ayarlıyor. Eğer ikisi senkronize bir şekilde ayarlanmazsa, uyumsuzluk oluşabilir ve olumsuz etkiler doğurabilir. Ayrıca, EVM-MAX ve SIMD, birçok kanıt sistemi için gaz maliyetlerini düşürerek L2'nin daha verimli olmasını sağlıyor. Bu, aynı görevleri yerine getirebilen EVM kodları ile daha fazla önceden derlenmiş kodun yerini almayı kolaylaştırıyor ve verimliliği büyük ölçüde etkilemeyebilir.
![Vitalik'in Ethereum'un Olası Geleceği Hakkında (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 yöntemle doğrulanabilir: ECDSA imzası. Başlangıçta, hesap soyutlaması bunu aşmayı amaçlıyordu ve hesapların doğrulama mantığının herhangi bir EVM kodu olmasına izin veriyordu. Bu, bir dizi uygulamayı etkinleştirebilir:
Aracısız çalışmasına izin veren gizlilik protokolleri, 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 beri hesap soyutlaması önerildiğinden beri, hedefi birçok "kolaylık hedefine" de genişledi, örneğin, ETH'si olmayan ancak bazı ERC20'leri olan bir hesabın ERC20 ile gaz ödeyebilmesidir.
MPC) çoklu taraf hesaplama (, anahtarları birden fazla parçaya bölmek ve bu parçaları birden fazla cihazda depolamak için kullanılan, 40 yıllık bir geçmişe sahip bir tekniktir. Bu, bu anahtar parçalarını doğrudan birleştirmeden imza oluşturmak için kriptografik teknikler kullanır.
EIP-7702, bir sonraki sert çatalda tanıtılması planlanan bir teklif olup, EIP-7702, tüm kullanıcılar ) dahil olmak üzere EOA kullanıcıları ( için hesap soyutlama kolaylığı sağlama konusundaki artan bir farkındalığın sonucudur. Amaç, kısa vadede tüm kullanıcıların deneyimini iyileştirmek ve iki ekosisteme bölünmeyi önlemektir.
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, buna bugünün EOA) dışarıdan sahip olunan hesapları, yani ECDSA imzası ile kontrol edilen hesaplar( dahildir.
Bazı zorluklar ), özellikle "rahatlık" zorluğu (, çok taraflı hesaplama veya EIP-7702 gibi ilerici teknolojilerle çözülebilir, ancak hesap soyutlama önerisinin başlangıçta ortaya konan ana güvenlik hedefi, akıllı sözleşme kodunun işlem doğrulamasını kontrol etmesine izin vermek için orijinal sorunu geriye dönük olarak ele almak suretiyle gerçekleştirilebilir. Şu ana kadar gerçekleştirilememesinin nedeni güvenli bir şekilde uygulamaktır, bu da bir zorluktur.
)# O nedir, nasıl çalışır?
Hesap soyutlamasının temeli basit: 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 kaynaklanıyor.
Tipik bir anahtar zorluk, çoklu arıza sorunudur:
Eğer 1000 hesabın doğrulama fonksiyonu belirli bir tekil S değerine bağımlıysa ve mevcut S değeri bellek havuzundaki tüm işlemlerin geçerli olmasını sağlıyorsa, o zaman S değerini tersine çeviren tek bir işlem bellek havuzundaki tüm diğer işlemlerin geçersiz olmasına neden olabilir. Bu, saldırganın bellek 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 hizmet reddi ### DoS ( risklerini sınırlamayı amaçlayan, nihayetinde "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 daha sonra işlenir. Bellek havuzunda, yalnızca kullanıcı işleminin doğrulama aşaması 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ı olabilir. Ayrıca, doğrulama adımına da katı bir gaz sınırlaması uygulanmaktadır.
![Vitalik'in Ethereum'un Olası Geleceği (6): The Splurge])https://img-cdn.gateio.im/webp-social/moments-ec1638a809393a6ed42724fb08f534da.webp(
ERC-4337, Ethereum istemcisi geliştiricilerinin o zamanlarda )Merge( üzerine yoğunlaşması nedeniyle, ek bir protokol standardı olarak tasarlanmıştır. Diğer işlevlerle ilgilenmek için ek bir enerjiye sahip değillerdi. Bu nedenle, ERC-4337, normal işlemlerin yerine kullanıcı işlemleri adı verilen nesneleri kullanmaktadır. Ancak, son zamanlarda 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 işlevi daha genişletmiştir:
)# Kalan işler ve dengeler
Şu anda ana sorun, hesap soyutlamasını protokole tamamen nasıl entegre edeceğimizi çözmektir. Son zamanlarda popüler olan yazım protokolü hesap soyutlama EIP'si EIP-7701'dir, bu öneri EOF'un üzerinde hesap soyutlaması sağlar. Bir hesabın doğrulama için ayrı bir kod bölümüne sahip olması mümkündür; eğer hesap bu kod bölümünü ayarlarsa, o zaman bu kod, o hesaptan gelen işlemlerin doğrulama adımında yürütülecektir.
Bu yönteminin büyüleyici yanı, yerel hesap soyutlamasının iki eşdeğer bakış açısını 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ırı kuantum direnci veya gizlilik koruma uygulamaları için etkisiz olacak kadar düşükse - o zaman bu yöntemin güvenliği oldukça açıktır: ECDSA doğrulamasını, benzer süre gerektiren EVM kodu yürütmesiyle değiştirmekten ibarettir.
Ancak, zamanla bu sınırları gevşetmemiz gerekiyor, çünkü aracısız çalışan gizlilik koruma uygulamalarına izin vermek ve kuantum direnci çok önemlidir. Bunun için, doğrulama adımlarının son derece minimalist olmasını gerektirmeden, hizmet reddi (DoS) riskini daha esnek bir şekilde çözmenin yollarını bulmamız gerekiyor.
Ana denge, "daha az insanı memnun eden hızlı bir çözüm yazmak" ile "daha uzun süre beklemek, belki daha ideal bir çözüm elde etmek" arasında gibi görünüyor; ideal yaklaşım, bir tür karma yöntem olabilir. Karma bir 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ırmak olabilir. Diğer bir yaklaşım, önce L2 üzerinde daha iddialı bir hesap soyutlama versiyonunu dağıtmaktır. Ancak, bununla ilgili zorluk, L2 ekibinin benimsenen önerinin uygulanması konusunda kendine güven duyması gerektiğidir; özellikle L1 ve/veya diğer L2'lerin gelecekte uyumlu çözümleri benimsemesini sağlamak için.
![Vitalik'in Ethereum'un Olası Geleceği (6): The Splurge]###https://img-cdn.gateio.im/webp-social/moments-66bd22f0b53601d0976aa3a2b701c981.webp(
Bir başka dikkate almamız gereken uygulama, anahtar depolama hesaplarıdır. Bu hesaplar, L1 veya özel L2 üzerinde hesapla ilgili durumu depolar, ancak L1 ve uyumlu herhangi bir L2 üzerinde kullanılabilir. Bunu etkili bir şekilde yapmak, L2'nin L1SLOAD veya REMOTESTATICCALL gibi opcode'ları desteklemesini gerektirebilir, ancak bu aynı zamanda L2 üzerindeki hesap soyutlaması uygulamasının bu opcode'ları desteklemesini de gerektirir.
)# Diğer yol haritası bölümleriyle nasıl etkileşiyor?
İçerik listeleri, hesap soyutlama işlemlerini desteklemelidir. Pratikte, içerik listelerinin gereksinimleri, merkeziyetsiz bellek havuzunun gereksinimleri ile oldukça benzerdir, ancak içerik listeleri için esneklik biraz daha fazladır. Ayrıca, hesap soyutlama uygulaması, mümkün olduğunca L1 ve L2 arasında koordinasyon sağlamalıdır. Gelecekte, çoğu kullanıcının anahtar depolama Rollup kullanmasını bekliyorsak, hesap soyutlama tasarımı