Ethereum hesap soyutlama alanının geçmişi ve geleceği üzerine derinlemesine bir inceleme

Bu makale iki ana bölümden oluşmaktadır:

Üst kısım, 2015 yılındaki ilk AA önerisinden yola çıkarak, sistem şu ana kadar yapılan önemli EIP önerilerinin içeriğini derledi, AA tarihsel önerilerinin gelişim sürecini tartıştı ve her bir öneriyi kapsamlı bir şekilde değerlendirdi.

Alt kısımda, EIP4337'nin piyasada soğuk bir tepki almasının nedenlerine yönelik karşılaştırmalı bir analiz yapılacak ve Ethereum'un bir sonraki sürüm güncellemesine dahil edilmesi beklenen EIP7702 derinlemesine incelenecektir. Bu öneri birleştirildiğinde, zincir üzerindeki uygulama biçimlerini tamamen değiştirecektir.

EIP-7702'nin devrim niteliğinde bir anlamı var, gelin bunu detaylı bir şekilde inceleyelim.

1. Hesap soyutlamasının arka planı

1.1 Hesap soyutlamanın anlamı

Ethereum kurucusu Vitalik, 2023 sonunda ETH yol haritasını güncellerken, hesap soyutlaması ayarını değiştirmedi. Şu anda ana akım model, EIP-4337'den sonraki aşamadaki isteğe bağlı EOA hesap dönüşümüne doğru gelişiyor.

EIP4337'nin piyasaya sürülmesinin üzerinden bir yıl geçti ve (, 1 Mart 2023'te Denver'daki WalletCon'da resmi olarak duyuruldu. ), kullanıcılar tarafından geniş çapta tanınırken, kullanım oranı düşük kaldı. Böyle bir çelişkili piyasa ortamında, EIP-7702'nin ilerlemesi büyük ölçüde öne alındı ve bir sonraki güncellemede birleştirileceği kesinleşti.

1.2 hesap soyut pazar durumu

Bir buçuk yıl süren gelişimden sonra, EIP4337'nin ana akım zincirlerdeki hesap sayısı sadece 12 milyon, bunun içinde Ethereum ana ağında aktif adres sayısı sadece 6,764'tür; bu, EOA ve CA adres sayısından çok uzaktır. Ethereum ana ağındaki bağımsız adres sayısı 270 milyona ulaşmıştır, bu da EIP4337'nin ana ağda neredeyse hiçbir somut gelişme göstermediği anlamına geliyor.

Ancak bu, AA'nın temel değerini etkilemez. EIP4337'nin tasarımı, ana ağın geriye dönük uyumluluk sorununu çözmesini zorlaştırır. Çeşitli L2 yerel olarak AA'yı entegre ederken, EIP4337 adres sayısı L2'de patlama yaşadı; bu arada Base ve Polygon zincirlerindeki Temmuz ayı aktif kullanıcı sayısı sırasıyla 1 milyon ve 3 milyon oldu.

Bu nedenle, EIP4337 tasarımında bir hata yoktur, birçok avantajı vardır. Mevcut durum, ana ağ ile L2 arasındaki farklılıklardan kaynaklanmaktadır; her birinin uygun bir çözüme ihtiyacı vardır.

2. Hesap soyutlaması nedir?

Hesap soyutlaması esasen mülkiyet ayrımı sorununu çözmektedir.

Ethereum sanal makinesi ( EVM ) mimarisinde iki tür hesap bulunmaktadır: dış hesap ( EOA ) ve sözleşme hesabı ( Contract Account ). Dış hesabın mülkiyeti 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 yetkisine" de sahiptir.

Bu, Ethereum hesabı işlem yapısının belirlediği bir durumdur. İşlem yapısından, Ethereum'un standart işleminin From alanı olmadığını görebiliriz. Fon transferi sırasında, hangi adresin fonlarının kullanıldığı VRS parametresi ( yani kullanıcının imzası ) ile ters çözümleme ile From adresi olarak belirlenir.

Bu, ECDSA gibi asimetrik şifreleme ve tek yönlü eşik fonksiyonları gibi kavramları içeriyor, ancak bunları burada ayrıntılı olarak tartışmayacağız. Sonuç olarak, burada güvenlik kriptografi ile sağlanıyor, ancak bu aynı zamanda mevcut EOA adres mülkiyet birleştirme zorluğuna da yol açıyor.

EIP4337'nin temel etkisi, işlem alanına Gönderen Adresi alanının eklenmesiyle, ö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 daha fazla soruna neden olabilmesidir:

1. Özel anahtarları korumak zor: Kullanıcı özel anahtarını ( kaybederse, siber saldırılara ve kriptografi kırılmalarına maruz kalırsa ) tüm varlıklarını kaybeder.

2. Tek İmza Algoritması: Yerel protokol, işlem doğrularken yalnızca ECDSA imza ve doğrulama algoritmasını kullanabilir.

3. İmza yetkisi çok yüksek: Yerel çoklu imza (, yalnızca akıllı sözleşme ile gerçekleştirilebilir ), tek imza ile her türlü işlem yapılabilir.

4. İşlem ücretleri yalnızca ETH ile ödenebilir, toplu işlem desteği yoktur.

5. İşlem gizliliği ihlali: Tek bir işlem, hesap sahibinin gizli 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, Ethereum üzerindeki herhangi bir uygulamayı kullanmak için kullanıcıların Eter ( tutması ve fiyat dalgalanmaları riskini üstlenmesi 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 fazla 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, çözüm, hesap soyutlamasını gerçekleştirmek, mülkiyeti (Owner) ve imza hakkını (Signer) ayrıştırmak ve böylece yukarıdaki sorunları kademeli olarak çözmektir.

Tarih boyunca birçok plan vardı, nihayetinde iki yol bir araya geldi.

3. AA tarihsel öneri bağlamının düzenlenmesi

Sorunun çözümünün birçok EIP önerisi varmış gibi görünse de, eninde sonunda iki ana fikir vardır. Her bir geçersiz EIP'nin ele aldığı sorunlar, nihayetinde mevcut çözümün kırılma noktalarına birleşmiştir.

3.1 İlk yol: EOA adresini CA adresine dönüştürmek

2015 yılı 15 Kasım'da, EIP-101 etrafında, Vitalik hesaplar için yeni bir yapı olarak sözleşmeleri öne sürdü. Adresi sadece kod ve depolama alanı olarak değiştirdi, işlem ücretlerinin ERC20 ile ödenmesini sağladı, yerel token'i bakiye ( için ERC20 benzeri hale dönüştürmek amacıyla önceden derlenmiş sözleşmeler aracılığıyla, işlem alanını yalnızca to, startgas, data ve code ile sadeleştirdi.

Şu anda, bu büyük bir atılım değişimi gibi görünüyor, temel tasarımı önemli ölçüde değiştirecek ve her hesabın adresinin kendi "kod" mantığına sahip olmasını sağlayacak ) bu, EIP-7702'nin gerçekleştirmek istediği etki.

Bu, diğer işlevleri türetebilir, örneğin:

1. İşlemler daha fazla kriptografik algoritma kullanabilsin, her adresin içindeki Kod ile imza doğrulama yöntemleri belirlenebilir.

2. Kuantum saldırılarına karşı dayanıklılık özelliğine sahip, çünkü kod güncellenebilir.

3. Ether'in ERC20 sözleşmesiyle aynı işlevsellikleri kazanmasını sağlamak, temel etki otomatik kesinti yetkisini gerçekleştirmek, yerel para kaybı olmadan.

4. Hesabın özelleştirme alanını artırma, sosyal geri yükleme, SBT desteği, anahtar kurtarma vb. ile uyumlu.

Devam edememenin nedeni oldukça basit, açıkça adımlar çok büyük atıldı, mevcut işlem hash çakışma sorunları ve güvenlik riskleri dikkate alınmadı, bu yüzden her zaman askıya alındı. Ancak her avantajın felsefesi, sonraki EIP4337 ve EIP7702'nin temel işlevlerinden biri haline geldi.

Daha sonra bu mantığı geliştirmeyi amaçlayan bir dizi EIP daha ortaya çıktı:

EIP-859: Ana zincir hesap soyutlama (2018-01-30)

Code'un dağıtım sorununu çözmeye çalışmak. Temel işlevi, eğer işlem tarafı sözleşmesi dağıtılmamışsa, işlemle birlikte gönderilen code parametresini kullanarak sözleşme cüzdanını dağıtmaktır. Ayrıca, gaz ödemesinin yanı sıra, işlem parametreleri içindeki doğrulama kısmı ile yürütme kısmı arasında bir ayırıcı haline gelen yeni PAYGAS opcode'u da önerilmiştir.

Her ne kadar o dönemde sonuçsuz kalmış olsa da, bu durum şimdi EIP7702'nin temel mantıklarından biri haline geldi. EIP7702'nin her bir işlemi, özel bir işlem yapısıyla birlikte belirli kodların eklenmesine olanak tanır, böylece EOA adresinin bu işlemde akıllı sözleşme yeteneğine sahip olmasını sağlar.

EIP-7702: EOA hesabı kodunu ayarla (2024-05-07)

Bu, makalenin sonraki tartışma mekanizmasının temel EIP'sidir. Vitalik, EIP-3074 için bir alternatif olarak EIP-7702'yi yayınladı. Bu nedenle EIP-3074 kullanılmaz hale geldi ve EIP-7702'nin yakında gerçekleşecek ETH Prague/Electra(Pectra) sert çatallamada dahil edileceği kesinleşti, ayrıntıları birazdan açacağız.

( 3.2 İkinci yol: EOA adresinin CA adresini yönlendirmesine izin verin

EIP-3074: AUTH ve AUTHCALL opcode'larının eklenmesi )2020-10-15###

EVM'ye AUTH ve AUTHCALL adında iki yeni OpCode ekleyerek, EOA'nın bu iki opcode aracılığıyla sözleşmelere EOA'nın kimliğini temsil eden diğer sözleşmeleri çağırmasına izin verilir.

Özetle, EOA, bir imzalı mesajı ( işlemine ), kendisine güvenilen bir sözleşmeye ( iletmekte, buna Invoker ) denir. Bu Invoker sözleşmesi, AUTH ve AUTHCALL opcode'larını kullanarak bu EOA'nın yerine işlem gerçekleştirebilir.

EIP-4337: Hesap soyutlamasını işlem bellek havuzuyla gerçekleştirme (2021-09-29)

MEV'den ilham alarak tasarlandı, temel değeri konsensüs katmanı protokol değişikliklerini tamamen önleyebilmesidir.

EIP4337, kullanıcıların bu nesneyi bellek havuzuna göndermesini sağlayan yeni bir işlem nesnesi olan UserOperation'ı önermektedir. Bundler'lar, madenci boyutundan toplu bir şekilde sözleşme yürütme işlemi için işlem işlemlerini paketler. Bu, temelde, alt düzey işlemleri ve hesap işlemlerini sözleşme düzeyinde gerçekleştirmek için taşımaktadır.

EIP-5189: Abstrakt hesapları yönetmek için destekleyici kullanarak (2022-06-29)

Bu, EIP4337'nin mantığını optimize etmek olarak kabul edilebilir; kötü niyetli Bundler'ları, fon cezası arka planı endorse etmek için bir mekanizma kurarak DoS engelleme saldırılarına karşı korumak amacıyla.

( 3.3 AA'yı desteklemek için diğer öneriler

EIP-2718: Yeni işlem türlerinin paketlenmesi )2020-06-13###

Bu, gelecekte eklenmesi planlanan yeni bir işlem türü için bir zarf olarak tanımlanan, zaten Final olan bir öneridir.

Sonuç, yeni bir işlem türü tanıtıldığında, farklı işlemleri ayırt etmek için belirli bir kodlama kullanarak yalnızca geriye dönük uyumluluğu sağlamasıdır, ileriye dönük uyumluluğa gerek kalmadan. En yaygın örnek EIP1559'dur, bu işlem ücretlerini ayırt eder, yeni işlem türü kodlaması kullanır ve başlangıçta var olan legacy işlem türünü etkilemez.

EIP-3607: EOA adresinin sözleşme dağıtımına izin verilmemesi (2021-06-10)

Bu, AA yolundaki ek bir çözümdür ve sözleşme dağıtım adresinin EOA adresiyle çakışmasını önlemek için kullanılır. Sözleşme oluşturma yöntemini kontrol edecek ve sisteme, zaten EOA adresi olan bir adrese kodun dağıtılmasına izin vermeyecektir. Bu risk aslında oldukça küçüktür, sonuçta 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öntemleri olsa da, Bitcoin'in toplam hesaplama gücüyle tahmin edilen süre bir yıl kadar alacaktır.

( 3.4 Hesap soyutlamasının 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 etkisidir, bunu gerçekleştirebilir:

• Birden fazla imza algoritmasını destekler
• Sosyal geri yüklemeyi destekler
• Özelleştirilebilir Gas ücretlerini destekleyen tokenler
• Toplu işlemleri destekler
• Hesap yönetimini destekler
• Üçüncü taraf ödeme gaz ücretlerini destekler

Ancak, EIP-4337'nin temel dezavantajı insan motivasyonu ilkesine aykırı olmasıdır.

Daha iyi görünüyor, ancak piyasa gelişiminin kısır döngüsüne girmiş durumda. Birçok Dapp hala uyumlu değil, bu nedenle kullanıcılar CA adreslerini kullanmak istemiyor, hatta CA kullanmanın daha yüksek işlem maliyeti var ) sıradan transfer senaryolarında, işlem ücretleri iki katına çıkıyor ###, Dapp'in kendisinin uyumluluğuna çok fazla bağımlı.

Bu nedenle Ethereum ana ağında henüz yaygınlaşmamıştır.

Maliyet, kullanıcılar için en önemli ölçüt olup, maliyetlerin düşürülmesi gerekmektedir.

Ama GAS'ı gerçekten azaltmak için, Ethereum'un kendisinin yumuşak çatal yükseltmesi yapması, GAS hesaplamasını veya opcode'ların GAS tüketimini değiştirmesi gibi modülleri değiştirmesi gerekiyor. Ancak yumuşak çatal yapacaksa, neden doğrudan EIP-7702'yi düşünmüyoruz?

4. EIP-7702'nin Kapsamlı Analizi

( 4.1 EIP-7702 nedir

Yeni bir işlem türü ile ayırt edilir, EOA'nın tek bir işlemde akıllı sözleşme işlevselliğine geçici olarak sahip olmasına izin verir, böylece iş açısından toplu işlemler, Gas'siz işlemler ve özel yetki yönetimi gibi destekler ve yeni bir EVM opCode)'in geriye uyumluluğa etkisini gerektirmez.

Kullanıcıların akıllı sözleşme dağıtmadan AA'nın çoğu yeteneğini elde etmelerini sağlarken, ayrıca üçüncü tarafların kullanıcı adına işlem başlatma yeteneğini sağlayabilir ve kullanıcıdan özel anahtar sağlamasını istemez, sadece imza yetkilendirme bilgilerini gerektirir.

4.2 Veri Yapısı

Yeni işlem türü 0x04'ü tanımlar, bu işlem türünün TransactionPayload'u aşağıdaki içeriğin RLP kodlama sonucu:

rlp([ zincir_id, nonce, max_priority_fee_per_gas, max_fee_per_gas, gaz_limiti, varış, değer, veri, erişim_listesi, authorization_list, signature_y_parity, 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şlemi imzalarken aynı zamanda yürütülecek olan akit kodunu da imzalar; bu, bir iki boyutlu liste olarak mevcuttur ve birden fazla işlem bilgisinin topluca saklanabileceğini, toplu işlemlerin gerçekleştirilebileceğini gösterir.

authorization_list = [[chain_id, address, nonce, y_parity, r, s], ...]