Ethereum Pectra yükseltmesi: EIP-7702 Derinlik analizi ve en iyi uygulama rehberi

Ön söz

Ethereum, önemli bir güncelleme olan Pectra yükseltmesini karşılamaya hazırlanıyor. Bu güncelleme kapsamında, 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ştirdi ve yerel hesap soyutlamasına doğru atılmış önemli bir adım olarak, Ethereum ekosistemine yeni bir etkileşim modeli getirdi.

Pectra, test ağında dağıtımı tamamladı ve yakın zamanda ana ağa geçmesi bekleniyor. Bu makalede EIP-7702'nin gerçekleştirme mekanizması derinlemesine incelenecek, olası fırsatlar ve zorluklar tartışılacak ve farklı katılımcılara pratik bir kullanım kılavuzu sunulacaktır.

Protokol Analizi

Genel Bakış

EIP-7702, EOA'nın akıllı sözleşme adresini belirlemesine ve ona kod ayarlamasına izin veren yeni bir işlem türü getirmektedir. Bu, EOA'nın tıpkı akıllı sözleşmeler gibi kod yürütmesini sağlar, aynı zamanda işlem başlatma yeteneğini korur. Bu özellik, EOA'ya programlanabilirlik ve bileşenlik kazandırır; kullanıcılar EOA içinde sosyal kurtarma, yetki kontrolü, çoklu imza yönetimi, zk doğrulama, abonelik bazlı ödeme, işlem sponsorlama ve işlem toplu işleme gibi işlevleri gerçekleştirebilirler. Dikkate değer bir nokta, EIP-7702'nin EIP-4337 ile gerçekleştirilen akıllı sözleşme cüzdanlarıyla mükemmel uyumlu olmasıdır; bu da yeni özelliklerin geliştirilmesi ve uygulanması sürecini basitleştirir.

EIP-7702, SET_CODE_TX_TYPE (0x04) işlem türünü tanıtmaktadır ve veri 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ı hariç, diğer tüm alanlar EIP-4844 ile aynı anlamı taşımaktadır. authorization_list, birden fazla yetkilendirme kaydı içerebilen bir liste türüdür. Her yetkilendirme kaydında:

• chain_id, yetkilendirme delegasyonunun geçerli olduğu ağı belirtir.
• address, yetkilendirilmiş hedef adresi ifade eder.
• nonce, mevcut yetkilendirilmiş hesabın nonce'u ile eşleşmelidir.
• y_parity, r, s yetkilendirilmiş hesabın yetkilendirmeyi imzaladığı imza verileridir

Bir işlemin authorization_list'i, birden fazla farklı yetkilendirilmiş hesabı içerebilir. ( EOA ) tarafından imzalanan yetkilendirme maddeleri, yetkilendirenin yetkilendirme işlemlerinin gaz ücretlerinin ödenmesini sağlar.

gerçekleştirmek

Yetkili, yetkilendirme verilerini imzalamadan önce chain_id, address, nonce değerlerini RLP kodlaması yapmalıdır. Ardından kodlanmış veriyi MAGIC sayısı ile birlikte keccak256 hash işlemi gerçekleştirilerek imzalanacak veri elde edilir. Son olarak, yetkilinin özel anahtarı ile hash'lenmiş veriyi imzalayarak y_parity, r, s verileri elde edilir. MAGIC (0x05) alan ayırıcı olarak kullanılır, farklı türdeki imzaların sonuçlarının çakışmadığından emin olmak için.

Yetkili tarafından yetki verilen chain_id 0 olduğunda, yetkilinin EIP-7702'yi destekleyen tüm EVM uyumlu zincirlerde yetkilerin yeniden oynanmasına izin verdiği anlamına gelir (ön koşul nonce'un da tam olarak eşleşmesidir).

Yetkili, yetkilendirme verilerini imzaladıktan sonra, işlem başlatıcısı bunları authorization_list alanında imzalar ve işlemi RPC üzerinden yayar. İşlem gerçekleştirilmeden önce, Proposer ön kontrol yapar ve bu işlemin bir sözleşme oluşturma işlemi olmadığını garanti eder, yani EIP-7702 tipi işlemi gönderirken, işlemin to adresi boş olamaz.

Bu tür işlemler, authorization_list alanının en az bir yetki maddesi içermesini gerektirir. Eğer birden fazla yetki maddesi aynı yetkilendiren tarafından imzalanmışsa, sadece son yetki maddesi geçerli olacaktır.

İşlem gerçekleştirildiğinde, düğüm önce işlem başlatıcısının nonce değerini artırır, ardından authorization_list içindeki her yetkilendirme kaydı için applyAuthorization işlemi gerçekleştirir. applyAuthorization işlemi sırasında düğüm önce yetkilendirenin nonce'unu kontrol eder, ardından yetkilendirenin nonce'unu artırır. Bu, eğer işlem başlatıcısı ile yetkilendiren aynı kullanıcı ise (EOA), yetkilendirme işlemini imzalarken nonce değerinin 1 artırılması gerektiği anlamına gelir.

Düğüm uygulama yetkilendirme girişi sırasında herhangi bir hata ile karşılaşılırsa, bu giriş atlanacak, işlem başarısız olmayacak ve diğer yetkilendirme girişleri uygulamaya devam edecektir; bu, toplu yetkilendirme senaryolarında DoS riskini önlemek içindir.

Yetki verilen uygulama tamamlandığında, yetkilendiren adresin code alanı 0xef0100 || address olarak ayarlanacaktır; burada 0xef0100 sabit bir tanımlayıcıdır, address ise yetkilendirilen hedef adrestir. EIP-3541'in kısıtlamaları, bu tür tanımlayıcıların yalnızca SET_CODE_TX_TYPE (0x04) türündeki işlemlerle dağıtılabileceğini garanti eder.

Yetki tamamlandıktan sonra, yetkilendiren kişinin yetkiyi kaldırmak istemesi durumunda, yalnızca yetkilendirilmiş hedef adresini 0 adresi olarak ayarlaması yeterlidir.

EIP-7702 ile tanıtılan yeni işlem türü, yetkilendirici (EOA)'in akıllı sözleşmeler gibi kod yürütmesini ve işlem başlatma yeteneğini korumasını sağlar. EIP-4337'ye kıyasla, bu kullanıcıya yerel hesap soyutlaması (Native AA) deneyimine daha yakın bir deneyim sunar ve kullanım engelini büyük ölçüde azaltır.

En İyi Uygulamalar

EIP-7702, Ethereum ekosistemine yeni bir canlılık kazandırırken, yeni uygulama alanları da yeni riskler getirmektedir. Aşağıda ekosistem katılımcılarının uygulama sürecinde dikkat etmesi gereken noktalar yer almaktadır:

özel anahtar saklama

EOA'nın yetkilendirilmesinden sonra, akıllı sözleşmelerin yerleşik sosyal kurtarma gibi yöntemleri sayesinde özel anahtar kaybından kaynaklanan fon kaybı sorunları çözülebilse de, EOA özel anahtarının sızdırılma riskini ortadan kaldırmak mümkün değildir. Yetkilendirme işlemi sonrasında, EOA özel anahtarı hala hesaba en yüksek kontrol yetkisine sahiptir; özel anahtara sahip olan, hesaptaki varlıkları dilediği gibi tasfiye edebilir. Kullanıcılar veya cüzdan hizmet sağlayıcıları, EOA'ya yetki verdikten sonra yerel olarak depolanan özel anahtarı tamamen silseler bile, özel anahtarın sızdırılma riskini tamamen ortadan kaldıramazlar; özellikle tedarik zinciri saldırısı riski bulunan senaryolarda.

Kullanıcılar için, vekaletle işlem yapılan hesapları kullanırken, özel anahtar korumasını her zaman öncelikli hale getirmeli ve her zaman dikkatli olmalıdır: Not your keys, not your coins.

Çoklu zincir tekrar

Kullanıcı yetkilendirme yetkisini imzalarken, chainId üzerinden yetkilendirmenin geçerli olacağı zinciri seçebilir veya 0 olarak chainId seçerek yetkilendirmeyi çoklu zincirlerde geçerli hale getirebilir. Bu sayede kullanıcı, tek bir imza ile çoklu zincirlerde yetkilendirme yapabilir. Ancak, çoklu zincirlerdeki aynı akıllı sözleşme adresinde farklı uygulama kodları bulunabileceğini unutmamak gerekir.

Cüzdan hizmet sağlayıcıları, kullanıcılar yetki devri yaparken, yetki devri geçerlilik zincirinin mevcut bağlantılı ağ ile uyumlu olup olmadığını kontrol etmeli ve kullanıcılara chainId'si 0 olan yetki devri imzalamalarının getirebileceği riskleri hatırlatmalıdır.

Kullanıcılar, farklı blok zincirlerindeki aynı sözleşme adreslerinin sözleşme kodlarının her zaman aynı olmadığını dikkate almalıdır, öncelikle vekalet verilen hedefi anlamalıdır.

başlatılamıyor

Günümüzdeki popüler akıllı sözleşme cüzdanları genellikle proxy modelini kullanmaktadır. Cüzdan proxy, dağıtım sırasında DELEGateCALL çağrısı ile sözleşmenin başlatma fonksiyonunu gerçekleştirerek cüzdanın başlatılması ile proxy cüzdan dağıtımını atomik bir işlem haline getirir ve önceden başlatılma sorununu önler. Ancak kullanıcı EIP-7702 kullanarak vekalet verdiğinde, yalnızca adresinin code alanını günceller, vekalet verilen adresi çağırarak başlatma gerçekleştiremez. Bu, EIP-7702'nin, yaygın ERC-1967 proxy sözleşmeleri gibi, sözleşme dağıtım işlemi sırasında başlatma fonksiyonunu çağırarak cüzdan başlatımını gerçekleştirmesini engeller.

Geliştiriciler, EIP-7702'yi mevcut EIP-4337 cüzdanıyla birleştirip uyumlu hale getirirken, cüzdanın başlatma işlemi sırasında yetki kontrolü yapmalıdır (örneğin, yetki kontrolü için ecrecover ile imza adresini geri kazanarak), böylece cüzdanın başlatma işleminin kapıdan hızlıca çıkma riski önlenmiş olur.

Depo Yönetimi

Kullanıcılar EIP-7702 delegasyon fonksiyonunu kullanırken, fonksiyon ihtiyaçlarındaki değişiklikler, cüzdan güncellemeleri gibi nedenlerle farklı bir sözleşme adresine yeniden delegasyon yapmaları gerekebilir. Ancak farklı sözleşmelerin depolama yapıları arasında farklılıklar olabilir (örneğin, farklı sözleşmelerin slot0 yuvası farklı veri türlerini temsil edebilir), yeniden delegasyon, yeni sözleşmenin eski sözleşmenin verilerini yanlışlıkla kullanmasına neden olabilir ve bu da hesap kilitlenmesi, fon kaybı gibi olumsuz sonuçlara yol açabilir.

Kullanıcı, yeniden devir durumlarını dikkatlice ele almalıdır.

Geliştiricilerin geliştirme sürecinde ERC-7201 tarafından önerilen Namespace Formula'sına uyması, değişkenlerin belirli bağımsız depolama alanlarına atanarak depolama çakışması riskini azaltması gerekir. Ayrıca ERC-7779 (draft), EIP-7702 için yeniden delege etme standart sürecini sağlamaktadır: depolama çakışmalarını önlemek için ERC-7201 kullanmayı, yeniden delege etmeden önce depolama uyumluluğunu doğrulamayı ve eski delege arayüzünü çağırarak eski verilerin depolamadan temizlenmesini içermektedir.

sahte yükleme

Kullanıcı yetki verdikten sonra, EOA akıllı sözleşme olarak da kullanılabilir, bu nedenle merkezi borsa (CEX) akıllı sözleşme ile para yatırmanın yaygınlaşmasıyla karşılaşabilir.

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

Hesap Dönüşümü

EIP-7702 delegasyonu uygulandıktan sonra, kullanıcı hesap türleri EOA ve SC arasında serbestçe dönüştürülebilir, hesaplar hem işlem başlatabilir hem de çağrılabilir. Bu, hesabın kendisini çağırdığı ve dışarıdan bir çağrı yaptığı zaman, msg.sender'ın aynı zamanda tx.origin olacağı anlamına gelir; bu da yalnızca EOA'nın katıldığı projelerin güvenlik varsayımlarını ihlal edecektir.

Sözleşme geliştiricileri, tx.origin'in her zaman EOA olduğunu varsaymamalıdır. Aynı şekilde, msg.sender == tx.origin kontrolü ile yeniden giriş saldırılarına karşı korunma da geçersiz hale gelecektir.

Geliştiriciler, geliştirme sürecinde gelecekteki katılımcıların akıllı sözleşmeler olabileceğini varsaymalıdır.

Sözleşme Uyumluluğu

Mevcut ERC-721 ve ERC-777 token'ları, sözleşmelere transfer yaparken Hook işlevine sahiptir; bu, alıcının token'ları başarıyla alabilmesi için ilgili geri çağırma işlevini uygulaması gerektiği anlamına gelir.

Geliştiriciler, kullanıcıların devrettiği hedef sözleşmenin ilgili geri çağırma fonksiyonlarını gerçekleştirdiğinden emin olmalıdır, böylece ana akım tokenlerle uyumlu olmasını sağlar.

Balık tutma 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ı son derece kolaylaşacaktır.

Cüzdan hizmet sağlayıcıları, kullanıcıların yetki devri imzası yaptığı zaman, kullanıcıya yetki devredilen hedef akıllı sözleşmeyi vurgulayarak, kullanıcıların olası bir phishing saldırısına maruz kalma riskini azaltmak için EIP-7702 türündeki işlemleri bir an önce desteklemelidir.

Ayrıca, hesap delegasyonunun hedef sözleşmeleri üzerinde daha derinlemesine otomatik analiz (açık kaynak kontrolü, yetki kontrolü vb.) yapmak, kullanıcıların bu tür risklerden kaçınmalarına daha iyi yardımcı olabilir.

Özet

Bu makale, Ethereum'un yakında gerçekleşecek Pectra güncellemesindeki EIP-7702 önerisi etrafında dönmektedir. EIP-7702, yeni bir işlem türü tanıtarak EOA'nın programlanabilirliğini ve birleştirilebilirliğini sağlar, böylece EOA ile sözleşme hesapları arasındaki sınırları belirsizleştirir. Mevcut durumda, pratikte test edilmiş EIP-7702 türü akıllı sözleşme standartları bulunmadığından, farklı ekosistem katılımcıları, kullanıcılar, cüzdan hizmet sağlayıcıları, geliştiriciler, CEX vb. birçok zorluk ve fırsatla karşı karşıyadır. Bu makalede açıklanan en iyi uygulama içeriği tüm potansiyel riskleri kapsayamaz, ancak yine de her tarafın pratik uygulamalarda dikkate alması gereken bir kaynak niteliğindedir.