Bundler'lar ve UserOperation'lar: ERC-4337 İşlemleri Nasıl Çalışır

Bir UserOperation, ERC-4337 tarafından tanımlanan imzalı niyet nesnesidir: bir akıllı sözleşme hesabının ne yapılmasını istediğini, bu eylemin nasıl doğrulanacağını ve nasıl ödeneceğini belirtir. Sıradan bir Ethereum işleminin aksine, harici sahipli bir hesap tarafından imzalanan protokol düzeyinde bir nesne değildir: imzası hesap sözleşmesinin kendisi tarafından denetlenir ve kendi yerel gazını ödemek zorunda değildir. Bir bundler ise, UserOperation'ları bu iş için ayrılmış alternatif bir mempool'dan toplayan, her birini simüle eden, geçerli olanları tek bir sıradan Ethereum işlemine paketleyen ve kanonik EntryPoint sözleşmesini çağıran zincir dışı aktördür — EntryPoint de partideki her işlemi, herhangi birini yürütmeden önce doğrular. Bundler gerçek gazı kendi EOA'sından peşin öder ve gönderen hesap ya da o hesabın paymaster'ı tarafından zincir üstünde kendisine geri ödeme yapılır. İsteğe bağlı bir paymaster sözleşmesi, tam da bu doğrulama adımında bir işlemi üstlenmeyi kabul edebilir; ücretlerin sponsorlanabilir hâle gelmesi ya da zincirin yerel gaz token'ı yerine bir ERC-20 token cinsinden ödenebilmesi buradan doğar.

Kısa bir ERC-4337 özeti

ERC-4337, hesap soyutlaması için Ethereum standardıdır — akıllı sözleşme hesaplarına, harici sahipli hesapların (EOA) her zaman sahip olduğu, eylem başlatma ve bunları ödeme konusundaki aynı birinci sınıf yeteneği, temel protokolde herhangi bir değişiklik yapmadan verme yoludur. ERC-4337, uzlaşma katmanını değiştirmek yerine, sonuçta sıradan Ethereum işlemleriyle sonuçlanan, daha üst düzey nesneler ve zincir dışı altyapıdan oluşan paralel bir sistem getirir. Önce en temel sürümünü istersen, hesap soyutlaması nedir açıklayıcımız motivasyonu ele alır, ERC-4337 nedir tüm standardı haritalar ve akıllı hesaplar ile EOA'lar iki hesap türünü doğrudan karşılaştırır. Bu yazı mekanizmaya yakınlaşır: sistemden geçen nesneler ve onları işleyen aktörler. ERC-4337'nin bir EVM standardı olduğunu unutmayın — Ethereum ve EVM uyumlu zincirler için geçerlidir, Solana veya TON gibi EVM-dışı zincirler için değil.

Bir UserOperation gerçekte nedir

ERC-4337'deki merkezi nesne UserOperation'dır. Yüzeysel olarak bir işleme benzer, ancak imzalanmış bir niyet beyanı olarak anlaşılması daha doğrudur: "hesabımın yapılmasını istediği şey burada ve bunu doğrulama ile ödeme parametreleri de bunlar." Bir sözleşmeye calldata olarak geçirilen bir struct'tır, yerel bir protokol nesnesi değil — temel katmanın ondan haberi bile yoktur.

Bir UserOperation, özünde şunları taşır:

• sender — işlemin adına hareket ettiği akıllı sözleşme hesabı.
• nonce — tekrar (replay) koruması; EntryPoint tarafından iki parçalı bir değer olarak (bir anahtar artı bir sıra numarası) izlenir, böylece bir hesap tek bir katı kuyruk yerine birbirinden bağımsız birden fazla nonce şeridi işletebilir.
• callData — hesabın yürütmesi gereken şey; çoğu zaman tek bir işlemde toplanmış birden fazla çağrıdan oluşan bir demet.
• hesap dağıtım verisi — isteğe bağlı; hesap sözleşmesini en ilk işleminde dağıtır (deploy eder). Bir akıllı hesabın, zincir üstünde henüz var olmadan önce deterministik biçimde türetilmiş bilinen bir adrese fon yüklenebilmesinin yolu budur.
• gaz limitleri — doğrulama ve yürütme için ayrı bütçeler; ayrıca EntryPoint'in kendi başına ölçemediği calldata ve ek yük için bundler'ı telafi eden bir preVerificationGas değeri.
• ücret parametreleri — EIP-1559'u yansıtan bir azami ücret ve bir azami öncelik ücreti.
• paymaster verisi — isteğe bağlı; işlemi hangi sözleşmenin sponsorlayacağı ve bunun ihtiyaç duyduğu bağlam.
• imza — protokol tarafından değil, hesabın kendi doğrulama fonksiyonu tarafından denetlenir.

Tam kodlama, EntryPoint sürümleri arasında değişti — v0.7 dağıtım ve paymaster bloblarını açık alanlara ayırır ve birkaç gaz değerini bir arada paketler; v0.6 ise tek parça initCode ve paymasterAndData bayt dizileri kullanıyordu — ama kavramsal içerik aynıdır. Entegrasyon yapıyorsan, bundler'ının hangi EntryPoint sürümünü hedeflediğini kontrol et.

Normal bir işlemden temel farkı, onu kimin ve neyin imzaladığıdır. Geleneksel bir Ethereum işlemi, sabit bir ECDSA şeması kullanan bir EOA'nın özel anahtarıyla imzalanmalıdır ve gazı yine o hesap öder. Bir UserOperation ise, göndericinin kendi akıllı sözleşme hesabı mantığı tarafından doğrulanır — bu mantık, hesabın tanımladığı herhangi bir imza şemasını, çok anahtarlı kuralı, oturum anahtarını veya yetkilendirme politikasını uygulayabilir — ve kendini yerel gazla ödemek zorunda hiç değildir. Bütün mesele bu esnekliktir: geçerli bir eylemin nasıl göründüğüne protokol değil, hesap karar verir.

Yaşadıkları alternatif mempool

UserOperation'lar, henüz işlem olmadıkları için normal Ethereum işlem mempool'una girmezler. Bunun yerine ayrı bir alternatif mempool'a (çoğunlukla alt-mempool denir) yayınlanırlar — ERC-4337 nesnelerine ayrılmış bir eşten eşe (peer-to-peer) ağ. Pratikte bir cüzdan ya da dApp, bir bundler'ın RPC uç noktasında eth_sendUserOperation çağırarak bir UserOperation gönderir; o bundler bunu paylaşılan alt-mempool'a yayabilir ya da kendi özel havuzunda tutabilir. Her iki durumda da bu nesneleri tüketen altyapı, temel katman mempool'unu değil, burayı dinler. Bu ayrım, hesap soyutlama trafiğini gerçek bir işleme paketlendiği ana kadar uzlaşma açısından kritik yoldan uzak tutar.

Bundler'ın rolü

Bir bundler, niyetleri zincir üstü gerçekliğe dönüştüren zincir dışı aktördür. İşinin dört parçası vardır. Birincisi, alternatif mempool'dan UserOperation'ları toplar. İkincisi, her birini simüle eder ve doğrular — hesabın doğrulama mantığını simüle edilmiş bir bağlamda çalıştırarak imzanın geçerli, nonce'un doğru ve hesabın ya da paymaster'ının maliyeti karşılayabildiğini teyit eder. Üçüncüsü, bir veya daha fazla geçerli UserOperation'ı tek bir sıradan Ethereum işlemine paketler. Dördüncüsü, bu işlemi kendi EOA'sından ağa gönderir, temel katman gazını peşinen öder ve zincir üstünde geri ödeme bekler.

Tek başına simülasyon yeterli koruma değildir, çünkü simülasyon ile bloğa dahil edilme arasında durum değişebilir. Bu yüzden ERC-4337, doğrulama kodunun ne yapabileceğini de kısıtlar: doğrulama aşamasında bir hesap ya da paymaster, zincir üstünde simülasyondakinden farklı davranmasına imkân verecek blok zaman damgalarını veya benzeri ortam değerlerini okuyamaz ve depolama erişimi büyük ölçüde kendi hesabıyla ilişkili slotlarla sınırlıdır. Çok sayıda kullanıcı adına hareket eden sözleşmelerin — özellikle fabrikaların (factory) ve paymaster'ların — teminat (stake) yatırması beklenir; böylece kötü davranan tek bir sözleşme, mempool'un büyük bir bölümünü ucuza geçersiz kılamaz. Bu kurallar tek bir nedenle vardır: bir bundler'ın simülasyonunu, zincir üstünde ne olacağının güvenilir bir öngörüsü hâline getirmek.

Bundler gazı peşinen ödediği ve dahil edilme karşılığında ücret kazandığı için, hesap soyutlama trafiği için özelleşmiş bir blok inşacısı (block builder) gibi davranır. Onu koruyan şey, simülasyon-ve-doğrulama adımıdır: kendisini geri ödemede başarısız olacak bir işlemi paketlemez.

EntryPoint sözleşmesi

Her şey EntryPoint adı verilen tek, kanonik bir akıllı sözleşmede birleşir. Bu sözleşme bir singleton'dır; her sürüm için EVM zincirlerinde aynı adrese dağıtılır ve işlemlerin ödemesini karşılayan depozitoları tutar. Bundler'ın işlemi, bir UserOperation dizisiyle EntryPoint'e yapılan bir çağrıdır; EntryPoint ardından katı bir iki aşamalı döngü çalıştırır.

Doğrulama aşamasında, her işlem için gönderen hesabın doğrulama fonksiyonunu (ve belirtilmişse paymaster'ınkini) çağırarak imzayı, nonce'u ve ödeme düzenlemesini zincir üstünde yeniden denetler ve ödemeyi kim yapacaksa ondan olası azami maliyeti rezerve eder. Ancak partideki tüm işlemler doğrulandıktan sonra yürütme aşamasına geçer; burada her işlemin calldata'sını hesabına göndererek transferi, takası ya da diğer eylemi gerçekten gerçekleştirir, sonra gerçek maliyeti kapatır ve kullanılmayan rezervasyonu iade eder.

Bu ayrım önemlidir: doğrulama ve yürütme birbirinden ayrılır, böylece durumu değiştiren herhangi bir iş çalışmadan önce partinin ödeme garantileri kurulur ve EntryPoint gazı birçok işlem genelinde bir kerede tam olarak hesaplayabilir. Ayrıca bu, bir işlemin yürütme sırasındaki başarısızlığının partideki diğerlerini zehirleyemeyeceği anlamına gelir.

Paymaster'ın oturduğu yer

Bir paymaster, bir UserOperation için hesap adına ödeme yapmayı kabul eden isteğe bağlı bir sözleşmedir. Bir UserOperation paymaster verisi içerdiğinde, EntryPoint doğrulama aşamasında o paymaster'a, işlemi sponsorlayıp sponsorlamayacağını ve hangi koşullarla sponsorlayacağını sorar; paymaster bir karar ve bir bağlam blob'u döndürür. Yürütmeden sonra EntryPoint, işlem sonrası bir adımda paymaster'ı gerçekte harcanan gaz bilgisiyle birlikte geri çağırır; token tahsil eden bir paymaster tam tutarı işte burada kapatır. Paymaster koşulsuz kabul edebilir (maliyeti bir uygulamanın üstlendiği gerçek gassız sponsorluk) ya da değer karşılığında kabul edebilir — en kullanışlı olanı, kullanıcıdan yerel gaz yerine bir ERC-20 token cinsinden ücret almaktır. Bu bileşene daha derin bir bakış için paymaster nedir yazısına bakın. Paymaster, akıştaki, "kullanıcının neyle ödediği"ni "ağın neyle ödendiği"nden ayıran kancadır.

Gaz ve hatalar nasıl ele alınır

ERC-4337'de gaz katmanlıdır. Bundler, dış işlem için gerçek ETH öder; EntryPoint her UserOperation'ın doğrulama ve yürütme gazını beyan ettiği limitlere göre ölçer; ve borçlu olan taraf — hesap ya da paymaster'ı — faturayı karşılamaya yetecek kadarını EntryPoint'e yatırmış olmalıdır; fatura partinin sonunda kapatılır. Bilmeye değer bir sonuç: bir ERC-4337 işlemi, eşdeğer düz bir işlemden bir miktar daha fazla gaza mal olur, çünkü eylemin kendisine ek olarak sözleşme düzeyindeki doğrulamanın ve EntryPoint muhasebesinin de bedelini ödersin.

Hatalar, önce-doğrulama tasarımıyla sınırlandırılır. Bir işlem zincir üstü doğrulama sırasında başarısız olursa partinin tamamı geri alınırdı; bundler bunun olmasına izin vermek yerine o işlemi düşürür ve partiyi yeniden kurar — zincir dışı simülasyonun amacı tam olarak budur. Bir işlem doğrulamayı geçer ama yürütmesi geri alınırsa (revert), yürütme etkileri geri sarılır; halihazırda harcanan gaz ise yine hesaplanır ve ödenir, böylece bundler dürüst iş için ödemesiz kalmaz. Bundler'ların bu kadar dikkatli simüle etmesinin nedeni bu asimetridir: kötüye kullanıma (griefing) karşı korumaları, kendilerini geri ödemeyecek hiçbir şeyi dahil etmeyi reddetmektir.

Yaşam döngüsü, sırasıyla

1. Cüzdanın bir UserOperation kurar: gönderen, nonce, calldata, gaz limitleri, ücret parametreleri, isteğe bağlı paymaster verisi.
2. Kullanılıyorsa bir paymaster, işlem yayınlanmadan önce sponsorluk koşullarını onaylar.
3. Hesabının imzalama mantığı onu imzalar — bunun tek bir ECDSA anahtarı olması gerekmez.
4. Cüzdan onu bir bundler'ın RPC'sine gönderir ve işlem alternatif mempool'a girer.
5. Bundler, standardın kısıtlı opcode ve depolama kuralları altında onu simüle edip doğrular.
6. Bundler onu diğer işlemlerle birlikte, EntryPoint üzerinde handleOps çağıran tek bir Ethereum işlemine paketler ve temel katman gazını öder.
7. EntryPoint her işlemi doğrular, her birinin calldata'sını yürütür, maliyetleri depozitolardan kapatır, fazlasını iade eder ve bundler'a geri ödeme yapar.

Bunun cüzdan kullanıcısına kazandırdıkları

Mekanizma ayrıntılı ama amacı sıradan ve faydalı: birkaç eylemi tek bir onayda toplamak (örneğin approve ile takası birlikte), sponsorlu ya da token'la ödenen ücretler, tek bir secp256k1 anahtarı dışındaki imza şemaları, harcama politikaları ve oturum anahtarları, sosyal ya da cihaz tabanlı kurtarma. Şunu da belirtmek gerekir: EIP-7702, sıradan bir EOA'nın geçici olarak akıllı hesap koduyla yürütme yapmasına izin verir ve bu, yukarıda anlatılan ERC-4337 altyapısının yerini almadan bu özelliklerin bir kısmındaki farkı kapatır.

WATS bunu nasıl kullanıyor

EVM zincirlerinde WATS bu akışın tam olarak tek bir parçasına dayanır: paymaster yuvası. WATS Hot Wallet içinde bir transfer, takas ya da stake yaptığında, cüzdanının kurduğu UserOperation bir paymaster adı taşır ve ücretin zincirin yerel gaz token'ı yerine ATS cinsinden alınmasını sağlayan şey o paymaster'dır — yani yalnızca hareket edebilmek için her ağda toz miktarda ETH, BNB ya da POL bakiyesi tutman hiç gerekmez. Senden bir bundler çalıştırman, bir EntryPoint sürümü seçmen ya da bir bundler RPC anahtarı tutman istenmez; bunlar altyapıdır ve cüzdanın işi geçerli bir UserOperation kurup göndermektir.

İki açıklama bunu dürüst tutar. Birincisi, ATS ile ödemek bir indirim değildir — ağ yine normal ücretini alır ve paymaster bunu kapatır; dolayısıyla değişen şey, altta yatan maliyet değil, bakiyenden hangi token'ın çıktığıdır. İkincisi, ERC-4337 yalnızca EVM'e özgüdür; bu yüzden Solana ve TON'da, burada anlatılan EntryPoint akışı yerine paymaster'ın rolünü eşdeğer bir ücret ödeyici düzeni oynar. ATS bir LayerZero OFT'dir; tek bir ATS bakiyesinin Ethereum, Arbitrum, Optimism, Base, Polygon, BNB Chain, Solana ve TON genelinde ücretleri karşılamasını sağlayan da budur ve tahsil edilen ATS yakılarak arz 100.000.000'den 30.000.000 tabanına indirilir. WATS baştan sona tamamen saklamasızdır: anahtarlarını sen tutarsın ve WATS asla bir anahtar tutmaz.

Bu akışı bir şartname olarak değil, çalışan bir sistem olarak görmek istersen, somut adım şu: WATS Hot Wallet'ta, yerel gaz token'ından hiç bulundurmadığın bir zincirde bir transfer dene. UserOperation, bundler ve EntryPoint işlerini gözden uzakta yapar, ücret ise ATS bakiyenden düşer. ATS ücret modelinin nasıl çalıştığı mekanizmayı baştan sona anlatır.