Çoklu zincirli hesap soyutlama çözümlerini keşfetme: Yerel destek ve ERC-4337 uyumluluğu

@OKX Ventures araştırmacısı Kiwi Yao tarafından yazılmıştır.

Çoklu zincirli hesap soyutlama (AA) çözümleri, birden fazla blok zinciriyle etkileşim kurmanın yeni ve yenilikçi bir yoludur. Kullanıcıların, gas ödemeleri için yeterli miktarda yerel tokene sahip olmak gibi temel teknik ayrıntılar hakkında endişelenmelerine gerek kalmadan birden fazla blok zincirinde hesap oluşturmalarına ve yönetmelerine olanak tanır. Bu, kullanıcıların blok zinciri teknolojisine girişini ve birden fazla blok zincirini aynı anda kullanmasını çok daha kolay hâle getirir. Çoklu zincirli AA çözümlerinin iki ana türü vardır: yerel destek ve ERC-4337 uyumluluğu.

Yerel destek, bir blok zincirinin doğrudan çoklu zincirli AA’yı desteklemesidir. ERC-4337 uyumluluğu, bir blok zinciri veya katman 2 ölçeklendirme çözümünün çok zincirli AA’yı uygulamak için bir akıllı sözleşme kullanmasıdır. Bu makalede, çok zincirli AA çözümleri için hem yerel desteği hem de ERC-4337 uyumluluğunu inceleyeceğiz. Ayrıca her yaklaşımın avantajlarını ve dezavantajlarını da tartışacağız.

ERC-4337 hesap soyutlama ile uyumlu ağlar

Arbitrum

Arbitrum, AIP-2 teklifinin kabul edilmesinin ardından Arbitrum One ve Arbitrum Nova’daki AA uç noktalarını resmî olarak etkinleştirdi. Teklif yeni bir RPC uç noktası sunuyor — eth_sendRawTransactionConditional — ERC-4337 paketleyicilerin ihtiyaçlarını karşılamak için özel olarak tasarlanmıştır.

Polygon

Polygon, ERC-4337 uyumludur ve bunu meta işlemler için Biconomy, Gas Station Ağı (GSN), Infura ve Gelato gibi çözümlerden yararlanarak başarmaktadır. Ayrıca Polygon’un zkEVM’si, ERC-4337 aracılığıyla AA’yı destekleyerek kullanıcıların herhangi bir tokenle ödeme yapmasına olanak tanır.

Optimism

Şu anda OP ana ağında Alchemy, Biconomy, CyberConnect, Pimlico ve Stackup gibi projeler aracılığıyla çeşitli AA altyapıları mevcuttur, ancak ayrıntılı mimari bilgiler henüz yayımlanmamıştır.

BNB

Ekip, BNB Chain’in 2023 teknik yol haritasında AA altyapısının kurulmasından bahsediyor. ERC-4337 ile uyumluluğu da teyit edildi ve daha fazla ayrıntının yakında yayımlanması bekleniyor.

Yerel hesap soyutlama

Starknet

Starknet, tüm hesapları sözleşme hesapları (CA’lar) veya akıllı hesaplar şeklinde oluşturarak AA’yı yerel olarak destekliyor. AA’yı yerel olarak desteklemenin amaçları arasında imza soyutlama ve ödeme soyutlama yer alıyor. Bunlar, farklı hesap sözleşmelerinin farklı imza doğrulama şemaları ve işlemler için farklı ödeme modelleri kullanmasına imkân sağlamayı amaçlıyor. Bu sayede, bireyler artık imza doğrulama ve bir üçüncü taraftan veya akıllı sözleşmeden ödeme yapma konusunda daha fazla seçeneğe sahip olduğundan, hesabı yönetme deneyimi büyük ölçüde geliştirilecek.

Starknet işlem akışı

Bir bloka eklenmek üzere bir işlem seçildiğinde, sıralayıcı onu alır ve yürütür. İşlemin yürütülmesi iki aşamada gerçekleşir. İlk olarak, sıralayıcı, hesap sözleşmesinden işlemi doğrulamasını ister. Daha sonra hesap sözleşmesinin bunu yürütmesini ister. Bu iki aşama, hesap sözleşmesinde doğrulama ve yürütme olmak üzere iki ayrı işlevle kodlanmıştır.

Bu aşamalar arasındaki ayrım, Starknet OS’nin sıralayıcıya ödemeyi garanti etmesini sağlar. Starknet işlem havuzuna hizmet reddi (DoS) saldırısı yapılmasını ve havuzun geçersiz işlemlerle doldurulmasını önlemek için Starknet, bir işlemi kabul eden bir düğümün, işlemi havuza eklemeden ve diğer düğümlere ve sıralayıcılara yayımlamadan önce bilinen duruma göre yerel olarak simüle etmesini zorunlu kılar. Simülasyon tamamlandıktan sonra işlem havuza girilebilir ve ağ üzerinde yayılabilir.

An illustration outlining the flow of a Starknet transaction

Kaynak: StarkNet

Starknet AA ve ERC-4337 AA karşılaştırması

• Starknet, paketleyicinin getirdiği ek karmaşıklığı ortadan kaldırır ve sıralayıcıyı paketleyici rolünü yerine getirecek şekilde atar. Bu, paketleyicilerin kullanıcı işlemlerini (user ops) yürütmesini gerektiren ERC-4337’nin AA çözümünden farklıdır.

• ERC-4337’nin AA çözümüyle karşılaştırıldığında, Starknet, ödeme yöneticisi benzeri bir işlem ücreti soyutlama protokolü içermez.

• Starknet ayrıca normal işlemler ile kullanıcı işlemleri arasında ayrım yapmayarak süreci basitleştirir.

• Önemli bir fark da kurulum sürecindedir. Starknet, CA’nın çalıştırılabilmesi için önce onu kurar. Starknet, temel olarak, özel bir “hesap_kurma” işlevini çağırarak yeni bir CA oluşturmak için token bakiyesi olan hesaplar gerektirir. Kurulan bu hesap sözleşmesi gas ödeyebilir. Karşılaştırmalı olarak, ERC-4337’nin AA çözümü önceden kurulum gerektirmez. Paketleyici, boş olmayan bir initCode parametresiyle bir kullanıcı işlemi yürüterek bir CA kurar. Kurulum süreci için token bakiyesi olan bir hesaba gerek yoktur ve gas ücreti ödeme yöneticisi tarafından ödenebilir.

zkSync

zkSync, yerel AA’yı destekler ve Ethereum Sanal Makinesi (EVM) ile uyumluluk sağlar. Starknet’e benzer şekilde, zkSync, çeşitli hesap sözleşmeleri için farklı imza doğrulama şemalarını ve işlemler için çeşitli ödeme modellerini ve token formlarını destekleyerek imza ve ödeme soyutlamayı amaçlar.

zkSync işlem akışı

zkSync’in işlem akışı, kişinin imzalanmış işlemi operatöre göndermesini ve bunun daha sonra doğrulama için önyükleyiciye gönderilmesini içerir. Doğrulama ve ücret alındıktan sonra önyükleyici, işlemi yürütmek için CA’yı arar.

zkSync AA ve ERC-4337 AA karşılaştırması

• ERC-4337’nin AA çözümünün aksine zkSync, harici sahipli hesaplar (EOA’lar) ile CA’lar arasında ayrım yapmaz.

• zkSync, validateTransaction işlevinin kurulan harici sözleşmeleri çağırmasına olanak tanır. Bu özellik, işlem doğrulamasının geçmesine ve işlemin yürütme yönünün başarısız olmasına neden olan bir durum değişikliği yaratabileceği için Ethereum’da kısıtlanmıştır.

• Diğer bir fark, zkSync’in validateTransaction işlevine ve ödeme yöneticisinin bu işlemi düzenleyen CA’nın harici depolama alanını çağırmasına izin vermesidir. Örneğin, CA’nın harici sözleşmedeki token bakiyesi, ödeme yöneticisi ve validateTransaction işlevi sayesinde görüntülenebilir. Bunun aksine, Ethereum böyle bir özelliği yasaklar.

zkSync, Starknet ve ERC-4337 uyumlu ağlar arasında AA çözümü karşılaştırmaları

Benzerlikler

• zkSync, Starknet ve ERC-4337 uyumlu ağlar benzer AA işlemlerini paylaşır. Bunlar arasında doğrulama aşaması, ücret mekanizması (hesap sözleşmesi veya ödeme yöneticisi tarafından ödenen) ve uygulama aşaması yer alır. Ek olarak, akıllı sözleşme cüzdanı arayüzleri validateTransaction ve executeTransaction işlevleri olarak sınıflandırılır.

• zkSync, Starknet ve ERC-4337, DoS Saldırılarını benzer şekilde ele alır. zkSync’in sözleşme mantığı yalnızca kendi yuvalarına dokunma iznine sahiptir ve sözleşme mantığının global değişkenleri kullanmasına izin verilmez. Benzer şekilde, Starknet’in sıralayıcısı, işlemleri bellek havuzuna eklemeden ve yayımlamadan önce yerel emülasyon gerektirir. Son olarak, ERC-4337’nin kullanıcı işlemi, validateUserOp adımına bir gas limiti koyar ve ödeme yöneticisinin token taahhüt etmesini gerektirir.

Farklılıklar

• En büyük fark, zkSync ve StarkNet’in her ikisinin de yerel AA olması ve ERC-4337 uyumlu ağlardan mimari farklılıkları olmasıdır.

• Zincir üstü gas tüketimi bakımından, zkSync ve StarkNet’in her ikisi de Rollup maliyetlerini dikkate alması gereken Katman 2 ölçeklendirme çözümleridir.

• AA’nın yürütülmesiyle ilgili farklı roller vardır. zkSync mimarisi, kullanıcı işlemlerini yerine getirmek için birlikte çalışan operatör ve önyükleyiciye (sistem sözleşmesi) sahiptir. StarkNet için, kullanıcı işlemleri paketleyici ve ödeme yöneticisi mekanizmaları olmadan sıralayıcı tarafından gerçekleştirilir. Son olarak, ERC-4337 uyumlu ağlar, paketleyicileri ve giriş noktası sözleşmelerini içeren farklı mimarilere sahiptir.

• Diğer bir önemli fark da CA kurulmadan önce işlemlerin gönderilip gönderilemeyeceğidir. Hem StarkNet’te hem de zkSync’te giriş noktası sözleşmesinde, CA’nın kişi için kurulmasına olanak tanıyan bir initCode alanı yoktur. Bu, hesap kurulmadan önce ikisinin de işlem gönderememesi anlamına gelir.

• Son olarak, harici sözleşmelerin çağrılmasında bir fark vardır. zkSync, validateTransaction işlevinin kurulan harici sözleşmeleri çağırmasına olanak tanır. Ancak hem ERC-4337 uyumlu ağlar hem de Starknet buna izin vermez.

Ödeme yöneticisi farkı

• Starknet’in ödeme yöneticisi arayüzü yoktur.

• ERC-4337 uyumlu ağlar için ödeme yöneticisi arayüzü validatePaymasterOp’u tanımlar. Bu, ödeme yöneticisinin bir işlem için ödeme yapma mantığını tanımlar. Arayüz, ayrıca, işlem yürütüldükten sonra ödeme yöneticisinin gas ücreti tazminatını alabilmesini sağlayan postOp işlevini de kullanır. Ödeme yöneticisinin, bir gas ödeme şekli olarak giriş noktası sözleşmesine Ethereum yatırması ve botların kötü amaçlı gruplar oluşturmalarını önlemek için giriş noktası sözleşmesine Ethereum taahhüt etmesi gerekir.

• zkSync, arayüzün validatePaymasterOp ve postOp işlevlerini tanımladığı ERC-4337 uyumlu ağlara benzer. Tanımları ERC-4337’ye benzer ancak işlevin bu kısmı henüz uygulanmamıştır. ERC-4337’nin ödeme yöneticisinden farklı olarak, zkSync’in ödeme yöneticisi, sahip olduğu gas yeterliyken postTransaction’ı çağırana kadar yürütmeye başlamaz. Öte yandan, validatePaymasterUserOp bir bağlam getirmediğinde ERC-4337’nin ödeme yöneticisi postOp’u çağırmaz.

Karşılaştırma Tablosu

Yerel destek ile ERC-4337 uyumluluğuna sahip ağlar arasındaki farkı görmek için hızlı bir referansa mı ihtiyacınız var? Aşağıdaki tablomuza göz atın.

Sonuç

Ethereum AA’yı kullanıma sunarken, birçok başka ağın da kitlesel benimsenişi daha zorlu hâle getirebilecek sorunları ele alarak aynı yolu izlediğine tanık oluyoruz. Çoklu zincirli AA sayesinde, birbirine rakip ekosistemler, gas ödeme esnekliği ve özel anahtarlara bağımlılık gibi sorunları çözme konusunda çok da geride olmadıklarını gösteriyor olabilir.

Çoklu zincirli AA, Web3 alanını bizimle keşfetmeye olan ilginizi artırdı mı? OKX’in AA’yı çoklu zincirli cüzdanımıza nasıl entegre edeceğini öğrenin.