Çoklu zincir hesap soyutlama analizi: Şifreleme altyapısının geleceğini tartışmak

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 şehrinde gerçekleştirilecek ve teknoloji ile topluluk gelişimine odaklanacaktır.

Bu yılki Ethereum Topluluğu Konferansı (EthCC 7), 350'den fazla blockchain endüstrisi öncüsünü konuşma yapmaya davet etti. imToken Labs'ın geliştiricisi Alfred davet edildi ve "Geleceği Açığa Çıkarma: Çok Zincirli Hesap Soyutlama Analizi" başlıklı bir konuşma yaptı.

Konuşma Noktalarının Genel Görünümü

• Hesap soyutlama (AA) iki temel unsur: imza soyutlama ve ödeme soyutlama. İmza soyutlama, kullanıcıların istedikleri doğrulama mekanizmasını seçmelerine olanak tanırken, ödeme soyutlama çeşitli işlem ödeme seçenekleri sunarak güvenliği ve kullanıcı deneyimini artırır.

• ERC-4337 ve yerel AA'nın "doğrulama" aşamasındaki giriş noktası fonksiyonları sabittir, ancak "uygulama" aşamasında yalnızca yerel AA sabit bir giriş noktasını korur. Farklı uygulama yöntemleri, işlem kısıtlamaları ve işlem adımları açısından kendine özgü özellikler taşır.

• EVM uyumlu zincir üzerinde ERC-4337'yi uygularken, iki anahtar fark bulunmaktadır: Rollup tasarımındaki protokol farkları ve adres hesaplama yöntemindeki farklılık. Bu farklar, L1 ve L2 arasında ERC-4337'yi uygularken gözden kaçabilecek bazı geliştirme detaylarının ortaya çıkmasına neden olmaktadır.

Hesap Soyutlama Tanıtımı

1. Hesap soyutlamanın tanımı

Hesap soyutlama (AA) esasen iki ana noktayı içerir:

• İmza soyutlama: Kullanıcılar, belirli bir dijital imza algoritması (örneğin ECDSA) ile sınırlı kalmadan, doğrulama mekanizmasını serbestçe seçebilirler.
• Ödeme soyutlama: Kullanıcılar, yerel varlıklar yerine ERC-20 varlıkları kullanarak ödeme yapmak veya üçüncü tarafların işlemleri desteklemesi gibi çeşitli işlem ödeme seçeneklerini kullanabilir.

Bu esneklik, güvenliği ve kullanıcı deneyimini büyük ölçüde artırmaktadır. Hesap soyutlama, bu iki temel hedefi çeşitli yollarla gerçekleştirmeyi amaçlamaktadır.

2. ERC-4337 analizi

Şu anda, Ethereum protokolündeki dışa sahip hesapların (EOA) sabit imza yöntemleri ve ödeme tasarımı gibi bazı sınırlamaları bulunmaktadır. ERC-4337, daha esnek hesap yönetimi ve işlem işleme yöntemleri getirerek bu sorunları çözmektedir.

• userOp yapısı: ERC-4337'de, kullanıcı userOp yapısını Bundler'a gönderir. Bundler, birden fazla userOp toplar ve bunları handleOps fonksiyonunu çağırarak EntryPoint sözleşmesine gönderir.
• EntryPoint sözleşmesi: Bu sözleşme, işletim sistemine benzer, işlemleri işleyen ana işlevler şunlardır:
  • Hesap sözleşmesindeki validate fonksiyonunu çağırarak userOp'un hesap sahibinin yetkisini aldığından emin olun.
  • Ücret alın.
  • Hesap sözleşmesindeki execute fonksiyonunu çağırarak userOp'un hedef işlemini gerçekleştir.

3. Yerel AA Tanıtımı

Ethereum'da hesaplar EOA ve sözleşme hesapları olarak ayrılır. Ancak yerel hesap soyutlamasında, her hesap bir sözleşmedir ve işlem işleme mekanizması doğrudan blok zinciri protokolüne entegre edilmiştir.

Her blok zinciri ağındaki AA tasarımı:

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

ERC-4337 ile Yerel AA Arasındaki Farklar

1. İşletim sistemi rolü

AA OS aşağıdaki sorunları çözmelidir:

• Gaz fiyatını kim belirliyor?
• İşlem sırasını kim belirler? Bellek havuzu nerede?
• Kim giriş noktası fonksiyonunu tetikledi?
• İşlem işleme sürecini ne belirler?

ERC-4337'de, bu roller Bundler ve EntryPoint Sözleşmesi aracılığıyla iş birliği yaparak tamamlanır.

Yerel AA'da, kullanıcı userOps'larını resmi sunucunun operatörüne/sıralayıcısına gönderir, Bundler ve EntryPoint Sözleşmesi yerine.

StarkNet'te, Sequencer bu görevlerin tümünü yerine getirmekten sorumludur.

zkSync Era'nın diğer AA uygulamalarından temel farkı, Operator'un bootloader (sistem sözleşmesi) ile birlikte çalışması gerektiğidir. Bootloader yeni blokları açar, parametrelerini tanımlar (blok parametreleri ve diğer Gas parametreleri dahil) ve doğrulama için Operator'dan gelen işlemleri alır.

2. Sözleşme Arayüzü

Üç adımın varlığı nedeniyle, hesap sözleşmesi arayüzü farklı uygulamalarda benzerlik gösterir, bu giriş noktası işlevleri yalnızca AA OS tarafından çağrılabilir:

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

ERC-4337 ve yerel AA'de, "doğrulama" aşamasının giriş noktası fonksiyonu sabittir, ancak "uygulama" aşamasında sadece yerel AA'deki giriş noktası sabittir.

3. Doğrulama adımlarının kısıtlaması

İşlemleri doğrulamanın maliyet kısıtlaması olmadığı için, bir saldırgan bellek havuzuna DoS saldırısı düzenleyebilir ve bu da paketleyiciyi (EIP-4337) veya operatör/sıralayıcıyı (yerel AA) etkileyebilir.

EIP-4337, yasaklı işlem kodlarını ve depolama erişimini nasıl kısıtlayacağını tanımlar. zkSync Era bazı OpCode kullanımını gevşetti:

• Sözleşme mantığı yalnızca kendi depolama alanına erişebilir. Eğer hesap sözleşmesinin adresi adres A ise, şunlara erişebilir:
  • Adres A'ya ait depolama alanı
  • Herhangi bir başka adres A'ya ait depolama alanı
  • Herhangi bir diğer adrese ait depolama slotu keccak256(A || X): Bu, adresi bir haritadaki anahtar olarak doğrudan kullanmak anlamına gelir ve keccak256(A || X) slotuna erişmekle eşdeğerdir. Örneğin, ERC-20 sözleşmesindeki varlık bakiyesi.
• Sözleşme mantığı, blok numarası gibi global değişkenlere erişemez. StarkNet ayrıca dış sözleşmelerin çağrılmasına da izin vermez.

4. Uygulama adımlarının kısıtlaması

zkSync'te, sistem çağrısını gerçekleştirmek için sistem bayrağının varlığını onaylamak gerekir. Örneğin, nonce'u artırmanın tek yolu NonceHolder ile etkileşimde bulunmaktır, oysa sözleşme dağıtımı ContractDeployer ile etkileşim gerektirir. Sistem bayrakları, hesap geliştiricilerinin sistem sözleşmeleri ile bilinçli bir şekilde etkileşimde bulunmasını garanti eder.

ERC-4337 ve StarkNet'te, yürütme aşamasında özel bir kısıtlama yoktur.

5. Rastgele sayı

• ERC-4337'de, giriş noktası rastgele sayı tasarımı 192 bit anahtar değerini ve 64 bit rastgele sayı değerini ayırır.
• zkSync'te, NonceHolder sistem sözleşmesi nonce'u yönetir, sıkı bir şekilde artmasını sağlar, yani rastgele sayıyı 1 artırır.
• StarkNet'te, nonce de katı bir şekilde artar, ancak belirli bir sözleşme tarafından yönetilen soyut bir nonce yoktur.

6. İlk işlemle dağıtım yapma

• ERC-4337, userOp yapısında, göndericiyi (hesap sözleşmesi) ilk userOp'unda dağıtmak için initcode alanını içerir.
• StarkNet ve zkSync'te, kullanıcıların hesap sözleşmesini dağıtmak için ilk işlemlerini operatöre/sıralayıcıya göndermeleri gerekir.

7. zkSync'teki özel tasarım

Eğer ETH'yi doğrudan Ethereum EOA'dan zkSync'e aktarırseniz, özel bir hesap sözleşmesi dağıtmaya gerek kalmadan, aynı adrese sahip varsayılan bir hesap alırsınız. Bu hesap, Ethereum EOA gibi çalışabilir ve karşılık gelen Ethereum EOA'nın özel anahtarıyla kontrol edilir.

Bu hesap türü None versiyonudur, version1 değil. DefaultAccount'un işlevlerini çağırmak mümkün değil çünkü çekirdek alanında herhangi bir kod dağıtımı yapılmamıştır.

L1'in 4337 ve L2'nin 4337 arasındaki fark

EVM uyumlu zincirlerde ERC-4337 uygulamanın iki temel farkı vardır: protokol farkları ve adres farkları.

1. Protokol farkları

Rollup tasarımında, L2'nin güvenlik ve hesaplama için verileri L1'e yüklemesi gerekir. ERC-4337 bağlamında, bu yükleme süreciyle ilgili ücretler, örneğin L1 güvenlik ücreti ve blob ücreti, ön doğrulama Gas'ına dahil edilmelidir. Ön doğrulama Gas'ında uygun yükleme ücretlerini belirlemek önemli bir zorluktur.

2. Adres farklılıkları

zkSync ERA'nın create fonksiyonundaki adres kodlama yöntemi, Ethereum ve OP toplama ile farklıdır. Ayrıca, StarkNet adres hesaplama için benzersiz bir hash fonksiyonu kullanır. EVM uyumlu zincirlerdeki ERC-4337 bağlamında, genellikle adres hesaplamanın her zincirde tutarlı olduğunu varsayıyoruz. Ancak, Ethereum ve L2'deki ERC-4337 uygulamaları arasında hesap sözleşmesi adreslerinin farklı olmasına neden olabilecek gözden kaçan bir ayrıntı vardır.

Ana sorun, sert çatallara yeni opcode eklemektir. Örneğin, eğer L2 zinciri Şanghay sert çatallamayı desteklemiyorsa ve derleme sırasında EVM versiyonu belirtilmemişse, push0'ın eklenmesi bytecode'un değişmesine yol açar, bu durumda Solidity kodu aynı olsa bile.