İlk bölüm, 2015'teki ilk hesap soyutlama teklifinden başlayarak, sistem bugüne kadar olan ana EIP tekliflerinin içeriğini gözden geçirdi, hesap soyutlama çözümlerinin tarihsel evrimini inceledi ve çeşitli çözümlerin avantajlarını ve dezavantajlarını değerlendirdi.
İkinci bölüm, EIP4337'nin piyasada soğuk bir tepkiyle karşılanmasının durumunu vurgulamakta ve Ethereum'un bir sonraki sürüm yükseltmesine dahil edilecek EIP7702'yi derinlemesine analiz etmektedir. Bu öneri birleştirildiğinde, zincir üzerindeki uygulamaların biçimini köklü bir şekilde değiştirecektir.
EIP-7702, devrim niteliğinde bir değişim olarak, içeriğini detaylı bir şekilde inceleyelim.
1. Hesap soyutlamanın arka planı
1.1 hesap soyutlamanın konumu
Ethereum kurucusu Vitalik, 2023 yılının sonunda ETH gelişim yol haritasını bir kez daha güncelledi, ancak hesap soyutlama ayarını değiştirmedi. Mevcut ana akım gelişim yolu, EIP-4337'den sonraki aşamaya gönüllü EOA dönüşümü (Voluntary EOA Conversion) ile girmektir.
1.2 hesap soyutlamanın piyasa durumu
Bir buçuk yıl süren gelişimden sonra, EIP4337'nin ana akım zincirlerdeki toplam adres sayısı yalnızca 12 milyon, bunlardan Ethereum ana ağındaki aktif adres sayısı ise sadece 6,764, EOA ve CA adresleriyle kıyaslandığında büyük bir fark var. Ethereum ana ağındaki bağımsız adres sayısı 270 milyon'a ulaşmış durumda, bu nedenle EIP4337'nin ana ağda neredeyse hiçbir somut gelişme kaydetmediği söylenebilir.
Ancak bu, AA'nın öz değerini etkilemiyor. EIP4337'nin tasarım amacı, ana ağın geriye dönük uyumluluk sorununu çözmektir, bu nedenle AA'yı yerel olarak destekleyen L2 zincirlerinde patlayıcı bir büyüme yaşandı. Örneğin, Temmuz ayında Base ve Polygon zincirlerinin aylık aktif kullanıcıları sırasıyla 1 milyon ve 3 milyon olarak ulaştı, bu da oldukça başarılı bir performans sergiledi.
Bu nedenle, EIP4337'nin tasarımı hatalı değil, birçok avantajı var. Mevcut durum esas olarak ana ağ ile L2 arasındaki farklardan kaynaklanıyor; her biri kendi uygun çözümünü benimsemelidir.
2. Hesap soyutlama nedir?
Hesap soyutlama esasen mülkiyet ayrımı sorununu çözmek içindir.
Ethereum sanal makinesi ( EVM ) mimarisinde iki tür hesap bulunmaktadır: dış hesap ( EOA ) ve sözleşme hesabı ( Contract Account ). Dış hesapta, mülkiyet ve imza yetkisi aslında aynı varlık tarafından tutulmaktadır. Özel anahtara sahip olan kişi, sadece hesabın "mülkiyetine" sahip olmakla kalmaz, aynı zamanda "tüm varlıkların transferini imzalama hakkına" da sahiptir.
Bu, Ethereum hesaplarının işlem yapısına bağlıdır. İşlem yapısından, Ethereum'un standart işleminin aslında From alanına sahip olmadığını görebiliriz. Peki, bir fon transferinin harcama adresi nasıl belirlenir? Aslında, bu VRS parametresi ( yani kullanıcının imzası ) ile geriye doğru From adresi türetilerek belirlenir.
Bu, ECDSA gibi asimetrik şifreleme ve tek yönlü eşik fonksiyonları gibi kavramları içerir, burada daha fazla ayrıntıya girmeyeceğim. Kısacası, bu mekanizma güvenliği sağlamak için kriptografi kullanmaktadır, ancak aynı zamanda mevcut EOA adres mülkiyet birleştirme sıkıntısına da yol açmıştır.
EIP4337'nin temel işlevi, işlem alanında Gönderen Adresi ekleyerek özel anahtar ile işlem gören adresin ayrılmasını sağlamaktır.
Mülkiyetin ayrılmasının bu kadar önemli olmasının nedeni, dış hesap (EOA) tasarımının daha fazla sorunu doğuracak olmasıdır:
Özel anahtarları korumak zordur: Kullanıcı özel anahtarını ( kaybederse, bir siber saldırıya uğrarsa veya kriptografi kırılırsa ), tüm varlıklarını kaybetmiş demektir.
Tek imza algoritması: Yerel protokol, işlemleri doğrularken yalnızca ECDSA imza ve doğrulama algoritmasını kullanabilir.
İmzalama yetkisi çok yüksek: Yerel çoklu imzayı desteklemiyor ( çoklu imza yalnızca akıllı sözleşmeler aracılığıyla gerçekleştirilebilir ), tek bir imza ile herhangi bir işlem gerçekleştirilebilir.
İşlem ücretleri yalnızca ETH ile ödenebilir, toplu işlemler desteklenmemektedir.
İşlem gizliliği ihlali: Tek bir işlem, hesap sahibinin gizli bilgilerini kolayca ifşa edebilir.
Bu kısıtlamalar sıradan kullanıcıların Ethereum'u kullanmasını zorlaştırıyor:
Öncelikle, Ethereum üzerindeki herhangi bir uygulamayı kullanmak için kullanıcıların Eter ( bulundurmaları ve fiyat dalgalanması riskini üstlenmeleri gerekmektedir ).
İkincisi, kullanıcıların karmaşık ücret mantığını işlemesi gerekiyor. Gas fiyatı, Gas limiti, işlem engeli (Nonce sırası ) gibi kavramlar kullanıcılar için çok karmaşık.
Sonunda, birçok blok zinciri cüzdanı veya uygulaması, ürün optimizasyonu ile kullanıcı deneyimini artırmaya çalışmasına rağmen, etkisi sınırlı kalmıştır.
Bu nedenle, çözüm, hesap soyutlamasını gerçekleştirmek, mülkiyet (Owner) ve imza yetkisini (Signer) ayrıştırmak (Decoupling) yoluyla yukarıda belirtilen sorunları aşamalı olarak çözmektir.
Tarih boyunca çeşitli öneriler sunulmuş, nihayetinde iki ana yol olarak özetlenmiştir.
3. AA tarihsel öneri bağlamının düzenlenmesi
Sorunun çözümü, birden fazla EIP önerisi gibi görünüyor, ancak sonuçta sadece iki temel yaklaşım var. Geçmişte kabul edilmeyen her EIP'de ele alınan sorunlar, mevcut çözümlerin dönüm noktalarını oluşturdu.
3.1 İlk yol: EOA adresini CA adresine dönüştürmek
15 Kasım 2015'te, EIP-101 etrafında, Vitalik hesaplar için yeni bir yapı olarak sözleşmeleri önerdi. Ana değişiklikler şunlardır:
Adresi sadece kod ve depolama alanı olarak değiştir
Ücret desteğini değiştir, ERC20 token'larının ödeme yapmasına izin ver
Yerel tokenleri ERC20 benzeri tokenlere dönüştürmek için önceden derlenmiş sözleşmeleri kullanarak, otomatik kesim yetkisi gibi işlevlere sahip.
İşlem alanlarını to, startgas, data ve code ile sadeleştir
Bu çözüm devrim niteliğinde bir değişim olarak nitelendirilebilir, temel tasarımı büyük ölçüde değiştirecek ve her hesap adresinin kendi "kod" mantığına sahip olmasını sağlayacaktır ( bu da şu anda EIP-7702'nin gerçekleştirmeyi amaçladığı etkidir ).
Bu, diğer işlevleri türetebilir, örneğin:
İşlemlerin daha fazla kriptografi algoritması kullanmasını sağlamak, her bir adresin iç Code'unun imza doğrulama ve kimlik doğrulama yöntemlerini belirlemesine olanak tanır.
Kuantum saldırılarına karşı dayanıklılık özelliklerine sahip, çünkü kod yükseltilebilir.
Ether'in ERC20 sözleşmesi ile aynı işlevsellik özelliklerine sahip olmasını sağlamak, temel etkisi otomatik kesim yetkisini gerçekleştirmek, yerel para birimini harcamadan.
Hesabın özelleştirme alanını artırma, sosyal geri yükleme, SBT desteği, anahtar geri alma gibi işlevlerle uyumlu.
Bu planın neden devam etmediği çok basit: adımlar çok büyük atıldı. O zamanki işlem hash çakışma sorunları ve güvenlik açıkları göz önünde bulundurulmadığı için sürekli ertelendi. Ancak, her bir avantajın fikri, sonraki EIP4337 ve EIP7702'nin temel işlevlerinden biri haline geldi.
Sonrasında bu mantığı geliştirmeyi amaçlayan bir dizi EIP daha bulunmaktadır:
EIP-859: ana zincir hesap soyutlama (2018-01-30)
Code'un dağıtım sorununu çözmeye çalışın. Temel işlevi şudur: Eğer işlem tarafı sözleşmesi dağıtılmamışsa, işlemle birlikte gelen code parametresini kullanarak sözleşme cüzdanını dağıtın. Ayrıca, gas ödemesinin yanı sıra işlem parametreleri içindeki doğrulama ve yürütme bölücüleri haline gelen yeni PAYGAS opcode'u da önerilmiştir.
O zaman başarılmasa da, bu şimdi EIP7702'nin temel mantıklarından biri haline geldi. EIP7702'nin her bir işlemi, özel işlem yapısı ile birlikte belirli bir kod eklenmesine izin verir, böylece bu işlemde EOA adresinin sözleşme yeteneklerine sahip olmasını sağlar.
EIP-7702: EOA hesap kodu (2024-05-07)
Bu, makalenin sonraki tartışmalarının ana EIP'sidir, Vitalik tarafından yayınlanmış, EIP-3074'ün alternatif çözümü olarak. Bu nedenle EIP-3074 terk edilmiştir, EIP-7702'nin önümüzdeki ETH Prag/Electra(Pectra) sert çatallama işlemiyle dahil edilmesi kararlaştırılmıştır, ayrıntılar aşağıda açıklanacaktır.
3.2 İkinci yol: EOA adresinin CA adresini sürdürmesine izin verin.
EIP-3074: AUTH ve AUTHCALL opcode'larını ekle (2020-10-15)
EVM'ye iki yeni opcode AUTH ve AUTHCALL eklenmiştir, böylece EOA bu iki opcode aracılığıyla sözleşmelere EOA'nın kimliğini temsil ederek diğer sözleşmeleri çağırma yetkisi verebilir.
Kısacası, bir EOA, kendisine güvenilen bir sözleşmeye ( imzalı bir mesaj ) gönderebilir. Bu sözleşmeye Invoker ( denir, bu Invoker sözleşmesi AUTH ve AUTHCALL opcode'larını kullanarak bu EOA'nın yerine işlem gönderebilir.
EIP-4337: İşlem havuzunu kullanarak hesap soyutlaması ) 2021-09-29 (
Bu öneri, MEV'den ilham alınarak tasarlanmıştır ve temel değeri, konsensüs katmanı protokolünde değişikliklerden tamamen kaçınmaktır.
EIP4337, kullanıcıların bu nesneyi bellek havuzuna göndermesi için yeni bir işlem nesnesi olan UserOperation'ı önerdi. Bundler'lar, madenci boyutundan toplu olarak işlem paketleyip sözleşme yürütme işlemlerini teslim eder. Özünde, temel işlemleri ve hesap işlemlerini sözleşme düzeyinde yürütmek için çekmektedir.
EIP-5189: Hesap soyutlama )2022-06-29( aracılığıyla onaylayıcılar tarafından işlenmesi
Bu, EIP4337 mantığının optimizasyonu olarak görülebilir; kötü niyetli Bundler'ın DoS engelleme saldırılarını önlemek için fon ceza belgeleme )endorser( mekanizması kurarak.
) 3.3 AA'yı desteklemek için diğer öneriler
EIP-2718: Yeni işlem türlerinin paketlenmesi zarfı ###2020-06-13(
Bu, gelecekte eklenen işlem türlerinin zarfı olarak yeni bir işlem türünü tanımlayan nihai bir öneridir.
Sonuç olarak, yeni bir işlem türü tanıtıldığında, farklı işlemleri ayırt etmek için belirli bir kodlama ile yalnızca geriye dönük uyumluluğa sahip olması sağlanır, ileriye dönük uyumluluğa gerek yoktur. En yaygın örnek EIP1559'dur; bu, işlemlerin ücretlerini ayırt eder, yeni bir işlem türü kodlaması kullanır ve başlangıçtaki legacy işlem türlerini etkilemez.
EIP-3607: EOA adreslerinin ) tarihinde sözleşme dağıtımını yasakla 2021-06-10(
Bu, AA yolundaki ek bir çözümdür ve sözleşme dağıtım adresinin EOA adresi ile çakışmasını önlemek için kullanılır. Sözleşme oluşturma yöntemini kontrol eder ve sistemin kodu zaten EOA adresi olan bir adrese dağıtmasına izin vermez. Bu risk aslında çok küçüktür, sonuçta Ethereum adresi 160 bit uzunluğundadır, özel anahtar ile belirli bir sözleşme adresinin özel anahtarını çarpıştırma yöntemi bulunsa da, Bitcoin ağı toplam hesaplama gücü ile tahmin edilirse, bunun için bir yıl daha gerekmektedir.
) 3.4 Hesap soyutlama gelişim süreci nasıl anlaşılmalıdır?
Öncelikle CA'ya dönüştürülen değeri anlamak gerekir.
Temelde EIP-4337'nin pratik etkisi budur, bu şunları gerçekleştirebilir:
Sosyal Kurtarma
gazsız işlem
Toplu işlem
Zaman bazlı kurallar
Çoklu İmza
Kural tabanlı ödeme
Ancak, EIP-4337'nin temel dezavantajı insan doğası motivasyon prensiplerine aykırı olmasıdır.
Görünüşte daha iyi, ancak bir piyasa gelişimi kısır döngüsüne sıkışmış durumda: birçok Dapp hâlâ uyumlu değil, bu da kullanıcıların CA adresini kullanmaya istekli olmamasına neden oluyor. Hatta CA kullanmak, daha yüksek işlem maliyetleri yaratabilir. ### Normal transfer senaryolarında, işlem ücretleri iki katına çıkabilir ( ve Dapp'in kendi uyumluluğuna aşırı bağımlıdır.
Bu nedenle, Ethereum ana ağında hala 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 kendisi üzerinde bir yumuşak çatal güncellemesi yapmak, GAS hesaplamasını veya opcode'ların GAS tüketimini değiştirmek gibi modülleri güncellemek zorundayız. Yumuşak çatal yapmayı düşünüyorsak, neden doğrudan EIP-7702'yi düşünmüyoruz?
![Ethereum hesap soyutlama alanının geçmişi ve geleceği üzerine derinlemesine inceleme])https://img-cdn.gateio.im/webp-social/moments-65d1ef9656425666ee30c38bbb63e769.webp(
4. EIP-7702'nin Kapsamlı Analizi
) 4.1 EIP-7702 nedir
Yeni işlem türleri aracılığıyla ayırır, EOA'nın tek bir işlemde akıllı sözleşme işlevselliğine geçici olarak sahip olmasına izin verir ve böylece iş açısından toplu işlemler, gazsız işlemler ve özelleştirilmiş yetki yönetimi gibi şeyleri destekler ve yeni bir EVM opcode ###'in geriye dönük uyumluluğu etkilemesine gerek kalmaz (.
Kullanıcıların akıllı sözleşme dağıtmadan AA'nın çoğu yeteneğini elde etmelerini sağlar, hatta üçüncü tarafların kullanıcı adına işlem başlatma yeteneğini sunabilir ve kullanıcıdan özel anahtar sağlamasını gerektirmez, yalnızca imza yetkilendirme bilgisi gereklidir.
) 4.2 veri yapısı
Yeni bir işlem türü 0x04'ü tanımlar, bu işlem türünün TransactionPayload'u aşağıdaki içeriğin RLP kodlanmış seri hali:
rlp###[
chain_id, // zincir ID'si, tekrar saldırılarını önlemek için
nonce, // işlem sayacı, işlemlerin benzersizliğini sağlamak
max_priority_fee_per_gas, // 1559 işlem ücreti
max_fee_per_gas, // 1559 işlem ücreti
gaz_sınırı,
hedef, // işlem hedef adresi
değer,
veri,
access_list, // erişim listesi, EIP-2929'daki Gaz optimizasyonu için kullanılır
yetki_listesi,
signature_y_parity, // 3 imza parametresi, işlem imzasını doğrulamak için
signature_r,
signature_s
](
Önemli olan, imzalayanların EOA'sında yürütmek istedikleri kodu saklayan authorization_list nesnesinin eklenmiş olmasıdır. Kullanıcı, işlem imzalarken yürütülecek sözleşme kodunu da imzalar; bu, iki boyutlu bir liste olarak mevcuttur ve kullanılabilir olduğunu belirtir.
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.
16 Likes
Reward
16
4
Share
Comment
0/400
FancyResearchLab
· 17h ago
Yine bir teorik PI tarafından ortaya atılan yeni bir gösteri. Su makalesi nerede?
View OriginalReply0
BrokenDAO
· 17h ago
Yine yenilik bayrağı altında tekrarlanan bir deney, herkes fazla iyimser olmasın... EIP-7702 büyük ihtimalle 4337'nin kaderini yeniden yaşayacak.
View OriginalReply0
LiquidityHunter
· 17h ago
4337? Veriler, benimseme oranının yalnızca %0,02 olduğunu gösteriyor... 7702 gerçek mal.
View OriginalReply0
rugged_again
· 18h ago
Vitalik Buterin bu sefer yine çok sağlam, gerçekten güzel.
Ethereum hesap soyutlamasının evrimi: EIP-4337'den EIP-7702'ye devrim niteliğindeki değişim
Ethereum Hesap Soyutlamasının Evrimi ve Geleceği
Giriş
Bu makale iki ana bölümden oluşmaktadır:
İlk bölüm, 2015'teki ilk hesap soyutlama teklifinden başlayarak, sistem bugüne kadar olan ana EIP tekliflerinin içeriğini gözden geçirdi, hesap soyutlama çözümlerinin tarihsel evrimini inceledi ve çeşitli çözümlerin avantajlarını ve dezavantajlarını değerlendirdi.
İkinci bölüm, EIP4337'nin piyasada soğuk bir tepkiyle karşılanmasının durumunu vurgulamakta ve Ethereum'un bir sonraki sürüm yükseltmesine dahil edilecek EIP7702'yi derinlemesine analiz etmektedir. Bu öneri birleştirildiğinde, zincir üzerindeki uygulamaların biçimini köklü bir şekilde değiştirecektir.
EIP-7702, devrim niteliğinde bir değişim olarak, içeriğini detaylı bir şekilde inceleyelim.
1. Hesap soyutlamanın arka planı
1.1 hesap soyutlamanın konumu
Ethereum kurucusu Vitalik, 2023 yılının sonunda ETH gelişim yol haritasını bir kez daha güncelledi, ancak hesap soyutlama ayarını değiştirmedi. Mevcut ana akım gelişim yolu, EIP-4337'den sonraki aşamaya gönüllü EOA dönüşümü (Voluntary EOA Conversion) ile girmektir.
1.2 hesap soyutlamanın piyasa durumu
Bir buçuk yıl süren gelişimden sonra, EIP4337'nin ana akım zincirlerdeki toplam adres sayısı yalnızca 12 milyon, bunlardan Ethereum ana ağındaki aktif adres sayısı ise sadece 6,764, EOA ve CA adresleriyle kıyaslandığında büyük bir fark var. Ethereum ana ağındaki bağımsız adres sayısı 270 milyon'a ulaşmış durumda, bu nedenle EIP4337'nin ana ağda neredeyse hiçbir somut gelişme kaydetmediği söylenebilir.
Ancak bu, AA'nın öz değerini etkilemiyor. EIP4337'nin tasarım amacı, ana ağın geriye dönük uyumluluk sorununu çözmektir, bu nedenle AA'yı yerel olarak destekleyen L2 zincirlerinde patlayıcı bir büyüme yaşandı. Örneğin, Temmuz ayında Base ve Polygon zincirlerinin aylık aktif kullanıcıları sırasıyla 1 milyon ve 3 milyon olarak ulaştı, bu da oldukça başarılı bir performans sergiledi.
Bu nedenle, EIP4337'nin tasarımı hatalı değil, birçok avantajı var. Mevcut durum esas olarak ana ağ ile L2 arasındaki farklardan kaynaklanıyor; her biri kendi uygun çözümünü benimsemelidir.
2. Hesap soyutlama nedir?
Hesap soyutlama esasen mülkiyet ayrımı sorununu çözmek içindir.
Ethereum sanal makinesi ( EVM ) mimarisinde iki tür hesap bulunmaktadır: dış hesap ( EOA ) ve sözleşme hesabı ( Contract Account ). Dış hesapta, mülkiyet ve imza yetkisi aslında aynı varlık tarafından tutulmaktadır. Özel anahtara sahip olan kişi, sadece hesabın "mülkiyetine" sahip olmakla kalmaz, aynı zamanda "tüm varlıkların transferini imzalama hakkına" da sahiptir.
Bu, Ethereum hesaplarının işlem yapısına bağlıdır. İşlem yapısından, Ethereum'un standart işleminin aslında From alanına sahip olmadığını görebiliriz. Peki, bir fon transferinin harcama adresi nasıl belirlenir? Aslında, bu VRS parametresi ( yani kullanıcının imzası ) ile geriye doğru From adresi türetilerek belirlenir.
Bu, ECDSA gibi asimetrik şifreleme ve tek yönlü eşik fonksiyonları gibi kavramları içerir, burada daha fazla ayrıntıya girmeyeceğim. Kısacası, bu mekanizma güvenliği sağlamak için kriptografi kullanmaktadır, ancak aynı zamanda mevcut EOA adres mülkiyet birleştirme sıkıntısına da yol açmıştır.
EIP4337'nin temel işlevi, işlem alanında Gönderen Adresi ekleyerek özel anahtar ile işlem gören adresin ayrılmasını sağlamaktır.
Mülkiyetin ayrılmasının bu kadar önemli olmasının nedeni, dış hesap (EOA) tasarımının daha fazla sorunu doğuracak olmasıdır:
Özel anahtarları korumak zordur: Kullanıcı özel anahtarını ( kaybederse, bir siber saldırıya uğrarsa veya kriptografi kırılırsa ), tüm varlıklarını kaybetmiş demektir.
Tek imza algoritması: Yerel protokol, işlemleri doğrularken yalnızca ECDSA imza ve doğrulama algoritmasını kullanabilir.
İmzalama yetkisi çok yüksek: Yerel çoklu imzayı desteklemiyor ( çoklu imza yalnızca akıllı sözleşmeler aracılığıyla gerçekleştirilebilir ), tek bir imza ile herhangi bir işlem gerçekleştirilebilir.
İşlem ücretleri yalnızca ETH ile ödenebilir, toplu işlemler desteklenmemektedir.
İşlem gizliliği ihlali: Tek bir işlem, hesap sahibinin gizli bilgilerini kolayca ifşa edebilir.
Bu kısıtlamalar sıradan kullanıcıların Ethereum'u kullanmasını zorlaştırıyor:
Öncelikle, Ethereum üzerindeki herhangi bir uygulamayı kullanmak için kullanıcıların Eter ( bulundurmaları ve fiyat dalgalanması riskini üstlenmeleri gerekmektedir ).
İkincisi, kullanıcıların karmaşık ücret mantığını işlemesi gerekiyor. Gas fiyatı, Gas limiti, işlem engeli (Nonce sırası ) gibi kavramlar kullanıcılar için çok karmaşık.
Sonunda, birçok blok zinciri cüzdanı veya uygulaması, ürün optimizasyonu ile kullanıcı deneyimini artırmaya çalışmasına rağmen, etkisi sınırlı kalmıştır.
Bu nedenle, çözüm, hesap soyutlamasını gerçekleştirmek, mülkiyet (Owner) ve imza yetkisini (Signer) ayrıştırmak (Decoupling) yoluyla yukarıda belirtilen sorunları aşamalı olarak çözmektir.
Tarih boyunca çeşitli öneriler sunulmuş, nihayetinde iki ana yol olarak özetlenmiştir.
3. AA tarihsel öneri bağlamının düzenlenmesi
Sorunun çözümü, birden fazla EIP önerisi gibi görünüyor, ancak sonuçta sadece iki temel yaklaşım var. Geçmişte kabul edilmeyen her EIP'de ele alınan sorunlar, mevcut çözümlerin dönüm noktalarını oluşturdu.
3.1 İlk yol: EOA adresini CA adresine dönüştürmek
15 Kasım 2015'te, EIP-101 etrafında, Vitalik hesaplar için yeni bir yapı olarak sözleşmeleri önerdi. Ana değişiklikler şunlardır:
Bu çözüm devrim niteliğinde bir değişim olarak nitelendirilebilir, temel tasarımı büyük ölçüde değiştirecek ve her hesap adresinin kendi "kod" mantığına sahip olmasını sağlayacaktır ( bu da şu anda EIP-7702'nin gerçekleştirmeyi amaçladığı etkidir ).
Bu, diğer işlevleri türetebilir, örneğin:
İşlemlerin daha fazla kriptografi algoritması kullanmasını sağlamak, her bir adresin iç Code'unun imza doğrulama ve kimlik doğrulama yöntemlerini belirlemesine olanak tanır.
Kuantum saldırılarına karşı dayanıklılık özelliklerine sahip, çünkü kod yükseltilebilir.
Ether'in ERC20 sözleşmesi ile aynı işlevsellik özelliklerine sahip olmasını sağlamak, temel etkisi otomatik kesim yetkisini gerçekleştirmek, yerel para birimini harcamadan.
Hesabın özelleştirme alanını artırma, sosyal geri yükleme, SBT desteği, anahtar geri alma gibi işlevlerle uyumlu.
Bu planın neden devam etmediği çok basit: adımlar çok büyük atıldı. O zamanki işlem hash çakışma sorunları ve güvenlik açıkları göz önünde bulundurulmadığı için sürekli ertelendi. Ancak, her bir avantajın fikri, sonraki EIP4337 ve EIP7702'nin temel işlevlerinden biri haline geldi.
Sonrasında bu mantığı geliştirmeyi amaçlayan bir dizi EIP daha bulunmaktadır:
EIP-859: ana zincir hesap soyutlama (2018-01-30)
Code'un dağıtım sorununu çözmeye çalışın. Temel işlevi şudur: Eğer işlem tarafı sözleşmesi dağıtılmamışsa, işlemle birlikte gelen code parametresini kullanarak sözleşme cüzdanını dağıtın. Ayrıca, gas ödemesinin yanı sıra işlem parametreleri içindeki doğrulama ve yürütme bölücüleri haline gelen yeni PAYGAS opcode'u da önerilmiştir.
O zaman başarılmasa da, bu şimdi EIP7702'nin temel mantıklarından biri haline geldi. EIP7702'nin her bir işlemi, özel işlem yapısı ile birlikte belirli bir kod eklenmesine izin verir, böylece bu işlemde EOA adresinin sözleşme yeteneklerine sahip olmasını sağlar.
EIP-7702: EOA hesap kodu (2024-05-07)
Bu, makalenin sonraki tartışmalarının ana EIP'sidir, Vitalik tarafından yayınlanmış, EIP-3074'ün alternatif çözümü olarak. Bu nedenle EIP-3074 terk edilmiştir, EIP-7702'nin önümüzdeki ETH Prag/Electra(Pectra) sert çatallama işlemiyle dahil edilmesi kararlaştırılmıştır, ayrıntılar aşağıda açıklanacaktır.
3.2 İkinci yol: EOA adresinin CA adresini sürdürmesine izin verin.
EIP-3074: AUTH ve AUTHCALL opcode'larını ekle (2020-10-15)
EVM'ye iki yeni opcode AUTH ve AUTHCALL eklenmiştir, böylece EOA bu iki opcode aracılığıyla sözleşmelere EOA'nın kimliğini temsil ederek diğer sözleşmeleri çağırma yetkisi verebilir.
Kısacası, bir EOA, kendisine güvenilen bir sözleşmeye ( imzalı bir mesaj ) gönderebilir. Bu sözleşmeye Invoker ( denir, bu Invoker sözleşmesi AUTH ve AUTHCALL opcode'larını kullanarak bu EOA'nın yerine işlem gönderebilir.
EIP-4337: İşlem havuzunu kullanarak hesap soyutlaması ) 2021-09-29 (
Bu öneri, MEV'den ilham alınarak tasarlanmıştır ve temel değeri, konsensüs katmanı protokolünde değişikliklerden tamamen kaçınmaktır.
EIP4337, kullanıcıların bu nesneyi bellek havuzuna göndermesi için yeni bir işlem nesnesi olan UserOperation'ı önerdi. Bundler'lar, madenci boyutundan toplu olarak işlem paketleyip sözleşme yürütme işlemlerini teslim eder. Özünde, temel işlemleri ve hesap işlemlerini sözleşme düzeyinde yürütmek için çekmektedir.
EIP-5189: Hesap soyutlama )2022-06-29( aracılığıyla onaylayıcılar tarafından işlenmesi
Bu, EIP4337 mantığının optimizasyonu olarak görülebilir; kötü niyetli Bundler'ın DoS engelleme saldırılarını önlemek için fon ceza belgeleme )endorser( mekanizması kurarak.
) 3.3 AA'yı desteklemek için diğer öneriler
EIP-2718: Yeni işlem türlerinin paketlenmesi zarfı ###2020-06-13(
Bu, gelecekte eklenen işlem türlerinin zarfı olarak yeni bir işlem türünü tanımlayan nihai bir öneridir.
Sonuç olarak, yeni bir işlem türü tanıtıldığında, farklı işlemleri ayırt etmek için belirli bir kodlama ile yalnızca geriye dönük uyumluluğa sahip olması sağlanır, ileriye dönük uyumluluğa gerek yoktur. En yaygın örnek EIP1559'dur; bu, işlemlerin ücretlerini ayırt eder, yeni bir işlem türü kodlaması kullanır ve başlangıçtaki legacy işlem türlerini etkilemez.
EIP-3607: EOA adreslerinin ) tarihinde sözleşme dağıtımını yasakla 2021-06-10(
Bu, AA yolundaki ek bir çözümdür ve sözleşme dağıtım adresinin EOA adresi ile çakışmasını önlemek için kullanılır. Sözleşme oluşturma yöntemini kontrol eder ve sistemin kodu zaten EOA adresi olan bir adrese dağıtmasına izin vermez. Bu risk aslında çok küçüktür, sonuçta Ethereum adresi 160 bit uzunluğundadır, özel anahtar ile belirli bir sözleşme adresinin özel anahtarını çarpıştırma yöntemi bulunsa da, Bitcoin ağı toplam hesaplama gücü ile tahmin edilirse, bunun için bir yıl daha gerekmektedir.
) 3.4 Hesap soyutlama gelişim süreci nasıl anlaşılmalıdır?
Öncelikle CA'ya dönüştürülen değeri anlamak gerekir.
Temelde EIP-4337'nin pratik etkisi budur, bu şunları gerçekleştirebilir:
Ancak, EIP-4337'nin temel dezavantajı insan doğası motivasyon prensiplerine aykırı olmasıdır.
Görünüşte daha iyi, ancak bir piyasa gelişimi kısır döngüsüne sıkışmış durumda: birçok Dapp hâlâ uyumlu değil, bu da kullanıcıların CA adresini kullanmaya istekli olmamasına neden oluyor. Hatta CA kullanmak, daha yüksek işlem maliyetleri yaratabilir. ### Normal transfer senaryolarında, işlem ücretleri iki katına çıkabilir ( ve Dapp'in kendi uyumluluğuna aşırı bağımlıdır.
Bu nedenle, Ethereum ana ağında hala 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 kendisi üzerinde bir yumuşak çatal güncellemesi yapmak, GAS hesaplamasını veya opcode'ların GAS tüketimini değiştirmek gibi modülleri güncellemek zorundayız. Yumuşak çatal yapmayı düşünüyorsak, neden doğrudan EIP-7702'yi düşünmüyoruz?
![Ethereum hesap soyutlama alanının geçmişi ve geleceği üzerine derinlemesine inceleme])https://img-cdn.gateio.im/webp-social/moments-65d1ef9656425666ee30c38bbb63e769.webp(
4. EIP-7702'nin Kapsamlı Analizi
) 4.1 EIP-7702 nedir
Yeni işlem türleri aracılığıyla ayırır, EOA'nın tek bir işlemde akıllı sözleşme işlevselliğine geçici olarak sahip olmasına izin verir ve böylece iş açısından toplu işlemler, gazsız işlemler ve özelleştirilmiş yetki yönetimi gibi şeyleri destekler ve yeni bir EVM opcode ###'in geriye dönük uyumluluğu etkilemesine gerek kalmaz (.
Kullanıcıların akıllı sözleşme dağıtmadan AA'nın çoğu yeteneğini elde etmelerini sağlar, hatta üçüncü tarafların kullanıcı adına işlem başlatma yeteneğini sunabilir ve kullanıcıdan özel anahtar sağlamasını gerektirmez, yalnızca imza yetkilendirme bilgisi gereklidir.
) 4.2 veri yapısı
Yeni bir işlem türü 0x04'ü tanımlar, bu işlem türünün TransactionPayload'u aşağıdaki içeriğin RLP kodlanmış seri hali:
rlp###[ chain_id, // zincir ID'si, tekrar saldırılarını önlemek için nonce, // işlem sayacı, işlemlerin benzersizliğini sağlamak max_priority_fee_per_gas, // 1559 işlem ücreti max_fee_per_gas, // 1559 işlem ücreti gaz_sınırı, hedef, // işlem hedef adresi değer, veri, access_list, // erişim listesi, EIP-2929'daki Gaz optimizasyonu için kullanılır yetki_listesi, signature_y_parity, // 3 imza parametresi, işlem imzasını doğrulamak için signature_r, signature_s ](
Önemli olan, imzalayanların EOA'sında yürütmek istedikleri kodu saklayan authorization_list nesnesinin eklenmiş olmasıdır. Kullanıcı, işlem imzalarken yürütülecek sözleşme kodunu da imzalar; bu, iki boyutlu bir liste olarak mevcuttur ve kullanılabilir olduğunu belirtir.