Ethereum hesap soyutlama alanının tarihi ve geleceğine derinlemesine bakış

Giriş

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

Üst kısım 2015 yılındaki ilk AA önerisinden başlayarak, sistem şu ana kadar EIP önerilerinin ana içeriğini düzenledi, tarihsel bir perspektiften AA tarihsel önerilerinin gelişim sürecini araştırmayı ve her bir önerinin avantajlarını ve dezavantajlarını kapsamlı bir şekilde değerlendirmeyi umuyor.

Alt kısım, EIP4337'nin piyasada karşılaştığı soğuk tepkileri vurgularken, Ethereum'un bir sonraki versiyon güncellemesine dahil edilecek EIP7702'yi derinlemesine analiz ediyor. Bu öneri birleştirildiğinde, zincir üzerindeki uygulama şekillerini tamamen değiştirecektir.

EIP-7702 tarihi bir öneme sahiptir, gelin bunu birlikte detaylıca inceleyelim.

1. Hesap soyutlamanın arka planı

1.1 Hesap soyutlamanın anlamı

Ethereum kurucusu Vitalik, 2023 yılının sonunda ETH gelişim yol haritasını bir kez daha güncelledi ve hesap soyutlaması ile ilgili ayarlar değişmeden kaldı. Mevcut ana akım model, EIP-4337'den "Gönüllü EOA hesap dönüşümüne" geçiş yapıyor.

EIP4337'nin piyasaya sürülmesinin üzerinden bir yıldan fazla geçtikten sonra, 1 Mart 2023 tarihinde Denver'daki WalletCon'da, resmi olarak Ethereum Vakfı geliştiricileri tarafından tasarlanan ve uygulanan ERC-4337 çekirdek sözleşmesinin OpenZeppelin denetiminden geçtiği ve resmi olarak piyasaya sürülen tarih olarak kabul edildiği duyuruldu. Pazar, kullanıcılar tarafından geniş bir şekilde kabul edilen ancak yaygın olarak kullanılmayan çelişkili bir durum sergilemekte. Bu ortamda, EIP-7702'nin ilerlemesi büyük ölçüde hızlandırıldı ve bir sonraki güncellemeye dahil edileceği kesinleşti.

( 1.2 Hesap soyutlamanın piyasa durumu

Bir buçuk yıllık gelişimin ardından, EIP4337'nin ana akım zincirlerdeki toplam hesap sayısı yalnızca 12 milyon, bunların içinde Ethereum ana ağındaki aktif adres sayısı yalnızca 6,764'tür ve EOA ile CA adres sayıları arasında büyük bir fark vardır. Ethereum ana ağındaki bağımsız adres sayısı 270 milyona ulaşmıştır. EIP4337'nin ana ağda neredeyse hiçbir somut gelişme kaydetmediğini söyleyebiliriz.

Ancak bu, AA'nın temel değerini etkilemez. EIP4337'nin tasarımı baştan itibaren ana ağın ciddi ileri uyumluluk sorunlarını çözmekte zorlanacağını belirlemişti. Çeşitli L2 zincirlerinin yerel AA'yı genel olarak entegre etmesiyle, 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 olarak kaydedildi, bu da oldukça iyi bir performans.

Bu nedenle, EIP4337'nin tasarımında bir hata yoktur, birçok avantajı vardır, bunları daha sonra sistematik olarak özetleyeceğiz. Mevcut durum, ana ağ ile L2 arasındaki farklardan kaynaklanmaktadır, her birinin kendine uygun bir çözüm gerekmektedir.

2. Hesap soyutlama nedir?

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

EVM mimarisinde iki tür hesap vardır: dış hesap ) EOA ### ve sözleşme hesabı ( Contract Account ). Dış hesabın mülkiyeti ve imza yetkisi gerçekte aynı varlık tarafından tutulmaktadır. Özel anahtara sahip olan kişi, sadece hesabın "mülkünü" değil, aynı zamanda "tüm varlıkları devretme yetkisini" de elinde bulundurmaktadır.

Bu, Ethereum hesaplarının işlem yapısının belirlediği bir durumdur. İşlem yapısından, Ethereum'un standart işlemlerinin From alanına sahip olmadığı anlaşılmaktadır. Aslında, VRS parametreleri ( ile kullanıcı imzası ) geri çözülerek From adresi elde edilmektedir.

Bu, ECDSA gibi asimetrik şifreleme, tek yönlü eşik fonksiyonları gibi kavramları içerir, burada daha fazla açılmayacaktır. Sonuç olarak, burada güvenlik şifreleme ile sağlanmakta olup, bu da mevcut EOA adres mülkiyet birleşiminin zorluğunu yaratmaktadır.

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, harici hesap (EOA) tasarımının daha fazla sorunu beraberinde getirecek olmasıdır:

1. Özel anahtarın korunması zordur: Kullanıcı özel anahtarını ( kaybederse, hacker saldırısı veya kriptografik kırılma ) tüm varlıkların kaybedilmesi anlamına gelir.

2. İmza algoritması tek: Yerel protokol işlem doğrulaması yalnızca ECDSA imza ve doğrulama algoritmasını kullanabilir.

3. İmza yetkisi çok yüksek: Yerel çoklu imza ( sadece akıllı sözleşme ile gerçekleştirilebilir ), tek imza ile herhangi bir işlem gerçekleştirilebilir.

4. İşlem ücretleri yalnızca ETH ile ödenebilir, toplu işlemler desteklenmemektedir.

5. İşlem gizliliği ihlali: Birbiriyle yapılan işlemler, hesap sahiplerinin 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 dalgalanması riskini üstlenmesi gerekmektedir ).

İkinci olarak, kullanıcıların karmaşık ücret mantığını işlemesi gerekiyor. Gaz fiyatı, gaz limiti, işlem tıkanıklığı ( nonce sırası ) gibi kavramlar kullanıcılar için fazla karmaşık.

Sonuç olarak, birçok blockchain cüzdanı veya uygulaması, ürün optimizasyonu ile kullanıcı deneyimini artırmaya çalışsa da, etkisi sınırlıdır.

Bu nedenle, kırılma noktası hesap soyutlamasını gerçekleştirmek, mülkiyet (Owner) ve imza hakkı (Signer) arasındaki bağı çözmektir, böylece yukarıda belirtilen sorunları kademeli olarak çözmek mümkündür.

Tarih boyunca birçok öneri sunulmuştur, nihayetinde iki yol üzerinde yoğunlaşmıştır.

3. AA Tarihsel Teklif Bağlamı Düzenlemesi

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

15 Kasım 2015'te, Vitalik EIP-101'de sözleşmeleri hesaplar olarak yeni bir yapı olarak önerdi. Adresi yalnızca kod ve depolama alanı olacak şekilde değiştirdi, işlem ücretleri ERC20 ile ödenebilecek şekilde desteklendi, yerel token'ları sınıf ERC20 depolama bakiyesine dönüştürmek için önceden derlenmiş sözleşmeler kullanıldı ), otomatik yetkilendirme gibi işlevler ### eklenerek işlem alanları to, startgas, data ve code ile sadeleştirildi.

Bu öneri, büyük bir sıçrama niteliğinde bir değişim olarak görülebilir, 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. ( de şu anki EIP-7702'nin gerçekleştirmek istediği etkidir ).

Aynı zamanda diğer işlevleri türetebilir, örneğin:

1. İşlemler daha fazla kriptografi algoritması kullanır, her adresin içindeki Code tarafından imza doğrulama yöntemi belirlenebilir.

2. Kuantum saldırılarına karşı dayanıklılık özelliklerine sahiptir, çünkü kod güncellenebilir.

3. Ethereum'in ERC20 sözleşmesi ile aynı işlevsellik özelliklerini sağlaması, temel etkisi, yerel parayı harcamadan otomatik kesinti yetkisi sağlamaktır.

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

Devam edememenin nedeni çok basit; açıkça adımlar çok büyük, mevcut işlem hash çakışma sorunları ve güvenlik riskleri yeterince dikkate alınmadı, bu nedenle her zaman ertelendi. Ancak her bir avantaj fikri, sonraki EIP4337 ve EIP7702'nin temel işlevlerinden biri haline geldi.

Sonrasında bu mantığı geliştirmeyi amaçlayan bir dizi EIP var:

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

Code dağıtım sorununu çözmeye çalışmak, 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ını dağıtmaktır. Ayrıca yeni bir PAYGAS opcode'u önerilmiştir, bu, sadece gaz ödemekle kalmayıp, aynı zamanda işlem parametreleri içindeki doğrulama ve yürütme kısımlarını ayıran bir ayırıcı olarak da işlev görmektedir.

O zaman uygulamaya konulamasa da, bu şimdi EIP7702'nin temel mantıklarından biri haline geldi. EIP7702'deki her işlem, özel işlem yapısı ile birleştirilerek belirli bir kod eklenebilir, böylece bu işlem sırasında EOA hesabı sözleşme yeteneğine sahip olur.

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

Bu, makalenin sonraki tartışma mekanizmasının temel EIP'sidir, Vitalik tarafından EIP-3074'ün alternatif çözümü olarak önerilmiştir. Bu nedenle EIP-3074 terk edilmiştir, EIP-7702'nin yaklaşan ETH Prague/Electra(Pectra) sert çatalında dahil edilmesi kesinleşmiştir, detayları birazdan açacağız.

( 3.2 İkinci yol: EOA adresinin CA adresini yönlendirmesi

EIP-3074: AUTH ve AUTHCALL opcode eklenmesi ) 2020-10-15 ###

EVM'ye AUTH ve AUTHCALL adında iki yeni OpCode eklenmiştir, bu sayede 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, imzalanmış mesajları ( işlemi ) güvenilir sözleşmelere ( gönderebilir ve buna Invoker ) denir. Bu Invoker sözleşmesi, AUTH ve AUTHCALL opcode'larını kullanarak EOA'nın işlem göndermesinin yerini alabilir.

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

MEV'den ilham alarak tasarlandı, temel değeri konsensüs katmanı protokol değişikliklerinden tamamen kaçınabilmektir.

EIP4337, yeni bir işlem nesnesi olan UserOperation'ı öneriyor. Kullanıcı, bu nesneyi bellek havuzuna gönderiyor ve bundler'lar, madenci boyutundan sözleşme yürütme işlemlerini toplu halde paketliyor. Esasen, alt düzey işlemleri ve hesap işlemlerini sözleşme düzeyinde yürütmek için birleştiriyor.

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

Bu, EIP4337 mantığının bir optimizasyonudur; kötü niyetli Bundler'ların DoS engelleme saldırılarını önlemek için fon ceza destekleyici mekanizmaları kurarak karşısında durmaktadır.

( 3.3 Diğer AA'yı destekleyen teklifler

EIP-2718: Yeni işlem türünün paketlenmiş zarfı )2020-06-13###

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

Sonuç olarak, yeni bir işlem türü getirildiğinde, belirli bir kodlama ile işlem çeşitlerini ayırmak yeterlidir, yalnızca geriye dönük uyum sağlamak gerekir, ileriye dönük uyum sağlamaya gerek yoktur. En yaygın örnek EIP1559'dur, işlem ücretlerini ayırır, yeni işlem türü kodlaması kullanır ve başlangıçtaki legacy işlem türünü etkilemez.

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

Bu, EOA adresleriyle çakışmayı önlemek için sözleşme dağıtım adresi üzerinde bir ek çözümdür. Sözleşme oluşturma yöntemini kontrol edecek ve sistemi, zaten bir EOA adresi olan bir adrese kodun dağıtılmasını yasaklayacaktır. Bu risk aslında çok küçüktür, sonuçta Ethereum adresi 160 bit uzunluğundadır, belirli bir sözleşme adresinin özel anahtarını çarpışma yoluyla elde etme yöntemi bulunsa da, Bitcoin ağındaki toplam hesaplama gücüne göre, bunun için bir yıl zaman gerekecektir.

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

Öncelikle CA'ya dönüştürülmüş değerin anlaşılması gerekir.

Temelde EIP-4337'nin pratik etkisidir, şunları gerçekleştirebilir:

Ancak, EIP-4337'nin temel dezavantajı insanlık motivasyon prensibini ihlal etmesidir.

Görünüşte daha iyi, ancak piyasa gelişiminin bir kısır döngüsüne girdi, birçok Dapp hala uyumlu değil, kullanıcılar CA adresi kullanmak istemiyor, hatta CA kullanmanın daha yüksek işlem maliyetleri var ) normal transfer senaryolarında, işlem ücretleri iki katına çıkıyor ###, ayrıca Dapp'in kendisinin uyumluluğuna aşırı bağımlıdır.

Bu nedenle, Ethereum ana ağı üzerinde hala yaygınlaşmamıştır.

Maliyet, kullanıcıların en önemli değerlendirme ölçütüdür, maliyetlerin düşürülmesi gerekmektedir.

Ama GAS'ı gerçekten düşürmek istiyorsak, Ethereum'un kendisi üzerinde bir yumuşak çatal yükseltmesi yapmak, GAS hesaplama veya opcode'un GAS tüketimi gibi modülleri değiştirmek gerekir. Eğer yumuşak çatal yapılacaksa, neden doğrudan EIP-7702'yi düşünmeyelim?

4. EIP-7702'nin Kapsamlı Analizi

( 4.1 EIP-7702 nedir

Yeni işlem türleri ile ayırt edilen bu, EOA'nın tek bir işlemde geçici olarak akıllı sözleşme işlevselliğine sahip olmasına izin verir ve bu sayede iş açısından toplu işlemler, Gas'siz işlemler ve özelleştirilmiş yetki yönetimi gibi işlemleri destekler, ayrıca yeni bir EVM opCode)'in ileriye dönük uyumluluğu etkilemesine gerek yoktur###.

Kullanıcıların akıllı sözleşme dağıtmadan, çoğu AA yeteneğini elde etmelerini sağlar. Hatta üçüncü tarafların kullanıcı adına işlem başlatma yeteneği sunabilir ve kullanıcıdan özel anahtar talep etmeden, yalnızca imza yetkilendirme bilgisi gerektirir.

( 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 kodlamasıdır:

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, imzalayanın EOA'sında gerçekleştirmek istediği kodu saklayan authorization_list nesnesinin eklenmiş olmasıdır. Kullanıcı, işlemi imzalarken aynı zamanda gerçekleştirilecek sözleşme kodunu da imzalar; bu, iki boyutlu bir liste olarak var olup, birden fazla işlem bilgisini toplu olarak saklayabileceğini belirtir ve toplu işlemler gerçekleştirilmesini sağlar.

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 gerçekleştirme sürecinin başlangıç aşamasında, her bir authorization_list için [chain_id, address, nonce, y_parity, r, s] demetini:

1. İmza r, s'den ecrecover kullanarak imzalayanın adresini ### geri alınız. Dikkat, bu Ethereum'un kendine ait bir mekanizmasıdır, bu nedenle bu EIP imza algoritmasını değiştirmemiştir ###. authority = ecrecover(keccak)MAGIC || rlp([chain_id, address, nonce]((, y_parity, r, s])önceki imza çözümlemesinde elde edilen from adresine benzer, burada elde edilen bu listeye yönelik yerel imza adresidir)

2. Zincir ID'sini ( doğrulayın, çatal zincir tekrar oynatmasını ).

3. authority imzalayıcı kodunun boş olup olmadığını veya ('e yetki verilip verilmediğini kontrol et