Cüzdanları Sonraki 1 Milyar Kullanıcıya Hazır Hale Getirmek: Hesap Soyutlama (Account Abstraction)

Önceden herhangi bir Web3 cüzdanı kuran her kullanıcı, cüzdanı kurarken rastgele verilen 12 kelimeyi ve onu saklamanın veya hatırlamanın zorluğunu yaşamıştır. Bu zorluk, kullanıcıların fonlarına tamamen “sahip” olabilmesi için bir zorunluluk olarak blok zincirlerle gelmekte. Her ne kadar güvenlik açısından çeşitli artılara sahip olsa da blok zincirlerdeki kullanıcı deneyiminin 12 kelimeyle ölçeklenemediği açıktır. Nitekim Ethereum’un kurucularından olan Vitalik, Ethereum’un asıl dizaynında cüzdanları böyle dizayn etmek istemediklerini fakat topluluğun çalışır ürün görme baskısından dolayı Ethereum’u “şu anki haliyle” yayına aldıklarını belirtiyor. Peki Ethereum’un kullanıcı deneyimini nasıl ölçekleyeceğiz, 1 milyar kullanıcıya ulaşma hedefiyle çıktığımız bu yoldaki en temel unsur olan kullanım kolaylığını nasıl sağlayacağız? İşte burada bizi Account Abstraction (çevirinin asıl anlamını karşıladığını düşündüğüm için yazının devamında hesap soyutlama olarak bahsedeceğim.) karşılıyor. Önceden hiç cüzdan kurmadıysanız, blok zincire tamamen uzaksanız veya deneyimli bir blok zinciri mühendisiyseniz bu hiç önemli değil; her düzeyden okuyucu bu yazıyı rahatlıkla anlayabilir. O zaman cüzdanları sonraki 1 milyar kullanıcıya hazır hale getirelim: Hesap Soyutlama.

Blok Zincirlerdeki Sahiplik ve EOA Cüzdanların Çalışma Mantığı:

Bitcoin bir uygulamaya özel çıkmış zincirlerin başlıcasıdır. Bitcoin’in asıl ve neredeyse tek kullanım alanı, ödeme sistemleridir. Eşten eşe para transferini mümkün kılmasıyla Bitcoin birçok soruna aslında çözüm buldu — ki hala azımsanamayacak miktarda kullanıcısı bulunmakta. Bitcoin’in bir uygulamaya yönelik bu yapısı, üzerinde geliştirme yapmak isteyen geliştiricileri çokça kısıtlayan bazı özelliklere sahiptir. Bu yüzden de Bitcoin üzerinde ödeme sistemi dışında uygulamalar geliştirmek isteyen geliştiriciler, başta Ethereum olmak üzere Turing Complete blok zinciri platformlarına yöneldiler. Ethereum şu anda bunlar arasında en yüksek TVL’e sahip ve en çok kullanılan platformlardan biridir.

Ethereum çıktığı ilk günden beri kullanıcı deneyimini iyileştirmeyi ve kolaylaştırmayı amaçlıyor. Bunun için cüzdanlarda çeşitli iyileştirmeler yapsalar da hala cüzdanların sıradan bir kullanıcı için çok zor olduğu açıktır. Bunun başlıca sebebi, Ethereum’daki sahipliği güvenli bir şekilde yapmanın zorluğundan geliyor. Peki; Ethereum’daki sıradan cüzdanlardaki EOA — (Externally Owned Account) sahiplik nasıl ispat ediliyor, bu cüzdanlarla yapacağımız işlemlerin geçerli olmasının şartları neler?

Ethereum’daki EOA cüzdanlar, sahipliği kanıtlamak için matematiğe ve kriptografiye güveniyor. Bir EOA cüzdanı oluşturabilmeniz, entropiye dayanan bir dizi matematiksel işlem ile sağlanır. Burada entropinin sonucu olarak gizli anahtara ve gizli anahtardan türetilmiş açık anahtar dediğimiz iki değere sahip oluruz. Bu konuyu bir analojiyle anlatacak olursak bir yokuş çıktığımız ve indiğimiz iki senaryoda yokuş inmeyi, gizli anahtardan açık anahtara erişmek olarak; yokuş tırmanmayı ise açık anahtardan gizli anahtara erişmek olarak anlatabiliriz. Gizli anahtar; Ethereum’daki sahipliğin en küçük, atomik bileşenidir. Herhangi bir şekilde tahmin edilemez ve açık anahtardan oluşturulamaz. Açık anahtar ise herkes tarafından erişilebilirdir ve gizli anahtardan tek yönlü matematiksel işlemler sonucu oluşturulur. Ethereum’daki işlemlerin geçerli olmasının birinci kuralı, EOA cüzdandan başlatılmış bu işlemlerin bu cüzdandan başlatıldığınının kanıtının ECDSA dijital imzalarıyla ispatlanmış olmasıdır.

Bir EOA cüzdanını oluşturmak ücretsizdir. EOA cüzdanı; Balance (bakiye), nonce, codehash ve Storage Root’tan oluşur. CodeHash sadece akıllı kontrat cüzdanlarda(sonraki bölümde detaylandırılacak) vardır ve EOA cüzdanda bulunmaz. StorageRoot, o cüzdanın depoladığı verilerin veri katmanından erişilebilir olmasını sağlayan kriptografik kanıtıdır ve CodeHash gibi EOA cüzdanlarda bulunmaz. Her bir cüzdandan başlatılan işlemler (transactions) cüzdanın sahipliği kanıtlayacak çeşitli özelliklere sahiptir ve bu özelliklerin her biri, o işlemin “geçerlilik kurallarını” belirler. Bu geçerlilik kuralları hesap soyutlamanın ana çerçevesini oluşturan başlıca kuralları oluşturduğundan hesap soyutlamayı anlamak için bu kuralları temel seviyede bilmek gerekiyor.

Bir Ethereum işlemi;

Nonce: Bilgisayar biliminde sıklıkla konuşulan problemlerden biri olan “eş zamanlılık” problemine çözüm olarak Ethereum’da kullanılan “sıralama” sayısıdır. Replay atakları önler ve ilgili işlemin cüzdanın kaçıncı işlemi olduğunu gösterir. Örnek bir tx nonce’u:

Gas Miktarı: Gas, Ethereum’un Turing Complete olabilmesindeki ana faktördür. Gas, kullanacağınız hesaplama gücünü önden hesaplayarak ona göre bir ücret ödediğimiz sistemin ana faktörüdür. İşlemlerdeki gas miktarı bu işlemin hesaplanması için ödemeye hazır olduğu ücreti belirtir.

Gas Limit: İşlemi oluşturan kişinin ödeyebileceği maksimum gas miktarını belirtir.

Alıcı: İşlemin sonlanacağı Ethereum adresini belirtir.

Değer: Alıcıya gönderilecek Ether’in miktarını belirtir.

Veri: Değişken verileri çağırabileceğimiz değişken uzunluktaki ikili veri yükünü ifade eder. Bir işlem aynı anda hem değere hem de veriye sahip olabilir, sadece değere yada sadece veriye de sahip olabilir veya ikisine sahip olmadan da çağırılabilir. Buradaki 4 kombinasyon da geçerli kabul edilir ve Ethereum’da işlenir.

Son olarak ECSDA imzalama sisteminin 3 parçası: v, r, s. Ethereum’daki cüzdanın sahipliğinin ispatı, bu imzalama sistemi sayesinde yapılır. İmzalama sistemi matematiksel ispata dayandığından araya üçüncü partiler girmeden Ethereum’daki işlemlerimizi gerçekleştirebiliriz.

Ethereum’daki EOA cüzdanlarından başlatılan bir işlemin geçerli kabul edilebilmesi için konulmuş kurallar yukarıdaki parametlere göre belirlenmiştir. Bir işlemin geçerli olması ve EVM’de işlenebilmesi için; nonce değerinin geçerli olması, ödenecek gas miktarının cüzdanda yer alması, harcanacak varlığın cüzdanda yer alması ve ECSDA imzasının geçerli olması gerekir. Hesap soyutlama, bu geçerlilik kurallarının değiştirilebilir, programlanabilir olmasını amaçlar. Hesap soyutlama EOA cüzdanlardan ziyade “akıllı kontrat” tabanlı cüzdanların ileri seviyeye taşınmasını amaçlıyor. Peki, akıllı kontrat tabanlı cüzdanlar nasıl çalışıyor?

Programlanabilir, Akıllı Kontrat Tabanlı Cüzdanlar:

Bitcoin’in programlanabilirliğinin önündeki en büyük engel, loop yaratan (yani bir sonuca ulaşana kadar sürekli çalışan) fonksiyonların sebep olduğu DOS (Denial of service) vektörüydü. Kötü niyetli bir kişi, loop yaratan bir fonksiyon çağırırsa tüm madenciler bu işlemi sonsuza kadar işlemek zorunda kalacağından asıl işlem yapacak kullanıcılar sisteme erişemeyecek ve sistem kullanılmaz olacaktı. Ethereum, bunu “gas” sistemiyle çözdü. Fonksiyonları çağırabilmek için ihtiyaç duydukları hesaplama gücü kadar “gas” ödeyerek sistemin güvenliğini riske atmadan turing complete bir durum makinesine (EVM) erişebildik. İşte Ethereum ve Bitcoindeki bu temel programlanabilirlik farkını EOA cüzdan ile akıllı kontrat cüzdanlardaki programlanabilirlik farkında benzetebiliriz. EOA cüzdanın ,güvenlik açısından aşamadığı bazı sebeplerden dolayı, programlanabilirliği çok kısıtlıyken Akıllı Kontrat tabanlı cüzdanlar tümüyle programlanabilir şekilde geliyor. Akıllı kontrat tabanlı cüzdanlara geçmeden önce akıllı kontratları anlamamız gerekmekte.

Ethereum’un ana konseptlerinden başlıcası akıllı kontratlardır. Akıllı kontratların özelliklerini kavramak, akıllı kontrat cüzdanları ve onların sorunlarını anlamak için kilit konulardan biridir. Ethereum’daki akıllı kontratlar EVM’de işlenmek üzere, önceden kuralları belli olacak şekilde yazılmış programlardır. Her bir akıllı kontrat, aynen EOA cüzdanlar gibi spesifik bir “adres”e sahiptir. Akıllı kontratlardaki adreslere direkt erişim mümkün değildir, bir akıllı kontrat işlem başlatamaz. Akıllı kontratlar EVM’den “soyutlanmadığı için bir akıllı kontrat ancak ve ancak EOA cüzdan ile yollanan geçerli bir işlem ile kodlarını EVM’de yürütebilir. Akıllı kontrat tabanlı cüzdanlar da özünde akıllı kontrat olduğu için bu özelliklere sahiptir. EOA cüzdanlardan farklı olarak programlanabilir yapıdadır fakat (yine EOA’dan farklı olarak) kendi başına işlem başlatamaz.

Yani özetle;

• Akıllı kontratlar bir işlemi başlatamazken EOA cüzdanlar bir işlem başlatabilir,
• Akıllı kontratların Ethereum’a yüklenebilmesi için bir miktar fee ödemek gerektiği için oluşturmak ücretsiz değildir, EOA cüzdan ücretsizdir.
• EOA cüzdanların programlanabilirliği çok sınırlıyken akıllı kontrat tabanlı cüzdanlar birçok farklı fonksiyonu ve programlanabilirliği mümkün kılar.
• Hem akıllı kontrat tabanlı cüzdanlar hem de EOA cüzdanlarla, diğer akıllı kontratları çağırabiliriz.

Akıllı kontratlar bir işlemi kendiliğinden başlatamadığı için birçok uygulamanın geliştirilme süreci sekteye uğruyor, bunlardan başlıcaları cüzdanlar ve gizlilik uygulamalarıdır. Hesap soyutlama, akıllı kontratların bu dezavantajlarını bertaraf etmek için önerilen geliştirmelerin genel adıdır.

Neden Akıllı Kontrat Tabanlı Cüzdanlar Yaygınlaşamıyor?

Bir akıllı kontratın gizli anahtarı bulunmaz, işlemi kendiliğinden başlatamaz ve kontratı kullanmak (oluşturmak) için bir miktar ücret ödenmesi gerektiğinden bahsettik. Peki bu ne gibi sorunlara yol açıyor, gelin akıllı kontrat tabanlı cüzdanları ve tornado cash örneğinden buradaki problemi anlayalım.

1. Tornado Cash ve gizlilik problemi: Tornado Cash gizliliği sağlamak üzere programlanmış bir karıştırıcıdır (mixer). İnsanların gizliliğe olan ihtiyacı oldukça nettir, isim servisleri ve merkezi borsalar başta olmak üzere tüm finansal aktivitelerimizin zincir üzerinde izlenebilmesi, gizlilik için ciddi sorun yaratmaktadır. Bunun için çalışan Tornado, en bilinen gizlilik araçlarından biridir. Çalışma mantığı oldukça basittir. Tornado Cash’te herkesin Ether yatırabileceği çeşitli havuzlar bulunur. Bu havuzlara 0.1 ,1 10 ve 100 Ether yatırabilirsiniz. Sonrasında yatırdığınız havuza Ether yatırdığınıza dair bir “kanıt alırsınız”. Ether yatırdığınızda Ether’iniz diğer kullanıcıların Ether’leriyle karışacağından eğer sıfırdan bir cüzdan açıp Tornado’dan o varlığı çekebilirseniz artık kimsenin izleyemediği, gizliliğinizi sağlayabildiğiniz cüzdanı gönül rahatlığıyla kullanabilirsiniz fakat burada bir problem bulunuyor. Tornado Cash kontratına yatırdığınız Ether için elinizde ispat olmasına rağmen “işlemi başlatabilmek için” bir miktar Ether’e ihtiyaç duyuyorsunuz. Bu Ether’i de ya kendi cüzdanınızdan atacak ya da bir merkezi borsa kullanacaksınız, bu durum da sağlamaya çalıştığımız gizliliği tamamen yok eden bir durum. “İşlemi başlatmak için gerekli” Ether’in gerekliliği, akıllı kontratların kendisinin işlemi başlatamamasından gelir. Tornado Cash’te Relayer dediğimiz aracılar protokolün içinde EOA cüzdan yürüterek işlemimize sponsor olur ve bu soruna çözüm bulur. Bunun karşılığında bir miktar ücret alırlar fakat eğer relayerler çalışmayı durdurursa gizlilik tehlikeye girdiğinden şu anki sistemin bir geliştirmeye ihtiyacı olduğu açıktır.

2. Akıllı Kontrat Tabanlı Cüzdanlar: Telefonunuza akıllı kontrat tabanlı bir cüzdan indirdiniz, cüzdana varlık aktardınız, kontrat Ethereuma yüklendi ve artık kullanıma hazır fakat aynı sorun burada da var, işlem yapmak istediğinizde telefonunuzun Face ID’si, parmak iziniz ya da mail sisteminin eliptik eğrisinin imzalamasıyla “geçerli” işlem başlatamadığınız için işlemlerinizi EOA cüzdandan başlatmak zorundasınız. Yine 12 kelimeye mecbur kalıyor ve EOA cüzdanınızdan işlemi başlatmak için cüzdanınıza giriş yapıyorsunuz…

Akıllı kontrat tabanlı cüzdanlar da az önce anlattığım gibi, kendiliğinden işlem başlatamadığından işlem başlatmak için bir EOA cüzdandan çıkmış işleme ihtiyaç duyar. Şu anda Ethereum’da çalışan akıllı kontrat tabanlı cüzdanlar, bir relayer aracılığıyla işleme sponsor olurlar ve karşılığında alacakları ücret ile bu işlemin gerçekleşmesini sağlarlar. Bu relayerler şu anda çoğunlukla merkezi aracılar olduğundan kullanıcılar sansür ve varlığın donması riskiyle karşılaşmakta. Bu dezavantajın sebebi de önceki bölümlerde anlattığımız akıllı kontrattan işlem başlatamamızdan kaynaklanır.

Bu iki sistemde de işlemlere sponsor olan relayerlerin merkezi yapılar olması çeşitli güvenlik ve sansür riskleri doğurduğundan bunları çözecek bir güncellemeye ihtiyacımız çok nettir ve evet, hesap soyutlama bizi tam olarak burada karşılamakta. Şimdiye kadarki bölümlerde hesap soyutlamaya neden ihtiyaç duyduğumuza baktık, şimdi sırada hesap soyutlamanın tarihteki değişimine ve EIP 4337’nin detaylarına bakacağız.

Hesap Soyutlamanın Evrimi:

EIP 86, EIP 2938, EIP 3074, EIP 4337

Hesap soyutlama ve akıllı kontratları bir sonraki aşamaya taşıma fikri, uzun süredir tartışılan fikirlerden biridir. Hesap soyutlama için 2017 yılından beri çeşitli Ethereum geliştirme teklifleri topluluğa sunulmuş ve bu teklifler zaman içinde evrimleşerek daha ileri seviyeye taşınmıştır. Ethereum geliştirme tekliflerine ve zaman içindeki evrimine bakalım:

1.EIP 86: Hesap soyutlamayı mümkün kılmak için 2017 yılında Vitalik Buterin tarafından önerilen EIP 86, işlemin “başlangıcını”, nonce şemasını ve işleme ait “imzalama” sisteminin soyutlanmasını içeriyor. Ethereum’un çok net sınırlarla kodlanmış “işlem geçerlilik kurallarını” değiştirilebilir kılmak için ECDSA (Ethereumda kullanılan dijital imza) dışındaki imzalamaları kullanarak geçerli işlem başlatabilmeyi sağlıyor. Bu sayede bir kontrattan önceden programladığımız imzalama kuralları sayesinde kontratlardan işlem başlatabiliyor ve kontrat tabanlı cüzdanları programlayabiliyor hale geliyoruz. EIP 86 ile;

• Şu anda çalışan MultiSig cüzdanlarında yapılan işlemler, EOA cüzdanlardan yollanır ve EOA cüzdanlar ile Ethereum gas fee’si ödemek zorunda kalırız. Kontrattan işlemi başlatamadığımız için bu durum şu an için zorunluluktur. EIP 86 ile MultiSig’in içindeki Ether’le bu gas fee’yi ödeyebilmemizi mümkün olur.
• Şu anda Ethereum’da kullanılan dijital imza, kuantum dirençli değildir. Farklı dijital imzaların kullanımını mümkün kılan EIP 86 ile kuantum dirençli Ethereum cüzdanları oluşturmak mümkün olur.
• Her ne kadar güncellemede bahsedilmese de bu güncelleme sayesinde programlanabilir akıllı kontrat tabanlı cüzdanların oluşturulması mümkün olur.
• Ethereum’daki karıştıcı kontratında bulunan varlıkları çekerken işlem için ödenmesi gereken gas fee’yi kontrattaki varlıkla ödemeyi mümkün kılarak Ethereum’da çalışan karıştırıcılardaki relayerler ihtiyacını ortadan kaldırır.

EIP 86, bu özellikleri protokol düzeyinde çok önemli güncellemeler yaparak mümkün kılmaya çalıştığı için o dönemki geliştiriciler tarafından rafa kaldırılmıştır. Bu kadar önemli güncellemeleri bir arada yapmak, merge’ü 6 yılda mümkün kılan Ethereum için, fazla radikal kaçtığı için ve tüm client geliştiricilerinin bu konuya odağını çevirmesini gerektirdiği için bu teklif kabul edilmemiştir.

Ayrıca EIP 86’da çözülmeyen bir DOS vektörü bulunmakta, benzer bir DOS vektörü EIP 4337’de bulunduğu için EIP 4337 başlığı altında bunun detaylarına ineceğiz.

2.EIP 2938: EIP 86’ya göre daha basit seviyede güncellemeleri içeren EIP 2938, 2020 yılında Vitalik ve 3 geliştirici tarafından hazırlandı. EIP2938 Hesap soyutlamayı mümkün kılmak için 2 yeni opcode’un eklenmesini içeriyor. Bu güncelleme sayesinde Ethereum’a yeni bir “işlem tipi” eklenerek hesap soyutlamanın çeşitli uygulamalarını mümkün kılıyor. Belirli şartları sağlayan kontratları “kontrat cüzdanı” olarak işaretleyerek eklenen yeni işlem tipini kullanmasına izin veriyor. EIP 2938, sınırlı bir hesap soyutlama sunuyor. İlk bölümde anlattığımız geçerlilik kurallarından gas’ı soyutlamamıza imkan sağlar. Nonce ve ECDSA (imzalama sistemleri) soyutlanamadığı için hesap soyutlamasıyla yapabileceğimiz çoğu uygulamayı bu EIP ile geliştiremiyorduk. Bu EIP de protocol seviyesinde güncellemeler gerektireceğinden, hesao soyutlamanı tam anlamıyla desteklemediğinden ve EIP 86 ve EIP 4337’de de bulunan DOS vektörüne kesin çözümler getiremediğinden kabul edilmedi.

3.EIP 3074: EIP 3074, aslında hesap soyutlamayı amaçlayan bir güncelleme değil. Transferlerin geçerlilik kurallarını değiştirmek gibi radikal bir değişiklikten ziyade daha basit bir güncellemeyle EOA cüzdanlara programlanabilirliği getirmeyi amaçlamaktadır. EIP 3074'te İşlemlerin orijini yine EOA cüzdanlar fakat bu güncelleme sayesinde bir EOA cüzdandaki işlem, farklı bir EOA cüzdandan tarafından başlatılabilir olacak. Bu sayede örneğin gas ödemek için Ether tutma zorunluluğu kalkacak. Bunu protokole AUTH ve AUTHCALL adında iki yeni opcode getirerek yapmayı amaçlamakta. Bu Opcode’ların amacı, EOA’nın işlem başlatma yetkisini (invoker diye adlandırılan) bir akıllı kontrata vererek meta işlemler , işlem birleştirme gibi bazı “hesap soyutlama ürünleri”ni mümkün kılmaktır. EOA cüzdanlardaki işlem başlatma yetkisini bir akıllı kontrata vermek birçok avantaj ve dezavantajı beraberinde getirmekte, gelin bu güncellemenin teknik detayına üstten bakıp bu avantaj ve dezavantajları derinlemesine inceleyelim:

EIP 3074 -az önce de anlattığımız üzere- invoker adı verilen bir kontratın, EOA cüzdandaki sahipliği almasına dayanan bir güncelleme. Burada bahsedilmesi gereken nüans, aslında 12 kelimeye hala mecbur olduğumuz ve bu güncellemenin EOA cüzdanları kaldırmadığıdır. EIP 3074, bir işlemde yer alan nonce ve gas’ı soyutlarken imzalama sistemini soyutlayamıyor. Gas’ın ve nonce yapısının değişmesi çeşitli hesap soyutlama ürünlerini mümkün kılıyor. Buna örnek olarak; sponsorlu işlemler ve işlem birleştirme verilebilir.

Sponsorlu (Meta) İşlemler EIP 3074’te Nasıl Çalışır?

Sıradan bir Ethereum cüzdanından ERC20 token transferi, kontrattan işlem başlatmak gibi işlemler gerçekleştirmek isterseniz Ether olarak fee ödemeniz zorunludur. Yani USDC ERC20 tokenini transfer etmek için cüzdanınızda hem USDC hem de Ether tutmak zorundasınız. Bu durumu ortadan kaldırmak için “sponsorlu” işlemler dediğimiz, belirli bir ücret karşılığında işleminize sponsor olan aracılarla yapılan, ve kullanıcının Ether tutmadan işlem yapabilmesini sağlayan bir dizi güncellemeler önerildi. Bunu şu anki EOA cüzdanlarında yapamıyoruz çünkü “geçerli işlem başlatabilmek için” ilk bölümde anlattığımız 7 gerçelilik kuralının tamamının sağlanması gerekli. Bu kurallardan biri de gas olduğundan işlem başlatmak için Ether tutmamız zorunluluğu oluşuyor. Gas’ı soyutladığımızda işlemi başlatmak için Ether tutma zorunluğunu ortadan kaldırmış ve “sponsorlu işlemleri” mümkün kılmış oluyoruz.

EIP 3074’le gelen iki opcode var demiştik, Auth sahipliği kontrata verirken AuthCall sahipliği verilen kontratın farklı cüzdanlarca çağırılmasını mümkün kılıyor. Kullanıcı öncelikle Invoker kontratına Auth opcode’uyla izin verir, sonrasında ERC 20 tokenin başlatılabilmesi için işlemi imzalar, imzalanan işlemin gas’ı authcall fonksiyonuyla sponsor tarafından karşılanır ve işlem EVM’de yürütülür. Biraz daha detay vermemiz gerekirse, Call ile AuthCall Opcode’unun arasındaki tek fark “Caller”i değiştirebilmemizdir. Bu sayede ERC20 token transferi, Ether ile fee ödemek zorunda kalmadan gerçekleşir.

İşlem Birleştirme EIP3074’te Nasıl Çalışır?

Ethereum’da bir ERC20 transferi yapacağınızı düşünelim; öncelikle “approve” fonksiyonunu için bir işlem yapmanız, sonrasında “transferfrom” ile bir işlem daha yapmanız gerekmekte. ERC20 kontratı üzerinden direkt approve fonksiyonunu çağıramadığımızdan bu iki fonksiyonu çağırmak için iki işlem yapmak zorundayız. Auth opcode’uyla beraber gelen mesajlaşma formatında bulunan “commit”le, birden fazla işlemi birleştirip tek işlem olarak EVM’de yürütebiliyoruz. Bu sayede birçok uygulamadaki kullanıcı deneyimini ileriye taşıyabiliriz.

Peki, EIP3074 Neden Hala İnceleme Sürecinde?

EIP 3074 de protocol düzeyinde değişiklik yaparak iki yeni opcode eklenmesini içerdiğinden ciddi bir güvenlik araştırması sürecinden geçmek zorundaydı. Bu güvenlik araştırmalarında başlıca üç konu sebebiyle EIP3074 hala inceleme sürecinde. Bu konulardan ilki, zaten halihazırda bulunan sandviç ataklarını daha da kolaylaştırmasıdır. (ileri okuma için:EIP-3074 Impact Study) İkincisi, invoker dediğimiz kontratların cüzdandaki varlıklara tamamen erişebilmesi ve varlıklar üzerinde sınırsız yetkiye sahip olmasından dolayı (İleri okumalar için: https://ethereum-magicians.org/t/a-case-for-a-simpler-alternative-to-eip-3074/6493) invoker kontratındaki bir açığın birçok kullanıcıyı mağdur edebilme riskiydi. Üçüncü sebep ise imzaları ve nonce’u soyutlayamadığından çeşitli Hesap Soyutlama uygulamalarının bu güncellemeyle gelememesiydi. Birazdan anlatacağım ve şu anda en çok gündemde olan 4337 DelegateCall fonksiyonu sayesinde EIP3074’deki AUTH fonksiyonunu 4337’ye de taşıyabileceğimiz EIP 5003 teklifi de Ethereum topluluğunca tartışılmakta.

EIP4337:

Önceki üç hesap soyutlama önerisinde de ortak bir sorun vardı: protokol düzeyinde çok kritik güncellemeleri önermeleri. Ethereum, üzerinde milyarlarca dolar varlık tutulan, her gün işlem değeri olarak milyarların transfer edildiği bir zincir olduğundan güncellemeler için ince eleyip sıkı dokumak gerekli. Peki, hesap soyutlamayı protokol düzeyinde güncellemeler getirmeden yapmak mümkün mü? İşte karşınızda 4337!

2021 yılında Vitalik ve bir grup geliştirici tarafından önerilen 4337 aslında çok temel bir prensibe dayanmakta: Normal mempool’a alternatif bir mempool geliştirmek ve tüm akıllı kontrat cüzdanların işlemlerini oradan kabul etmek. Önce basit bir anlatımla başlayıp, sonrasında detaylarına gireceğiz. Beraber önce mempool’un kendisini, sonra alternatif mempool’u oluşturup ERC4337’nin kendi içindeki mantığını kavrayacağız.

1. Öncelikle bir EOA cüzdandan işlem başlatılır — Private Key ile imzalama yapılır, bir gas değerleri vs belirlenir.
2. Sonrasında mempool’a bu işlemler bir full node aracılığıyla iletilir.
3. Validatör, mempool’daki işlemlerden (genelde) en karlı olanları seçer (geliri maksimize etmek için) sonrasında işlemler bloğa dahil olur ve işlem onaylanır.

Peki merge sonrası gelen MEV Boost, Flashbots ve oradaki client’ler nasıl çalışıyor?

Her şeyden önce MEV’in ne olduğunu kısaca hatırlatıp, Block Builder’in buradaki rolünü kısaca anlatmak istiyorum. Kullanıcıların gönderdiği işlemler mempool’da blok üreticileri tarafından dahil edilmeyi bekler. Bu bekleyiş sırasında blok üreticilerine bir fırsat doğar: işlemlerin sırasını değiştirerek gelir elde etmek. Sandviç atak, Arbitraj gibi MEV çeşitleri bulunmakta. Linkteki flood’tan fazlasına ulaşabilirsiniz:https://twitter.com/lyteraio/status/1578808153923145728

Validatörlerin işlemleri sıralama avantajını satabilecekleri bir açık market Ethereum’da bulunmuyor. Bloğu kimin üreteceğini önceden bilemediğimiz için MEV yapmak isteyen kullanıcılar validatörlerle “Ethereum protokolü seviyesinde” anlaşamıyor. İşte tam olarak burada bizi FlashBots’un geliştirdiği MEV Boost karşılıyor.

Ethereum POS zinciri 2 adet client (istemci)’den oluşur. (client’e neden ihtiyaç duyuyoruz derseniz yazımdan https://medium.com/@doganeth/blok-zincir-anatomisi-1c72e0296562 ulaşabilirsiniz) Bu clientler Yürütme (Execution) ve Konsensus clientidir. Bu iki client ayrı ayrı yazılımlardır ve zincirde blok üretmek, blokları onaylamak ve konsensusa katılmak için gereklidir. Bu yazılımlar istenildiği gibi değiştirilebilir ve farklı farklı çeşittedir. MEV Boost da MEV’e uygun hale getirilmiş yürütme clientlerinden biridir. Burada anlamamız ve aklımızda kalması gereken başlıca unsur, MEV Boost’u tüm validatörlerin kullanmak zorunda olmamasıdır. Peki, MEV Boost nasıl çalışır?

Mempool’da bekleyen işlemlerin sırasını değiştirerek olası maddi kazançları araştıran Searcher (Bundle) dediğimiz aktörler Blok Üreticilerine -bir miktar rüşvetle beraber- işlemleri iletir. Blok Üreticisinin tek rolü en çok rüşvet vereni ilk onaylamasıdır. Sonrasında Relayerlere üretilmiş blok iletilir. Üretilmiş bloklar validatörlere iletilir, validatörler de bu bloğu onaylar ve blok, blok zincire yayınlanmış, kullanıcıların işlemleri “yürütülmüş” olur. MEV boost kullanmayan validatörler bu akıştan etkilenmez ve direkt mempool’dan işlemleri alır. Yani aslında şu anda MEV, Ethereum’a ekonomik olarak getirisi olacak ekstra bir katman eklenerek sağlanmaktadır. Ekstra bir katman eklenmesi de bu anlattıklarımdan aklınızda kalması gereken ikinci husus.

Şimdi gelelim asıl konuya: EIP 4337’te alternatif bir mempool nasıl yaratacağız?

EIP 4337; protokolün tamamını değiştirmek yerine, az önce anlattığım MEV Boost’un validatörlerin sadece bir kısmında kullanılması gibi, blok üreticilerinin sadece bir kısmının yapacağı güncelleme sayesinde ayrı bir işlem tipinin oluşturulmasını öneriyor. Biraz daha detaylarına girelim:

• Buradaki işlemler UserOperation denen bir isimlendirmeyle adlandırılıyor. UserOperation, ERC4337 standardında geliştirilmiş bir cüzdandan başlatılmış işlemlere verilen isimdir diyebiliriz. UserOperation, normal mempool’dan tamamen bağımsız bir mempoola gider.
• Bu mempool’daki işlemleri dinleyen ve bloklara dahil edecek olan aktörümüz ise Bundle’lardır. Bundle’lar blok üreticilerinden oluşur — tüm Bundle’lar blok üreticisi olmak zorunda ama tüm blok üreticileri Bundle olmak zorunda değildir.
• Entrypoint kontratı, bu akıllı kontrat tabanlı cüzdanın tüm işlemlerinin yürütüldüğü global bir kontrattır. UserOperation başta olmak üzere tüm cüzdan faaliyetleri zincir üstünde bu kontrat ile sağlanır.
• Entrypoint kontratı başlıca üç parçadan oluşuyor: cüzdan kontratı, aggregator ve paymaster. Cüzdan kontratı, cüzdana ne yapması gerektiğini söyleyen, kuralları belirleyen, varlıkların tutulduğu başlıca kontrattır.

Aggregator: Kontrat cüzdanlar için imzaların geçerliliğini kontrol eden bir “akıllı kontrat”tır. Birazdan detaylandıracağız.

Paymaster: İşlemlere sponsor olan aktörlerdir. Yukarıda anlattığım; Ether dışında diğer tokenlerle ödeme yapmak ve gizlilik uygulamalarında ilk işlemi başlatmak gibi işlemlerde işlemlere sponsor olarak bu işlemlerin gerçekleşmesini sağlarlar.

Entrypoint kontratı ve içeriğini özel olarak inceleyeceğiz fakat ondan önce Bundle’ın tam olarak ne yaptığını anlayalım: EntryPoint kontratında başlıca iki fonksiyon bulunur: ValidateUserOp; UserOperation’u girdi olarak alır ve UserOperation’ın nonce’siniunu, imzasının geçerli olup olmadığını ve fee ödeyip ödemeyeceğini kontrol eder. Eğer burada işlem kurallarına aykırı herhangi bir şey gözlenmesi durumunda (yanlış nonce, fee için yetersiz bakiye veya geçersiz imzalama gibi) UserOperation’ın yürütülmesi durdurulur. Execute fonksiyonu ise UserOperation’daki calldata’yı çağırarak işlemin yürütülmesini sağlar.

Burada önemli bir nüans bulunmakta. Normalde işlemin geçerlilik kuralları (Gas, Nonce Signature — kısaca ilk bölümde anlattığım kurallar) zincirin dışında kontrol edilir. Burada EVM’in içinde kontrol ediliyor yani bu da ek gas ödenmesi demek. Peki yeteri kadar gas fee ödenmeyen UserOperation, zincirin üzerinde kontrol edilirse ne olur? Block üreticisi (Bundler) zincir üzerinde geçerlilik kurallarının kontrolü için fee ödemek zorunda olduğundan, öncelikle lokal olarak işlemin geçerli olup olmadığını, yeteri kadar fee ödeyip ödeyemeceğini kontrol eder. Sonrasında bu işlemi zincirin üzerinde yürütmeye alır. (Bazı OpCode’lar yerel simülasyon sırasında -zincirin dışında olduğumuzdan- güvenle simüle edilemiyor. Bu yüzden bunlar önden yasaklı olarak gelmekte. Bu, protokolü DoS atağından korumak için getirilmiş zorunlu bir özellik.)

Burada Bundler’in asıl rolünün işlemin başlatılması için EOA cüzdana gerekliliği kaldırması diyebiliriz. İşlem Bundler aracılığıyla başlatırılır. Yukarıdaki diyagramda Paymaster ve Aggregator kullanmayan ve halihazırda var olan bir akıllı kontrat cüzdanın basit bir işleminin nasıl yapıldığını konuşmuş olduk fakat 4337’nin bize sağladığı özellikler elbette bunlarla sınırlı değil. Paymaster ve aggregation’a bakalım:

Paymaster: Paymaster’ler UserOperation’lara sponsor olmak için entrypoint kontratında yer alan bir kontrattır. Paymaster’in; Ether dışında herhangi bir tokenle fee’yi ve gizlilik tabanlı uygulamalarda işlemi başlatmak için gerekli fee’yi ödemek gibi kullanım alanları bulunur. Kullanıcı deneyimi ileriye taşımak için oluşturulan Paymaster, isteğe bağlı olarak kullanılır. Peki, Paymaster işlemlere nasıl sponsor oluyor?

Önceki bölümde Paymaster olmadan bir işlemin nasıl yapıldığını, orada ValidateUserOp fonksiyonunun nasıl çalıştığını ve görevini anlatmıştım. Paymaster’in kullanıldığı bir işlemde ValidatePaymasterOp denen bir fonksiyon ile sponsorlu işlemler yapılıyor. Öncelikle ValidateUserOp çağırılır bu fonksiyon ile nonce ve imza gibi UserOperation’ın geçerliliği kontrol edilir, sonrasında ValidatePaymasterOp çağırılır. Bu fonksiyon ile paymaster’in gerçekten gas ödeyip ödeyemeyecek varlığının olup olmadığı kontrol edilir. Eğer Paymaster fee’yi ödemek için yeterli bakiyeye sahipse ExecuteOp fonksiyonu çağırılır ve işlem bu sayede sponsorlu gerçekleşir.

Burada önemli bir detay bulunmakta: ValidateUserOp fonksiyonu -her bir UserOperation (neredeyse) tamamen farklı bir storage’a eriştiğinden- geçersiz bir UserOperation diğer UserOperation’a etki etmez. Fakat Paymaster fonksiyonunda bu durum farklı. Paymaster’in storage’ı, o paymasteri kullanan tüm UserOperation’da aynı olduğundan, bir ValidatePaymasterOp fonksiyonunun geçersiz çıktı döndürmesi durumu o Paymasteri kullanan tüm UserOperation’ların geçersiz olmasıyla sonuçlanacaktır. Bu durum da bir DoS vektörü yaratmakta. Bunun önüne geçmek için her bir Bundle, Paymaster’leri banlama ve kısıtlama yetkisine sahiptir fakat bu da bir kişinin yüzlerce/binlerce kötü niyetli Paymaster kurmasının önüne geçmez. Burada Sybil ataklarının önüne geçmek için Paymaster olmak isteyen kullanıcılara bir miktar Ether stake etme zorunluluğu getirilmiş durumda. Bu da DoS vektörünü tamamen yok etmiyor fakat zorlaştırmış oluyor.

Aggregator: Normalde her bir UserOperation’ın geçerliliği ValidateUserOp ile kontrol edilirken, her birinin imzaları EVM’de ayrı ayrı onaylanır. EOA cüzdanlardaki işlemlerin geçerlilik kuralları EVM’nin dışında protokol düzeyindeki kodlarla kontrol edildiğinden ekstra gas ücretlerine neden olmaz, bu yüzden de UserOperation ile gönderilen işlemler EOA’ya göre daha yüksek gas cost’a neden olacaktır. Bunun yarattığı dezavantajı bertaraf etmek ve daha ölçeklenebilir UserOperation’lara erişmenin yolu: İmzaları birleştirmek ve tek imzada birden fazla işlemi onaylatmaktan geçiyor. Aggregator’lar tam olarak bunu yapmakta. Peki aggregator’ların sağladığı bu imza birleştirme nasıl çalışıyor?

Normal bir dijital imzada 4 parça bulunur: Gizli Anahtar(Private Key), Mesaj, Açık Anahtar (Public Key) ve İmza. Gizli anahtarınız ile bir mesaj imzaladığınızda “İmza”yı elde ediyorsunuz. Bir mesajın geçerliliğini kontrol etmek için ise açık anahtar, mesaj ve imzaya ihtiyacınız var. Bunu basit fonksiyonları çağırarak kontrol edebiliyorsunuz.

Her bir ValidateUserOp da tam olarak UserOperation’un geçerli bir keypair’e sahip olup olmadığını kontrol eder. Az önce anlattığım gibi, bunların her biri için tekrar tekrar KeyPair döngülerini çalıştırmak yüksek gas maaliyetlerine sebep olmaktadır.

Aggregator; birden fazla UserOperation’un mesajlarını ve imzasını birleştirerek tek fonksiyonda ispatlanmasını sağlıyor. Birleştirilmiş imzayı onaylamak, diğer tüm mesajların geçerli olduğunu ispatlamak için yeterlidir. Bu sayede ilk aşamada calldata maliyetini yaklaşık %26 düşürebiliyoruz. Bu konuda Vitalik’in Tweet’ine bu linkten ulaşabilirsiniz. (Rolluplarda asıl maliyetin Ethereum ana katmanında data maliyeti olduğunu aklınızda tutun — Vitalik buna gönderme yapıyor.) https://twitter.com/VitalikButerin/status/1554983955182809088

Aggregator’un UserOperation’a ait imzaları birleştirmesi ve işlemlerin onaylanması süreci şöyle ilerlemekte: Öncelikle Bundler UserOperation’ları Aggregator’a iletir, Aggregator birleştirilmiş imzayı Bundeler’e veriyor ve Bundler, HandleAggregatedOps fonksiyonuyla işlemi çağırıyor. Bu fonksiyonla imzalar EntryPoint’teki Aggregator kontratıyla onaylanıyor ve sonrasında ExecuteUserOp fonksiyonuyla işlemler yürütülüyor.

EIP 4337 başta olmak üzere EIP 2938 ve EIP86’nın da önündeki en büyük engel DoS vektörlerini ortadan kaldırmak. Bu anlattığım konseptlerden, neden hesap soyutlamanın DoS vektörüne sebep olduğunu belki anlamış olabilirsiniz ama genel anlamda en temeldeki nedeni tekrar açıklamak ve bu bölümü bitirmek istiyorum.

Normalde bir Ethereum işleminin geçerli olup olmadığı çok sıkı kurallara bağlanmış bir dizi geçerlilik formülleriyle belirlenir ve birkaç değere bakmak, işlemin geçerli olup olmadığını ve ödeme yapıp yapmayacağını anlamak için yeterlidir. 4337’yle beraber gelen hesap soyutlamadaki işlemlerde ise bir işlemin geçerli olup olmayacağını ancak ve ancak o işlemi tamamen yürüttükten sonra anlayabiliyoruz. Bu nokta çok önemli çünkü DoS vektörüne sebep olan şey de bu. İşlemi tamamen yürütmeden işlemin geçerli olup olmayacağını anlayamayacağımız için geçersiz veya ödeme yapamayacak işlemleri de zincirde çağırabilir, hatta asıl kullanıcıların sistemi kullanamamasına sebep olabilir. Bu yüzden validateUserOp fonksiyonunda bazı opcode’lar engellenmişbanlı ve bu yüzden Paymaster’ler stake etmek zorundadır. Bu problem şu an için hala çözülmeye çalışılan ve üzerinde uğraşılan problemlerden biri.

4337’de Bundler’in gelir modeli çok basit: bloğu oluşturan aktör, işlemleri sıralama yetkisine sahip olur. Bu durum da onu MEV için birincil aktör yapar. MEV avantajını elde eden blok üreticisi, aynen şu anda MEV boost’ta çalışan blok üreticileri gibi gelir elde edecektir.

Tebrikler! Şu an 4337’nin ve hesap soyutlamanın tüm parçalarına ayrı ayrı hakimsiniz. Ethereum’un hesap soyutlama yolunda geçirdiği değişimlere, yapılmış önerilere ve günümüzde Ethereum başta olmak üzere 4337’nin entegre edildiği zincirlerdeki cüzdanların nasıl çalıştığını öğrendiniz.

Şimdi sırada protokol düzeyindeki hesap soyutlama entegrasyonları var. Starknet, Zksync ve Fuel’i ele alacağız.

Protokol Düzeyindeki Çözümler Neden Önemli?

Ethereum, şu anda $30B’dan fazla kilitli varlık bulunduran, her gün milyarlarca dolarlık varlık transferine ev sahipliği yapan, blok zincirleri arasında ekonomik olarak en aktif zincirdir. Bu haliyle protokol düzeyindeki güncellemeler çok zor ve uzun süreçler almakta. Öyle ki “Merge” güncellemesi tam 5 yıllık bir sürecin sonucunda gerçekleşebildi. Fakat Rollup’larda böyle sorunlar bulunmamakta. Güvenliği Ethereum’dan devralırken tamamen yeni bir zincir olduklarından geriye dönük bir uyumluluk sorunu çekmiyorlar. Bu haliyle protokol düzeyindeki hesap soyutlama entegrasyonunun Rollup’larda geliştirilmemesi için hiçbir neden bulunmuyor. Starknet CairoVM’i , Zksync de LLVM’i ve Fuel de FuelVM’i kullanmakta. Starknet ve Zksync 4337’ye çok benzer güncellemeleri kendi VM’lerinde uygularken Fuel tamamen ayrı bir yaklaşımla predicate denen bir inovasyonla hesap soyutlamayı mümkün kılmayı amaçlıyor. Detaylarına bakalım:

Starknet: Starknet’in nasıl bir entegrasyon sağladığına girmeden önce kısaca ZK-Rollup’lardaki Sequencer ve prover’in rolünü kavrayalım. Sequencer; işlemleri sıralamak, rollup’taki kullanıcılara soft confirmation yollamak ve sıralanmış işlemleri prover’e iletmekten sorumluyken, prover bu iletilen işlemlerin kanıtını üretmekten sorumlu. Bu işlemleri onaylan aktör ise Ethereum’daki köprü kontratında bulunan verifier’dır. Burada bilmemiz gereken tek şey; Sequencer’in işlemleri Batch’e eklemekten, işlemlerin geçerliliğini kontrol etmesinden ve Batch’i prover’e iletmekten sorumlu olmasıdır. Starknet ve Zksync benzer bir mantıkla çalışmakta. Hesap soyutlama için Starknet, EIP 4337’nin değiştirilmiş bir versiyonunu protokol düzeyinde uygulamış durumda. Burada protokol düzeyindeki hesap soyutlama, üç aşamadan oluşuyor:

1. Sequencer, mempool’dan işlemi seçiyor, seçtiği işlemin “sadece” nonce değerinin geçerli olup olmadığını kontrol ediyor.
2. İşlemin nonce’u geçerli ise hesap kontratı üzerinden validateTX fonksiyonunu çağrılıyor.
3. Eğer işlem geçerli ve işlemin sonucunda ödeme yapacaksa ExecuteTX fonksiyonu çağrılıyor ve işlem yürütülüyor. Eğer işlem geçersiz ise işlem yürütülmüyor ve sequencer ödeme alamıyor.

Burada EIP 4337’den farklı olarak lokal bir simülasyon sadece nonce değeri için söz konusu. Bu da protokolü DoS vektörlerine daha açık bir hale getiriyor. Bunun için mempool’a gelen işlemlerin işlemin yürütülmesinin sonucunda ödeme yapacağının kesin olması gerekir. Bu yüzden işlemler Starknet ağında yayılmadan önce kontrol edecek bir koruma mekanizması daha bulunuyor. İşlem mempool’a düşüp ağa yayılmadan önce bir Node (Sequencer) tarafından geçerliliği kontrol edilir. Bu sayede geçersiz işlemler ağda yayılmaz ve kötü niyetli kontrat hesapları DoS atağı düzenleyemez.

Starknet’in Paymaster için yaptığı entegrasyon EIP 4337’yle neredeyse aynı olduğundan tekrara düşmemek adına bahsetmeyeceğim. Unutmayın ki Starknet’in entegrasyonu henüz Starknet Alpha’da olduğundan değişebilir ve geliştirmek için çeşitli öneriler bulunmakta.

zkSync Era: zkSync de az önce anlattığım gibi; EIP 4337’ye benzer bir entegrasyon sağlamış durumda. Starknet’te anlattığım gibi zkSync de bir ZK-Rollup ve Sequencer işlemleri sıralayıp, Batch’e eklemekle sorumludur. zkSync’nin hesap soyutlama entegrasyonunda hala kapalı kaynak kodlu çok önemli aktörlerin bulunduğunu belirtmeliyim. Bu yüzden birçok veriyedetaya erişemedim, Bootloader (birazdan anlatacağım) gibi çok önemli bir aktörün kodlarının kapalı olması ve dokümanda bilgi olarak “Bootloader’in dürüst davranacağından ve protokolün bir parçası olduğundan emin olabilirsiniz” bilgisinden başka bir detay bulunmadığını da es geçmeyelim. zkSync Era’da da EIP 4337 ve Starknet’tte olduğu gibi iki aşama bulunuyor. Burada EOA ve Kontrat hesapları aynı mempool’a geliyor, Operator (4337’deki Bundle ile benzer) işlemleri alıyor ve Bootloader(4337’deki entrypoint) denen bir akıllı kontrat yardımıyla işlemler EVM’de yürütülüyor. (Simülasyon’un nasıl işlediği, bu simülasyonu yapıp yapmadıkları konusunda herhangi bir doküman göremedim, zkSync takımından geri bildirimlere açığım. Kendilerine ulaşmaya çalıştım fakat ulaşamadım.)

İşlemin geçerliliğinin kontrol edildiği Validation aşaması:

Öncelikle nonce değerinin geçerli olup olmadığı kontrol edilir. (Bir Not: zkSync’deki nonce entegrasyonu deterministik sipariş (ordering)’e dayandığından bir cüzdan, aynı anda sadece bir işlem başlatabilir. Takım, ileride bunu güncellemeyi düşünmekte.) .Operator öncelikle validateTransaction fonksiyonunu çağırıyor. Bu fonksiyon işlemin geçerliliğini kontrol ediyor ve eğer işlem geçerliyse sonraki aşamaya geçiyor. Sonraki aşamada işlemin fee’si ödeniyor. 3 farklı fonksiyon çalışıp, Paymaster’in veya direkt kullanıcının cüzdanından ödeme alınıp alınamayacağını kontrol ediyor. Validasyonun son aşamasında BootLoader’in işlemi çağırmak için gerekli fee’yi alıp almadığını kontrol ediyor.

İşlemi yürüten Execution aşaması:

Bu aşama iki parçadan oluşuyor. Öncelikle executeTransaction fonksiyonu çağrılıyor, sonrasında eğer Paymaster kullanıldıysa PostOp fonksiyonu çağrılıyor. Bu da Paymaster’ın ERC 20 tokenlerle ödeme yapmasını kolaylaştırmak için konmuş bir fonksiyondur.

Ayrıca zkSync full EIP 1271 (​​https://eips.ethereum.org/EIPS/eip-1271) desteği vermeyi planlıyor. Şu an için sadece ECSDA (Ethereumda kullanılan imza) kullanılabilse de takım, ileride bir imza kütüphanesi oluşturarak farklı imzalama çeşitlerini desteklemeyi planlamakta. Kendi zincirlerine entegre ettikleri Entrypoint kontratının kodlarına erişemedim ve herhangi bir audit raporu göremediğimi eklemem gerekiyor.

Fuel: Fuel, diğer iki rollup’tan farklı olarak optimistik rollup olarak geliyor ve hesap modeli olarak UTXO kullanıyor. UTXO’nun getirdiği avantajlar sayesinde herhangi bir DoS vektörüne neden olmadan hesap soyutlamanın getirdiği birçok özelliği bünyesinde barındırıyor ve hesap soyutlama uygulamalarını destekliyor. Peki, nasıl? (Fuel Network hakkında Lytera’da detaylı bir raporumuz bulunmakta — Linkten ulaşabilirsiniz: https://lytera.io/report/yurutme-katmanina-yeni-bir-bakis-fuel-network/)

UTXO — An Unspent Transaction Output yani harcanmamış işlem çıktısını ifade etmekte. Bunu basit bir analojiyle anlatacak olursak, elinizde nakit $100 olduğunu düşünelim, $30’ını bana gönderirseniz elinizde harcanmamış $70 kalacaktır. İşte bu harcanmamış çıktı da UTXO’yu temsil eder. Daha teknik bir ifadeyle: Blok zincirlerdeki işlemler girdi ve çıktılardan oluşur, UTXO’yu harcamak için elinizdeki UTXO’nun kanıtını dijital imzalarla yapar ve harcarsınız, bu girdi olarak kabul edilir ve size çıktı olarak harcanmamış olan UTXO’yu verir. Bir kere harcanmış UTXO tekrar harcanamaz. İşlemin sonunda iki UTXO oluşur ve sistem harcanmamış çıktılar üzerinden ilerlemeye devam eder.

UTXO hakkında bilinmesi gereken en temel konsept, her bir UTXO’nun kendi içinde harcandığı ve blok zincirin durumunda diğer UTXO’ların yapısında herhangi bir erişiminin olmamasıdır. Ethereum ve diğer Account tabanlı hesap modeli kullanan zincirleri programlarken elinizdeki tek şey “girdiler”dir. Fuel’in UTXO modelinde ise “şu şartları sağlarsan bu çıktı çıkacak” şeklinde fonksiyonlar yazmak için çıktıları kullanabilirsiniz. Fuel’deki UTXO konseptiyle gelen “Predicate”ler, Fuel’in hesap soyutlamasını mümkün kılmaktadır.

Predicate dediğimiz şey, aslında bir kod parçasından ibarettir. Predicate, bir kontrat hesabı ya da EOA cüzdan değil, sadece belirli şartları sağladığı koşulda harcanacağını belirten bir dizi kod kümesinden oluşur. Her bir predicate’in bir varlık gönderip alabileceğiniz bir adresi vardır fakat bu adres predicate’in bytecode’unun hash’i alınarak elde edilir. Predicate sayesinde, çeşitli koşullar altında o predicate’in harcanabilmesini içeren fonksiyonlar yazılabilir. Yani aslında predicate, kendi içinde harcanabilirlik şartlarını içeren bir UTXO’dur diyebiliriz. UTXO modeli sayesinde predicate’in kendi içindeki harcanabilirlik kuralları geliştiricilere birçok uygulamanın kapısını açmakta.

Örnek üzerinden konuşalım: Bir predicate’ye harcanma koşulu olarak ⅔ cüzdandan imza sağlama şartı getirebiliriz. Aynısını bir kontrat cüzdanında da yapabiliriz fakat ikisinin arasında büyük bir fark var: Predicate’yi oluşturmak için tek yapmanız gereken predicate’nin kodunun hash’ini almak — elinizde artık predicate’nin adresi bulunuyor. Predicate’teki varlıklar imzalardan sonra direkt harcanabilir ve fee, predicate’nin kendisi tarafından ödenebilir fakat kontrat hesabında (Safe kontratları üzerinden konuşuyorum) kontratta milyarlarca dolar saklansa bile cüzdanı kurmak için ve işlemi başlatmak (⅔ imzalı bir multi sig için 2. imzayı veren kişi işlemi başlatır ve fee öder) için EOA cüzdanlara mecburuz. Bu da kullanıcı deneyimi açısından gerçekten kötü bir deneyim sunmakta. Yani predicate’lerden işlem başlatmak, kendi içindeki geçerlilik kurallarını sağladığınız sürece mümkün.

Yani predicate sayesinde varlığın kendisini, UTXO’yu programlanabilir hale getiriyoruz. Ayrıca diğer hesap soyutlama entegrasyonlarında bulunan çok önemli iki problemi çözmüş oluyoruz:

1. Ethereum’da ERC4337 tabanlı bir cüzdandan başlatılan işlemin gerçekten ödeme yapıp yapmayacağını ancak işlemi yürüttükten sonra anlayabildiğimiz için çeşitli DoS vektörleri bulunmaktaydı. Bunun sebebi Ethereum’daki ERC4337 tabanlı işlemlerin blok zincirin son durumuna erişimine olmasıdır. Buna Stateful (duruma erişimi olan) hesap soyutlaması adı veriliyor. Fuel’deki UTXO mimarisi sayesinde her bir UTXO sadece kendi storage’sine eriştiğinden ve predicate’lerin harcanması deterministik olarak belirlendiğinden Fuel’deki hesap soyutlamanın duruma herhangi bir şekilde erişimi yoktur. Bu yüzden Fuel’deki hesap soyutlama bir DoS vektörüne sebebiyet vermemektedir. Buna da Stateless (duruma erişimi olmayan) hesap soyutlama ismi veriliyor.
2. Ethereum’daki EIP 4337’de hala işlemler EOA’dan başlatılıyor. Predicate’lerin kendi içindeki harcama koşulları sağlandığı sürece herkes işlemi başlatabilir. Bu da yine kullanıcılara ve geliştiricilere gelişmiş bir deneyim sunacak gibi duruyor.

Fuel’in ECrecovery adında uygulama katmanı seviyesinde imza onaylama desteği vermeye de hazırlandığını söylemeliyim. Fuel’in protokolündeki varlıkların tamamına programlabilirliği getirecek bu mimarisinin birçok üründe Web2 seviyesinde kullanıcı deneyimi sunacağını düşünüyorum.

Son Düşüncelerim ve Hesap Soyutlama ile Yapılabilecekler:

Hesap soyutlamanın ne olduğunu ve nasıl çalıştığını, çözmeye çalıştığı problemleri detaylı bir şekilde anlattım. Peki hesap soyutlama bize ne gibi avantajlar sağlıyor ve hesap soyutlama ile neler geliştirebiliriz?

Her ne kadar hesap soyutlama hala geliştirilme aşamasında olsa da hesap soyutlama ile yapabileceklerimizin sınırı zihin gücümüzle sınırlı. Tam anlamıyla programlanabilir cüzdanlar, sosyal kurtarma, 2 faktörlü koruma, native multi sig, işlem birleştirme ve daha fazlası…

Gelecek çok heyecan verici, geleceği konuşmak daha heyecan verici! Geleceği konuşmaya, bizle kalın!

Yazının yazım sürecinde sorularıma yanıt veren Tahir, Hamza ve Ulaş’a özel olarak teşekkürler… Bu yazıyı yazmak için faydalandığım tüm kaynakları https://hackmd.io/BJYF5A3kSqCZaBZDoPIFYw?view linkinde topladım.

_________________________________________________________________

Clave

Bizler Clave olarak, mümkün olan en güvenli ve en güvenli şekilde kullanıcılara en iyi kullanıcı deneyimini sunmak için hesap soyutlamanın geleceğini inşa ediyoruz. Bizleri sosyal medyadan takip ederek destek verebilir ve geleceğin finansına dahil olabilirsiniz.

Website
Twitter
Linkedin