Geleceği Açığa Çıkarma: Çok Zincirli Hesap Soyutlama Analizi

8-11 Temmuz tarihlerinde, Ethereum topluluk konferansı Brüksel'de gerçekleştirildi. Bu, Avrupa'nın en büyük Ethereum yıllık etkinliği olup, teknoloji ve topluluğa odaklanmaktadır.

Bu konferansta 350'den fazla blok zinciri sektörünün öncü düşünce lideri konuşma yaptı. Bunlar arasında "Geleceği Açıklamak: Çok Zincirli Hesap Soyutlama Analizi" başlıklı bir konuşma da yer alıyor.

Konuşma noktaları:

• Hesap soyutlama(AA)'in iki ana noktası: 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çeneklerini destekler. Bu esneklik, 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'nın giriş noktası sabittir. Farklı uygulamalarda işlem doğrulama kısıtlamaları ve işlem yürütme adımları farklı özelliklere sahiptir.

• EVM uyumlu zincir üzerinde ERC-4337 uygularken, Rollup tasarımındaki protokol farklılıkları ve adres hesaplama yöntemlerindeki farklılıklar, L1 ve L2 arasında ERC-4337 uygularken bazı ince geliştirme detaylarının ortaya çıkmasına neden olan iki önemli farktır.

Aşağıda konuşmanın tam metni bulunmaktadır:

Merhaba herkes, bugün ERC-4337 ve yerel AA kavramlarını tanıtacağım, aralarındaki farkları tartışacağım ve L1 ile L2'nin 4337 standardının ana farklarına odaklanacağım.

Hesap Soyutlama Tanıtımı

1. Hesap soyutlamanın tanımı

hesap soyutlama(AA) temel olarak iki ana noktayı içerir: imza soyutlaması ve ödeme soyutlaması.

• İmza soyutlama: Kullanıcılar, yalnızca belirli sayısal imza algoritmaları (örneğin ECDSA) ile sınırlı olmaksızın, istedikleri herhangi bir doğrulama mekanizmasını seçebilirler.
• Ödeme soyutlama: Kullanıcılar, yerel varlık yerine ERC-20 varlıklarını kullanarak ödeme yapmak veya üçüncü tarafların işlemleri sponsor etmesine izin vermek gibi çeşitli işlem ödeme seçenekleri kullanabilir.

Bu esneklik, daha güvenli ve daha iyi bir kullanıcı deneyimi sunar. Hesap soyutlamanın amacı, bu iki temel noktayı çeşitli yollarla gerçekleştirmektir.

2. ERC-4337 Tanıtımı

Şu anda, Ethereum protokolündeki dışa sahip hesapların (EOA) bazı kısıtlamaları vardır, örneğin sabit imza yöntemleri ve ödeme tasarımı. ERC-4337, daha esnek hesap yönetimi ve işlem işleme yöntemlerini tanıtarak bu sorunları çözmektedir.

• userOp yapısı: ERC-4337'de, kullanıcı userOp yapısını Bundler'a gönderir. Bundler, birden fazla userOp'u toplar ve bunları handleOps fonksiyonunu çağırarak EntryPoint sözleşmesine gönderir.
• EntryPoint sözleşmesi: Bu sözleşme, işlemeleri bir işletim sistemi gibi yönetir, başlıca işlevleri şunlardır:
  • Hesap sözleşmesindeki validate fonksiyonunu çağırarak userOp'nin 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 ikiye ayrılır. Ancak, yerel AA'da her hesap bir sözleşmedir ve işlem işleme mekanizması doğrudan blok zinciri protokolüne entegre edilmiştir.

Her blockchain ağındaki AA tasarımı:

• ERC-4337 hesap soyutlama: Ethereum, Arbitrum, Optimism, Base, Linea, Scroll, Polygon PoS
• Yerel hesap soyutlama ERC-4337'ye uygundur: StarkNet & zkSync dönemi
• Gizlilik tasarımı olan yerel hesap soyutlama: Aztec

ERC-4337 ve Yerel AA Arasındaki Farklar

1. İşletim Sistemi Rolü

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

• Gaz fiyatlarının belirleyicisi
• İşlem sırasını belirleyen ve bellek havuzunun konumu
• Giriş noktası fonksiyonunun tetikleyicisi
• İşlem işleme sürecinin belirleyici faktörleri

ERC-4337'de, bu roller Bundler ve EntryPoint Contract aracılığıyla işbirliği içinde tamamlanır.

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

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

zkSync'te, Era'nın diğer AA uygulamalarından temel farkı, Operator'ün bootloader (sistem sözleşmesi) ile işbirliği yapması gerektiğidir. Bootloader yeni blokları açar, parametrelerini tanımlar (blok parametreleri ve diğer Gas parametreleri dahil) ve doğrulama için Operator'den 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östermektedir, bu giriş noktası fonksiyonları yalnızca AA OS tarafından çağrılabilir:

• ERC-4337: Kullanıcı işlemlerini doğrulama
• zkSync: işlem doğrulama, işlem ödemesi, işlem gerçekleştirme
• StarkNet: çalıştır, doğrula, beyanı doğrula, dağıtımı doğrula

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

3. Doğrulama adımlarının sınırlamaları

İşlem doğrulamanın maliyet sınırlaması olmadığı için (esasen, işlem doğrulama bir görünüm fonksiyonunu çağırmaktır), saldırganlar bellek havuzuna DoS saldırısı yaparak paketleyiciyi (EIP-4337) veya operatörü/sıralayıcıyı (yerel AA) bozabilirler.

EIP-4337, hangi işlem kodlarının yasaklandığını ve depolama erişimini nasıl sınırlayacağını tanımlar. zkSync Era, bazı OpCode'ların kullanımını gevşetmiştir:

• Sözleşme mantığı yalnızca kendi depolama alanına erişebilir. Eğer hesap sözleşmesinin adresi adres A ise, erişebilir:

  • Adres A'ya ait depolama alanı
  • Herhangi bir diğer adres A'nın depolama yeri
  • Herhangi bir diğer adresin depolama slotu keccak256 (A || X): Bu, adresin bir haritadaki anahtar olarak doğrudan kullanılması anlamına gelir (örneğin, mapping (address => value)), keccak256 (A || X) slotuna erişmeye eşdeğerdir. Örneğin, ERC-20 sözleşmesindeki varlık bakiyesi.

• Sözleşme mantığı, küresel değişkenlere, örneğin blok numarasına erişemez. StarkNet de dış sözleşmelerin çağrılmasına izin vermez.

4. Adım yürütme kısıtlaması

zkSync'te, sistem çağrılarının gerçekleştirilmesi için sistem bayrağının varlığının onaylanması 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 bayrağı, hesap geliştiricilerinin sistem sözleşmeleriyle bilinçli bir şekilde etkileşimde bulunmalarını sağlar.

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 değerini ayırmaktadır.
• zkSync'te, NonceHolder sistem sözleşmesi nonce'yi yönetir, sıkı bir şekilde artış sağlar, yani rastgele sayıyı 1 artırır.
• StarkNet'te nonce de katı bir şekilde artan bir sıradadır, ancak belirli bir sözleşme tarafından yönetilen soyut bir nonce yoktur.

6. İlk işlemi kullanarak dağıtım yapın

• ERC-4337, userOp yapısında initcode alanını içerir, böylece ilk userOp'unda göndereni (hesap sözleşmesi) dağıtabilir.
• 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 gerekmektedir.

7. zkSync'teki özel tasarım

Eğer ETH'yi doğrudan Ethereum EOA'dan zkSync'e özel bir hesap sözleşmesi dağıtmadan aktarırsanız, aynı adrese sahip varsayılan bir hesap alırsınız. Bu hesap, Ethereum EOA gibi çalışabilir ve aynı zamanda ilgili Ethereum EOA'nın özel anahtarı ile kontrol edilir.

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

L1 ve L2'deki 4337'nin farkı

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

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 maliyetler, örneğin L1 güvenlik ücreti ve blob ücreti, ön doğrulama Gas'ına dahil edilmelidir. Ön doğrulama Gas'ında uygun yükleme maliyetlerini belirlemek büyük bir zorluktur.

2. Adres farkı

zkSync ERA'nın create fonksiyonundaki adres kodlama yöntemi, Ethereum ve OP toplama yöntemlerinden farklıdır. Ayrıca, StarkNet adres hesaplama için benzersiz bir hash fonksiyonu kullanmaktadır. EVM uyumlu zincirler üzerindeki ERC-4337 bağlamında, genellikle adres hesaplamanın her zincirde tutarlı olduğu varsayılır. Ancak, Ethereum ve L2'deki ERC-4337 uygulamaları arasında hesap sözleşme adreslerinin farklı olmasına neden olabilecek dikkat edilmesi zor bir detay vardır.

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

Sonuç

Yukarıda hesap soyutlama ile ilgili bazı bilgiler bulunmaktadır. Herhangi bir sorunuz varsa, benimle Twitter'da iletişime geçmekten çekinmeyin.