Ethereum Pectra yükseltmesindeki EIP-7702: EOA'yı güçlendiren büyük bir devrim

Ön söz

Ethereum, Pectra yükseltmesini karşılamaya hazırlanıyor, bu önemli bir güncelleme. Bu kapsamda, EIP-7702, Ethereum dış hesap (EOA) üzerinde devrim niteliğinde bir dönüşüm gerçekleştirdi. Bu öneri, EOA ile sözleşme hesapları CA arasındaki sınırları belirsizleştiriyor ve EIP-4337'den sonra yerel hesap soyutlaması yönünde atılan önemli bir adım olarak, Ethereum ekosistemine yeni bir etkileşim modeli getiriyor.

Pectra, test ağında dağıtımını tamamladı ve yakında ana ağına çıkması bekleniyor. Bu makalede EIP-7702'nin uygulama mekanizması derinlemesine incelenecek, olası fırsatlar ve zorluklar tartışılacak ve farklı katılımcılar için pratik bir işlem kılavuzu sunulacaktır.

Protokol Analizi

Genel Bakış

EIP-7702, EOA'nın bir akıllı sözleşme adresi belirlemesine ve böylece ona kod ayarlamasına izin veren tamamen yeni bir işlem türünü tanıtmaktadır. Bu şekilde, EOA kodu bir akıllı sözleşme gibi çalıştırabilirken, aynı zamanda işlem başlatma yeteneğini de korur. Bu özellik, EOA'ya programlanabilirlik ve birleştirilebilirlik kazandırır; kullanıcılar bu sayede EOA içinde sosyal kurtarma, yetki kontrolü, çoklu imza yönetimi, zk doğrulama, abonelik tabanlı ödemeler, işlem sponsorluğu ve işlem toplu işleme gibi işlevleri gerçekleştirebilir. Ayrıca, EIP-7702'nin EIP-4337 tarafından gerçekleştirilen akıllı sözleşme cüzdanları ile mükemmel uyumlu olduğunu belirtmek gerekir; ikisinin kesintisiz entegrasyonu, yeni işlevlerin geliştirilmesi ve uygulanması sürecini büyük ölçüde basitleştirmiştir.

EIP-7702'nin spesifik uygulaması, SET_CODE_TX_TYPE (0x04) işlem türünü içeren bir işlemi getirmektir. Verinin yapısı aşağıdaki gibi tanımlanmıştı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])

authorization_list alanı şu şekilde tanımlanmıştır:

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

Yeni işlem yapısında, authorization_list alanı dışında kalanlar EIP-4844 ile aynı anlama sahiptir. Bu alan liste türündedir ve listede birden fazla yetkilendirme girişi bulunabilir, her yetkilendirme girişinde:

• chain_id alanı, bu yetkilendirme delegasyonunun geçerli olduğu ağı belirtir.
• address alanı, vekaletin hedef adresini belirtir.
• nonce alanı, geçerli yetkilendirilmiş hesabın nonce'u ile eşleşmelidir.
• y_parity, r, s alanları yetkilendirilmiş hesabın yetkilendirme için imzaladığı imza verileridir.

Bir işlemdeki authorization_list alanı, birden fazla farklı yetkilendirilmiş hesabın ( EOA ) tarafından imzalanan yetkilendirme girişlerini içerebilir; yani işlem başlatıcısı, yetkilendirenle farklı olabilir, böylece yetkilendirenin yetkilendirme işlemleri için gaz ücreti ödenebilir.

gerçekleştirmek

Yetkili, yetkilendirme verilerini imzalamadan önce chain_id, address, nonce değerlerini RLP kodlaması yapmalıdır. Ardından, kodlanmış verileri MAGIC sayısıyla birlikte keccak256 hash işlemi yaparak imzalanacak veriyi elde eder. Son olarak, yetkilinin özel anahtarını kullanarak hashlenmiş veriyi imzalar ve y_parity, r, s verilerini elde eder. Burada, MAGIC (0x05) alan ayırıcı olarak kullanılır ve farklı türdeki imzaların sonuçlarının çakışmamasını sağlamak amacıyla kullanılır.

Dikkat edilmesi gereken husus, yetkilendirenin yetki verdiği chain_id'nin 0 olması durumunda, yetkilendirenin tüm EIP-7702 destekleyen EVM uyumlu zincirlerde yetkilerin yeniden oynatılmasına izin verdiğini göstermesidir (öncelikle nonce'un da tam olarak eşleşmesi şartıyla).

Yetkili, yetkilendirme verilerini imzaladıktan sonra, işlem başlatıcısı bunları authorization_list alanında imzalayıp RPC aracılığıyla işlem yayınlar. İşlem, blok içinde yürütülmeden önce, Proposer işlemi ön kontrol yapar; burada to adresi üzerinde zorunlu bir kontrol gerçekleştirerek bu işlemin bir sözleşme oluşturma işlemi olmadığını garanti eder, yani EIP-7702 türünde bir işlem gönderilirken, işlemin to adresi boş olamaz.

Aynı zamanda, bu tür işlemler, işlemdeki authorization_list alanının en az bir yetkilendirilmiş madde içermesini zorunlu kılar, eğer birden fazla yetkilendirilmiş madde aynı yetkilendiren tarafından imzalanmışsa, o zaman yalnızca son yetkilendirilmiş madde geçerli olacaktır.

Sonrasında, işlem yürütme sürecinde, düğüm öncelikle işlem başlatıcısının nonce değerini artıracak, ardından authorization_list içindeki her bir yetkilendirme kalemi için applyAuthorization işlemini gerçekleştirecektir. applyAuthorization işleminde, düğüm önce yetkilendirenin nonce'unu kontrol edecek, ardından yetkilendirenin nonce'unu artıracaktır. Bu, eğer işlem başlatıcısı ve yetkilendiren aynı kullanıcıysa (EOA), yetkilendirme işlemi imzalanırken nonce değerinin 1 artırılması gerektiği anlamına gelir.

Bir düğüm belirli bir yetkilendirme maddesini uygularken herhangi bir hata ile karşılaşırsa, bu yetkilendirme maddesi atlanacak, işlem başarısız olmayacak ve diğer yetkilendirme maddeleri uygulamaya devam edecektir. Böylece toplu yetkilendirme senaryolarında DoS riski ortaya çıkmayacaktır.

Yetkili uygulama tamamlandıktan sonra, yetkilendiren adresin code alanı 0xef0100 || address olarak ayarlanacaktır, burada 0xef0100 sabit bir kimliktir, address ise devredilen hedef adrestir. EIP-3541'in kısıtlamaları nedeniyle, kullanıcıların 0xef baytı ile başlayan sözleşme kodunu normal yollarla dağıtması mümkün değildir, bu nedenle bu tür kimliklerin yalnızca SET_CODE_TX_TYPE (0x04) türündeki işlemlerle dağıtılması sağlanır.

Yetki tamamlandıktan sonra, yetki veren kişi yetkisini kaldırmak isterse, yalnızca vekalet verilen hedef adresini 0 adresi olarak ayarlaması yeterlidir.

EIP-7702 ile tanıtılan yeni işlem türü, yetkililerin ( EOA ) gibi akıllı sözleşmeler gibi kod çalıştırmalarını sağlar ve aynı zamanda işlem başlatma yeteneğini korur. EIP-4337 ile karşılaştırıldığında, bu kullanıcıya yerel hesap soyutlaması ( Native AA ) deneyimine daha yakın bir deneyim sunar ve kullanıcıların kullanım eşiğini büyük ölçüde düşürür.

En İyi Uygulamalar

EIP-7702'nin Ethereum ekosistemine yeni bir canlılık katmasına rağmen, yeni uygulama senaryoları da yeni riskler getirecektir. İşte ekosistem katılımcılarının uygulama sürecinde dikkat etmesi gereken noktalar:

özel anahtar saklama

EOA, akıllı sözleşmelerin yerleşik sosyal kurtarma gibi yöntemler kullanarak özel anahtar kaybından kaynaklanan fon kaybı sorunlarını çözebilse de, EOA özel anahtarının sızma riskini ortadan kaldırmaz. Şunu netleştirmek gerekir ki, yetkilendirme işlemi gerçekleştirildikten sonra, EOA özel anahtarı hâlâ hesap üzerinde en yüksek kontrol yetkisine sahiptir; özel anahtar sahibi, hesap içindeki varlıkları dilediği gibi tasfiye edebilir. Kullanıcılar veya cüzdan hizmet sağlayıcıları, EOA'nın yetkilendirme işlemini tamamladıktan sonra, yerel olarak saklanan özel anahtarı tamamen silseler bile, özel anahtarın sızma riskini tamamen ortadan kaldıramazlar, özellikle tedarik zinciri saldırısı riski bulunan senaryolar söz konusu olduğunda.

Kullanıcılar için, yetkilendirilmiş hesapları kullanırken, kullanıcıların her zaman özel anahtar korumasını öncelikli hale getirmeleri ve sürekli dikkat etmeleri gerekir: Not your keys, not your coins.

Çoklu Zincir Yeniden Oynama

Kullanıcı, yetki devri imzalarken, chainId aracılığıyla yetkinin geçerli olacağı zinciri seçebilir; elbette kullanıcı, yetki devri için chainId'si 0 olanı da seçebilir. Bu, yetkinin birden fazla zincir üzerinde tekrar geçerli olmasını sağlar ve kullanıcıların tek bir imza ile birden fazla zincir üzerinde yetki devretmelerine olanak tanır. Ancak dikkat edilmesi gereken nokta, birden fazla zincirdeki aynı akıllı sözleşme adresinde farklı uygulama kodlarının mevcut olabileceğidir.

Cüzdan hizmet sağlayıcıları için, kullanıcı delegasyon yaptığında, delegasyonun geçerli olduğu zincirin mevcut bağlı olduğu ağ ile uyumlu olup olmadığını kontrol etmeli ve kullanıcılara chainId'si 0 olan delegasyonun getirebileceği riskleri bildirmelidir.

Kullanıcılar ayrıca, farklı zincirlerdeki aynı sözleşme adreslerinin, sözleşme kodlarının her zaman aynı olmadığını dikkate almalıdır, öncelikle taahhüt edilen hedefi anlamalıdır.

Başlatılamadı

Mevcut ana akım akıllı sözleşme cüzdanlarının çoğu, proxy modeli kullanmaktadır. Cüzdan proxy'si dağıtım sırasında, DELEGateCALL ile sözleşmenin başlatma fonksiyonunu çağırarak cüzdanın başlatılmasını ve proxy cüzdanın dağıtımını atomik bir işlem olarak gerçekleştirmekte, böylece erken başlatma sorununu önlemektedir. Ancak kullanıcılar EIP-7702'yi kullanarak vekalet verirken, yalnızca adresinin code alanını güncelleyebilmekte, vekalet verilen adres aracılığıyla başlatma işlemi gerçekleştiremektedir. Bu durum, EIP-7702'nin yaygın ERC-1967 proxy sözleşmeleri gibi dağıtım işleminde başlatma fonksiyonunu çağırarak cüzdan başlatma işlemini gerçekleştirememesine neden olmaktadır.

Geliştiriciler için, EIP-7702'yi mevcut EIP-4337 cüzdanlarıyla birleştirirken, cüzdanın başlatma işlemi sırasında izin kontrolü yapılmasına (örneğin, ecrecover ile imza adresinin geri alınması yoluyla izin kontrolü yapılması) dikkat edilmelidir; bu, cüzdanın başlatma işleminin başkaları tarafından geçilme riskini önlemek içindir.

Depolama Yönetimi

Kullanıcılar EIP-7702 vekalet işlevini kullanırken, işlev gereksinimlerinin değişmesi, cüzdan güncellemeleri gibi nedenlerle farklı bir akıllı sözleşme adresine yeniden vekalet vermek isteyebilir. Ancak farklı sözleşmelerin depolama yapıları arasında farklılıklar olabilir (örneğin, farklı sözleşmelerin slot0 alanı farklı türde verileri temsil edebilir), yeniden vekalet verme durumunda, yeni sözleşmenin eski sözleşmenin verilerini yanlışlıkla yeniden kullanmasına neden olabilecek bir durum ortaya çıkabilir ve bu da hesap kilitlenmesi, fon kaybı gibi olumsuz sonuçlara yol açabilir.

Kullanıcılar için, yeniden devretme durumunu dikkatli bir şekilde ele almak önemlidir.

Geliştiriciler için, geliştirme sürecinde ERC-7201 tarafından önerilen Namespace Formula'sına uymak, değişkenleri belirlenen bağımsız depolama konumlarına atamak, depolama çakışması riskini azaltmak için önemlidir. Ayrıca, ERC-7779 (draft), EIP-7702 için yeniden devretme standart sürecini sunmaktadır: depolama çakışmalarını önlemek için ERC-7201 kullanmak ve yeniden devretmeden önce depolama uyumluluğunu doğrulamak, ayrıca eski devirleri çağırarak depolamanın eski verilerini temizlemek.

sahte yükleme

Kullanıcılar yetki verdikten sonra, EOA aynı zamanda akıllı sözleşme olarak kullanılabilecektir, bu nedenle merkezi borsa (CEX) akıllı sözleşme ile para yatırma işlemlerinin yaygınlaşması ile karşılaşabilir.

CEX, her bir para yatırma işleminin durumunu trace ile kontrol etmeli ve akıllı sözleşme sahte para yatırma risklerini önlemelidir.

Hesap Dönüşümü

EIP-7702 yetkilendirmesi uygulandıktan sonra, kullanıcı hesap türleri EOA ile SC arasında serbestçe dönüşebilir, bu da hesapların hem işlem başlatabilmesini hem de çağrılabilmesini sağlar. Bu, hesabın kendisini çağırması ve dışarıdan bir çağrı yapması durumunda, msg.sender'ın tx.origin olacağı anlamına gelir, bu da yalnızca EOA'nın proje katılımı için güvenlik varsayımlarını ihlal eder.

Sözleşme geliştiricileri için, tx.origin'in her zaman EOA olduğu varsayımı artık geçerli olmayacak. Aynı şekilde, msg.sender == tx.origin kontrolü ile yeniden giriş saldırılarına karşı savunma da etkisiz hale gelecektir.

Geliştiricilerin geliştirme sürecinde gelecekteki katılımcıların akıllı sözleşmeler olabileceğini varsayması gerekir.

Sözleşme Uyumluluğu

Mevcut ERC-721, ERC-777 token'ları sözleşmeye transfer yaparken Hook işlevine sahiptir, bu da alıcının token'ları başarıyla alabilmesi için ilgili geri arama fonksiyonunu uygulaması gerektiği anlamına gelir.

Geliştiriciler için, kullanıcıların yetkilendirdiği hedef sözleşmenin ilgili geri çağırma işlevlerini uygulaması beklenir, böylece ana akım tokenlerle uyumlu olabilecektir.

Olta Kontrolü

EIP-7702 yetkilendirmesi uygulandıktan sonra, kullanıcı hesaplarındaki varlıklar akıllı sözleşmeler tarafından kontrol edilebilir hale gelecektir. Kullanıcı hesaplarını kötü niyetli bir sözleşmeye yetkilendirdiğinde, saldırganların fonları çalması oldukça kolaylaşacaktır.

Cüzdan sağlayıcıları için, mümkün olan en kısa sürede EIP-7702 türü işlemleri desteklemek son derece önemlidir ve kullanıcılar delege imzası yaptıklarında, kullanıcıya delege edilen hedef sözleşmeyi vurgulayarak göstermelidir, böylece kullanıcıların olası bir kimlik avı saldırısına maruz kalma riskini azaltabilir.

Ayrıca, hesap delegasyonuna tabi hedef sözleşmelerin daha derinlemesine otomatik analizi (açık kaynak kontrolü, izin kontrolü vb.) kullanıcıların bu tür risklerden kaçınmalarına daha iyi yardımcı olabilir.

Özet

EIP-7702, yeni bir işlem türü tanıtarak EOA'nın programlanabilirliğini ve birleştirilebilirliğini sağlar, EOA ile akıllı sözleşme hesapları arasındaki sınırları bulanıklaştırır. Şu anda pratikte test edilmiş bir EIP-7702 uyumlu akıllı sözleşme standardı olmadığından, farklı ekosistem katılımcıları, kullanıcılar, cüzdan hizmet sağlayıcıları, geliştiriciler, CEX gibi, birçok zorluk ve fırsatla karşı karşıya kalmaktadır. Bu yazıda açıklanan en iyi uygulamalar içeriği, tüm potansiyel riskleri kapsamayabilir, ancak yine de tarafların pratik uygulamalarda dikkate alması için değerlidir.