Derinlik analiz Ethereum hesap soyutlamanın tarihsel evrimi ve gelecek perspektifi
Giriş
Bu makale, Ethereum hesap soyutlaması (AA)'ın gelişim sürecini iki ana açıdan inceleyecektir:
Öncelikle, 2015'teki ilk AA önerisinden bu yana tarihsel bağlamı geriye dönük olarak inceleyeceğiz, bugüne kadar yapılan çeşitli EIP önerilerinin ana içeriklerini sistematik olarak gözden geçireceğiz, AA önerisinin evrim sürecini derinlemesine keşfedeceğiz ve her bir önerinin avantaj ve dezavantajlarını kapsamlı bir şekilde değerlendireceğiz.
İkincisi, EIP4337'nin piyasada düşük tepkilere neden olmasının sebeplerini analiz edeceğiz ve Ethereum'un gelecekteki sürüm güncellemelerine dahil edilecek EIP7702'yi derinlemesine inceleyeceğiz. Bu öneri birleştirildiğinde, zincir üzerindeki uygulamaların şeklini temelden değiştirecektir.
EIP-7702, devrim niteliğinde bir değişim olarak kabul edilebilir, gelin birlikte içindeki sırları derinlemesine inceleyelim.
1. Hesap soyutlamanın arka planı
1.1 hesap soyutlamanın anlamı
Ethereum kurucusu yakın zamanda ETH gelişim yol haritasını güncelledi, ancak hesap soyutlama ile ilgili ayarlar değişmedi. Mevcut ana akım model EIP-4337'den, bir sonraki aşama olan "isteğe bağlı dönüşüm EOA hesapları" na geçiş yapıyor.
EIP4337'nin piyasaya sürülmesinin üzerinden bir yıl geçmiş olmasına rağmen, piyasa tepkisi oldukça çelişkili - kullanıcılar genel olarak değerini kabul ediyor, ancak gerçek kullanım oranı düşük. Bu durumda, EIP-7702'nin ilerlemesi büyük ölçüde hızlandı ve bir sonraki güncellemede birleştirileceği kesinleşti.
1.2 Hesap soyutlamanın pazar durumu
Bir buçuk yıl gelişimin ardından, EIP4337'nin ana akım halka açık blok zincirlerindeki adres sayısı sadece 12 milyon, bunların arasında Ethereum ana ağındaki aktif adres sayısı ise yalnızca 6,764'tür; bu da EOA ve CA adres sayılarından oldukça uzaktır. Ethereum ana ağındaki bağımsız adres sayısı 270 milyona ulaşmış durumda, bu da EIP4337'nin ana ağda neredeyse hiçbir somut ilerleme kaydedemediğini göstermektedir.
Ancak bu, AA'nın temel değerinin etkilendiği anlamına gelmez. EIP4337'nin tasarımı, ana ağın geriye dönük uyumluluk sorununu iyi bir şekilde çözmesini zorlaştırıyordu. Çeşitli L2 zincirleri yerel AA'yı yaygın bir şekilde entegre ettikçe, EIP4337'nin adres sayısı L2'de patlama büyümesi yaşadı; bunlar arasında Base ve Polygon zincirlerinin Temmuz ayındaki aylık aktif kullanıcıları sırasıyla 1 milyon ve 3 milyon olarak oldukça dikkate değer.
Bu nedenle, sorun EIP4337'nin tasarımında değil, ana ağ ile L2 arasındaki farklılıklardan kaynaklanmaktadır; her biri için uygun çözümlere ihtiyaç vardır.
Ethereum sanal makinesi ( EVM ) mimarisinde iki tür hesap türü vardır: harici hesap ( EOA ) ve sözleşme hesabı ( Contract Account ). EOA'da, hesabın sahipliği ve imza yetkisi aynı varlık tarafından tutulur. Özel anahtara sahip olan kişi yalnızca hesabın "sahipliğine" sahip olmakla kalmaz, aynı zamanda "tüm varlıkların transferini imzalama yetkisine" de sahiptir.
Bu özellik, Ethereum hesap işlem yapısının belirlenmesinden kaynaklanmaktadır. Ethereum'un standart işlem yapısında aslında From alanı yoktur. İşlem başlatıcısının adresi, VRS parametresi ( yani kullanıcının imzası ) ile tersine çözülerek elde edilir.
Bu tasarım, kriptografi ile güvenliği sağlasa da, mevcut EOA adres mülkiyetinin birleştirilmesi sorununa yol açmaktadır.
EIP4337'nin temel etkisi, işlem alanında 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, EOA tasarımının birçok sorunu doğurmasıdır:
Özel anahtarın korunması zordur: özel anahtarın kaybolması tüm varlıkların kaybedilmesi anlamına gelir.
İmza algoritması tek: Yerel protokol yalnızca ECDSA imza ve doğrulama algoritmasını destekler.
İmza izinleri çok yüksek: Yerel çoklu imza desteği 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'u kullanmasını zorlaştırıyor:
Öncelikle, kullanıcıların Ethereum üzerindeki uygulamaları kullanabilmesi için Eter ('e sahip olmaları ve fiyat dalgalanması riskini almaları gerekmektedir.
İkincisi, kullanıcıların Gas price, Gas limit, işlem engelleme )Nonce sırası ( gibi karmaşık ücret mantıklarıyla başa çıkması gerekiyor, bu kavramlar kullanıcılar için aşırı karmaşık.
Son olarak, birçok blok zinciri cüzdanı veya uygulaması kullanıcı deneyimini artırmak için ürün optimizasyonu yapmaya çalışsa da, etkisi sınırlıdır.
Bu nedenle, zorlukların üstesinden gelmenin anahtarı hesap soyutlamasını gerçekleştirmek, sahipliği )Owner( ve imzalama yetkisini )Signer( birbirinden ayırmak ve böylece yukarıda belirtilen sorunları aşamalı olarak çözmektir.
Tarih boyunca çeşitli önerilerde bulunulmuştur, nihayetinde iki ana yolda birleşmiştir.
3. Hesap Soyutlama Tarihsel Teklifler Bağlamının Düzenlenmesi
Sorunun çözümünün birden fazla EIP önerisi olduğu görünse de, aslında iki ana fikir vardır. Geçmemiş her EIP'de ele alınan sorun, nihayetinde mevcut çözümlerin dönüm noktalarında toplanmıştır.
) 3.1 Birinci Rotası: 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ıyı sözleşmeler olarak önerdi. Bu öneri, adreslerin yalnızca kod ve depolama alanı içermesini, ERC20 tokenları ile işlem ücretlerinin ödenmesini desteklemeyi, önceden derlenmiş sözleşmeler aracılığıyla yerel tokenlerin ERC20 benzeri tokenlere dönüştürülmesini ### otomatik kesim yetkisi gibi işlevler ( eklemeyi ve işlem alanlarını yalnızca to, startgas, data ve code içerecek şekilde basitleştirmeyi öneriyordu.
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ğlayacak ) bu, mevcut EIP-7702'nin gerçekleştirmeyi hedeflediği etki (.
Diğer işlevleri türetebilir, örneğin:
Daha fazla kripto algoritması kullanarak işlem destekleyin, her adresin içindeki Kodu imza doğrulama yöntemi olarak belirler.
Kuantum saldırılarına karşı dayanıklılık özelliğine sahiptir, çünkü kod güncellenebilir.
Ether ile ERC20 sözleşmesiyle aynı işlevsellik özelliklerini sağlamak, yetkilendirme için kesinti yapmak, yerel parayı tüketmeye gerek yoktur.
Hesabın özelleştirme alanını artırın, sosyal kurtarma, SBT, anahtar kurtarma gibi işlevleri destekleyin.
Bu planın devam etmemesinin nedeni çok basit: adımlar çok büyük atıldı, o zamanki işlem hash çakışma sorunu ve güvenlik riskleri yeterince dikkate alınmadı, bu yüzden sürekli olarak ertelendi. Ancak, içindeki her bir avantaj fikri, sonraki EIP4337 ve EIP7702'nin temel işlevlerinden biri haline geldi.
Bundan sonra bu mantığı geliştirmeye çalışan bir dizi EIP oldu:
EIP-859: ana zincir hesap soyutlama )2018-01-30(
Bu öneri, Code'un dağıtım sorununu çözmeyi amaçlamaktadır. Temel işlevi, işlem tarafı sözleşmesi dağıtılmadığında, işlemle birlikte gelen code parametresini kullanarak sözleşme cüzdanının dağıtımını gerçekleştirmektir. Ayrıca, işlem parametrelerindeki doğrulama ve yürütme kısımlarını ayıran yeni bir PAYGAS opcode'u önerilmiştir; bu, gaz ödemesinin yanı sıra kullanılacaktır.
O zamanlar gerçekleştirilememiş olsa da, bu düşünce günümüzde EIP7702'nin temel mantıklarından biri haline geldi. EIP7702'deki her işlem, özel bir işlem yapısı ile birlikte belirli bir kodu içerebilir, böylece EOA adresi bu işlemde sözleşme yeteneğine sahip olabilir.
EIP-7702: EOA hesap kodunu ayarla )2024-05-07(
Bu, bu makalenin sonraki tartışmalarının merkezindeki EIP'dir, Vitalik tarafından önerilmiştir ve EIP-3074'ün alternatifidir. Bu nedenle EIP-3074 terk edilmiştir, EIP-7702'nin yaklaşan ETH Prag/Electra)Pectra( sert çatalında dahil edilmesi belirlenmiştir, detayları daha sonraki bölümlerde ayrıntılı olarak ele alacağız.
) 3.2 İkinci Yol: EOA adresinin CA adresini sürdürmesine izin verin
EIP-3074: AUTH ve AUTHCALL opcode'larını ekleyin ###2020-10-15(
Bu öneri, EVM'ye EOA'nın bu iki opcode ile sözleşmelere EOA kimliğini kullanmadan diğer sözleşmeleri çağırmasına izin vermek için AUTH ve AUTHCALL adlı iki yeni opcode eklenmesini önermektedir.
Kısacası, EOA, imzalanmış bir mesajı ) işlemi ('yi kendisine güvenilir bir sözleşmeye ) gönderir, bu sözleşmeye Invoker ( denir. Bu Invoker sözleşmesi, bu EOA'nın işlemi göndermesi yerine AUTH ve AUTHCALL opcode'larını kullanabilir.
EIP-4337: İşlem havuzunu kullanarak hesap soyutlama )2021-09-29(
Bu öneri, MEV'den ilham alınarak tasarlanmıştır ve temel değeri, konsensüs katmanı protokolünün değiştirilmesinden tamamen kaçınmaktır.
EIP-4337, kullanıcıların bu nesneyi bellek havuzuna göndermesi için yeni bir işlem nesnesi UserOperation'ı önerdi. Bundler'lar, madenci bakış açısından toplu olarak paketleyip sözleşme ile işlem işlemlerini yürütmek için teslim eder. Bu, temelde alt düzey işlemleri ve hesap işlemlerini sözleşme düzeyinde yürütme seviyesine yükseltmektir.
EIP-5189: aracılar aracılığıyla hesap soyutlama )2022-06-29(
Bu, kötü niyetli Bundler'ın DoS engelleme saldırılarını önlemek için ) destekçi ( mekanizması aracılığıyla finansal ceza onayları oluşturarak EIP4337 mantığının bir optimizasyonu olarak görülebilir.
) 3.3 Diğer AA'yı destekleyen öneriler
EIP-2718: Yeni işlem türü paketleme zarfı ###2020-06-13(
Bu, gelecekte eklenecek işlem türlerinin zarfı olarak tanımlanan yeni bir işlem türünü belirleyen nihai bir öneridir.
Sonuç olarak, yeni işlem türleri tanıtıldığında, farklı işlem türlerini ayırmak için belirli bir kodlama kullanarak yalnızca geriye dönük uyumluluğu göz önünde bulundurmak yeterlidir, ileriye dönük uyumluluğa gerek kalmaz. En yaygın örnek EIP1559'dur, bu işlem ücretlerini ayırır, yeni işlem türü kodlaması kullanırken, başlangıçtaki legacy işlem türünü etkilemez.
Bu, AA yolundaki bir ek çö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 edecek ve sistemi, kodun zaten EOA adresi olan bir adrese dağıtılmasına yasaklayacaktır. Bu risk aslında çok düşüktür; çünkü Ethereum adresleri 160 bit uzunluğundadır. Belirli bir sözleşme adresinin özel anahtarını elde etmek için özel anahtar çakışması yönteminin olmasına rağmen, tüm Bitcoin ağının hesaplama gücünü kullandığınızda bile bunun için yaklaşık bir yıl gerekeceği tahmin edilmektedir.
) 3.4 Hesap soyutlamanın gelişim sürecini nasıl anlamalıyız?
Öncelikle CA'ya dönüştürülen değeri anlamak gerekir.
Bu esasen EIP-4337'nin pratik etkisidir, bunu gerçekleştirebilir:
Çoklu imza ve sosyal geri yüklemeyi destekler
Toplu işlemleri destekler
ERC20 token ile gas ücretini ödeme desteği
İşlem limitlerini destekler
Gas ücreti ödenmesini destekleyen gas olmadan işlem ###
Hesap kilidini destekleme ( sıcak ve soğuk cüzdan geçişi )
Ancak, EIP-4337'nin temel dezavantajı insan motivasyonu ilkesine aykırı olmasıdır.
Görünüşte daha iyi, ancak piyasa gelişiminin bir kilitlenmesine girdi: Birçok Dapp henüz uyumlu değil, kullanıcılar CA adreslerini kullanmak istemiyor, hatta CA kullanmanın daha yüksek işlem maliyetleri yaratabileceği durumlar var. ( Normal transfer senaryolarında, işlem ücretleri iki katına çıkabilir. ) Dapp'in kendisinin uyumluluğuna aşırı bağımlılık.
Bu, neden hala Ethereum ana ağında yaygınlaşmadığının sebebidir.
Maliyet, kullanıcılar için en önemli ölçüt olup, maliyetlerin düşürülmesi gerekmektedir.
Ancak GAS'ı gerçekten azaltmak için Ethereum'un kendisinin yumuşak çatal güncellemesi yoluyla GAS hesaplamasını veya opcode'un GAS tüketimini içeren modülleri değiştirmesi gerekmektedir. Yumuşak çatal yapılacaksa, neden doğrudan EIP-7702'yi düşünmüyoruz?
4. EIP-7702'nin Kapsamlı Analizi
( 4.1 EIP-7702 Tanıtımı
Bu öneri, yeni bir işlem türü tanıtarak EOA'nın tek bir işlemde akıllı sözleşme işlevine geçici olarak sahip olmasına izin veriyor. Böylece toplu işlemler, gazsız işlemler ve özelleştirilmiş yetki yönetimi gibi iş operasyonlarını destekliyor ve yeni bir EVM opCode) eklemeden geriye uyumluluğu etkilemiyor###.
Kullanıcıların akıllı sözleşmeleri dağıtmalarına gerek kalmadan çoğu AA yeteneğini elde etmelerini sağlar, hatta üçüncü tarafların kullanıcılar adına işlem başlatmasına olanak tanır, kullanıcıların özel anahtar sağlamasına gerek olmadan, yalnızca imza yetkilendirme bilgisi yeterlidir.
( 4.2 Veri Yapısı
EIP-7702, 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 kodlamasıyla sıralanmış sonucudur:
Yeni eklenen authorization_list nesnesi, imzalayanın EOA'sında çalıştırmak istediği kodu saklar. Kullanıcı işlem imzalarken, aynı zamanda gerçekleştirilecek olanı da imzalar.
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.
9 Likes
Reward
9
4
Share
Comment
0/400
RektRecovery
· 13h ago
meh... başka bir AA önerisi, muhtemelen 4337 gibi rekt olacak. şimdi tahmin ediyorum
EIP-7702: Ethereum hesap soyutlamasında yeni bir atılım ve gelecekteki gelişmeler
Derinlik analiz Ethereum hesap soyutlamanın tarihsel evrimi ve gelecek perspektifi
Giriş
Bu makale, Ethereum hesap soyutlaması (AA)'ın gelişim sürecini iki ana açıdan inceleyecektir:
Öncelikle, 2015'teki ilk AA önerisinden bu yana tarihsel bağlamı geriye dönük olarak inceleyeceğiz, bugüne kadar yapılan çeşitli EIP önerilerinin ana içeriklerini sistematik olarak gözden geçireceğiz, AA önerisinin evrim sürecini derinlemesine keşfedeceğiz ve her bir önerinin avantaj ve dezavantajlarını kapsamlı bir şekilde değerlendireceğiz.
İkincisi, EIP4337'nin piyasada düşük tepkilere neden olmasının sebeplerini analiz edeceğiz ve Ethereum'un gelecekteki sürüm güncellemelerine dahil edilecek EIP7702'yi derinlemesine inceleyeceğiz. Bu öneri birleştirildiğinde, zincir üzerindeki uygulamaların şeklini temelden değiştirecektir.
EIP-7702, devrim niteliğinde bir değişim olarak kabul edilebilir, gelin birlikte içindeki sırları derinlemesine inceleyelim.
1. Hesap soyutlamanın arka planı
1.1 hesap soyutlamanın anlamı
Ethereum kurucusu yakın zamanda ETH gelişim yol haritasını güncelledi, ancak hesap soyutlama ile ilgili ayarlar değişmedi. Mevcut ana akım model EIP-4337'den, bir sonraki aşama olan "isteğe bağlı dönüşüm EOA hesapları" na geçiş yapıyor.
EIP4337'nin piyasaya sürülmesinin üzerinden bir yıl geçmiş olmasına rağmen, piyasa tepkisi oldukça çelişkili - kullanıcılar genel olarak değerini kabul ediyor, ancak gerçek kullanım oranı düşük. Bu durumda, EIP-7702'nin ilerlemesi büyük ölçüde hızlandı ve bir sonraki güncellemede birleştirileceği kesinleşti.
1.2 Hesap soyutlamanın pazar durumu
Bir buçuk yıl gelişimin ardından, EIP4337'nin ana akım halka açık blok zincirlerindeki adres sayısı sadece 12 milyon, bunların arasında Ethereum ana ağındaki aktif adres sayısı ise yalnızca 6,764'tür; bu da EOA ve CA adres sayılarından oldukça uzaktır. Ethereum ana ağındaki bağımsız adres sayısı 270 milyona ulaşmış durumda, bu da EIP4337'nin ana ağda neredeyse hiçbir somut ilerleme kaydedemediğini göstermektedir.
Ancak bu, AA'nın temel değerinin etkilendiği anlamına gelmez. EIP4337'nin tasarımı, ana ağın geriye dönük uyumluluk sorununu iyi bir şekilde çözmesini zorlaştırıyordu. Çeşitli L2 zincirleri yerel AA'yı yaygın bir şekilde entegre ettikçe, EIP4337'nin adres sayısı L2'de patlama büyümesi yaşadı; bunlar arasında Base ve Polygon zincirlerinin Temmuz ayındaki aylık aktif kullanıcıları sırasıyla 1 milyon ve 3 milyon olarak oldukça dikkate değer.
Bu nedenle, sorun EIP4337'nin tasarımında değil, ana ağ ile L2 arasındaki farklılıklardan kaynaklanmaktadır; her biri için uygun çözümlere ihtiyaç vardır.
2. Hesap soyutlama nedir?
Hesap soyutlama esasen mülkiyet ayrımı sorununu çözüyor.
Ethereum sanal makinesi ( EVM ) mimarisinde iki tür hesap türü vardır: harici hesap ( EOA ) ve sözleşme hesabı ( Contract Account ). EOA'da, hesabın sahipliği ve imza yetkisi aynı varlık tarafından tutulur. Özel anahtara sahip olan kişi yalnızca hesabın "sahipliğine" sahip olmakla kalmaz, aynı zamanda "tüm varlıkların transferini imzalama yetkisine" de sahiptir.
Bu özellik, Ethereum hesap işlem yapısının belirlenmesinden kaynaklanmaktadır. Ethereum'un standart işlem yapısında aslında From alanı yoktur. İşlem başlatıcısının adresi, VRS parametresi ( yani kullanıcının imzası ) ile tersine çözülerek elde edilir.
Bu tasarım, kriptografi ile güvenliği sağlasa da, mevcut EOA adres mülkiyetinin birleştirilmesi sorununa yol açmaktadır.
EIP4337'nin temel etkisi, işlem alanında 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, EOA tasarımının birçok sorunu doğurmasıdır:
Özel anahtarın korunması zordur: özel anahtarın kaybolması tüm varlıkların kaybedilmesi anlamına gelir.
İmza algoritması tek: Yerel protokol yalnızca ECDSA imza ve doğrulama algoritmasını destekler.
İmza izinleri çok yüksek: Yerel çoklu imza desteği 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'u kullanmasını zorlaştırıyor:
Öncelikle, kullanıcıların Ethereum üzerindeki uygulamaları kullanabilmesi için Eter ('e sahip olmaları ve fiyat dalgalanması riskini almaları gerekmektedir.
İkincisi, kullanıcıların Gas price, Gas limit, işlem engelleme )Nonce sırası ( gibi karmaşık ücret mantıklarıyla başa çıkması gerekiyor, bu kavramlar kullanıcılar için aşırı karmaşık.
Son olarak, birçok blok zinciri cüzdanı veya uygulaması kullanıcı deneyimini artırmak için ürün optimizasyonu yapmaya çalışsa da, etkisi sınırlıdır.
Bu nedenle, zorlukların üstesinden gelmenin anahtarı hesap soyutlamasını gerçekleştirmek, sahipliği )Owner( ve imzalama yetkisini )Signer( birbirinden ayırmak ve böylece yukarıda belirtilen sorunları aşamalı olarak çözmektir.
Tarih boyunca çeşitli önerilerde bulunulmuştur, nihayetinde iki ana yolda birleşmiştir.
3. Hesap Soyutlama Tarihsel Teklifler Bağlamının Düzenlenmesi
Sorunun çözümünün birden fazla EIP önerisi olduğu görünse de, aslında iki ana fikir vardır. Geçmemiş her EIP'de ele alınan sorun, nihayetinde mevcut çözümlerin dönüm noktalarında toplanmıştır.
) 3.1 Birinci Rotası: 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ıyı sözleşmeler olarak önerdi. Bu öneri, adreslerin yalnızca kod ve depolama alanı içermesini, ERC20 tokenları ile işlem ücretlerinin ödenmesini desteklemeyi, önceden derlenmiş sözleşmeler aracılığıyla yerel tokenlerin ERC20 benzeri tokenlere dönüştürülmesini ### otomatik kesim yetkisi gibi işlevler ( eklemeyi ve işlem alanlarını yalnızca to, startgas, data ve code içerecek şekilde basitleştirmeyi öneriyordu.
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ğlayacak ) bu, mevcut EIP-7702'nin gerçekleştirmeyi hedeflediği etki (.
Diğer işlevleri türetebilir, örneğin:
Daha fazla kripto algoritması kullanarak işlem destekleyin, her adresin içindeki Kodu imza doğrulama yöntemi olarak belirler.
Kuantum saldırılarına karşı dayanıklılık özelliğine sahiptir, çünkü kod güncellenebilir.
Ether ile ERC20 sözleşmesiyle aynı işlevsellik özelliklerini sağlamak, yetkilendirme için kesinti yapmak, yerel parayı tüketmeye gerek yoktur.
Hesabın özelleştirme alanını artırın, sosyal kurtarma, SBT, anahtar kurtarma gibi işlevleri destekleyin.
Bu planın devam etmemesinin nedeni çok basit: adımlar çok büyük atıldı, o zamanki işlem hash çakışma sorunu ve güvenlik riskleri yeterince dikkate alınmadı, bu yüzden sürekli olarak ertelendi. Ancak, içindeki her bir avantaj fikri, sonraki EIP4337 ve EIP7702'nin temel işlevlerinden biri haline geldi.
Bundan sonra bu mantığı geliştirmeye çalışan bir dizi EIP oldu:
EIP-859: ana zincir hesap soyutlama )2018-01-30(
Bu öneri, Code'un dağıtım sorununu çözmeyi amaçlamaktadır. Temel işlevi, işlem tarafı sözleşmesi dağıtılmadığında, işlemle birlikte gelen code parametresini kullanarak sözleşme cüzdanının dağıtımını gerçekleştirmektir. Ayrıca, işlem parametrelerindeki doğrulama ve yürütme kısımlarını ayıran yeni bir PAYGAS opcode'u önerilmiştir; bu, gaz ödemesinin yanı sıra kullanılacaktır.
O zamanlar gerçekleştirilememiş olsa da, bu düşünce günümüzde EIP7702'nin temel mantıklarından biri haline geldi. EIP7702'deki her işlem, özel bir işlem yapısı ile birlikte belirli bir kodu içerebilir, böylece EOA adresi bu işlemde sözleşme yeteneğine sahip olabilir.
EIP-7702: EOA hesap kodunu ayarla )2024-05-07(
Bu, bu makalenin sonraki tartışmalarının merkezindeki EIP'dir, Vitalik tarafından önerilmiştir ve EIP-3074'ün alternatifidir. Bu nedenle EIP-3074 terk edilmiştir, EIP-7702'nin yaklaşan ETH Prag/Electra)Pectra( sert çatalında dahil edilmesi belirlenmiştir, detayları daha sonraki bölümlerde ayrıntılı olarak ele alacağız.
) 3.2 İkinci Yol: EOA adresinin CA adresini sürdürmesine izin verin
EIP-3074: AUTH ve AUTHCALL opcode'larını ekleyin ###2020-10-15(
Bu öneri, EVM'ye EOA'nın bu iki opcode ile sözleşmelere EOA kimliğini kullanmadan diğer sözleşmeleri çağırmasına izin vermek için AUTH ve AUTHCALL adlı iki yeni opcode eklenmesini önermektedir.
Kısacası, EOA, imzalanmış bir mesajı ) işlemi ('yi kendisine güvenilir bir sözleşmeye ) gönderir, bu sözleşmeye Invoker ( denir. Bu Invoker sözleşmesi, bu EOA'nın işlemi göndermesi yerine AUTH ve AUTHCALL opcode'larını kullanabilir.
EIP-4337: İşlem havuzunu kullanarak hesap soyutlama )2021-09-29(
Bu öneri, MEV'den ilham alınarak tasarlanmıştır ve temel değeri, konsensüs katmanı protokolünün değiştirilmesinden tamamen kaçınmaktır.
EIP-4337, kullanıcıların bu nesneyi bellek havuzuna göndermesi için yeni bir işlem nesnesi UserOperation'ı önerdi. Bundler'lar, madenci bakış açısından toplu olarak paketleyip sözleşme ile işlem işlemlerini yürütmek için teslim eder. Bu, temelde alt düzey işlemleri ve hesap işlemlerini sözleşme düzeyinde yürütme seviyesine yükseltmektir.
EIP-5189: aracılar aracılığıyla hesap soyutlama )2022-06-29(
Bu, kötü niyetli Bundler'ın DoS engelleme saldırılarını önlemek için ) destekçi ( mekanizması aracılığıyla finansal ceza onayları oluşturarak EIP4337 mantığının bir optimizasyonu olarak görülebilir.
) 3.3 Diğer AA'yı destekleyen öneriler
EIP-2718: Yeni işlem türü paketleme zarfı ###2020-06-13(
Bu, gelecekte eklenecek işlem türlerinin zarfı olarak tanımlanan yeni bir işlem türünü belirleyen nihai bir öneridir.
Sonuç olarak, yeni işlem türleri tanıtıldığında, farklı işlem türlerini ayırmak için belirli bir kodlama kullanarak yalnızca geriye dönük uyumluluğu göz önünde bulundurmak yeterlidir, ileriye dönük uyumluluğa gerek kalmaz. En yaygın örnek EIP1559'dur, bu işlem ücretlerini ayırır, yeni işlem türü kodlaması kullanırken, başlangıçtaki legacy işlem türünü etkilemez.
EIP-3607: EOA adresinin kontrat dağıtımını yasakla )2021-06-10(
Bu, AA yolundaki bir ek çö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 edecek ve sistemi, kodun zaten EOA adresi olan bir adrese dağıtılmasına yasaklayacaktır. Bu risk aslında çok düşüktür; çünkü Ethereum adresleri 160 bit uzunluğundadır. Belirli bir sözleşme adresinin özel anahtarını elde etmek için özel anahtar çakışması yönteminin olmasına rağmen, tüm Bitcoin ağının hesaplama gücünü kullandığınızda bile bunun için yaklaşık bir yıl gerekeceği tahmin edilmektedir.
) 3.4 Hesap soyutlamanın gelişim sürecini nasıl anlamalıyız?
Öncelikle CA'ya dönüştürülen değeri anlamak gerekir.
Bu esasen EIP-4337'nin pratik etkisidir, bunu gerçekleştirebilir:
Ancak, EIP-4337'nin temel dezavantajı insan motivasyonu ilkesine aykırı olmasıdır.
Görünüşte daha iyi, ancak piyasa gelişiminin bir kilitlenmesine girdi: Birçok Dapp henüz uyumlu değil, kullanıcılar CA adreslerini kullanmak istemiyor, hatta CA kullanmanın daha yüksek işlem maliyetleri yaratabileceği durumlar var. ( Normal transfer senaryolarında, işlem ücretleri iki katına çıkabilir. ) Dapp'in kendisinin uyumluluğuna aşırı bağımlılık.
Bu, neden hala Ethereum ana ağında yaygınlaşmadığının sebebidir.
Maliyet, kullanıcılar için en önemli ölçüt olup, maliyetlerin düşürülmesi gerekmektedir.
Ancak GAS'ı gerçekten azaltmak için Ethereum'un kendisinin yumuşak çatal güncellemesi yoluyla GAS hesaplamasını veya opcode'un GAS tüketimini içeren modülleri değiştirmesi gerekmektedir. Yumuşak çatal yapılacaksa, neden doğrudan EIP-7702'yi düşünmüyoruz?
4. EIP-7702'nin Kapsamlı Analizi
( 4.1 EIP-7702 Tanıtımı
Bu öneri, yeni bir işlem türü tanıtarak EOA'nın tek bir işlemde akıllı sözleşme işlevine geçici olarak sahip olmasına izin veriyor. Böylece toplu işlemler, gazsız işlemler ve özelleştirilmiş yetki yönetimi gibi iş operasyonlarını destekliyor ve yeni bir EVM opCode) eklemeden geriye uyumluluğu etkilemiyor###.
Kullanıcıların akıllı sözleşmeleri dağıtmalarına gerek kalmadan çoğu AA yeteneğini elde etmelerini sağlar, hatta üçüncü tarafların kullanıcılar adına işlem başlatmasına olanak tanır, kullanıcıların özel anahtar sağlamasına gerek olmadan, yalnızca imza yetkilendirme bilgisi yeterlidir.
( 4.2 Veri Yapısı
EIP-7702, 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 kodlamasıyla sıralanmış sonucudur:
rlp)[ zincir_id, nonce, max_priority_fee_per_gas, max_fee_per_gas, gaz_sınırı, varış, değer, data, erişim_listesi, yetki_listesi, signature_y_parity, signature_r, signature_s ]###
Yeni eklenen authorization_list nesnesi, imzalayanın EOA'sında çalıştırmak istediği kodu saklar. Kullanıcı işlem imzalarken, aynı zamanda gerçekleştirilecek olanı da imzalar.