Çoklu Hesap Soyutlama Analizi: Şifreleme Altyapısının Geleceğini Keşfetmek

Son günlerde, Ethereum topluluk konferansı (EthCC 7) Belçika'nın Brüksel şehrinde 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 yılki konferansta, 350'den fazla blok zinciri endüstrisinin öncüsü konuşma yaptı; bunlar arasında bir geliştirici "Geleceği Ortaya Çıkarma: Çoklu Zincir Hesap Soyutlaması Analizi" başlıklı bir konuşma yaptı.

Konuşma Temel Noktaları

• Hesap soyutlama (AA) esasen iki ana noktayı içerir: imza soyutlama ve ödeme soyutlama. İmza soyutlama, kullanıcıların istedikleri herhangi bir doğrulama mekanizmasını seçmelerine olanak tanırken, ödeme soyutlama ise çeşitli işlem ödeme seçeneklerinin kullanılmasına izin verir. Bu esneklik, daha güvenli ve daha iyi bir kullanıcı deneyimi sunar.

• 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'de giriş noktası sabittir. Doğrulama işlemlerinin kısıtlamaları ve uygulama işlemlerinin adımları, farklı uygulamalarda kendi özelliklerine ve kısıtlamalarına sahiptir.

• EVM uyumlu zincir üzerinde ERC-4337'nin uygulanmasında iki ana fark vardır: Rollup tasarımındaki protokol farklılıkları ve adres hesaplama yöntemlerindeki farklılıklar, L1 ve L2 arasında ERC-4337'yi gerçekleştirirken dikkate alınması zor geliştirme detaylarının ortaya çıkmasına neden olur.

Hesap Soyutlama Tanıtımı

Hesap soyutlama nedir?

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

1. İmza soyutlama: Kullanıcı, yalnızca belirli sayısal imza algoritmaları (örneğin ECDSA) ile sınırlı olmaksızın, istediği herhangi bir doğrulama mekanizmasını seçebilir.

2. Ödeme soyutlama: Kullanıcılar, yerel varlıkları ödemek için ERC-20 varlıklarını kullanmak veya üçüncü tarafların işlemleri desteklemesine izin vermek gibi çeşitli işlem ödeme seçeneklerini kullanabilir.

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

ERC-4337 hakkında

Şu anda, Ethereum protokolündeki dış sahipli hesapların (EOA) bazı kısıtlamaları var, örneğin sabit imza yöntemleri ve ödeme tasarımı. 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'u toplar ve bunları EntryPoint sözleşmesine göndermek için handleOps fonksiyonunu çağırır.

• EntryPoint sözleşmesi: Bu sözleşme, işletim sistemi gibi işlemleri yönetir, ana işlevleri şunlardır:

  • Hesap sözleşmesindeki validate fonksiyonunu çağırarak userOp'un hesap sahibi tarafından yetkilendirildiğinden emin olun.
  • Ücret talep et.
  • Hesap sözleşmesindeki execute fonksiyonunu çağırarak userOp'un hedef işlemini gerçekleştirin.

Yerel AA Tanıtımı

Ethereum'da, hesaplar EOA ve sözleşme hesapları olarak 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 gömülüdür.

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 uyar: StarkNet ve zkSync dönemi
• Gizlilik tasarımı olan yerel hesap soyutlama: Aztec

ERC-4337 ve Yerel AA Arasındaki Farklar

işletim sistemi rolü

AA OS'un aşağıdaki sorunları çözmesi gerekiyor:

• Gaz fiyatını kim belirliyor?
• İşlem sırasını kim belirler? Bellek havuzu nerede?
• Kim giriş noktası fonksiyonunu tetikler?
• İş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'de, kullanıcı userOps'larını Bundler ve EntryPoint Sözleşmesi yerine resmi sunucunun operatörüne/sıralayıcısına gönderir.

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

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

sözleşme arayüzü

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

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

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.

doğrulama adımlarının sınırlamaları

İşlemleri doğrulamanın maliyet sınırlaması olmadığı için (özünde, işlemleri doğrulamak 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) bozabilir.

EIP-4337, hangi işlem kodlarının yasaklandığını ve depolama erişimini nasıl kısıtlayacağını tanımlar. zkSync Era, bazı OpCode 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, şunlara erişebilir:

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

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

yürütme 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 gerekmektedir. Örneğin, nonce'u artırmanın tek yolu NonceHolder ile etkileşimde bulunmaktır, oysa sözleşme dağıtmak için ContractDeployer ile etkileşimde bulunmak gerekir. Sistem bayrakları, hesap geliştiricilerin sistem sözleşmeleri ile bilinçli bir şekilde etkileşimde bulunduğunu garanti eder.

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

rasgele sayı

• ERC-4337'de, giriş noktası rastgele sayı tasarımı 192 bit anahtar değeri ile 64 bit rastgele değer arasında ayırım yapmaktadır.
• zkSync'de, NonceHolder sistem sözleşmesi nonce'u yönetir, sıkı bir şekilde artışını sağlar, yani rastgele sayıyı 1 artırır.
• StarkNet'te nonce da kesinlikle artan bir sıradadır, ancak belirli bir sözleşme tarafından yönetilen soyut bir nonce yoktur.

ilk işlem ile dağıtım yapma

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

zkSync'teki özel tasarım

Eğer ETH'yi Ethereum EOA'dan zkSync'e doğrudan aktarır ve özel bir hesap sözleşmesi dağıtmanıza gerek kalmazsa, aynı adrese sahip varsayılan bir hesap alırsınız. Bu hesap, Ethereum EOA gibi çalışabilir ve ayrıca ilgili Ethereum EOA'nın özel anahtarıyla kontrol edilir.

Bu hesap türü None sürümüdür, version1 değil. DefaultAccount fonksiyonunu çağırabilirsiniz çünkü çekirdek alanında herhangi bir kod dağıtılmamıştır.

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

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

protokol farklılıkları

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 işlemiyle ilgili maliyetler, örneğin L1 güvenlik ücreti ve blob ücretleri, ön doğrulama Gas'ına dahil edilmelidir. Ön doğrulama Gas'ındaki uygun yükleme maliyetlerini belirlemek önemli bir zorluktur.

adres farkı

zkSync ERA'nın create fonksiyonundaki adres kodlama yöntemi, Ethereum ve OP toplama ile farklıdır. Ayrıca, StarkNet adres hesaplamasında benzersiz bir hash fonksiyonu kullanır. EVM uyumlu zincirlerdeki 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 ayrıntı vardır.

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