Blokzincir, kullanıcıların merkezi bir server ile etkileşmek yerine birbirine denk kopyalardan biri ile etkileştiği ve bu etkileşimin(girdinin) hata-toleranslı koordinasyon(consensus) ile sonuca ulaştırıldığı bir Replicated State Machine’dır.
State Machine, computation(hesaplama)nın matematiksel bir tanımlamasıdır. Herhangi bir anda sonlu durumlardan(state) birinde olan soyut(abstract) makinedir.
State, State Transition Function(State değişim fonksiyonu) ile tanımlanmış kurallara uygun olarak değişir. Bu değişim kullanıcının State Machine ile etkileşmesi, mesaj göndermesi ile olur. Blokzincirle etkileşirken gönderilen bu mesajlar farklı biçimlerde olabilir. Örneğin bir mesaj “Şu işlem yolunu ve hesaplamayı onaylıyorum” şekinde de olabilir “Şu sonuca ulaşmak için istediğin hesaplamayı yap” gibi de olabilir.
Bu mesaj biçimlerinden ilkine Transaction ikincisine Intent diyoruz. Bu mesaj biçimlerini inceleyelim.

Transaction

State’in değişmesi için kullanıcıların State Machine’e mesaj (işlem(transaction)) gönderdiğinden bahsettik. Bu gönderilen mesajların geçerli olup olmadığına
Nonce : cüzdanın kaçıncı işleminin olduğunu belirten sayı(replay saldırısını önlemek için),
Alıcı,
Gönderilen Ether miktarı,
İşlemin verisi(akıllı kontrat ile etkileşime geçildiyse onun verisi, veri yükü),
İmzanın geçerli olduğunun kontrol edilebilmesi için v,r,s değerleri
Gas price ve Gas limit verileri ile karar verilir.
Bu mesajları Ethereum blokzincirinde EOA adı verdiğimiz cüzdanlar ile göndeririz.

Externally Owned Account(EOA) public/private anahtar çiftinden oluşan, oluşturması ücretsiz, blokzincirle etkileşime geçmek için kullanılan(mesaj imzalayabilen) cüzdanlardır.

Ancak bu cüzdanlar programlanabilir olmadığı için kullanıcı deneyimi yetersiz kalıyor.
Hesap Soyutlama, akıllı kontratların da işlem başlatabilmesini sağlayarak kullanıcı deneyimini iyileştirmeyi amaçlar.

Account Abstraction(Hesap Soyutlama)

Hesap Soyutlama, Ethereum topluluğu tarafından uzun süredir tartışılan, EOA cüzdanların programlanamıyor oluşundan dolayı kullanıcı deneyiminin kötü olmasına çözüm getirmeyi amaçlayan bir fikirdir. Bunu gerçekleştirmek için EIP 86, EIP 2938, EIP 3074, EIP 4337 gibi teklifler verilmiştir.

Hesap Soyutlama için 4 farklı proposal(teklif) verilmiş olsa da ben bu yazıda hali hazırda Ethereum mainnete implement edilmiş olan teklifden, EIP4337den bahsedeceğim.

EIP4337

EOA cüzdanların programlanamaması problemini akıllı kontratların işlem başlatabilmesini sağlayarak çözmeyi öneren bu teklif bunu akıllı kontratların başlatacağı işlemler için ayrı bir mempool oluşturarak yapmayı öneriyor.
Akıllı kontratlar tarafından başlatılan işlemler userOperation olarak adlandır ve EOA cüzdanların başlattığı işlemlerin olduğu mempooldan bağımsız olan diğer mempool’a gönderilir. Oluşturacağı bu yeni mempool’u da herkesin dinlemesi gerekmiyor. Yani blok üreticilerinin hepsi bu işlemleri izlemek, bloklara dahil etmek için yarışmak zorunda değil. Bu mempooldaki işlemleri görüp bloklara dahil etmek için yarışan aktörlere Bundler deniliyor.
Bazı Denial Of Service ataklarından dolayı Bundlerların olabildiğince az iş yapmasını sağlanmalı. Bunun için de bir Entrypoint kontratı deploy edilir ve işlemlerin geçerlilik kurallarını bu kontratın kontrol etmesini sağlanır. Aynı zamanda bu kontrat callData’yı çağırarak execution’u başlatır.

callData, işlemlerde geçirdiğimiz veridir. Yani aslında bahsettiğim “mesaj”dır.

Entrypoint kontratı işlemi Nonce değerini, İmzasının geçerli olup olmadığını ve fee için yeterli miktar olup olmadığını kontrol eder.
EntryPoint kontratında aynı zamanda Paymaster ve Aggregator adlı 2 parça daha bulunur. Paymaster’ın işlevi kullanıcıların gönderdiği işlemlere sponsor olabilmesidir. Yani siz fee’yi ETH olarak değil USDC olarak ödemek istiyorsanız Paymaster size sponsor olur. Belli DoS vektörleri yüzünden Paymaster olmak isteyen kullanıcılar bir miktar ETH Stake ederek Paymaster olabilir. Bundlerlar Paymasterlardan ödeme kabul etmeme lüksüne sahiptir. Yani bir Bundler seçtiği spesifik bir Paymasterın işlemini kabul etmeyebilir. Bunun yapılmış olma sebebi DoS atakları önlemek. Bu işlemleri kabul etmek için sebepleri var(gelir elde etmek) ancak spam görürlerse kabul etmeyebilirler.
Aggregator(birleştirici) ise işlemleri sıkıştırır. Gönderilmiş işlemlerin imzalarını aggregate ederek(birleştirerek) daha hızlı bir şekilde doğrulanmasını ve daha az yer tutmasını sağlar. Bunun ucuz kontrol edilebilmesi için de Ethereumda BN254( alt_bn_128) precompile’ı mevcuttur.
İşlemlerin kontratlar tarafından başlatılmasını, bunun nasıl yapılabileceğini gördük. Bunu yapma amacımız kullanıcıların işlemlerini birleştirebilmesini sağlamak ve bu şekilde kullanıcı deneyimini iyileştirmekti.
Daha önce bahsettiğim “Şu sonuca ulaşmak için istediğin hesaplamayı yap” biçimideki mesajlar(Intentler) ile de bu işlem birleştirmek, farklı token ile fee ödemek gibi kullanıcı deneyimini üst düzeye çıkaracak şeyleri yapabiliyoruz.

Intent merkezli yaklaşım

CoW Swap örneği ile başlayan 1Inch Fusion ile devam eden, yakında UniswapX ile bir örneğini daha göreceğimiz Intent mimarisini bu üç örnekten başlayarak inceleyelim.

CoW Swap

CoW Swap, kullanıcıların girdiği limit emirleri zincir dışında birbiri ile eşleyen(emiri yerine getiren) ve sonrasında bunları zincire gönderen bir tür borsadır. Kullanıcıların girdiği limit emirleri birbiri ile eşleyen kişilere Solver denir. Solverlar bu limit emir eşleme üzerinden gelir elde ederler.
Bu verilen emirler off-chain(zincir dışı) olduğu için MEV riski yoktur. Cow Swap’ın asıl amacı da budur.

Maximal Extractable Value (MEV), blok üreticilerinin işlemlerin sırasını değiştirerek sizin üzerinizden gelir elde etmesidir.

CoW Swapta imzaladığınız mesaj diğer DEXler gibi “1 Etherime karşılık 2000 USDC istiyorum” şeklinde değil, “1 Etherime karşılık en az 2000 USDC istiyorum” şeklindedir. Aradaki fark slipaj ve istenen sonucun garanti edilmesidir. Yani eğer 2000 USDC almazsanız, fiyat düşerse/emir doldurulamazsa emriniz iptal edilir. CoW Swap’ın güzelliklerinden biri de bu başarısız emirler için de gas ödemeyecek olmanızdır.
CoW Swap’ın problemi çözümü bulacak Solverı kendisi seçmesidir. İstediği Solverlara çözümü buldurtur ve kâr ettirir. Bu sebepten CoW Swap’ın merkeziyetsizliği tartışmalıdır.

1Inch Fusion

CoW Swap ile benzer bir mimaride çalışır ama burada Dutch Auction söz konusudur. Yani limit emir girildikten sonra solver’ın alacağı ödül gittikçe azalır. Solver intent’i çözdüğünde(kullanıcının emrini yerine getirdiğinde), fiyat kullanıcının belirttiği seviyenin altına düştüğünde veya emirin süresi dolduğunda auction kapanır.

Burada Solver olarak belirttiğim 3. partilere 1INCH resolver diyor. Birazdan bahsedeceğim Anoma bu 3. partiye Solver dediği için ve bunlar benzer işler yaptıkları için ben Solver terimini kullanmayı tercih ettim.

1INCH Fusion’un getirdiği en önemli yenilik fee için native varlık ödeme zorunluluğunuzun olmaması. Yani 1INCH Fusion’u Ethereum üzerinde kullanacaksanız gas’i ETH olarak ödemek zorunda değilsiniz Solver size sponsor olabilir.
1INCH Solver olmak isteyenlerden bir miktar 1inch token ve KYC istemektedir. KYC istemesi büyük bir problem.

UniswapX

UniswapX de yakın zamanda duyurulmuş olan Intent merkezli bir borsadır. CoW Swapda ve 1INCH Fusionda olduğu gibi MEV koruması, başarısız işlemlerde gas koruması vb. mevcuttur. UniswapX de yine 1INCH Fusion gibi Dutch Auction mekanizmasını kullanır. UniswapX’in bunlara ek olarak getirdiği şey cross-chain trading ve pool agnostic olmasıdır. Yani kullanıcı UniswapX üzerinden emrini girdikten sonra Solver bu emri istediği havuzdan, istediği borsadan gerçekleştirebilir.

Burada Solver olarak belirttiğim 3. partilere UniswapX filler diyor. Birazdan bahsedeceğim Anoma bu 3. partiye Solver dediği için ve bunlar benzer işler yaptıkları için ben Solver terimini kullanmayı tercih ettim.

UniswapX aynı zamanda kullanıcıların cross-chain trade yapabilmesine de izin verecek. Yani Polygondaki MATIC’inizi Ethereumda ETH ile swaplayabileceksiniz. Ethereum’da ETH → Polygonda ETH → Polygonda ETH’yi MATIC ile swapla rotasını izlemenize gerek kalmayacak.

Intenler sadece limit emirlerden ibaret değildir. OTC(over the counter) NFT satışı veya OTC token satışı gibi farklı amaçlar için de kullanılabilirler ancak ben burada en bilinen örnekleri incelemek istedim.

Intentleri app-spesifik olarak kullanıldığı durumları inceledik. Peki ya bunu app-spesifik olarak değil de kendi blokzincirimizde kullanmak istesek?
Gelin inceleyelim.

Anoma

Anoma, blokzincirlere Intent-merkezli mimari sunan bir framework’dur(geliştiriciler için set ).
Intentlerin Transactionlar gibi imperative(zorunlu, emir) değil de declerative(bildiren, beyan eden) bir yapısı var. Yani Transactionlarda gidilecek yol(execution path) etkileşime geçilen akıllı kontrat(veya protokolün kendisi) tarafından zorunlu tutulan kuralları varken Intentlerde etkileşimin sonucu bildirilir ve bu sonuca ulaşmak için 3. partilerin istediği yolu çizmesine izin verilir.
Bu 3. partilere Solver dendiğini söylemiştik şimdi bunları biraz daha detaylı inceleyelim.

Intent mimarisinin vazgeçilmezi : Solverlar

Solverlar kullanıcıların beyan ettiği/belirttiği sonuca ulaşması için aradaki işlemleri gerçekleştiren 3. partilerdir.
Intentler birbirleri ile direkt eşleşiyor olabilir, çözüm için kendi likiditesini kullanabilir veya 2den fazla Intenti bir araya getirerek çözebilir. Bir çok Solver’ın kısmen likidite sağlaması ile çözüm sağlanabilir. Ya da daha farklı olarak bir Solver diğerine partial solution(kısmi çözüm) sunabilir ve çözen Solver’ın kârından pay isteyebilir. Solverlar çözümü bulduktan sonra çözümü işlem(transaction) haline getirip bunu Tx mempool’a atar.

Bu Transaction(TX) mempool(havuz) aşağıda bahsedilen intent mempool’dan farklıdır. Intent mempool public değildir Solverlar kendi aralarında intentleri gezdirir ve bunu yapmaları için teşvik edilirler ancak Solverlar çözdükten sonraki Tx mempool(işlem havuzu) herkese açıktır, herkes görebilir.

Bu noktada sorulabilecek en önemli sorulardan biri Solverların Intentleri nasıl elde ettiğidir. Yani bir Solver kullanıcının gönderdiği Intent’i nasıl görecek? Ethereumdaki gibi herkese açık bir mempool mu olacak? Herkese açık mempool olması durumunun yaratacağı DoS sorununu ve herkese açık olmazsa ortaya çıkacak sansür problemini Anoma’nın nasıl çözdüğü konusunu konuşalım.

DoS — Cencorship Resistance, Incentives

Transaction-based blokzincirde sizin işleminiz cüzdanınızdan bir full node’a gönderilir ve o full node işlemi mempool’a atar veya eğer blok üreticisi ise kendisi blok’a dahil eder.
Intent-centric mimaride sizin imzaladığınız intent bir 3. parti olan Solvera(istediğiniz Solver’a iletebilirsiniz imzaladığınız intent’i) iletilir ve Solverların işlemleri diğerlerine iletmemek için iyi sebepleri vardır. Kendisi çözmeye çalışıp bekletebilir, partial solution arayabilir, kendisine ulaşan Intent üzerinden gelir elde etmek ister, bunun için bekletebilir. Örneğin siz “1 ETH için 2000 USDC istiyorum” şeklinde bir Intent’i imzalayıp ilettiniz. Solver ETH fiyatının düşmesini bekleyip Etheri daha ucuza satıp aradaki farktan gelir elde etmek isteyebilir.
Mempool’u permissionless yapıp yapmama konusunda böyle bir problem mevcut. Mempool permissionless olsa bile Solver diğerlerine işlemi iletmeyebilir. Permissionless olmasındaki problem Denial Of Service ataklarıdır. Kullanıcılar sürekli spam intent imzalayarak Solverları meşgul edebilir. Bunun kullanıcıya maliyeti sıfır olacaktır çünkü Solver ancak ve ancak Intent’i çözebilirse fee geliri elde edebilir.
Mempool’u permissioned yaparsak, sansür sorunu aynı kalmakla beraber ortaya bir de merkezileşme(Solver sayısında azalma, rekabetin azalması) sorunu çıkıyor.
Aynı zamanda bir Solver diğerlerine de saldırabilir(DoS).
Bütün bu problemleri çözmek için Anoma’nın getirdiği şey : Path Autentication ve Partial Solution.
Bir Solver, Intent’i kullanıcıdan aldıktan sonra eğer çözümü bulur da kendisi gerçekleştiremezse(eksik likiditeden dolayı vb.) bir diğer Solver’a nasıl çözüleceğini iletip sonuçtan kâr isteyebilir. Buna Partial Solution denir.
Çözemezse ve bir diğer Solver’a iletmek isterse önce bunu kendisi imzalar. Bu sayede Intent’i görmüş bütün Solverlar imzalayarak iz bırakır ve bu Intent’in kimlerin elinden geçtiği görülür. Buna Path Autentication denir. Bütün Solverlar bu bilgileri kullanarak diğer Solverlara dair kendi görüşlerinin listesini tutar. Ne kadar güvenilir olduklarına dair bir liste. Bu sayede sansür yapan, diğer Solverlar ile etkileşmeyen Solverların güvenilirliği düşer ve gelir elde etmekte zorlanırlar.

Consensus Layer

Solverlar intent’i çözüp Transaction haline getirdikten sonra bu işlemleri Transaction Mempool’a gönderir. Validatorler bu mempooldan işlemleri seçip blokları oluşturur, kendi aralarında oylar ve sonrasında işlemleri Execute etmek üzere Validity Predicates denilen kontratlara gönderir.

Execution

Ethereum’un Account Abstraction modelinde(erc4337) entryPoint kontratının nonce, imza ve yeterli fee olup olmadığını kontrol ettiğinden bahsetmiştik. Bunun DoS atakları önlemek için olduğunu söyledik.
Anoma’da da benzer sebeplerden işlemlerin geçerliliğini Validity Predicates denilen kontrat benzeri yapılar kontrol ediyor. Validity Predicates, Solver’ın gönderdiği işlemlerin kullanıcının istediği State değişimini sağlayıp sağlamadığını kontrol eder.
Validity Predicates’ın tek amacı State kontrolü değildir. Bu yapılar aynı zamanda kullanıcıların cüzdanını programlayabilmesini de sağlar. Belli değer üstü transferleri sınırlama, her ay belli bir alıcıya para transferi vb. amaçlarla cüzdanı programlayabilmemize olanak sağlar.
Şimdiye kadar bahsedilen bütün Intentler Transparent(şeffaf) idi. Peki biz bu intent’i gizliliğimizi koruyacak şekilde iletmek istersek?
Shielded Intent, intent’i kimin gönderdiğinin zero-knowledge proof ile Solverlardan gizlenmesidir.
Private Intent ise intent’i hem kimin gönderdiğini gizlemesi hem de içeriğinin Solverlardan gizlenmesidir.

SUAVE

MEV’in blok üreticilerinin işlemlerin sırasını değiştirerek gelir elde etmesi olduğunu söylemiştik. Flashbots’un şu anki MEV modeli Ethereum’un ileride getireceği PBS modelinden esinlenerek oluşturuldu.
Bu modelde bazı nodelar(searcher) gördüğü fırsatları Builder dediğimiz blok üreticilerine gönderiyor ve onlar da bu fırsatları dinleyip, en kârlı olanını seçip sıralamayı değiştiriyor sonuçta elde edilen kârdan searcher’a pay veriyor.
Her zincirde ayrı ayrı çalışıyor bu mekanizma. Yani X zincirinde MEV yapan nodelar ile Ethereumda MEV yapanlar arası herhangi bir iletişim yok. Bunu değiştirebilir miyiz? Burada SUAVE devreye giriyor.
Suave, kendi nodelarına gönderilen işlemleri alternatif bir mempool’a ileterek bu işlemlerden alabileceği maksimum verimi almaya(MEV) çalışacak.
https://writings.flashbots.net/the-future-of-mev-is-suave/
Bütün bunların yapılma sebebi SUAVE’nin bir chain olacak olması ve bu chain’in preference(tercih) adı verilen yapısı. Bu yapı incelediğimiz Intent mimarisine çok benzer. Kullanıcılar gönderdiği “mesajları” Anoma mimarisindeki gibi “Şu sonuca ulaşmak için istediğin hesaplamayı yap” tarzında gönderiyor.
Örneğin “Polygondaki 100 Matic’i alıp Ethereumda 1 ETH verene X kadar Eth(veya başka coin/token) ödeyeceğim” şeklinde bir preference iletilebilir. Veya daha zekice bir yöntem olarak “Optimism ve Arbitrum arasındaki ETH fiyat arbitrajını gerçekleştirene X kadar Eth(veya başka coin/token) ödeyeceğim” şeklinde preference iletilebilir.
Bu preference iletildikten sonra bizim Anoma’da Solver dediğimiz SUAVEde karşılığı Executorlar SUAVE mempool’unu dinler ve kullanıcıların preference’lerini gerçekleştirebilmek için birbiri ile yarışır. En sonunda çözümü bulanlar çözümü belirtilen mempool’a göndererek(örnek üzerinden gidersek Ethereum mempool’a/destination(alıcı) zincire) veya bir başka blok üreticisine ileterek(kendisi o chain’in validator’u olmayabilir) gerçekleştirir ve executor’un ödülü(preference’ı gönderenin vermeye razı olduğu fee) SUAVE zincirinde verilir.
https://dba.mirror.xyz/NTg5FSq1o_YiL_KJrKBOsOkyeiNUPobvZUrLBGceagg
Burada tabii kullanıcının ödeyeceği gas’e sponsor olmak gibi Anoma mimarisinde mümkün olan şeyler mümkün.
SUAVE zincirinin güvenlik modeli(Layer 1/rollup vb.) henüz belli değil. Konu üzerinde araştırmalar sürüyor.