Fiyatlar yükleniyor…

Akıllı Kontrat Cüzdanı Hesabını ve Oturumlarını Nasıl Okursunuz

Akıllı hesap işlemi tek bir işlem değildir. Paylaşılan bir EntryPoint'in yönlendirdiği, bir bundler'ın ilettiği ve bir paymaster'ın sponsor olabildiği bir UserOperation'dır. Onaylamadan önce her alanı nasıl okuyacağınızı öğrenin.

Akıllı Kontrat Cüzdanı Hesabını ve Oturumlarını Nasıl Okursunuz

Akıllı hesap neden farklı bir zihinsel modeldir

Bir adresi kopyaladıysanız, blok gezgininde kontrol ettiyseniz ve bir işlemin ne yaptığını çözmeye çalıştıysanız, bir anahtarın bir hesabı kontrol ettiği varsayımından yola çıkıyorsunuzdur. Akıllı sözleşme cüzdanları bu varsayımı bozar. Etherscan'da veya benzeri bir gezginde gördüğünüz adres bir anahtar değildir. Bir sözleşmedir. Sözleşme varlıklara sahiptir, kuralları uygular ve hangi talimatların kabul edileceğine karar verir. Kullanıcı, daha doğrusu o anda hareket etmesine izin verilen anahtar veya oturumlar kümesi, talimatlarını ayrı bir boru hattı aracılığıyla bu sözleşmeye gönderir.

Tek bir zincir üstü işlemin blok gezgininde neden sık sık gürültülü göründüğünü bu açıklar. Tek bir işlem gibi görünen şey, dahilen birkaç katmandır: kullanıcının imzaladığı niyet, onu gönderen bir relayer, onu doğrulayan bir EntryPoint sözleşmesi, isteğe bağlı olarak gas ödeyen paymaster mantığı ve akıllı hesabın içinde gerçek işlemi çalıştıran callData. Zincir üstündeki biçim başta tanıdık değildir ve saldırganların tam olarak güvendiği şey de bu tanıdık olmama halidir.

İşlem ve UserOperation: temel fark

Normal bir Ethereum işleminin okunabilir altı alanı vardır: from, to, value, data, gas limit ve signature. ERC-4337 standardı kapsamında tanımlanan bir UserOperation, devredilmiş ve desteklenen çalıştırma için tasarlanmış alanlar ekler. Okuma açısından en çok önemli olanlar şunlardır: akıllı hesap adresi olan sender; EOA nonce'una bağlı olmayan, hesaba özel nonce; ilk kullanımda hesabı dağıtan initCode; onaylanırsa akıllı hesabın çalıştıracağı callData; bir ECDSA imzası, bir bundler'dan gelen toplu bir BLS imzası veya hesabın kendisi tarafından tanımlanan bir validator kancası olabilen signature.

Düz işlemlerde bulunmayan bir gas ödemeleri katmanı da vardır. paymasterAndData, bundler'a geri ödeme yapacak paymaster sözleşmesini gösterir. Paymaster, sizi sponsor etmeyi kabul etmeden önce UserOperation'ınızı incelemeye yetkilidir ve bazı uygulamalarda çağrınız tamamlandıktan sonra çalışan postOp adımını değiştirebilir. Bu post-op geri çağrısı gerçek bir saldırı yüzeyidir: kötü niyetli bir paymaster, çağrınızın dönüş verilerini okuyabilir ve bunları yetkilendirmediğiniz şekillerde kullanabilir. Paymaster'lara herhangi bir muhatap gibi davranın, çünkü sıkı bir anlamda onlar tam olarak odur.

Bir UserOperation'ı okumak bu nedenle en azından dört şeyi kontrol etmek demektir: sender'ın gerçekten sahip olduğunuz veya beklediğiniz bir sözleşmeyi gösterdiğini, callData'nın yetkilendirdiğiniz adresleri (bir oturum veya koruyucu onaylı beyaz liste) hedeflediğini, gas parametrelerinin absürt şekilde yüksek olmadığını ve paymaster'ın davranışına güvendiğiniz biri olduğunu.

EntryPoint sözleşmesi: paylaşılan altyapı riski

Yazıldığı sırada Ethereum ana ağında her ERC-4337 akıllı hesabı tek bir EntryPoint adresini paylaşır. Standart açıkça birden fazla EntryPoint sürümüne izin verse de pratikte tek bir kurallı dağıtım faaliyetlerin büyük bölümünü taşır. Bu merkezileşme bilinçli bir tasarım tercihidir: paylaşılan bir EntryPoint, paketleyicilerin, paymaster'ların ve hesap uygulamalarının ikili entegrasyonlara gerek kalmadan birlikte çalışmasını sağlar. Aynı zamanda riski de tek noktada toplar.

EntryPoint yükseltilirse, bir yönetim oyuyla ele geçirilirse ya da bir güvenlik açığı barındırdığı ortaya çıkarsa, üzerinden geçen her akıllı hesap aynı anda etkilenir. Bu varsayımsal bir durum değildir. 2023'ün sonlarında EntryPoint ile ilişkili bir kütüphane etrafındaki denetçi kaynaklı bir olay kamuya duyuruldu ve entegrasyonlar genelinde yamandı. Büyük ölçekte bir kayıp yaşanmadı, ancak ders açıktı: paylaşılan altyapı tek bir arıza noktasıdır ve hesabınızın güvenliği yalnızca bu yığındaki en zayıf bileşen kadar güçlüdür.

Bu nedenle zincir üstü verileri okurken hesabınızın yönlendirildiği EntryPoint'in beklediğiniz sürüm olduğunu hızlıca kontrol etmek gerekir. Ana ağ ve çoğu L2, kurallı EntryPoint adreslerini yayımlar ve Etherscan gibi araçlar denetlenen dağıtımları etiketler. Bir UserOperation'ın kurallı olmayan bir EntryPoint'e gönderildiğini görürseniz bunu güçlü bir uyarı işareti olarak değerlendirin: bu durum, imzaları ele geçirmek için tasarlanmış bir kimlik avı relayer'ı ya da bir fork olabilir.

Oturum anahtarları: kapsamı ve süresi sınırlı alt onaylar

Oturumlar, en çok anlaşılmayı hak eden, ama aynı zamanda en çok suistimal edilen özelliktir. Oturum anahtarı, belirli bir uygulamaya, tanımlı bir zaman aralığında ve tanımlı bir izin kümesiyle verdiğiniz ikincil bir imzalayıcıdır. Pratikte bu, bir dApp'in sizin adınıza önümüzdeki bir saat boyunca, belirli bir harcama üst limitiyle ve izin verilen token sözleşmeleri listesiyle Uniswap üzerinde işlem yapma izni istemesi gibi görünür.

Zincir üstünde oturum, akıllı hesabınızın içindeki bir state olarak yaşar. Depolamada genellikle şu sırayla görünen ilgili alanlar şunlardır: yetkilendirilmiş bir oturum anahtarı adresi; bir son kullanma zaman damgası ya da blok numarası; dönem başına bir harcama limiti (çoğunlukla günlük ya da dönem başına); bir hedef izin listesi ya da seçici izin listesi; ve ek kurallar uygulayabilen bir politika kancası. Uygulamalar farklılık gösterir. Safe Modules, Zodiac Heads, Biconomy oturumları ve Kernel oturum doğrulayıcıları bunları biraz farklı kodlar ve doğrudan depolamayı okurken tam yuva düzeni önemlidir.

Akılda tutulması gereken nokta, oturumların varsayılan olarak güvenli olmadığı, yalnızca sınırlı olduğudur. Uniswap'in yönlendiricisiyle sınırlanmış bir oturum, ancak Uniswap'in yönlendiricisi kadar iyidir. Seçici izin listesi veren bir oturum, uygulama hangi seçicileri çağıracağını biliyorsa yine tehlikeli olanlara denk gelebilir. Dönem sıfırlamalı bir harcama limiti uygulamayan oturumlar ise kullanıcı dikkat etmeyi bıraktığında zaman içinde fonları tüketebilir.

İki pratik alışkanlık yardımcı olur. Birincisi, cüzdan arayüzünün gösterdiği tam depolama yuvasını ya da çözümlenmiş görünümü oturum iznini imzalamadan önce okuyun ve bunu dApp'in pazarlama metni değil, gerçek kaynak olarak kabul edin. İkincisi, hem dönem başına bir üst limit hem de çağrı başına bir üst limit içeren oturumları tercih edin; böylece tek bir kontrol dışı çağrı makul bir maksimumu aşamaz.

Tek bir UserOperation'ı ayrıntılı okumak

Cüzdanınızda 0xabc... gibi bir karmanın göründüğünü ve bunun gerçekte ne yaptığını öğrenmek istediğinizi hayal edin. İşlemi bir blok gezgininde açın, ardından callData'sı handleOps ile başlayan EntryPoint işlemine tıklayın. Dahili işlemler sekmesi asıl hikâyeyi anlatır.

Adım 1: validateUserOp

EntryPoint önce hesabınızın validateUserOp fonksiyonunu geri çağırır. İmza burada kontrol edilir, nonce'lar yeniden oynatma korumasına karşı doğrulanır ve oturum politikaları uygulanır. Başarısız bir doğrulama tüm paketi geri alır; bu nedenle başarılı bir çalıştırma, en az bir geçerli imzalayıcının işlemi onayladığına dair kanıttır.

Adım 2: execute

Doğrulama geçerse EntryPoint, sağladığınız callData ile hesabınızın execute fonksiyonunu çağırır. Bu, kullanıcının gördüğü eylemdir: bir takas, bir transfer ya da bir sözleşme etkileşimi. Bu dahili çağrının callData'sını okumak, kullanıcının istediği asıl hedefi, değeri ve fonksiyon seçicisini verir.

Adım 3: postOp

Yürütmenin ardından paymaster'ın postOp fonksiyonu çalışır; bu, gaz borçlarının kapatılması, kullanılmayan gazın iade edilmesi ya da paketleyiciye ödeme yapılması gibi işler için kullanılır. Buradaki herhangi bir state değişikliği sizin doğrudan verdiğiniz bir izinle değil, paymaster tercihinizle yetkilendirilmiştir. Burada gerçekleşen tuhaf şeyler, örneğin fazladan token transferleri ya da yeni onaylar, daha ayrıntılı inceleme yapmanız için bir işarettir.

Bu üç katmanı bir araya getirmek, kimin neyi onayladığını, neyin çalıştırıldığını ve sonrasında hangi yan etkilerin oluştuğunu gösterir. Çoğu kimlik avı kalıbı, neye bakmanız gerektiğini bildiğinizde bu düzeyde görünür hâle gelir.

Paymaster'lar ve paketleyiciler: görünürlük ve güven

Paketleyici, UserOperation'ınızı alıp diğerleriyle paketleyen ve EntryPoint'e gerçek zincir üstü işlemi gönderen taraftır. EntryPoint.handleOps'u çağıran taraf paketleyici olduğu için gazı zincir düzeyinde paketleyicinin adresi öder. Akıllı hesap sahibi olarak, bir paymaster sponsor olmaya razıysa gaz için ETH'ye hiçbir zaman ihtiyacınız olmaz. Bu rahattır, ama aynı zamanda bir güven ilişkisidir.

Bir paymaster'ın taahhüdü zincir üstünde iki şekilde kodlanır: EntryPoint'e yatırdığı teminat (standart kuralları kapsamında kötü davranış nedeniyle kesilebilir) ve sponsor olup olmayacağına karar veren validatePaymasterUserOp fonksiyonunun politikası. Kesme mekanizması vardır, ancak kaba bir son çare, ince ayarlı bir garanti değildir. Bir paymaster yine de gördüğü işlemleri izleyebilir, sansürleyebilir ya da öne geçebilir.

En az tartışılan risk öne geçme (front-running) riskidir. Swap'ınızı yürütülmeden önce gören bir paymaster, işlemi kendi adresine kopyalayıp aynı blokta çalıştırabilir ve beklediğiniz fiyat iyileştirmesini kendisi alabilir. Bu kuramsal değildir; madenci tarafından çıkarılabilir değerle aynı dinamiktir ve hesap soyutlama dünyası için yeniden paketlenmiştir. Hafifletme yöntemleri vardır (özel mempool'lar, commit-reveal şemaları, imzalı niyet katmanları), ancak bunlar etkin kullanım gerektirir. Varsayılan genel paketleyiciler ve paymaster'lar böyle bir koruma sunmaz.

Zincir üstü verileri okumak burada da yardımcı olur. İşlemleriniz sürekli aynı slot numarasına ya da belirli bir adresin hemen ardına düşüyorsa, o paketleyici ya da paymaster sizi yakından izliyor demektir. Özel bir mempool'a geçmek ya da öne geçmeme politikalarını açıkça taahhüt eden ve doğrulanabilir bir geçmişi olan paymaster'ları kullanmak güvenlik açısından gerçek bir yükseltmedir.

Oturumların ve izinlerin zincir üzerinde iptal edilmesi

Akıllı hesap kullanıcılarının en sık yaptığı hata, bir oturumu dApp'in kullanıcı arayüzünde iptal etmenin yeterli olduğunu düşünmektir. Genellikle yeterli değildir. dApp'in kullanıcı arayüzü oturumu unutabilir, ancak zincir üzerindeki yetkilendirme süresi dolana kadar aktif kalır. Akıllı hesap sözleşmesi bir hareketsizlik zaman aşımını uygulayana ya da siz aktif olarak iptal edene kadar, oturum anahtarı EntryPoint'in kabul edeceği işlemleri imzalamaya devam edebilir.

Gerçek iptal üç pratik biçimde gerçekleşir. Birincisi, varsa, akıllı hesabın iptal işlevini oturum anahtarının tanımlayıcısıyla çağırmaktır. İkincisi, hesabın ana imzalayanını döndürmektir; bu, yetkisi imzalayana bağlı olan tüm oturumları geçersiz kılar. Üçüncüsü, oturumun doğal olarak sona ermesini beklemektir; bu yalnızca baştan yeterince kısa bir süre belirlediyseniz işe yarar.

Zincir üzerindeki iptali okumak iki şeyi kontrol etmek anlamına gelir: iptal edilmiş veya süresi dolmuş durumu yansıtması gereken oturum depolama alanı ve iptal edilen anahtar için artık ilerlememesi gereken hesap nonce sırası. Sözde bir iptalden sonra hâlâ işlem imzalayan bir oturum anahtarı görürseniz, durup araştırma zamanı gelmiş demektir. Eski bir kullanıcı arayüzü olabilir ya da hiçbir zaman düzgün şekilde kapsamı belirlenmemiş ve şimdi istismar edilen bir oturum olabilir.

Akıllı hesap etkinliğini akıllıca nasıl takip edersiniz

Akıllı hesap etkinliği hızla ilerler ve zincir üzerindeki iz, ancak alttaki katmanları anladığınızda anlam kazanır. İşlemlerinizi kimin yönlendirdiğini, hangi paymaster'ların bunlara sponsor olduğunu ve hangi oturumların hâlâ aktif olduğunu elle takip etmek kaybedilen bir oyundur. Zippfeed, cüzdan ve protokol manşetlerini duyarlılık puanlaması (boğa, nötr veya ayı) ve bir önem derecesi ile sunar; böylece bir sonraki imzanızdan önce gürültünün ardındaki örüntüleri fark edebilirsiniz.

Sıkça sorulan sorular

Akıllı kontrat cüzdanı normal bir kripto cüzdandan daha mı güvenli?
Olabilir, ancak bu uygulamaya ve sizin alışkanlıklarınıza bağlıdır. Akıllı bir hesap günlük limitler belirlemenize, birden fazla imza istemenize, anahtarları döndürmenize ve seed ifadelerine gerek kalmadan erişimi kurtarmanıza olanak tanır. Bu özellikler işe yarar. Yeni riskler ise paylaşılan EntryPoint altyapısı, paymaster güveni ve düzgün şekilde iptal edilmeyen oturumlardır. Yanlış kullanılan bir oturum anahtarı, sızan bir seed ifadesi kadar hızlı biçimde fonları boşaltabilir; dolayısıyla güvenlik yalnızca teknolojide değil, onu nasıl yapılandırdığınızda ve denetlediğinizdedir. Bu bir eğitim içeriğidir, finansal tavsiye değildir.
UserOperation kavramı basitçe nedir?
UserOperation, ERC-4337 kapsamında akıllı hesaplar için tasarlanmış sözde bir işlemdir. Bir gönderici, nonce, initCode, callData, imza ve paymaster verisi taşır, doğrudan yürütülmek yerine paylaşılan bir EntryPoint kontratına gönderilir. EntryPoint'in sizin adınıza doğrulayıp çalıştırdığı, isteğe bağlı olarak bir paymaster tarafından gazı ödenen mühürlü bir talimat gibi düşünebilirsiniz.
Bir dApp'in istediği her oturum anahtarı talebini onaylamalı mıyım?
Oturum anahtarlarını, iş araçlarınızdaki bir API anahtarına nasıl davranıyorsanız öyle ele alın. Mümkün olan en dar kapsamı, olabildiğince kısa bir süreyi ve her çağrı ile her dönem için net bir harcama limitini verin. İmzalamadan önce cüzdan arayüzünün gösterdiği depolama alanını okuyun ve dApp'i kullanmayı bıraktığınız anda oturumları iptal edin. Rutin etkileşimler için geniş ve uzun ömürlü oturumları kabul etmek için hiçbir neden yoktur.
Akıllı cüzdan oturumunu zincir üzerinde nasıl iptal ederim?
Hesabın bir revoke fonksiyonu varsa onu çağırın ya da birincil imzalayıcıyı döndürün ki bu imzalayıcıya bağlı oturumlar geçersiz hale gelsin. Oturumun doğal olarak süresinin dolmasını beklemek yalnızca zaman aşımı kısa ise işe yarar. Sonrasında her zaman bir blok gezgininde oturum depolama yuvasını kontrol ederek zincir üzerinde doğrulama yapın; bir dApp arayüzünün oturumu unutması, zincir üzerindeki iznin silindiği anlamına gelmez.