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

Giriş

Bu makale iki ana modülden oluşmaktadır:

Üst kısım, 2015'teki ilk AA önerisinden başlayarak, şu ana kadar olan ana EIP öneri içeriklerini sistematik olarak gözden geçirdi, AA tarihsel öneri sürecini inceledi ve her bir seçeneğin artı ve eksilerini kapsamlı bir şekilde değerlendirdi.

Alt kısım, EIP4337'nin piyasada kötü geri dönüşlerle karşılaştığı durumu vurgularken, Ethereum'un bir sonraki sürüm güncellemesine dahil edilecek EIP7702'yi derinlemesine analiz ediyor. Bu öneri birleştirildiğinde, zincir üzerindeki uygulama biçimlerini tamamen değiştirecektir.

EIP-7702 devrim niteliğinde bir öneme sahiptir, gelin bunun detaylarını inceleyelim.

1. Hesap soyutlamanın arka planı

1.1 Hesap soyutlamanın anlamı

Ethereum kurucusu Vitalik, 2023 yılının sonunda ETH geliştirme yol haritasını bir kez daha güncelledi, ancak hesap soyutlama ayarları değişmedi. Şu anda ana akım model, EIP-4337'den sonraki aşama olan VoluntaryEOA Conversion('a ve ) EOA hesaplarına gönüllü geçişe doğru ilerliyor.

1.2 hesap soyutlamanın piyasa durumu

Bir buçuk yıl gelişimin ardından, EIP4337'nin ana akım blok zincirlerindeki toplam hesap sayısı yalnızca 12 milyon, bu arada Ethereum ana ağındaki aktif adres sayısı sadece 6.764'tür ve EOA ile CA adres sayısı arasında büyük bir fark vardır. Ethereum ana ağındaki bağımsız adres sayısı 270 milyon'a ulaşmıştır, bu da EIP4337'nin ana ağda neredeyse hiçbir somut gelişim göstermediğini göstermektedir.

Ancak bu, AA'nın temel değerini etkilemez. EIP4337'nin tasarımından itibaren ana ağ uyumluluğu sorununu çözmesi zor olduğu belliydi, ancak çeşitli L2 katmanlarında yaygın olarak uygulanıyor. Bu arada, Base ve Polygon zincirlerinin Temmuz ayındaki aktif kullanıcı sayıları sırasıyla 1 milyon ve 3 milyon olarak gerçekleşti, bu da oldukça başarılı bir performans sergiliyor.

Bu nedenle, EIP4337'nin tasarımında bir sorun yoktur, mevcut durum ana ağ ile L2 arasındaki farklılıklardan kaynaklanmaktadır, bunlar farklı uygulanabilir çözümler benimsemelidir.

2. Hesap soyutlama nedir?

Hesap soyutlama esasen mülkiyet ayrımı sorununu çözüyor.

EVM mimarisinde iki tür hesap vardır: dış hesap ( EOA ) ve sözleşme hesabı ( Contract Account ). EOA'nın mülkiyeti ve imza yetkisi aslında aynı kişi tarafından tutulur. Özel anahtara sahip olan kişi, yalnızca hesabın "mülkiyetine" sahip olmakla kalmaz, aynı zamanda "tüm varlıkları transfer etme yetkisini" de elinde bulundurur.

Bu, Ethereum hesaplarının işlem yapısının belirlediği bir durumdur. Standart işlem yapısında aslında From alanı yoktur, fon transferi VRS parametresi ( kullanıcısının imzası ile ) üzerinden From adresinin tersine çözülmesi ile gerçekleştirilir.

EIP4337'nin temel etkisi, işlem alanında Gönderen Adresi eklemektir, böylece özel anahtar ile işlem yapılan adresin ayrılması sağlanı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:

1. Özel anahtarların korunması zordur: özel anahtarın kaybolması tüm varlıkların kaybedilmesi anlamına gelir.

2. Tek imza algoritması: Yerel protokol yalnızca ECDSA algoritmasını kullanarak işlemleri doğrulayabilir.

3. İmza yetkisi çok yüksek: Yerel çoklu imza yok, tek bir imza ile herhangi bir işlem gerçekleştirilebilir.

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

5. İşlem gizliliği ihlali: Tekil 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, Ethereum uygulamalarını kullanmak için ETH'ye sahip olmalı ve fiyat dalgalanma riskini üstlenmelisiniz.

İkincisi, kullanıcıların Gas price, Gas limit, işlem tıkanıklığı gibi karmaşık ücret mantıklarıyla başa çıkması gerekiyor.

Sonunda, birçok blok zinciri cüzdanı kullanıcı deneyimini artırmak için ürün optimizasyonu yapmaya çalışsa da, etkisi sınırlıdır.

Bu nedenle, anahtar, hesap soyutlamasını gerçekleştirmek, mülkiyet (Owner) ve imza yetkisini (Signer) ayırmak ve böylece yukarıda belirtilen sorunları kademeli olarak çözmektir.

Tarih boyunca birçok plan olmuştur, nihayetinde iki yol olarak özetlenmiştir.

3. AA tarihsel teklif bağlamı incelemesi

Sorunun çözümünün birçok EIP önerisi varmış gibi görünmesine rağmen, sonunda yalnızca iki temel düşünce var. Geçmemiş her EIP'nin ele aldığı sorunlar, mevcut çözümün dönüm noktalarında birikmiştir.

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

15 Kasım 2015'te Vitalik, EIP-101'de hesaplar için yeni bir yapı olarak sözleşmeleri önerdi. Adresi yalnızca kod ve depolama alanı olarak değiştirmek, ERC20 ile işlem ücretlerini ödemeyi desteklemek, yerel token'ları ERC20 benzeri bir depolama bakiyesine dönüştürmek için önceden derlenmiş sözleşmeleri kullanmak ve işlem alanlarını to, startgas, data ve code ile basitleştirmek.

Bu plan birçok işlev türetebilir:

1. İşlemlerde daha fazla kripto algoritması kullanılabilir, imza doğrulama yöntemi adresin içindeki koda göre belirlenir.

2. Kuantum saldırılarına karşı dayanıklı özelliklere sahip, çünkü kod yükseltilebilir.

3. ETH'nin ERC20 sözleşmeleriyle aynı işlevselliğe sahip olmasını sağlamak, örneğin yetkilendirme.

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

Devam edememenin nedeni çok basit, adımlar fazla büyüktü, mevcut işlem hash çakışma sorunları ve güvenlik riskleri yeterince dikkate alınmadı. Ancak her avantaj fikri, sonrasında EIP4337 ve EIP7702'nin temel işlevlerinden biri haline geldi.

Sonrasında bu mantığı geliştirmeye yönelik bir dizi EIP daha vardır:

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

Code dağıtım sorununu çözmeye çalışıyor, temel olarak tarafların sözleşmesi dağıtılmamışsa işlemle birlikte gelen code parametresini kullanarak dağıtım gerçekleştirilmesi gerektiğini ifade ediyor. Ayrıca, işlem parametrelerindeki doğrulama kısmı ile yürütme kısmı arasındaki ayırıcı olarak yeni bir PAYGAS opcode'u önerdi.

Her ne kadar o zaman sona ermiş olsa da, EIP7702'nin temel mantıklarından biri haline geldi. EIP7702'nin her işlemi, özel işlem yapısı ile birlikte kod içerebilir ve bu sayede EOA adresinin bu işlemde sözleşme yeteneğine sahip olmasını sağlar.

EIP-7702: EOA hesap kodunu ayarlama (2024-05-07)

Bu, bu makalenin sonraki tartışmalarının merkezindeki EIP'dir, Vitalik tarafından EIP-3074'ün alternatif çözümü olarak önerilmiştir. EIP-3074 kullanılmaktan kaldırılmıştır, EIP-7702'nin yaklaşan ETH Prague/Electra hard fork'unda dahil edilmesi kesinleşmiştir.

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 işlem kodu AUTH ve AUTHCALL ekleyerek, EOA'nın bu iki opcode aracılığıyla sözleşmelere EOA kimliği yerine diğer sözleşmeleri çağırma yetkisi vermesini sağlamak.

EOA, imzalı mesajı ( işlemi ) güvenilir bir sözleşmeye ( Invoker ) olarak gönderebilir. Bu Invoker sözleşmesi AUTH ve AUTHCALL opcode'larını kullanarak EOA yerine işlem gönderebilir.

EIP-4337: İşlem bellek havuzunu kullanarak hesap soyutlama (2021-09-29)

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

Yeni bir işlem nesnesi olan UserOperation'ı önerin, kullanıcı bu nesneyi bellek havuzuna gönderir, bundler'lar madenci açısından topluca paketleyip sözleşme yürütme işlemlerini teslim eder, esasen alt işlem ve hesap işletimini sözleşme seviyesinde yürütmeye taşır.

EIP-5189: aracılar aracılığıyla soyut hesap işlemleri (2022-06-29)

EIP4337 mantığını optimize etmek, DoS engelleme saldırılarını önlemek için fon ceza arka planı sağlayıcı mekanizması kurarak.

3.3 Diğer AA'yı destekleyen teklifler

EIP-2718: Yeni işlem türü ambalaj zarfı (2020-06-13)

Final olarak belirlenmiş öneri, yeni işlem türlerini gelecekteki ek işlem türlerinin zarfı olarak tanımlar.

Yeni işlem türleri tanıtıldığında, belirli bir kodlama ile ayrım yapılarak yalnızca geriye dönük uyumluluk sağlanır, ileriye dönük uyumluluk gerekmez. En yaygın örnek EIP1559'dur, işlem ücretlerini ayırarak yeni işlem türü kodlaması kullanır ve ilk legacy işlem türünü etkilemez.

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

AA yolundaki ek çözüm, sözleşme dağıtım adresi ile EOA adresinin çakışmasını önlemektedir. Sözleşme oluşturma yöntemini kontrol etmekte, kodun zaten EOA olan bir adrese dağıtılmasına izin verilmemektedir. Bu risk oldukça düşüktür, Ethereum adresi 160 bit uzunluğundadır, özel anahtar kullanarak belirli bir sözleşme adresi anahtarının çakışmasını sağlama yöntemi mevcut olsa da, Bitcoin'in tüm hesap gücüyle tahmini bir yıl sürmektedir.

3.4 Hesap soyutlama gelişim süreci nasıl anlaşılmalıdır?

Öncelikle CA'ya dönüşümünün değerini anlamak gerekir, bu temelde EIP-4337'nin pratik etkisidir:

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

Görünüşte daha iyi, ancak piyasa gelişiminde bir kısır döngüye girmiş. Birçok Dapp uyumsuz, kullanıcılar CA adresi kullanmak istemiyor, CA kullanmanın daha yüksek işlem maliyetleri var. Dapp'in kendisine aşırı derecede bağımlı.

Bu nedenle 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.

Gerçekten Gas'ı düşürmek istiyorsanız, Ethereum'un kendisinin yumuşak çatallanma güncellemesi yapması, Gas hesaplamasını veya opcode Gas tüketim modüllerini değiştirmesi gerekmektedir. Eğer yumuşak çatallaşma yapılacaksa, neden doğrudan EIP-7702'yi düşünmüyorsunuz?

4. EIP-7702'nin Kapsamlı Analizi

4.1 EIP-7702 nedir

Yeni işlem türleri aracılığıyla EOA'nın tek bir işlemde geçici olarak akıllı sözleşme işlevselliğine sahip olmasına izin verilir, toplu işlemleri, Gas'sız işlemleri ve özel yetki yönetimini destekler ve yeni bir EVM opCode'unun tanıtılmasını gerektirmez.

Kullanıcıların, akıllı sözleşmeleri dağıtmalarına gerek kalmadan çoğu AA yeteneğini elde etmeleri mümkündür; hatta üçüncü tarafların kullanıcı adına işlem başlatma yeteneğini sağlayabilirler, sadece imza yetkilendirme bilgisi sağlamaları yeterlidir, özel anahtar sağlamak yerine.

4.2 veri yapısı

Yeni işlem türü 0x04'ü tanımlayın, TransactionPayload aşağıdaki içeriğin RLP kodlamalı seri hale getirilmiş 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])

Yeni authorization_list nesnesi eklendi, imzalayıcıların EOA'da yürütmek istedikleri kodu saklar. Kullanıcı, işlemi imzalarken yürütülecek sözleşme kodunu da imzalar, iki boyutlu bir liste olarak bulunur ve birden fazla işlem bilgisini toplu olarak saklayabilir.

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 başladığında, her authorization_list için [chain_id, address, nonce, y_parity, r, s] demetinin:

1. İmza r, s kullanarak imzalayanın adresini ecrecover ile geri yükleyin.

2. Zincir ID ('in fork'lanmış zincir yeniden oynatmasını doğrulayın ).

3. authority imzalayıcı kodunun boş veya yetkilendirilmiş olup olmadığını doğrulayın.

4. authority imzacı nonce('inin doğrulanması authority imza yeniden oynanmasını önlemek için ).

5. authority imzacısı kodunu 0xef0100 || address olarak ayarlayın.

6. authority imza sahipleri nonce('yi artırarak yerel imza yeniden oynatma)'ı önleyin.

7. authority imzacı hesabını erişilen adresler listesine ekleyin.

4.3.2 İşlem Aşaması

"Yeni" sürüm sadece kod dağıtım davranışını değiştirdi.

Artık hesap kodunu contract_code olarak ayarlamayacağız, bunun yerine authorization_list'in address alanından kodu alıp hesap kodu olarak ayarlayacağız.

Yetki kodunu yürütürken, authorization_list'ten belirtilen adresten kod yüklenir ve imzalayan hesap bağlamında yürütülür.

Kullanıcı sözleşme kodu, zincirde belirli bir adreste gerçek olarak depolanır, doğrudan işlemde yer almaz.

İşlem talimatları ve ilgili parametreler, işlem yükü data alanında saklanır.

4.4 EIP-7702'nin değeri

Web3 cüzdanındaki tüm zincir bağlantılarında değişiklikler oldu, kullanıcı deneyimi büyük ölçüde değişti. EOA, normal işlemleri bir sözleşme gibi birden fazla mantıkla başlatabilir, örneğin toplu transfer. CeFi senaryosundaki işlem tanımlama, para yatırma ve çekme ücretlerini etkiler.

Mevcut birçok kalıbı kırmak:

1. Hesap bakiyesi, bu hesaptan kaynaklanmayan işlemler nedeniyle azalabilir.

2. İşlem gerçekleştirilmesi başladıktan sonra EOA nonce birden fazla artabilir.

3. tx.origin ve msg.sender karşılaştırma koruma mantığını kırmak, birçok mevcut sözleşmenin risk taşıdığı anlamına geliyor.

4. EOA kendisi olaylar gönderebilir, bu da bazı zincir üstü olay tanıma dinleme işlemlerini etkiler.

5. EOA adresi ERC20, 721, 1155 gibi varlıkları alırken başarısız olabilir ( geri çağırma mekanizması nedeniyle ).

4.5 EIP-7702 ve EIP-4337 karşılaştırması

1. EIP-7702 avantajları

• Gaz daha düşük, entrypoint modülüne gerek yok, zincir üzerindeki işlemleri azaltır.
• Kullanıcı geçiş maliyetleri daha düşük, önceden zincir üzerindeki sözleşmeleri dağıtmaya gerek yok.
• EIP4337 ile karşılaştırıldığında, kod delegasyon yürütmesi de var, iki yol var:

Tam Yetki (Full Delegation )

• Belirli bir işlemi