Çok Zincirli Hesap Soyutlama: Şifreleme Altyapısının Geleceğini Ortaya Çıkarıyor

8-11 Temmuz 2024 tarihlerinde, Avrupa'nın en büyük Ethereum yıllık etkinliği - Ethereum Topluluk Konferansı (EthCC) Belçika'nın Brüksel kentinde gerçekleştirildi. Bu yılki konferansta (EthCC 7), 350'den fazla blockchain sektörü öncüsü konuşma yaptı. Bunlar arasında imToken Labs geliştiricisi Alfred de yer aldı ve "çok zincirli hesap soyutlama解析" konusunu derinlemesine inceledi.

Konuşma Noktaları

• Hesap soyutlama (AA) iki ana çekirdek: imza soyutlaması ve ödeme soyutlaması. İlki, kullanıcıların istedikleri doğrulama mekanizmasını seçmelerine olanak tanırken, ikincisi çeşitli işlem ödeme seçeneklerini destekleyerek güvenliği ve kullanıcı deneyimini artırmaktadır.

• ERC-4337 ve yerel AA'nın doğrulama ve yürütme aşamalarındaki giriş noktası fonksiyonu tasarımında farklılıklar vardır. ERC-4337'nin doğrulama aşaması giriş noktası sabittir, ancak yürütme aşaması sabit değildir; yerel AA'da ise her iki aşamanın giriş noktası da sabittir.

• EVM uyumlu zincir üzerinde ERC-4337 uygulandığında, Rollup tasarımındaki protokol farklılıkları ve adres hesaplama yöntemindeki farklılıklar, L1 ve L2 arasında uygulamada ince ama önemli farklılıklara neden olmaktadır.

Hesap Soyutlama Genel Bakış

hesap soyutlamanın doğası

Hesap soyutlama (AA) esasen iki ana noktayı kapsamaktadır:

1. İmza soyutlama: Kullanıcılara istedikleri herhangi bir doğrulama mekanizmasını seçme imkanı tanır, belirli bir dijital imza algoritması ile sınırlı kalmaz.

2. Ödeme soyutlama: Kullanıcılar, işlem ücretlerini ödemek için çeşitli yöntemler kullanabilir, örneğin yerel varlıkların yerine ERC-20 token'ları kullanmak veya işlemi üçüncü tarafların sponsorluk yapması.

Bu esneklik, güvenliği ve kullanıcı deneyimini büyük ölçüde artırdı.

ERC-4337解析

ERC-4337, Ethereum dışarıdan sahip olunan hesapların (EOA) sınırlamalarını aşmayı ve daha esnek hesap yönetimi ve işlem işleme yöntemleri sunmayı amaçlamaktadır:

• userOp yapısı: Kullanıcı userOp'yi Bundler'a gönderir, Bundler birden fazla userOp'yi toplar ve handleOps fonksiyonunu çağırarak EntryPoint sözleşmesine gönderir.

• EntryPoint sözleşmesi: İşlem işlemeciliğinin merkezi olarak, ana işlevleri şunları içerir:

  1. Kullanıcı işlemi yetkilendirmesini doğrulamak için hesap sözleşmesinin validate fonksiyonunu çağırın.
  2. Ücret alma.
  3. Hesap sözleşmesinin execute fonksiyonunu çağırarak userOp hedef işlemini gerçekleştir.

Yerel AA Özeti

Yerel AA'de, her hesap bir sözleşmedir ve işlem işleme mekanizması doğrudan blok zinciri protokolüne entegre edilmiştir. Farklı ağların kullandığı AA tasarımı birbirinden farklıdır:

• ERC-4337 hesap soyutlama: Ethereum, Arbitrum, Optimism, Base, Linea, Scroll, Polygon PoS
• ERC-4337'ye dayalı yerel hesap soyutlama: StarkNet ve zkSync Era
• Gizlilik tasarımına sahip yerel hesap soyutlama: Aztec

ERC-4337 ve Yerel AA'nın Karşılaştırılması

işletim sistemi rolü

AA işletim sistemi aşağıdaki sorunları çözmelidir:

• Gaz fiyatlarının belirlenmesi
• İşlem sırasının belirlenmesi ve bellek havuzu konumu
• Giriş noktası fonksiyonunun tetiklenmesi
• İşlem işleme sürecinin tanımı

ERC-4337, Bundler ve EntryPoint Sözleşmesi aracılığıyla bu görevleri tamamlar. Yerel AA'da ise, kullanıcılar userOps'u doğrudan resmi sunucunun operatörüne/sıralayıcısına gönderir.

StarkNet'te, Sequencer bu tüm görevleri yerine getirir. zkSync Era ise Operator'ın bootloader (sistem sözleşmesi) ile birlikte çalışmasını gerektirir.

sözleşme arayüzü

Hesap sözleşmesi arayüzü farklı uygulamalarda genel olarak benzerdir ve AA işletim sistemi tarafından çağrılan giriş noktası fonksiyonlarını içerir:

• ERC-4337: Kullanıcı işlemlerini doğrulama
• zkSync: işlemleri doğrulama, işlem ödemesi, işlemleri yürütme
• StarkNet: çalıştır, doğrula, doğrula_beyan, doğrula_dağıt

doğrulama adımı kısıtlaması

DoS saldırılarını önlemek için, her bir uygulama doğrulama işlemlerine farklı kısıtlamalar getirmiştir:

• ERC-4337, yasaklı işlem kodları ve depolama erişim kısıtlamalarını tanımlar.
• zkSync Era, bazı OpCode kullanımını gevşetti ancak depolama erişim alanını sınırladı.
• StarkNet dış sözleşmelerin çağrılmasına izin vermez.

uygulama adımı kısıtlaması

• zkSync, sistem çağrısını gerçekleştirmek için sistem bayrağının onayını gerektirir.
• ERC-4337 ve StarkNet'in yürütme aşamasında özel bir kısıtlama yoktur.

rastgele sayı işleme

• ERC-4337, 192 bit anahtar değerini ve 64 bit rastgele değeri ayırır.
• zkSync, nonce'leri yönetmek için NonceHolder sistem sözleşmesini kullanır ve sıkı bir şekilde artış sağlar.
• StarkNet'in nonce'u da kesinlikle artar, ancak özel bir yönetim sözleşmesi yoktur.

İlk işlem dağıtımı

• ERC-4337, userOp yapısında, hesap sözleşmelerini ilk kez dağıtmak için initcode alanını içerir.
• StarkNet ve zkSync, kullanıcıların hesap sözleşmesini dağıtmak için ilk işlemlerini operatöre/sıralayıcıya göndermelerini gerektirir.

zkSync özel tasarım

zkSync, kullanıcıların ETH'yi Ethereum EOA'dan doğrudan transfer etmelerini sağlar, özel bir hesap sözleşmesi dağıtmadan aynı adresle varsayılan bir hesap elde eder, bu hesap Ethereum EOA gibi çalışabilir.

L1 ve L2'deki ERC-4337 Uygulama Farklılıkları

protokol farklılıkları

L2'nin verileri güvenlik ve hesaplama için L1'e yüklemesi gerekir. ERC-4337'de, ilgili L1 güvenlik ücretleri ve blob ücretleri ön doğrulama Gazına dahil edilmelidir, bu da uygun yükleme ücretlerini belirlemeyi zorlaştırmaktadır.

adres farkı

Farklı blok zincirlerinin adres hesaplama yöntemlerinde farklılıklar vardır:

• zkSync ERA'nın create fonksiyonundaki adres kodlama yöntemi Ethereum ve OP toplama yöntemlerinden farklıdır.
• StarkNet, adres hesaplaması için benzersiz bir hash fonksiyonu kullanır.

Ayrıca, sert çatallamada eklenen opcode'lar, bytecode değişikliğine neden olabilir ve bu da hesap sözleşmesi adresinin tutarlılığını etkileyebilir. Örneğin, eğer L2 zinciri Şanghay sert çatallamasını desteklemiyorsa ve derleme sırasında EVM versiyonu belirtilmemişse, push0'ın eklenmesi bytecode'u değiştirecektir.