zkSync'te yerel Hesap Soyutlamasına Giriş

Yazar: ChiHaoLu, imToken Labs tarafından yazıldı

Bu makale temel olarak zkSync'in Katman 2 çözümündeki soyut hesapların (AA, soyut hesaplar) geliştirilmesini ve ilgili içeriğini tanıtmaktadır. Odak noktası üç bölüm üzerinde olacaktır:

• Hesap sözleşmesi: hesap türü, önemli giriş noktası ve hesap sözleşmesinin ilgili önemli noktaları
• İşlem: doğrulama yöntemi, yürütme yöntemi ve AA işleminin süreci
• İşlem ücreti: işlem ücreti, Paymaster

İçindekiler

• önsöz
• zkSync AA sözleşmesine kısa genel bakış
• zkSync çağında ücret modeli ve Paymaster
• Özet ve karşılaştırma
• Çözüm

arka plan

• Akıllı sözleşme cüzdanına ve ortak özelliklerine aşina
• Ethereum işlemlerinin nasıl çalıştığına dair genel bir bakış edinin
• EIP-4337'nin çalışma modunun genel olarak anlaşılması
• ZK (geçerlilik) Toplamasının çalışma moduna ilişkin genel bir anlayış
• zkSync'e Hızlı Bakış

Burada okuma kolaylığı açısından zkSync'i derinlemesine anlamak gerekli değildir, zkSync'in temel bilgilerini kısaca gözden geçirmek gerekir. ZkSync'in iki ana sürümü vardır; sürüm 1.0 (zkSync Lite) ve sürüm 2.0 (zkSync Era).

zkSync sürüm 1.0 yalnızca EOA'yı (harici hesap) destekler ve akıllı sözleşmeleri desteklemez (yalnızca belirteç aktarımını ve değişimini destekler), zkSync 2.0, yani zkSync Era, yerel AA'ya (soyut hesap) aittir (tüm hesap türleri sözleşmedir, EOA yoktur) EOA ile Ethereum'daki sözleşme hesabı arasındaki fark olan) ve EVM (Ethereum Sanal Makinesi) ile uyumludur ve Rust, Yul, Vyper, Solidity vb. kullanılarak akıllı sözleşmelerin geliştirilmesini destekler.

Aşağıda belirtilen zkSync, aksi belirtilmediği sürece zkSync 2.0'ı, yani zkSync Era'yı ifade eder.

zkSync Era'da, zkSync'in bazı önemli işletim sistemi işlevlerini akıllı sözleşmelerde uyguladıkları anlaşılan birden fazla sözleşme vardır. Bu sözleşmeler, önceden derlenmiş, hiç dağıtılmamış sözleşmelerdir (doğrudan düğümde çalıştırılırlar), ancak hepsinin resmi bir adresi vardır.

AA protokolünü uygularken, zkSync bazı sözleşmeler aracılığıyla mantıksal işlemler ve yargılamalar gerçekleştirecektir. Örneğin, tek seferlik doğrulama sırasında NonceHolder tarafından değerlendirilirken, soyut hesap mekanizmasının uygulanması ve ücretlerin tahsilatı önyükleyici tarafından değerlendirilir. onları birer birer.

Hesap Özetleme Özeti

Hesap soyutlamanın temel konsepti iki temel noktada özetlenebilir: imza soyutlaması ve ödeme soyutlaması.

İmza soyutlamanın amacı, çeşitli hesap sözleşmelerinin farklı doğrulama şemalarını kullanmasını sağlamaktır. Bu, kullanıcıların yalnızca belirli bir eğriyi kullanabilen bir dijital imza algoritmasıyla sınırlı olmadığı, istedikleri doğrulama mekanizmasını seçebilecekleri anlamına gelir.

Ödeme soyutlaması, kullanıcılara çeşitli işlem ödeme seçenekleri sunmayı amaçlamaktadır. Örneğin, ödemeler yerel tokenlar yerine ERC-20 tokenları kullanılarak yapılabilir veya işlemler üçüncü bir tarafın sponsorluğunda gerçekleştirilebilir veya hatta daha özel ödeme modelleri yapılabilir.

zkSync 2.0'daki hesaplar, EOA gibi işlemleri başlatabilir ancak aynı zamanda sözleşme hesapları gibi keyfi mantığı uygulamak için programlanabilirliğini de kullanabilir. AA hesaplarını kullanma deneyimini daha esnek hale getirmek ve böylece yukarıdaki iki hedefe ulaşmak için Ethereum'daki iki hesap türünün avantajlarını birleştiren Hesap Soyutlama adını verdiğimiz şey budur: imza soyutlama ve ödeme soyutlama.

zkSync Çağında AA Mekanizması

zkSync Çağında, zkSync AA'nın en önemli rolü, EIP-4337'nin Giriş Noktası Sözleşmesine karşılık gelen, esas olarak işlemleri işlemek ve AA mekanizmasını yürütmek için kullanılan bir Sözleşme olan önyükleyicidir. Önyükleyici kullanıcı tarafından çağrılamaz (yalnızca Operatör tarafından tetiklenebilir) ve hiçbir zaman konuşlandırılmamıştır (doğrudan düğümde çalışır), ancak resmi bir adresi vardır (ödeme almak için kullanılabilir).

Operatör, ZK Rollup'ta önemli bir rol oynar.Merkezi bir Off-Chain Sunucusudur.Görmüş olabileceğiniz Sequencer'a benzer şekilde, bootloader gibi sözleşmelerin dışarıdan tetiklenmesinden sorumludur.

Native hesap soyutlama protokolleri (StarkNet, zkSync gibi) temel olarak EIP-4337 referans alınarak tasarlanmıştır.zkSync uygulamasında kullanıcı işlemi Operatöre gönderecek ve Operatör de işlemi bootloader'a göndererek bir işlem başlatacaktır. bir dizi işlem.

Blok açısından bakıldığında:

Önyükleyici Operatörden girdi aldığında, önyükleyici ilk önce blok için bazı ortam değişkenlerini (gas fiyatı, blok numarası, blok zaman damgası vb.) tanımlayacaktır. Ardından, önyükleyici işlem listesini sırayla okuyacak, önce hesap sözleşmesinin işlemle uyumlu olup olmadığını sorgulayacak (yani, AA mekanizmasındaki doğrulama işlevini çağıracak) ve ardından bunları bloğa koyacaktır.

Her işlem doğrulandıktan sonra Operatör, bloğun doğrulayıcıya gönderilecek kadar büyük olup olmadığını (veya zaman aşımına uğrayıp uğramadığını) doğrular. Yeterince büyükse veya zaman aşımına uğradıysa, Operatör bloğu kapatır, önyükleyiciye yeni işlemler eklemeyi durdurur ve işlemin yürütülmesini tamamlar.

İşlemler açısından bakıldığında, Operatör önyükleyiciyi tetiklediğinde, önyükleyici her işlemi sırayla işleyecektir:

1. Kullanıcı hesabının sözleşme adresine karşılık gelen nonce'nin yasal olup olmadığını doğrulayın
2. Doğrulama için kullanıcı hesabı sözleşmesindeki doğrulama işlevini çağırın
3. Doğrulama geçildikten sonra, hesap sözleşmesi gaz ücretini önyükleyicinin adresine (veya daha sonra tanıtılacak olan Paymaster aracılığıyla) havale edecek ve önyükleyici yeterli para alıp almadığını kontrol edecektir.
4. İşlemi gerçekleştirmek için kullanıcı hesabı sözleşmesindeki ute işlevini çağırın.

Yukarıdaki ilk üç adım, EIP-4337'nin doğrulama döngüsüne (Doğrulama Döngüsü) karşılık gelir ve dördüncü adım, EIP-4337'nin yürütme döngüsüne (ution Döngüsü) karşılık gelir.

Burada esas olarak genel bir giriş yer almaktadır ve her adımın ayrıntıları ve rolleri, aşağıdaki ayrıntılı açıklamada tek tek detaylandırılacaktır.

zkSync soyut hesap sözleşmesine hızlı genel bakış

Bir kez

zkSync'in hesap nonce'si, NonceHolder adlı bir sistem sözleşmesine kaydedilir; bu, her bir (hesap_adres, nonce) çiftinin, nonce'nin yasal olup olmadığına karar vermek için eşleme (haritalama) tarafından kullanılıp kullanılmadığını hatırlatır.

Yukarıdakilere göre, Operatör önyükleyiciyi tetikledikten sonraki ilk adım, nonce'yi kontrol etmektir. Bu nedenle, her işlem başlamadan önce NonceHolder, halihazırda kullanılan nonce kümesinin yasal olup olmadığını doğrulamak için kullanılacaktır (şu anda yalnızca kullanılıp kullanılmadıklarını kontrol etmektedir). Nonce yasal ise, doğrulama aşamasına (Doğrulama Aşaması) girecek ve bu aşamada nonce kullanılmış olarak işaretlenecektir; yasal değilse işlem (doğrulama) başarısız olacaktır.

zkSync'in mevcut nonce'si hakkında önemli noktalar:

Şu anda kullanıcılar, yürütülmek üzere farklı nonce'lara sahip birden fazla işlemi aynı anda hesaba gönderebilse de, zkSync paralel işlemeyi desteklemediğinden, farklı nonce'lara sahip işlemler yine de sıralı olarak işlenecektir.

Teorik olarak, kullanıcılar herhangi bir 256-bit sıfır olmayan tamsayıyı nonce olarak kullanabilirler, ancak zkSync yine de nonce'ın sırayla artırıldığından emin olmak için nonce'ı yönetmenin bir yolu olarak IncrementNonceIfEquals kullanılmasını önermektedir (şu anda zkSync'in AA mekanizması yalnızca kullanılmayan nonce'ı onaylamaktadır, ancak resmi belge, gelecekte sıralı artışın gerekebileceğini gösterir).

Hesap Sözleşmesi

zkSync'teki hesap sözleşmesi aşağıdaki dört gerekli giriş noktasına (Giriş Noktası) sahiptir:

• validateTransaction: Kullanıcıların kendi doğrulama mantığını (çeşitli imza algoritmaları, çoklu imza vb. gibi) özelleştirebildiği, işlemin hesap sahibi tarafından yetkilendirilip yetkilendirilmediğini onaylamak için doğrulama aşamasında çağrılır.
• payForTransaction: İşlem ücreti bu hesaptan ödendiğinde (paymaster kullanmak yerine), operatör bu fonksiyonu çağırarak bootloader adresine ETH'nin en az tx.gasprice * tx.gaslimit ödemesini yapacaktır. *hazırlıkForPaymaster: İşlem ücreti Paymaster tarafından ödeneceği zaman operatör, paymaster ile etkileşime geçmeden önce hazırlık çalışmasını tamamlamak için bu fonksiyonu arayacaktır. zkSync tarafından sağlanan örnek, Paymaster tarafından onaylanan bir ERC-20 tokenidir.
• uteTransaction: Doğrulama aşaması başarıyla geçilip işlem ücreti başarıyla tahsil edildikten sonra bu fonksiyon kullanıcının gerçekleştirmek istediği işlemi (sözleşmeyle etkileşim, havale vb.) gerçekleştirmek için kullanılacaktır.

Paymaster hakkında işlem ücreti tutarı (tx.gasprice * tx.gaslimit) vb. ilerleyen bölümlerde anlatılacaktır.

Ayrıca zkSync hesabında zorunlu olmayan bir sigorta işlevi olan uteTransactionFromOutside da bulunmaktadır. İşlemler gerçekleştirilemediğinde (örneğin dizi oluşturucunun yanıt vermemesi veya zkSync'in düzenleyici bir risk olarak bulunması durumunda) "kaçış mekanizması" kullanılarak fonlar L1'e çekilebilir. Bu bölümün AA protokolü ile pek ilgisi olmadığından burada detaylı olarak anlatılmayacaktır.İlgilenenler zkSync'in resmi belgelerini ve özelliklerini inceleyebilirler.

Doğrulama İşlevlerinin Önemli Noktaları ve Sınırlamaları

validateTransaction işlevinde çeşitli özel mantıklar uygulayabilirsiniz. Örneğin, hesap EIP-1271 standardını uyguladıysa, validateTransaction için doğrudan EIP-1271'deki doğrulama mantığını uygulayabilir veya çoklu imzalı hesap sözleşmesi uygulamasına başvurabilirsiniz. zkSync resmi belgesinde.

Aynı zamanda EIP-4337'nin Doğrulama Aşamasında DoS tehditlerinden kaçınmak için bazı kısıtlamalar (harici işlem kodları içeremez ve sınırlı derinlik vb. içeremez) vardır ve zkSync'te de benzer kısıtlamalar vardır, örneğin:

1. Sözleşme mantığı yalnızca kendi yuvasına dokunabilir (hesap sözleşmesinin adresi A ise):

• A adresine ait slot

• başka herhangi bir adresteki A yuvası

• Adresi doğrudan eşlemenin anahtarı olarak kullanabilen (eşleme (adres=>değer) gibi) başka herhangi bir adresin keccak256(A||X) yuvası, aynı zamanda keccak256( yuvasına erişime izin vermeye eşdeğerdir. A||X), genişlemeyi sağlamak için. Örneğin ERC-20'deki token bakiyeleri.

2. Sözleşme mantığı, blok.numarası gibi genel değişkenleri kullanmamalıdır

İşlevlerin Yürütülmesine İlişkin Önemli Noktalar ve Sınırlamalar

UteTransaction fonksiyonunda dikkat edilmesi gereken şey, eğer bir sistem çağrısı (Call) gerçekleştirmek istiyorsanız, is bayrağına sahip olduğundan emin olmanız gerekir. Çünkü bu sistem sözleşmeleri hesap sistemi üzerinde büyük etkiye sahiptir. Örneğin, nonce'ı artırmanın tek yolu NonceHolder ile etkileşim kurmaktır. Bir sözleşmeyi dağıtmak için ContractDeployer ile etkileşime girmelisiniz. is bayrağını kullanmak, hesap geliştiricilerin bilinçli olarak etkileşime girmesini sağlayabilir. Sistem sözleşmeleri ile.

Ancak, is işaretini kendiniz işlemekten kaçınmak için zkSync tarafından sağlanan ContractsCaller kitaplığını kullanmanız ve sistem çağrısını tamamlamak için CallWithPropagatedRevert'i kullanmanız önerilir.

Yukarıdaki kod örneği DEPLOYER__CONTRACT ile etkileşimi içerir. Hesap geliştiricilerinin karşılaştığı en yaygın sistem sözleşmesi durumu, bir sözleşmeyi dağıtmak için bir hesap kullanmak istememizdir.Bu sırada ContractDeployer sistem sözleşmesiyle etkileşime geçmeliyiz. Bu durumda hesap geliştiricinin, sözleşmenin başarıyla dağıtıldığından ve gerekli işlemleri gerçekleştirdiğinden emin olmak için ContractDeployer sözleşmesiyle iletişim kurması gerekir.

zkSync çağında ücret modeli ve Paymaster

Ücretler ve Gas Limiti

zkSync'in ücret modeli Ethereum'a çok benzer, ücret tokenı hala ETH'dir. Ancak diğer Katman 2 çözümleri (Arbitrum, Optimism gibi) gibi zkSync'in de temel hesaplama ve yazma yuvası maliyetlerine ek olarak L1'e yayınlamanın ek maliyetini (güvenlik ücreti) dikkate alması gerekir. L1'e veri yayınlayan gazın fiyatı çok istikrarsız olduğundan, zkSync Operatörü her blok açıldığında aşağıdaki dinamik parametreleri tanımlar (işlemleri kaydetmeye başlar):

• gasPrice: gwei cinsinden gas fiyatı, yani yukarıda belirtilen işlem nesnesindeki tx.gasprice

• gasPerPubdata: Ethereum'da bir bayt veri yayınlamak için gereken gaz miktarı

Buna ek olarak, EIP-4337'den farklı olarak zkSync'in üç gaz limiti tanımlamasına gerek yoktur: VerificationGas, utionGas ve preVerificationGas, ancak yukarıdaki maliyetlerin tamamını karşılamak için yalnızca bir gasLimit gerektirir; dolayısıyla kullanıcıların gasLimit'in, Doğrulama aşaması, işlem aşaması ve veri yükleme Güvenlik ücretleri gibi tüm masraflar L1'e aittir. Bu ücret maliyeti yukarıda belirtilen işlem nesnesindeki tx.gaslimit'e dahildir.

Bootloader'a ödenen işlem ücretini almak için ikisini (tx.gasprice * tx.gaslimit) çarpın.

Ödeme sorumlusu

Paymaster, kullanıcı işlem ödeme ücreti aşamasında kullanıcının hesap sözleşmesi yerine esas olarak bootloader'a ETH öder. Kullanıcılar işlem ücretini ödemek için aşağıdakiler gibi (ancak bunlarla sınırlı olmamak üzere) farklı Paymaster ve ödeme modlarını seçebilir:

• İşlem başlatılmadan önce veya işlem gerçekleştirildikten sonra ERC-20 tokenlarının Paymaster'a ödenmesi

• Paymaster sözleşmesine kredi kartıyla yükleme yapın

• Paymaster, kullanıcılar için ücretlerin bir kısmını veya tamamını ücretsiz olarak ödemeye devam edecek

Kullanıcıların Paymaster ile etkileşim şekli farklı protokollere bağlıdır; merkezi veya merkezi olmayan olabilir; işlemden önce veya sonra olabilir; ERC-20 tokenlerini veya yasal ödeme aracını kullanabilir, hatta ücretsiz olabilir.

zkSync'in Paymaster sözleşmesi temel olarak validateAndPayForPaymasterTransaction (gerekli) ve postTransaction (isteğe bağlı) olmak üzere iki işlevden oluşur; bunların her ikisi de yalnızca önyükleyici tarafından çağrılabilir:

• validateAndPayForPaymasterTransaction, Paymaster sözleşmesinin tamamında uygulanması gereken tek işlevdir. Operatör Paymaster parametreli bir işlem aldığında işlem ücretinin kullanıcının hesap sözleşmesi ile değil Paymaster tarafından ödendiği anlamına gelir. Bu noktada operatör, Paymaster'ın işlem ücretini ödemeye istekli olup olmadığını belirlemek için validateAndPayForPaymasterTransaction'ı çağıracaktır. Paymaster kabul ederse bu fonksiyon en az tx.gasprice * tx.gaslimit ETH'yi bootloader'a gönderecektir.

• postTransaction, genellikle geri ödeme (kullanılmayan gazı gönderene iade etmek) için kullanılan isteğe bağlı bir işlevdir. Ancak mevcut zkSync henüz bu işlemi desteklemiyor.

ZkSync'teki Paymaster, EIP-4337'den farklı olarak postTransaction uygulandıktan sonra postTransaction'ı yürütecektir. EIP-4337, validatePaymasterUserOp bağlamı döndürmediğinde postOp'u çağırmayacaktır (ve bunun tersi de geçerlidir).

Yukarıdakilere dayanarak örneğin kullanıcı artık işlem ücreti Paymaster tarafından ödenen bir işlemi göndermek istiyor, süreç şu şekilde:

1. Nonce'nin yasal olup olmadığını doğrulamak için NonceHolder'ı kullanın
2. İşlemin hesap sahibi tarafından yetkilendirildiğini doğrulamak için kullanıcının Hesap Sözleşmesinde validateTransaction'ı çağırın
3. Kullanıcının Hesap Sözleşmesinde prepareForPaymaster'ı çağırın; bu, örneğin Paymaster'a belirli sayıda ERC-20 Tokenını onaylayabilir veya hiçbir şey yapmayabilir.
4. Paymaster'ın işlem ücretini ödemeye ve tahsil etmeye istekli olduğunu doğrulamak için Paymaster Sözleşmesinde validateAndPayForPaymasterTransaction'ı çağırın ve aynı zamanda Paymaster kullanıcıdan belirli bir miktarda ERC-20 (daha önce onaylanmıştır) tahsil edecektir.
5. Önyükleyicinin doğru miktarda (en az tx.gasprice * tx.gaslimit) ETH ücreti aldığını doğrulayın
6. Kullanıcının istediği işlemi gerçekleştirmek için kullanıcının Hesap Sözleşmesinde uteTransaction'ı çağırın
7. Paymaster Sözleşmesi postTransaction'ı uyguluyorsa ve gaz hala yeterliyse (gas bitme hatası yoksa), postTransaction'ı yürütün

Son adımda gaz bitmesi nedeniyle postTransaction gerçekleştirilemese bile bu AA işlemi başarılı kabul edilir ancak postTransaction'ı çağırma eylemi atlanır.

zkSync'in Paymaster'ını daha derinlemesine incelerseniz, Doğrulama Kurallarının 4337'den biraz farklı olduğunu (zkSync Paymaster başka herhangi bir sözleşme slotuna basabilir) ve ayrıca çeşitli türlerin (Onay tabanlı gibi) bulunduğunu göreceksiniz. detayların karşılaştırılması İlgilenenler resmi belgelere veya önceki uygulamalarıma başvurabilirler.

Özet ve Karşılaştırma

Önceki açıklamalar sayesinde hesap sözleşmesinin hangi önemli giriş noktalarına sahip olduğunu, bunların işlevlerini ve ilgili kısıtlamaları öğrenmiş olduk. Aynı zamanda sistem sözleşmesinin fonksiyonlarını da öğrendik. Şimdi zkSync'te bir otomatik işlem (AA) işleminin yapım aşamasından tamamlanmasına kadar olan sürecini özetleyelim, ayrıca daha fazlasını öğrenmek isteyenler için daha detaylı referanslar sunacağım:

1. Kullanıcı, işlem nesnelerini (örneğin: gelen, giden, veri, değer vb.) oluşturmak için SDK'yı veya cüzdanı yerel olarak kullanır.

2. Kullanıcı işlemi imzalar. Buradaki imzanın mutlaka geleneksel EIP-712 formatı ve ECDSA eğri imzası olması gerekmez. zkSync ayrıca EIP-2718 ve EIP-1559'u da destekler.Bir imza yöntemi ve doğrulama yöntemi seçmenin anahtarı, hesap sözleşmesindeki doğrulama işlevi aracılığıyla doğrulama yapmaktır.

3. İmzalanan işlemi RPC API aracılığıyla operatöre gönderin. Bu noktada işlem bekleme durumuna girer. Operatör, işlemi önyükleyiciye iletir (önyükleyici sözleşmesinde prosesL2Tx işlevini çağırır) ve bir dizi AA protokol sürecini başlatır.

4. Bootloader, Nonce'nin yasal olup olmadığını kontrol edecek ve kontrol etmek için NonceHolder'ı kullanacaktır.

5. Önyükleyici, işlemin hesap sahibi tarafından yetkilendirildiğini doğrulamak için kullanıcı hesabı sözleşmesindeki validateTransaction işlevini çağıracaktır.

6. Bootloader'ın ücretleri tahsil etmesinin iki yolu vardır ve özel ücretlendirme yöntemi, işlem parametrelerine bağlıdır (işlem nesnesini oluştururken paymaster parametresinin eklenip eklenmediğine):

a. İşlem ücretini tahsil etmek için payForTransaction işlevini ve hesap sözleşmesini arayın;

b. Paymaster sözleşmesiyle işlem ücretini tahsil etmek için hazırlığıForPaymaster ve validateAndPayForPaymasterTransaction işlevlerini çağırın.

7. "Hesapla ücret sözleşmesi yapmak için payForTransaction'ı arayın" veya "Paymaster ile ücret sözleşmesi yapmak için prepareForPaymaster'ı arayın ve validateAndPayForPaymasterTransaction'ı arayın"

8. Bootloader'ın en az tx.gasprice * tx.gaslimit işlem ücreti alıp almadığını kontrol edin.

9. Bootloader, işlemi gerçekleştirmek için kullanıcı hesabı sözleşmesindeki uteTransaction işlevini arayacaktır.

10. (İsteğe bağlı) İşlem ücretini ödemek için Paymaster kullanılıyorsa, önyükleyici postTransaction işlevini çağıracaktır. Paymaster postTransaction'ı uygulamazsa veya gaz tükenirse bu adım atlanacaktır.

Yukarıdaki 4.~7. adımlar doğrulama aşamasıdır (önyükleyicinin l2TxValidation'ında tanımlanmıştır) ve 8.~9. adım yürütme aşamasıdır (önyükleyicinin l2Txution'ında tanımlanmıştır).

EIP-4337, StarkNet ve zkSync Era'nın karşılaştırılması

Temel olarak, üçünün AA mekanizması süreçleri benzerdir ve bunların hepsi doğrulama aşaması → işlem ücreti mekanizması (hesap sözleşmesi veya Paymaster tarafından ödenir) → uygulama aşamasıdır. Temel farklar şunlardır:

• AA mekanizmasının uygulanmasının rolü şudur: zkSync çağındaki açılış ile diğer iki AA arasındaki fark, Operatörün önyükleyici ile işbirliği yapması gerektiğidir (sistem sözleşmesi), örneğin önyükleyici yeni bir blok açacak ve tanımlayacaktır. bloğun ilgili parametrelerini girin ve işlemi alın. Üye tarafından tüccar gönderilir ve doğrulanır. 4337'de bu kısım Bundler ve EntryPoint tarafından koordine edilirken, StarkNet'te bu kısım tamamen Sequencer'dan sorumludur.
• Gaz Maliyetinin L1 güvenlik ücretini dikkate alması gerekiyor mu: L2 AA'nın, yalnızca aktarımda bahsedilen ZK (Geçerlilik) Toplamaları Yerel AA'yı değil, L1'e veri yükleme maliyetini de dikkate alması gerekir, aynı zamanda İyimser olduğunda L1'e dahil edilmesi gerekir Toplamalar 4337 Güvenlik ücretini uygular (preVerificationGas'ta hesaplanır, ayrıntılar için Alchemy ile ilgili belgelere bakın).
• Hesap sözleşmesi dağıtılmadan önce işlem göndermenin mümkün olup olmadığı: StarkNet ve zkSync çağında, kullanıcının hesap sözleşmesini dağıtmasına olanak tanıyan initCode alanına sahip 4337 gibi bir EntryPoint yoktur, dolayısıyla işlem göndermez hesap yapılandırılmadan önce.

Karşılaştırıldı

StarkNet, Paymaster mekanizmasını henüz hayata geçirmediğinden ve zkSync de gaz iadesi mekanizmasının tasarımını henüz tamamlamadığından, daha detaylı bazı karşılaştırmalar burada listelenmemiştir.

Ek olarak, mevcut 4337 paketleyici için P2P bellek havuzunu tamamladık ve zkRollups'ın Sıralayıcısı ve Operatörü de tek resmi sunuculardır, dolayısıyla belirli merkezi bileşenler vardır.

Geliştirme sürecinde, zkSync'in çeşitli paketleyicilere bağlanma sorunu olmadığından (yalnızca Operatör API'si ile etkileşime girmesi gerekir), 4337'yi kullanmak kolaydır ve hesap sözleşmeleri (SDK) geliştirme deneyimi de daha iyidir; aynı zamanda zkSync, Solidity'yi bir sözleşme Geliştirme dili olarak kullanabilir, dolayısıyla StarkNet geliştirmede Kahire eşiğini aşmaya gerek yoktur.

Çözüm

Hem StarkNet hem de zkSync yerel AA (Yerel AA) kategorisine ait olduğundan, StarkNet AA ile ilgili "StarkNet Hesap Soyutlamasına Giriş" (StarkNet Hesap Soyutlamasına Giriş) başlıklı önceki tanıtımıma da bakabilirsiniz. Ayrıca daha fazla bilgi için EIP-4337 ile ilgili diğer makaleleri okuyabilirsiniz.