Ethereum hesap soyutlama alanının geçmişi ve geleceği üzerine derinlemesine inceleme
Giriş
Bu makale iki ana bölümden oluşmaktadır:
Birinci bölüm, 2015 yılındaki ilk AA önerisinden yola çıkarak, şu ana kadar yapılan başlıca EIP önerilerinin içeriğini sistematik olarak incelemekte, AA tarihsel önerilerinin gelişim sürecini tartışmakta ve her bir öneriyi kapsamlı bir şekilde değerlendirmektedir.
İkinci bölüm, EIP4337'nin piyasada karşılaştığı tepkileri karşılaştırmaya odaklanmakta ve Ethereum'un bir sonraki sürüm yükseltmesine dahil edilecek EIP7702'yi derinlemesine analiz etmektedir. Bu öneri birleştirildiğinde, zincir üzerindeki uygulama biçimlerini tamamen değiştirecektir.
EIP-7702 devrim niteliğinde bir anlam taşıyor, gelin birlikte derinlemesine inceleyelim.
1. Hesap soyutlamanın arka planı
1.1 Hesap soyutlamanın anlamı
Ethereum kurucusu Vitalik, 2023'ün sonunda ETH geliştirme yol haritasını tekrar güncelledi, ancak hesap soyutlaması üzerindeki konum değişmedi. Mevcut ana akım model, EIP-4337'den bir sonraki aşamaya "gönüllü dönüşüm EOA hesapları" na geçiş yapıyor.
1.2 Hesap soyutlamanın pazar durumu
Bir buçuk yıl süren gelişim sonucunda, EIP4337'nin ana akım blok zincirlerindeki toplam adres sayısı yalnızca 12 milyon, bunlardan Ethereum ana ağındaki aktif adres sayısı ise yalnızca 6.764'tür ve EOA ile CA adres sayısından oldukça uzaktır. Ethereum ana ağındaki bağımsız adres sayısı 270 milyona ulaşmıştır, dolayısıyla EIP4337'nin ana ağda gelişimi yavaş ilerlemektedir.
Ancak bu, AA'nın öz değerini etkilemez. EIP4337'nin tasarımı, ana ağda iyi bir şekilde geriye dönük uyumluluk sağlamasını zorunlu kılar. Çeşitli L2 zincirlerinin yerel AA'yı genel olarak entegre etmesiyle, EIP4337'nin adres sayısı L2'de patlama yaşadı; örneğin, Base ve Polygon zincirlerinin Temmuz ayındaki aktif kullanıcı sayıları sırasıyla 1 milyon ve 3 milyon olarak kaydedildi, bu da oldukça başarılı bir performans sergiledi.
Bu nedenle, EIP4337'nin tasarımı bir hata değildir, birçok avantajı vardır. Mevcut durum, ana ağ ile L2 arasındaki farklardan kaynaklanmaktadır, bunların her biri kendine uygun çözümlere ihtiyaç duymaktadır.
EVM mimarisinde iki tür hesap tipi vardır: dış hesap ( EOA ) ve sözleşme hesabı ( CA ). Dış hesapta, mülkiyet ve imza yetkisi aynı varlık tarafından tutulur. Özel anahtara sahip olan kişi sadece hesabın "mülkiyeti"ne sahip olmakla kalmaz, aynı zamanda "tüm varlıkların transferini imzalama yetkisi"ne de sahiptir.
Bu, Ethereum hesaplarının işlem yapısının belirlediği bir durumdur. İşlem yapısından görülebileceği gibi, standart işlemin aslında From alanı yoktur. Fon transferi sırasında, belirli harcama adresi VRS parametresi ( yani kullanıcının imzası ) ile tersine çözümlenerek elde edilir.
EIP4337'nin temel etkisi, işlem alanına Gönderen Adresi ekleyerek özel anahtar ile işlem yapılan adresin ayrılmasını sağlamaktır.
Mülkiyet ayrımının bu kadar önemli olmasının nedeni, dış hesap (EOA) tasarımının birçok sorunu doğuracak olmasıdır:
Özel anahtarların korunması zordur: özel anahtarın kaybolması, tüm varlıkların kaybolması anlamına gelir.
İmza algoritması tek: Yerel protokol, işlemleri yalnızca ECDSA algoritması ile doğrulayabilir.
İmza yetkisi çok yüksek: Yerel çoklu imza işlevi yok, tek imza ile herhangi bir işlem gerçekleştirilebilir.
İşlem ücreti yalnızca ETH ile ödenebilir, toplu işlemler desteklenmemektedir.
İşlem gizliliği kolayca ifşa olabilir: bire bir işlemler hesap sahiplerinin bilgilerini analiz etmeyi kolaylaştırır.
Bu kısıtlamalar sıradan kullanıcıların Ethereum kullanmasını zorlaştırıyor:
Öncelikle, kullanıcıların Eter bulundurması ve fiyat dalgalanma riskini üstlenmesi gerekir.
İkincisi, kullanıcıların Gas fiyatı, Gas limiti, işlem tıkanması gibi karmaşık ücret mantığını işlemesi gerekiyor.
Son olarak, blok zinciri cüzdanları veya uygulamaları, kullanıcı deneyimini artırmak için ürün optimizasyonu yapmaya çalışıyor, ancak etkisi sınırlı.
Bu nedenle, çözüm hesap soyutlamasını gerçekleştirmek, mülkiyet (Owner) ve imza yetkisini (Signer) birbirinden ayırarak yukarıdaki sorunları kademeli olarak çözmektir.
Tarihte birçok plan vardı, en sonunda iki ana yola indirgendiler.
3. AA tarihsel öneri akışının düzenlenmesi
Sorunun çözümü birçok EIP önerisi gibi görünüyor, ancak temelde iki ana düşünce var. Her geçmeyen EIP'nin ele aldığı sorunlar, mevcut çözümlerin kırılma noktalarında toplanmıştır.
3.1 İlk yol: EOA adresini CA adresine dönüştürmek
2015 yılının Kasım ayında, Vitalik EIP-101'de hesaplar için yeni bir yapı olarak sözleşmeleri öne sürdü. Adresleri sadece kod ve depolama alanı olarak değiştirerek, ERC20 işlem ücretlerini destekledi, yerel token'ları ERC20 benzeri bakiye depolamak için önceden derlenmiş sözleşmeler aracılığıyla dönüştürdü ve işlem alanlarını to, startgas, data ve code ile sadeleştirdi.
Bu öneri, büyük bir sıçrama niteliğinde bir değişimdir ve temel tasarımı önemli ölçüde değiştirecektir, her hesap adresinin kendi "kod" mantığına sahip olmasını sağlayacaktır. (, EIP-7702'nin gerçekleştirmeyi amaçladığı etkidir ).
Aynı zamanda başka işlevler türetebilir, örneğin:
İşlemlerin daha fazla kripto algoritması kullanmasına izin verin, her adresin içindeki Kod tarafından imza doğrulama yönteminin belirlenmesine izin verin.
Kuantum saldırılarına karşı dayanıklılık özelliğine sahiptir, çünkü kod güncellenebilir.
Ether'in ERC20 sözleşmesi ile aynı işlevselliğe sahip olmasını sağlamak, örneğin otomatik yetkilendirme.
Hesabın özelleştirme alanını artırın, sosyal geri yükleme, SBT desteği, anahtar kurtarma vb. ile uyumlu.
Devam edilmemesinin nedeni, adımların çok büyük atılması ve mevcut işlem hash çakışma sorunları ile güvenlik riskleri konusunda dikkatsiz olunmasıdır; ancak her bir avantaj fikri, sonraki EIP4337 ve EIP7702'nin temel işlevlerinden biri haline gelmiştir.
Sonrasında bu mantığı geliştirmeye yönelik bir dizi EIP daha var:
EIP-859: ana zincir hesap soyutlama(2018-01-30)
Code'un dağıtım sorununu çözmeye çalışıyor. Temel işlevi, eğer işlem tarafının sözleşmesi dağıtılmamışsa, işlemle birlikte gelen code parametresini kullanarak sözleşme cüzdanı dağıtımı gerçekleştirmektir. Ayrıca, sadece gaz ödemekle kalmayıp, aynı zamanda işlem parametrelerindeki doğrulama ve yürütme kısımlarının ayırıcı olarak da işlev görecek yeni bir PAYGAS opcode'u önerilmiştir.
Her ne kadar o zaman başarılı olamamış olsa da, bu EIP7702'nin temel mantıklarından biri haline geldi. EIP7702'deki her işlem, özel işlem yapısıyla bir araya getirilerek, belirli bir kodun eklenmesine olanak tanır ve böylece EOA adresinin bu işlemde sözleşme yeteneğine sahip olmasını sağlar.
EIP-7702: EOA hesap kodu ayarlama (2024-05-07)
Bu, bu makalenin sonraki tartışmalarının merkezindeki EIP'dir ve Vitalik tarafından EIP-3074'ün alternatif çözümü olarak önerilmiştir. EIP-3074 kullanılmaktan kaldırıldı, EIP-7702 yakında gerçekleşecek olan ETH Prague/Electra(Pectra) hard fork'unda dahil edilecektir.
3.2 İkinci yol: EOA adresinin CA adresini sürmesi
EIP-3074: AUTH ve AUTHCALL opcode'lerini ekle (2020-10-15)
EVM'ye iki yeni OpCode eklenmiştir: AUTH ve AUTHCALL, böylece EOA bu iki opcode aracılığıyla sözleşmelere EOA kimliği yerine diğer sözleşmeleri çağırma yetkisi verebilir.
Özetle, EOA, imzalı mesajları ( işlemi ) kendisine güvenilen sözleşme ( olarak adlandırılan Invoker )'a gönderebilir, bu Invoker sözleşmesi AUTH ve AUTHCALL opcode'larını kullanarak EOA'nın gönderdiği işlemleri yerine getirebilir.
EIP-4337: Hesap soyutlamasını işlem bellek havuzunda gerçekleştirmek (2021-09-29)
MEV'den ilham alınarak tasarlandı, temel değeri konsensüs katmanı protokol değişikliklerinden tamamen kaçınmaktır.
EIP4337, UserOperation adlı yeni bir işlem nesnesi öneriyor. Kullanıcı bu nesneyi bellek havuzuna gönderiyor ve bundler'lar, madenci boyutundan toplu olarak sözleşme yürütme işlemlerini paketliyor. Esas olarak, temel işlemleri ve hesap işleyişini sözleşme katmanında yürütmeye taşıyor.
EIP-5189: Aracılar üzerinden soyut hesap işlemleri (2022-06-29)
Bu, EIP4337 mantığının optimizasyonudur; kötü niyetli Bundler'ın DoS engelleme saldırılarını önlemek için fon ceza destekleyici mekanizması oluşturarak yapılmıştır.
3.3 Diğer AA'yı destekleyen öneriler
EIP-2718: Yeni işlem türü için paketleme zarfı (2020-06-13)
Bu, gelecekte eklenen işlem türlerinin zarfı olarak yeni bir işlem türünü tanımlayan, zaten Final olan bir öneridir.
Sonuç olarak, yeni bir işlem türü getirildiğinde, işlem türlerini ayırt etmek için belirli bir kodlama kullanılır, sadece geriye dönük uyumluluk sağlanır, ileriye dönük uyumluluk gerekmez. En yaygın örnek EIP1559'dur; işlem ücretlerini ayırt eder, yeni işlem türü kodlaması kullanır ve başlangıçta kullanılan legacy işlem türlerini etkilemez.
EIP-3607: EOA adreslerinin sözleşme dağıtımına izin verilmemesi (2021-06-10)
Bu, sözleşme dağıtım adresi ile EOA adresinin çakışmasını önlemek için AA yolundaki ek bir plandır. Sözleşme oluşturma yöntemini kontrol edecek ve kodun zaten EOA adresi olan bir adrese dağıtılmasına izin vermeyecektir. Bu risk aslında çok küçüktür, Ethereum adresi 160 bit uzunluğundadır; belirli bir sözleşme adresinin özel anahtarını çarpışma ile elde etme yöntemi mevcut olsa da, Bitcoin'in toplam işlem gücüne yatırım yapılarak bunun gerçekleştirilmesi tahminen bir yıl alır.
3.4 Hesap soyutlama gelişim süreci nasıl anlaşılmalıdır?
Ancak, EIP-4337'nin temel dezavantajı insan doğası motivasyon ilkelerine aykırı olmasıdır.
Görünüşte daha iyi, ancak pazar gelişiminin bir kısır döngüsüne sıkışmış durumda: birçok Dapp hala uyumlu değil, kullanıcılar CA adresi kullanmak istemiyor, CA kullanmak ise daha yüksek işlem maliyetine neden oluyor ( normal transfer senaryolarında, işlem ücretleri iki katına çıkıyor ), Dapp'in kendisinin uyumluluğuna aşırı bağımlılık.
Bu yüzden Ethereum ana ağında henüz yaygınlaşmamıştır.
Maliyet, kullanıcıların en önemli ölçütüdür, maliyetlerin düşürülmesi gerekmektedir.
Ama gerçekten GAS'ı azaltmak istiyorsak, Ethereum'un kendisinin yumuşak bir hard fork güncellemesi yapması, GAS hesaplama veya opcode GAS tüketimi gibi modülleri değiştirmesi gerekiyor. Yumuşak bir hard fork yapılacaksa, doğrudan EIP-7702'yi düşünmek daha iyi.
4. EIP-7702'nin Kapsamlı Analizi
4.1 EIP-7702 nedir
Yeni işlem türü sayesinde EOA, tek bir işlemde akıllı sözleşme işlevselliğine geçici olarak sahip olmasını sağlıyor, toplu işlemlere, Gas'siz işlemlere ve özelleştirilmiş izin yönetimine destek veriyor ve yeni EVM opCode('i tanıtmadan geriye uyumluluğu etkilemeden).
Kullanıcıların akıllı sözleşme dağıtmasına gerek kalmadan, çoğu AA yeteneğini elde edebileceği ve hatta üçüncü tarafların kullanıcı adına işlem başlatma yeteneği sunabileceği, ayrıca kullanıcıdan özel anahtar talep edilmeden sadece imza yetkilendirme bilgisi gerektiği.
4.2 veri yapısı
Yeni bir işlem türü 0x04 tanımlayın, TransactionPayload aşağıdaki içeriğin RLP kodlama serileştirme sonucudur:
Önemli olan, imzacının EOA'sında yürütmek istediği kodu saklayan authorization_list nesnesinin eklenmiş olmasıdır. Kullanıcı, işlemi imzalarken yürütülecek sözleşme kodunu da imzalar; bu, iki boyutlu bir liste olarak bulunur ve birden fazla işlem bilgisini topluca saklayabilir, toplu işlemleri gerçekleştirebilir.
İşlem yürütme başladığında, her bir authorization_list için [chain_id, address, nonce, y_parity, r, s] demetini:
İmza r, s'den imzacı adresini geri almak için ecrecover kullanın.
Zincir ID('in fork'tan korunması için tekrar oynama) doğrulaması.
authority imzalayıcılarının kodunun boş olup olmadığını veya devredilip devredilmediğini doğrulayın.
authority imzalayıcısının nonce('ini doğrulayarak authority imzasının yeniden oynanmasını önleyin).
authority imza sahiplerinin kodunu 0xef0100 || address( EIP3607 çarpışma önleme stratejisini atlamak için ) olarak ayarlayın.
authority imzalayıcılarının nonce( yerel imza tekrarını önlemek için artırılması).
authority imzalayıcı hesabını erişilen adres listesine ekleyin ( sıcak adres, sorgulama depolama gaz ücretini azaltın ).
4.3.2 İşlem Aşaması
"Yeni" sürüm yalnızca kod dağıtım davranışını değiştirdi.
account_code'u contract_code olarak ayarlamaktan vazgeçildi, bunun yerine authorization_list'ten address ile belirtilen kodu alıp account_code olarak ayarlayın.
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
LiquidationWizard
· 07-25 01:53
Ne yapıyor bu 7702?
View OriginalReply0
GasWaster
· 07-24 18:03
aman Tanrım başka bir eip... geçen yıl başarısız tx'ler için 2eth harcadım ve şimdi bana bunu mu söylüyorlar?
View OriginalReply0
EntryPositionAnalyst
· 07-24 15:19
AA'nın popülaritesi birkaç gün içinde tekrar geldi.
View OriginalReply0
MetaMuskRat
· 07-22 06:03
Yine AA'dan bahsediyorlar, Blok Zinciri'nin eski şişede yeni şarap olduğu sanırım.
EIP-7702, Ethereum ekosistemini yeniden şekillendirecek. Hesap soyutlama yeni bir çağa giriyor.
Ethereum hesap soyutlama alanının geçmişi ve geleceği üzerine derinlemesine inceleme
Giriş
Bu makale iki ana bölümden oluşmaktadır:
Birinci bölüm, 2015 yılındaki ilk AA önerisinden yola çıkarak, şu ana kadar yapılan başlıca EIP önerilerinin içeriğini sistematik olarak incelemekte, AA tarihsel önerilerinin gelişim sürecini tartışmakta ve her bir öneriyi kapsamlı bir şekilde değerlendirmektedir.
İkinci bölüm, EIP4337'nin piyasada karşılaştığı tepkileri karşılaştırmaya odaklanmakta ve Ethereum'un bir sonraki sürüm yükseltmesine dahil edilecek EIP7702'yi derinlemesine analiz etmektedir. Bu öneri birleştirildiğinde, zincir üzerindeki uygulama biçimlerini tamamen değiştirecektir.
EIP-7702 devrim niteliğinde bir anlam taşıyor, gelin birlikte derinlemesine inceleyelim.
1. Hesap soyutlamanın arka planı
1.1 Hesap soyutlamanın anlamı
Ethereum kurucusu Vitalik, 2023'ün sonunda ETH geliştirme yol haritasını tekrar güncelledi, ancak hesap soyutlaması üzerindeki konum değişmedi. Mevcut ana akım model, EIP-4337'den bir sonraki aşamaya "gönüllü dönüşüm EOA hesapları" na geçiş yapıyor.
1.2 Hesap soyutlamanın pazar durumu
Bir buçuk yıl süren gelişim sonucunda, EIP4337'nin ana akım blok zincirlerindeki toplam adres sayısı yalnızca 12 milyon, bunlardan Ethereum ana ağındaki aktif adres sayısı ise yalnızca 6.764'tür ve EOA ile CA adres sayısından oldukça uzaktır. Ethereum ana ağındaki bağımsız adres sayısı 270 milyona ulaşmıştır, dolayısıyla EIP4337'nin ana ağda gelişimi yavaş ilerlemektedir.
Ancak bu, AA'nın öz değerini etkilemez. EIP4337'nin tasarımı, ana ağda iyi bir şekilde geriye dönük uyumluluk sağlamasını zorunlu kılar. Çeşitli L2 zincirlerinin yerel AA'yı genel olarak entegre etmesiyle, EIP4337'nin adres sayısı L2'de patlama yaşadı; örneğin, Base ve Polygon zincirlerinin Temmuz ayındaki aktif kullanıcı sayıları sırasıyla 1 milyon ve 3 milyon olarak kaydedildi, bu da oldukça başarılı bir performans sergiledi.
Bu nedenle, EIP4337'nin tasarımı bir hata değildir, birçok avantajı vardır. Mevcut durum, ana ağ ile L2 arasındaki farklardan kaynaklanmaktadır, bunların her biri kendine uygun çözümlere ihtiyaç duymaktadır.
2. Hesap soyutlama nedir?
Hesap soyutlama esasen mülkiyet ayrımını çözme meselesidir.
EVM mimarisinde iki tür hesap tipi vardır: dış hesap ( EOA ) ve sözleşme hesabı ( CA ). Dış hesapta, mülkiyet ve imza yetkisi aynı varlık tarafından tutulur. Özel anahtara sahip olan kişi sadece hesabın "mülkiyeti"ne sahip olmakla kalmaz, aynı zamanda "tüm varlıkların transferini imzalama yetkisi"ne de sahiptir.
Bu, Ethereum hesaplarının işlem yapısının belirlediği bir durumdur. İşlem yapısından görülebileceği gibi, standart işlemin aslında From alanı yoktur. Fon transferi sırasında, belirli harcama adresi VRS parametresi ( yani kullanıcının imzası ) ile tersine çözümlenerek elde edilir.
EIP4337'nin temel etkisi, işlem alanına Gönderen Adresi ekleyerek özel anahtar ile işlem yapılan adresin ayrılmasını sağlamaktır.
Mülkiyet ayrımının bu kadar önemli olmasının nedeni, dış hesap (EOA) tasarımının birçok sorunu doğuracak olmasıdır:
Özel anahtarların korunması zordur: özel anahtarın kaybolması, tüm varlıkların kaybolması anlamına gelir.
İmza algoritması tek: Yerel protokol, işlemleri yalnızca ECDSA algoritması ile doğrulayabilir.
İmza yetkisi çok yüksek: Yerel çoklu imza işlevi yok, tek imza ile herhangi bir işlem gerçekleştirilebilir.
İşlem ücreti yalnızca ETH ile ödenebilir, toplu işlemler desteklenmemektedir.
İşlem gizliliği kolayca ifşa olabilir: bire bir işlemler hesap sahiplerinin bilgilerini analiz etmeyi kolaylaştırır.
Bu kısıtlamalar sıradan kullanıcıların Ethereum kullanmasını zorlaştırıyor:
Öncelikle, kullanıcıların Eter bulundurması ve fiyat dalgalanma riskini üstlenmesi gerekir.
İkincisi, kullanıcıların Gas fiyatı, Gas limiti, işlem tıkanması gibi karmaşık ücret mantığını işlemesi gerekiyor.
Son olarak, blok zinciri cüzdanları veya uygulamaları, kullanıcı deneyimini artırmak için ürün optimizasyonu yapmaya çalışıyor, ancak etkisi sınırlı.
Bu nedenle, çözüm hesap soyutlamasını gerçekleştirmek, mülkiyet (Owner) ve imza yetkisini (Signer) birbirinden ayırarak yukarıdaki sorunları kademeli olarak çözmektir.
Tarihte birçok plan vardı, en sonunda iki ana yola indirgendiler.
3. AA tarihsel öneri akışının düzenlenmesi
Sorunun çözümü birçok EIP önerisi gibi görünüyor, ancak temelde iki ana düşünce var. Her geçmeyen EIP'nin ele aldığı sorunlar, mevcut çözümlerin kırılma noktalarında toplanmıştır.
3.1 İlk yol: EOA adresini CA adresine dönüştürmek
2015 yılının Kasım ayında, Vitalik EIP-101'de hesaplar için yeni bir yapı olarak sözleşmeleri öne sürdü. Adresleri sadece kod ve depolama alanı olarak değiştirerek, ERC20 işlem ücretlerini destekledi, yerel token'ları ERC20 benzeri bakiye depolamak için önceden derlenmiş sözleşmeler aracılığıyla dönüştürdü ve işlem alanlarını to, startgas, data ve code ile sadeleştirdi.
Bu öneri, büyük bir sıçrama niteliğinde bir değişimdir ve temel tasarımı önemli ölçüde değiştirecektir, her hesap adresinin kendi "kod" mantığına sahip olmasını sağlayacaktır. (, EIP-7702'nin gerçekleştirmeyi amaçladığı etkidir ).
Aynı zamanda başka işlevler türetebilir, örneğin:
İşlemlerin daha fazla kripto algoritması kullanmasına izin verin, her adresin içindeki Kod tarafından imza doğrulama yönteminin belirlenmesine izin verin.
Kuantum saldırılarına karşı dayanıklılık özelliğine sahiptir, çünkü kod güncellenebilir.
Ether'in ERC20 sözleşmesi ile aynı işlevselliğe sahip olmasını sağlamak, örneğin otomatik yetkilendirme.
Hesabın özelleştirme alanını artırın, sosyal geri yükleme, SBT desteği, anahtar kurtarma vb. ile uyumlu.
Devam edilmemesinin nedeni, adımların çok büyük atılması ve mevcut işlem hash çakışma sorunları ile güvenlik riskleri konusunda dikkatsiz olunmasıdır; ancak her bir avantaj fikri, sonraki EIP4337 ve EIP7702'nin temel işlevlerinden biri haline gelmiştir.
Sonrasında bu mantığı geliştirmeye yönelik bir dizi EIP daha var:
EIP-859: ana zincir hesap soyutlama(2018-01-30)
Code'un dağıtım sorununu çözmeye çalışıyor. Temel işlevi, eğer işlem tarafının sözleşmesi dağıtılmamışsa, işlemle birlikte gelen code parametresini kullanarak sözleşme cüzdanı dağıtımı gerçekleştirmektir. Ayrıca, sadece gaz ödemekle kalmayıp, aynı zamanda işlem parametrelerindeki doğrulama ve yürütme kısımlarının ayırıcı olarak da işlev görecek yeni bir PAYGAS opcode'u önerilmiştir.
Her ne kadar o zaman başarılı olamamış olsa da, bu EIP7702'nin temel mantıklarından biri haline geldi. EIP7702'deki her işlem, özel işlem yapısıyla bir araya getirilerek, belirli bir kodun eklenmesine olanak tanır ve böylece EOA adresinin bu işlemde sözleşme yeteneğine sahip olmasını sağlar.
EIP-7702: EOA hesap kodu ayarlama (2024-05-07)
Bu, bu makalenin sonraki tartışmalarının merkezindeki EIP'dir ve Vitalik tarafından EIP-3074'ün alternatif çözümü olarak önerilmiştir. EIP-3074 kullanılmaktan kaldırıldı, EIP-7702 yakında gerçekleşecek olan ETH Prague/Electra(Pectra) hard fork'unda dahil edilecektir.
3.2 İkinci yol: EOA adresinin CA adresini sürmesi
EIP-3074: AUTH ve AUTHCALL opcode'lerini ekle (2020-10-15)
EVM'ye iki yeni OpCode eklenmiştir: AUTH ve AUTHCALL, böylece EOA bu iki opcode aracılığıyla sözleşmelere EOA kimliği yerine diğer sözleşmeleri çağırma yetkisi verebilir.
Özetle, EOA, imzalı mesajları ( işlemi ) kendisine güvenilen sözleşme ( olarak adlandırılan Invoker )'a gönderebilir, bu Invoker sözleşmesi AUTH ve AUTHCALL opcode'larını kullanarak EOA'nın gönderdiği işlemleri yerine getirebilir.
EIP-4337: Hesap soyutlamasını işlem bellek havuzunda gerçekleştirmek (2021-09-29)
MEV'den ilham alınarak tasarlandı, temel değeri konsensüs katmanı protokol değişikliklerinden tamamen kaçınmaktır.
EIP4337, UserOperation adlı yeni bir işlem nesnesi öneriyor. Kullanıcı bu nesneyi bellek havuzuna gönderiyor ve bundler'lar, madenci boyutundan toplu olarak sözleşme yürütme işlemlerini paketliyor. Esas olarak, temel işlemleri ve hesap işleyişini sözleşme katmanında yürütmeye taşıyor.
EIP-5189: Aracılar üzerinden soyut hesap işlemleri (2022-06-29)
Bu, EIP4337 mantığının optimizasyonudur; kötü niyetli Bundler'ın DoS engelleme saldırılarını önlemek için fon ceza destekleyici mekanizması oluşturarak yapılmıştır.
3.3 Diğer AA'yı destekleyen öneriler
EIP-2718: Yeni işlem türü için paketleme zarfı (2020-06-13)
Bu, gelecekte eklenen işlem türlerinin zarfı olarak yeni bir işlem türünü tanımlayan, zaten Final olan bir öneridir.
Sonuç olarak, yeni bir işlem türü getirildiğinde, işlem türlerini ayırt etmek için belirli bir kodlama kullanılır, sadece geriye dönük uyumluluk sağlanır, ileriye dönük uyumluluk gerekmez. En yaygın örnek EIP1559'dur; işlem ücretlerini ayırt eder, yeni işlem türü kodlaması kullanır ve başlangıçta kullanılan legacy işlem türlerini etkilemez.
EIP-3607: EOA adreslerinin sözleşme dağıtımına izin verilmemesi (2021-06-10)
Bu, sözleşme dağıtım adresi ile EOA adresinin çakışmasını önlemek için AA yolundaki ek bir plandır. Sözleşme oluşturma yöntemini kontrol edecek ve kodun zaten EOA adresi olan bir adrese dağıtılmasına izin vermeyecektir. Bu risk aslında çok küçüktür, Ethereum adresi 160 bit uzunluğundadır; belirli bir sözleşme adresinin özel anahtarını çarpışma ile elde etme yöntemi mevcut olsa da, Bitcoin'in toplam işlem gücüne yatırım yapılarak bunun gerçekleştirilmesi tahminen bir yıl alır.
3.4 Hesap soyutlama gelişim süreci nasıl anlaşılmalıdır?
Öncelikle CA'ya dönüşümün değerini anlamak gerekir, temelde bu EIP-4337'nin pratik etkisidir:
Ancak, EIP-4337'nin temel dezavantajı insan doğası motivasyon ilkelerine aykırı olmasıdır.
Görünüşte daha iyi, ancak pazar gelişiminin bir kısır döngüsüne sıkışmış durumda: birçok Dapp hala uyumlu değil, kullanıcılar CA adresi kullanmak istemiyor, CA kullanmak ise daha yüksek işlem maliyetine neden oluyor ( normal transfer senaryolarında, işlem ücretleri iki katına çıkıyor ), Dapp'in kendisinin uyumluluğuna aşırı bağımlılık.
Bu yüzden Ethereum ana ağında henüz yaygınlaşmamıştır.
Maliyet, kullanıcıların en önemli ölçütüdür, maliyetlerin düşürülmesi gerekmektedir.
Ama gerçekten GAS'ı azaltmak istiyorsak, Ethereum'un kendisinin yumuşak bir hard fork güncellemesi yapması, GAS hesaplama veya opcode GAS tüketimi gibi modülleri değiştirmesi gerekiyor. Yumuşak bir hard fork yapılacaksa, doğrudan EIP-7702'yi düşünmek daha iyi.
4. EIP-7702'nin Kapsamlı Analizi
4.1 EIP-7702 nedir
Yeni işlem türü sayesinde EOA, tek bir işlemde akıllı sözleşme işlevselliğine geçici olarak sahip olmasını sağlıyor, toplu işlemlere, Gas'siz işlemlere ve özelleştirilmiş izin yönetimine destek veriyor ve yeni EVM opCode('i tanıtmadan geriye uyumluluğu etkilemeden).
Kullanıcıların akıllı sözleşme dağıtmasına gerek kalmadan, çoğu AA yeteneğini elde edebileceği ve hatta üçüncü tarafların kullanıcı adına işlem başlatma yeteneği sunabileceği, ayrıca kullanıcıdan özel anahtar talep edilmeden sadece imza yetkilendirme bilgisi gerektiği.
4.2 veri yapısı
Yeni bir işlem türü 0x04 tanımlayın, TransactionPayload aşağıdaki içeriğin RLP kodlama serileştirme sonucudur:
rlp([chain_id, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, destination, value, data, access_list, authorization_list, signature_y_parity, signature_r, signature_s])
Önemli olan, imzacının EOA'sında yürütmek istediği kodu saklayan authorization_list nesnesinin eklenmiş olmasıdır. Kullanıcı, işlemi imzalarken yürütülecek sözleşme kodunu da imzalar; bu, iki boyutlu bir liste olarak bulunur ve birden fazla işlem bilgisini topluca saklayabilir, toplu işlemleri gerçekleştirebilir.
authorization_list = [[chain_id, address, nonce, y_parity, r, s], ...]
4.3 işlem yaşam döngüsü
4.3.1 Doğrulama Aşaması
İşlem yürütme başladığında, her bir authorization_list için [chain_id, address, nonce, y_parity, r, s] demetini:
4.3.2 İşlem Aşaması
"Yeni" sürüm yalnızca kod dağıtım davranışını değiştirdi.
account_code'u contract_code olarak ayarlamaktan vazgeçildi, bunun yerine authorization_list'ten address ile belirtilen kodu alıp account_code olarak ayarlayın.
Yetki kodunu çalıştırırken, authorization_list'in address alanından belirtilen adres kodunu yükleyin ve imzalayan hesap bağlamında yürütün.
Bu, kullanıcı sözleşme kodunun zincir üzerinde belirli bir adreste saklandığı, doğrudan işlemde yer almadığı anlamına gelir.