Ethereum Akıllı Hesapları: UserOperation, Bundler ve Gas Sponsorluğu

Sıradan harici sahipli hesap (EOA), kontrolü özel anahtar imzasıyla kanıtlar; nonce işlemlerin sırasını belirler. Model basittir, ancak genellikle aynı anahtar her eylemi onaylar.

Bir EOA işlemi tek bir üst düzey işlem taşır; çağrılan sözleşme içeride başka sözleşmeleri de çağırabilir.

Ethereum bekleyen işlemler rehberi, ERC-4337'den farklı olan EOA yolunu açıklar. Akıllı hesap, varlık tutabilen ve çağrı çalıştırabilen bir sözleşmedir.

Doğrulama kodu tek imza, birden fazla imza için eşik veya süreli izinler isteyebilir. ERC-4337, işlemleri onaylama ve yürütme arayüzü tanımlar; belirli bir cüzdanı ya da kurtarma politikasını zorunlu kılmaz.

Ethereum.org yedek anahtar ve gas sponsorluğu gibi olasılıkları anlatır; her cüzdanda olduklarını söylemez. “Akıllı cüzdan” adı tek başına hesabı kimin kontrol ettiğini göstermez.

Varlıkları hangi sözleşmenin tuttuğunu, hesabın hangi kod ve EntryPoint'e güvendiğini ve hangi imza sahiplerinin çağrıları onaylayabildiğini kontrol edin.

Hesap mantığı yükseltilebiliyorsa yönetici yetkileri ve değişiklik süreci de varlık kontrolünü etkiler.

UserOperation, akıllı hesabın yapmak istediği eylemi tanımlar. Genellikle gönderen hesap adresini, hesaba özgü nonce'u, çağrı verisini, imzayı, gas limitlerini ve ücret koşullarını içerir.

Yeni hesap oluşturmak için factory bilgisi veya sponsor istemek için paymaster verisi de eklenebilir. Alanların kesin biçimi EntryPoint sürümüne göre değişebilir.

Cüzdan bu nesneyi eth_sendTransaction ile doğrudan zincire göndermek yerine eth_sendUserOperation gibi ERC-4337 RPC sunan bir bundler'a veya relay'e iletir. İstek, EOA işlem havuzundan ayrı bir UserOperation havuzundan geçer.

UserOperation hash'i isteği tanımlar; bundler'ın oluşturduğu zincir üstü işlemin ayrı bir hash'i ve makbuzu olur. ERC-7769 gönderim ve sonuç sorgulama RPC yöntemlerini tanımlar.

Bundler yanıtı, isteğin o hizmetin kontrollerinden geçip havuzuna alındığı anlamına gelebilir. Bloğa dahil edildiğini veya uygulama eyleminin başarılı olduğunu kanıtlamaz. İsteğin diğer bundler'lara yayılması altyapı ve politikalara bağlıdır.

Sağlayıcının kabul yanıtını zincirdeki sonuçtan ayrı değerlendirin.

Bundler, UserOperation'ı alır, kullandığı EntryPoint sürümüyle uyumluluğu kontrol eder ve hesabın ve paymaster'ın doğrulama mantığını simüle eder. İmza, hesaba duyulan EntryPoint güveni, nonce, gas ve sponsorluk koşullarını denetler.

Kurallara uymayan veya simülasyonda başarısız olan isteği reddedebilir. ERC-4337 bundler rehberi simülasyon ve paket gönderimini açıklar.

Ardından bir veya daha fazla uygun işlem seçer ve EntryPoint'teki handleOps işlevini çağıran normal bir Ethereum işlemi oluşturur. Bu işlemin bloğa girip girmemesi blok üretimine ve ağ koşullarına bağlıdır.

UserOperation hash'i almak, işlemin kanonik zincirde yürütüldüğünü kanıtlamaz. UserOperation havuzu EOA havuzundan ayrıdır; her sağlayıcı aynı istekleri görmeyebilir. Bundler işlemi reddedebilir veya bekletebilir.

Desteklenen ağlar, EntryPoint sürümleri ve kurallar değişebilir. Durumu incelerken cüzdan görünümünü, UserOperation makbuzunu ve paket işleminin zincir makbuzunu birbirinden ayırın.

ERC-4337 EntryPoint belgesi doğrulama ve ücret hesaplama rolünü açıklar. EntryPoint, bundler'ın handleOps çağrısını alır ve her akıllı hesabın doğrulama işlevini çalıştırır.

Hesap, güvenilir EntryPoint'i, imzayı ve kendi izin kurallarını denetler. ERC-4337 nonce'u 192 bitlik bir anahtar ve 64 bitlik bir sıra değerinden oluşur.

EntryPoint her hesap ve anahtar için sırayı doğrular ve artırır; hesap anahtara özel anlam verebilir veya ek kurallar uygulayabilir. İsteğe bağlı paymaster da işlemi sponsor olup olmayacağını doğrular.

Doğrulama geçerse EntryPoint, callData içindeki eylemi çalıştırmak ve maliyeti hesaplamak için hesabın yürütme işlevini çağırır. EntryPoint, her cüzdan tasarımı için protokol değişikliği gerektirmeden akıllı hesap akışını mümkün kılan ortak sözleşmedir.

Cüzdanın kullandığı gerçek adresi, sürümü ve ağı kontrol edin. Simülasyon yararlı bir önizlemedir, dahil edilme sözü değildir. Beklerken zincir durumu, ücretler, geçerlilik penceresi veya harici sözleşme değişebilir.

Doğrulama geçse bile uygulama çağrısı başarısız olabilir ya da geri alınabilir. Bloğa eklenmesi, amaçlanan token transferinin veya sözleşme eyleminin başarılı olduğunu tek başına kanıtlamaz.

UserOperation paymaster bilgisi içeriyorsa EntryPoint, bu sözleşmeye sponsor olmaya istekli olup olmadığını sorar. Uygulama ücreti üstlenebilir veya kullanıcının hesabında ETH olmadan işlem başlatmasına izin verebilir.

Bazı tasarımlar token ile ödeme veya farklı uygunluk koşulları da sunar; bunlar cüzdan ve paymaster uygulamasına bağlıdır. Sponsorluk maliyeti ortadan kaldırmaz.

Paymaster uygulamaları, kullanıcıları, işlem adedini veya tutarı sınırlayabilir, isteği inceleyip reddedebilir. EntryPoint'teki yatırılmış bakiyesi işlem maliyetlerini öder.

Ayrı stake gerekiyorsa bu, doğrulama kuralları uyarınca teminattır; gas için harcanabilir yatırımla aynı değildir.

ERC-4337 paymaster rehberi ve EIP-4337 doğrulama ile ödeme akışını açıklar. Uygulamada sıfır ücret görünmesi maliyet olmadığı anlamına gelmez.

Sponsor önce ödeme yapıp abonelik, token ücreti veya hizmet koşullarıyla değerini geri alabilir. Maliyeti en sonunda kimin üstlendiğini, sponsorluk sınırını ve başarısız işlemlerde de gas harcanıp harcanmayacağını kontrol edin.

Cüzdan destekliyorsa bir UserOperation'a uygulama izni ve takas birlikte eklenebilir. İki eylem EntryPoint'ten tek işlem olarak geçer. Bu, tek bir normal EOA işleminden ve bundler'ın ayrı UserOperation'ları bir zincir işleminde toplamasından farklıdır.

Hangi yapının kullanıldığını cüzdan önizlemesinden kontrol edin. Varsayımsal bir örnekte, onaylanan sponsorlu işlemin gerçek gas maliyeti 0,0012 ETH olsun.

Bu tutar kullanıcının hesabından değil, paymaster'ın EntryPoint yatırılmış bakiyesinden karşılanabilir. Rakam sadece örnektir, güncel fiyat teklifi değildir. Gerçek maliyet kullanılan gas'e, ücret koşullarına ve ağa bağlıdır.

Paketleme her zaman daha ucuz veya güvenli değildir. Birden çok çağrının atomik çalışması hesabın hataları nasıl ele aldığına bağlıdır.

Bir çağrı başarısız olunca bütün paketin geri alınıp alınmadığını, diğer eylemlerin tamamlanıp tamamlanamayacağını ve gas'i kimin ödeyeceğini kontrol edin. Yanlış gas tahmini reddedilme veya başarısızlığa yol açabilir.

Ethereum gas ücretleri rehberi ücret alanlarını açıklar.

Hesapta yedek imza sahipleri veya güvenilir guardian'ların eşiği sağlayınca anahtar değiştirdiği bir süreç bulunabilir. Bazı tasarımlar mevcut anahtar sahibine itiraz için bekleme süresi verir.

Ancak her zaman tek bir imza gerekiyorsa anahtarı kaybetmek erişimi kalıcı olarak kapatabilir. ERC-4337 hesaba kendi doğrulama kurallarını koyma imkânı verir; tüm hesaplara yedek anahtar veya sosyal kurtarma eklemez.

Az sayıda guardian veya zayıf anahtar değiştirme kuralları saldırı yolu yaratabilir. Çok guardian ya da ağır koşullar gerçek sahibin kurtarmasını geciktirebilir.

Eşiği, bekleme süresini, iptal hakkını ve kurtarma anahtarlarının nerede tutulduğunu inceleyin. Kurallar, işlemi kimin onaylayacağı kadar kimin engelleyebileceğini de belirler. Sözleşme cüzdanı otomatik olarak saklamalı veya saklamasız değildir.

Kontrol, imza anahtarlarının kimde olduğuna, admin ya da upgrade yetkisinin kimde bulunduğuna ve hosted signer veya kurtarma hizmetinin neyi onaylayabildiğine bağlıdır. Varlıkları tutan sözleşmeyi, onu yöneten anahtar ve hizmetlerden ayrı inceleyin.

Seed phrase kurtarma rehberi farklı bir kurtarma türünü ele alır.

Cüzdan önizlemesinde ağı, hesap adresini, hedef sözleşmeleri, çağrı verisini, token izninin kapsamını ve çağrı sayısını kontrol edin. İmza, ekranda vurgulanan eylemden fazlasına izin verebilir.

İmzalanan veriyi anlamıyorsanız uygulamanın ve cüzdanın resmî belgelerine bakın. Sponsorluk için paymaster adına değil uygunluk koşullarına, kullanım sınırlarına, alternatif ödeme yöntemlerine ve başarısızlık maliyetine bakın.

Sponsorluk etkin etiketi uygulamanın koşulsuz ücretsiz olduğu anlamına gelmez; paymaster işlemi reddedebilir. Ağ yoğunluğu ve blok gecikmesi de ayrı konulardır.

UserOperation uzun süre bekliyorsa EOA işlemlerindeki “hızlandır” veya “iptal et” yolunu doğrudan uygulamayın. Önce işlem hash'ini ve makbuzunu bulun. Bundler işlem hash'i varsa blok makbuzunu ve yürütme sonucunu da kontrol edin.

RPC makbuzları tek işlemin gerçek maliyetini ve başarısını tüm paket işleminin makbuzundan ayırabilir.