Intent Tabanlı Mimarilere Giriş
Blok Zincir sektörü neredeyse her ay yeni kavramlar yaratıyor ve bunun tüm blok zincir sektörünü değiştireceğini iddia ediyor. Bir dönem sharding, rolluplar , hesap soyutlama, sıfır bilgi ispatları, ZKML ve daha nicesi…
Son zamanlarda, özellikle de Paradigm’in makalesi sonrası Intent tabanlı mimariler oldukça konuşulmaya başlandı. Bu konuda birçok farklı girişim ortaya çıktı ve milyonlarca dolar yatırım aldı. Haydi gelin; Intent dediğimiz kavram tam olarak ne, kullanıcı olarak hayatımda neyi değiştirecek, VC’lerin hızlıca para kazanmak için uydurduğu yeni bir kavram mı, anlattıldığı kadar büyülü bir çözüm mü sorularının cevaplarına bakalım.
Not: Bu yazıyı yazma sebebim Türkçe’de bu konuda yazılmış yazı görmemiş olmam. Maalesef aşırı derin araştırma yaptığım ve “araştırma yazısı” diyebileceğim seviyede bir yazı değil.
Transaction (İşlem) Nedir?
Intent’i anlamak için öncelikle işlem dediğimiz şeyin ne olduğunu anlamamız gerekiyor çünkü Intent, işlem tanımımızı ve haliyle blok zincirlerle etkileşim tarzımızı değiştiriyor.
Ethereum’u basitçe bir kapalı kutuya benzetebiliriz. Dışarıdaki dünyada neler döndüğünden asla haberi olamayacak, belirli kurallara sahip bir kapalı kutu. Bu kutu, dışarıdaki dünyada neler döndüğünden bihaber olduğundan kutuyla etkileşime girmek için birtakım kuralları sağlayacak bir formatta mesaj göndermemiz gerekiyor. Bu mesaj formatına İşlem (Transaction) deniyor.
https://medium.com/@doganeth/blok-zincir-anatomisi-1c72e0296562
Transaction oluşturmak, blok zincirle etkileşime girmek için basitçe iki şeye ihtiyacımız var: Bir cüzdan = private key ve blok zincire ne yapmasını söyleyecek bir mesaj. Bir saniye, blok zincire ne yapmasını söylemek ne demek?
Blok Zincirler (Yukarıdaki blog yazımda daha detaylı anlattığım üzere) bir durum makinesidir aslında. Bu durum makinesinin durumunu değiştirmek için bir fonksiyon bulunur ve bu fonksiyona “durum değişiklik fonksiyonu” (State transition function) denir. İşte Ethereum’daki işlemler; bu durum değişiklik fonksiyonuna, durumu nasıl değiştirmesi gerektiğini söyler.
Yani işin en özünde işlem yapmak için cüzdanımızdan imzaladığımız mesaj, Ethereum’a ne yapmasını direkt söyler; durum değişikliğini direkt tanımlar ve bunu Ethereum’un anlayabileceği mesaj formatında anlatır.
Burada bir tık daha detay olacak ama Ethereum Yellow Paper’inden direkt İşlemin tanımını da koymak isterim.
Yani özetle kullanıcılar blok zincirle etkileşime girerken ne istediğini değil, direkt ne yapması gerektiğini söylüyor. Peki kullanıcılar blok zincire ne yapması gerektiğini değil de ne istediğini söylese, blok zincir de “bir şekilde” bunu anlasa ne olurdu? Evet Intent tabanlı mimariler tam olarak bunu amaçlıyor.
Intent Nedir?
Intent dediğimiz şey, blok zincirlerle etkileşime girmekte yeni bir paradigma sunuyor. Intent için çok fazla tanım olsa da bence en güzel tanım bilgisayar programcılığındaki Declarative ve Imperative kodlama prensipleri üzerinden yapılan tanım.
Bilgisayar programcılığında basitçe iki kodlama prensibi bulunur. Imperative kodlama tarzında, bilgisayara tam olarak ne yapması gerektiğini anlatılırken; Declarative kodlama tarzında bilgisayara, bu programın ne amaçladığını (Intent, ingilizcede amaç demek — umarım bir şeyler uyandırır aklınızda) anlatılır.
Aynı şekilde İşlem (Transaction); Ethereum’a ne yapması gerektiğini anlatırken, Intent dediğimiz işlem tipi yalnızca blok zincirle etkileşime girerek ne “amaçladığını, bunun sonucunda ne istediğini” anlatır.
Bir Blok Zincir Intent’i Nasıl Anlayabilir — Solverlerle tanışın.
Yazının önceki kısımlarında bahsettiğim gibi, blok zincirler sadece belirtilen mesaj tipindeki mesajları anlayabilir. Yani Ethereum, Intent tabanlı bir işlemi anlayamaz. Intent’i anlayacak, bunu Ethereum’un anlayacağı şekle çevirecek bir aracıya ihtiyaç duyuyoruz. Burada yardımımıza “Solver” dediğimiz aktörler çıkıyor.
Solver’ler gönderilen intent’leri anlar ve Ethereum (yada diğer blok zincirlerin) anlayacağı hale çevirir. Örneğin: Bir kullanıcı normalde bir swap yapmak için önce bir DEX seçer, o DEX’te hangi tokeni ve hangi token’le takaslamak istediğini seçer ve bunun sonucunda bir işlem imzalar. Burada kullanıcı öncelikle doğru ağı seçmeli, tokeni seçmeli ve sonrasında ne kadar token istediğini seçip DEX arayüzünün ona gösterdiği (anlaması imkansız) veriyi cüzdan üzerinden imzalayıp blok zincire ne yapması gerektiğini anlatması gerekir.
Intent tabanlı bir işlemde ise kullanıcı sadece atmak istediği swap’ı söyler ve solverler zincirin dışında onun için en iyi fiyatı ve en optimal execution path (işlemin nasıl yürütüleceğinin tanımlanması) bulup kullanıcının işlemini blok zincire gönderir. Kullanıcının tek düşünmesi gereken şey, ne istediğidir.
Intent tabanlı işlemlerde Solverler zincirin dışında kullanıcılar için en iyi yolu araştırırken, kullanıcıların işlemlerini birleştirip onlara en iyi fiyatı sunabilir. Örneğin 1 Ether’ini 1500 USDC’ye takaslamak isteyen bir kullanıcıyla, 1500 USDC’sini 1 Ether’le takaslamak isteyen bir kullanıcının işlemlerini birleştirip hem gas’ten, hem de price impact’ten koruyabilecek bir zincir dışı eşleştirme (matching) mekanizması kullanabilir.
Intent Tabanlı Mimarilerin Zorlukları
Blok zincirlerin kapalı kutu gibi dizayn edilmesi ve sadece belirli formattaki mesajları işlemesinin önemli bir sebebi var: Sistemi güvenli tutmak. Hesap soyutlama araştırma yazımda detaylı şekilde anlattığım üzere; bir Ethereum işleminin geçerli olup olmadığını anlamamız için Ethereum işlemleri çok net şekilde belirtilmiş geçerlilik kurallarına sahiptir. Eğer bir sistem bu geçerlilik kurallarına sahip değilse, işlemlerin geçerli olup olmadığı için o işlemin sonucunu hesaplaması gerekir. Maalesef Ethereum’da işlemlerin sonucunun hesaplanmasının tek yolu, o işlemi Ethereum’da yürütmek. Bu yüzden zincirin dışındaki Solverlerin intentin geçerliliğini nasıl kontrol edeceği, bunu nasıl mümkün kılacakları bir problem. (Karmaşık olduğunun farkındayım, anlamasanız da olur. Aşağıdaki tartışmaları okuyabilirsiniz.)
Bunun dışında bir solver’in çizdiği yolun, en iyi yol olduğundan nasıl emin olunacağı da açık bir soru. Merkeziyetsiz bir solver mekanizmasında birden fazla olan execution yolunun hangisinin seçileceği ya ek bir konsensus mekanizmasıyla, ya ilk gelen alır gibi yada dutch action gibi mekanizmalarla çözülecek gibi duruyor.
Bunlara ek olarak intent tabanlı mimarilerdeki bir diğer problem de standartların nasıl belirleneceği. Bir intent tam olarak nasıl ifade edilmeli, cüzdanda kullanıcıya ne gösterilmeli ve dahası…
Son olarak, burada bahsedilmesi gereken bir de MEV konusu var. Şu an yazıyı giriş seviyesinde tutmak istediğimden bahsetmiyorum.
Son Görüşlerim:
Intent tabanlı mimariler çok önemli, bu konuda uygulama spesifik (Uniswap V4, CoW swap, 1inch) mimariler ve genel (SUAVE, Anoma, Essential) mimariler bulunmakta.
Şu an neredeyse tamamı çok erken aşamada ve ürüne hazır olması için çok vakit geçmesi gerekiyor. Ben Clave’de Product Researcher olarak çalıştığım için buradaki yenilikleri sıkı şekilde takip ediyorum ve herhangi bir fırsat gördüğümde direkt ürünümüze eklemek için takımla paylaşıyorum.
Şu anda olduğumuz noktada her şey çok erken ve -neredeyse- tamamen pazarlamadan ibaret. Geleceği merakla izliyorum.
Okuduğunuz için teşekkürler.
