Soroban, Stellar'ın akıllı sözleşme motoru

Stellar’da akıllı sözleşme var mı? Var. Soroban, Stellar’ın akıllı sözleşme platformu ve Protocol 20’nin 20 Şubat 2024’te oylanıp kabul edilmesinden beri ana ağda çalışıyor. Kullanıcılara tamamen 19 Mart 2024’te açıldı (SDF yazılım sürümleri). Geliştiriciler sözleşmeleri Rust ile yazıyor, WebAssembly’ye (Wasm) derliyor ve 2014’ten beri ödemeleri taşıyan aynı Stellar ağına dağıtıyor. Soroban ayrı bir zincir ya da yan zincir değil.

Soroban’ı ilginç kılan var olması değil (artık çoğu katman 1 ağında sözleşme var), arkasındaki tasarım tercihleri. Ücretler tek bir “gas” rakamı yerine kaynak başına fiyatlanıyor. Saklanan veri kira ödüyor ve arşivlenebiliyor. Sözleşmeye yeniden giriş (re-entry) engelleniyor. Yerel varlıklar sarmalamaya gerek kalmadan sisteme bağlanıyor. Bu rehberde Stellar akıllı sözleşmelerinin nasıl çalıştığını, ne tuttuğunu, Ethereum’un EVM’inden nasıl ayrıldığını ve Asya’daki geliştiricilerin nelerden yararlanabileceğini anlatıyoruz.

Stellar’da akıllı sözleşme var mı? Kısa bir tarihçe

Stellar, ömrünün büyük kısmında genel amaçlı sözleşmelerden bilinçli olarak uzak durdu. Protokol; yerleşik bir emir defteri, multisig, path payment’lar, claimable balance’lar ve 2021’den itibaren yerel AMM havuzlarıyla geliyordu. Bu, ödemeleri ve basit alım satımı karşılıyordu ama kimse borç verme piyasası gibi özel bir mantık dağıtamıyordu.

Soroban bunu değiştirdi. SDF, 2022’de ekosistemi beslemek için 100 milyon dolarlık Soroban Adoption Fund’ı duyurdu ve kod 2023’ü testnet ile Futurenet’te geçirdi. Protocol 20, bir hata düzeltmesi nedeniyle üç haftalık gecikmenin ardından 20 Şubat 2024’te ana ağa ulaştı. SDF ardından platformu aşamalı olarak açtı: 20 Şubat’ta Faz 0, 27 Şubat’ta Faz 1 ve ağı genel kullanıma açan Faz 2, 19 Mart 2024’te (SDF’nin aşamalı geçiş yazısı). Bir yerde “Soroban 2023’te başladı” diye okursan, bu ana ağı değil test ağlarını kastediyor.

İsimlendirme üzerine küçük bir not: SDF’nin yeni materyalleri giderek sadece “Stellar akıllı sözleşmeleri” diyor ve Soroban-RPC’nin adı 2024’te Stellar RPC olarak değişti. Soroban adı ise soroban-sdk Rust crate’inde ve günlük geliştirici dilinde yaşamaya devam ediyor; yani iki terim de aynı şeyi anlatıyor.

Soroban nasıl çalışır: Rust, WebAssembly ve host

Bir Soroban sözleşmesi, Wasm’a derlenmiş küçük bir Rust programı. SDF’nin genel bakış sayfası net: şimdilik yalnızca Rust destekleniyor ve sözleşmeler tam Rust standart kütüphanesini kullanamıyor. Bunun yerine soroban-sdk crate’i üzerine kuruluyorlar (akıllı sözleşmelere genel bakış). Yukarıdaki widget, minimal bir sözleşmenin iskeletini gösteriyor: bir struct, #[contractimpl] ile işaretlenmiş bir impl bloğu ve bir ortam tutamacı (environment handle) ile argümanlar alan bir fonksiyon.

Wasm, Stellar Core’a gömülü bir “host” içinde çalışıyor. Host; depolama, kriptografi, event’ler, sözleşmeler arası çağrılar ve yetkilendirme sağlıyor. Böylece sözleşmeler küçük kalıyor ve pahalı işler yerel kod olarak çalışıyor. Bir sözleşmeyi çağırmak için InvokeHostFunctionOp içeren bir işlem gönderiyorsun. Akıllı sözleşme işlemleri tam olarak tek bir operasyon taşırken klasik işlemler 100’e kadar operasyonu bir araya getirebiliyor.

Test tarafı güçlü bir yön. SDK, zincir üstü ortamla eşleşen yerel bir host uygulamasıyla geliyor; böylece testnet’e dokunmadan önce normal bir IDE’de hata ayıklayabilir, birim, fuzz ve özellik (property) testleri koşturabilirsin. Yetkilendirme de yerleşik. Bir fonksiyon bir adres üzerinde require_auth() çağırıyor ve host ilgili imzaları kontrol ediyor. Bu, sıradan hesaplarda ve Protocol 21’deki secp256r1 desteğinden beri passkey tabanlı akıllı cüzdanlarda çalışıyor.

Soroban ücretleri ve kaynak modeli

Her Soroban işlemi iki şey öder: bir dahil etme ücreti (inclusion fee) ve bir kaynak ücreti (resource fee) (ücretler, kaynak limitleri ve ölçüm). Dahil etme ücreti diğer Stellar ücretleri gibi işliyor. En az 100 stroop (0,00001 XLM) ve defterler dolduğunda surge pricing, işlemleri verdikleri teklife göre sıralıyor. Kaynak ücreti ise Soroban’a özgü kısım ve kalem kalem hesaplanıyor: CPU komutları, okunan ve yazılan defter kayıtları, G/Ç baytları, işlem boyutu, event’ler ve dönüş değeri, depolama kirası.

Bunun bir kısmı iade edilebiliyor. CPU, okuma ve yazma baytları ve bant genişliği beyan edildiği gibi ücretlendiriliyor. Kira, event’ler ve dönüş değeri kullanılmazsa iade ediliyor. Pratikte bu rakamları asla tahmin etmiyorsun: işlemi önce Stellar RPC üzerinden simüle ediyorsun ve simülasyon, eklenecek kaynak ayak izini ve ücreti döndürüyor.

Gerçek para karşılığı küçük kalıyor. Son kontrolümüzde ana ağda en sık alınan ücret 100 stroop’luk minimumdu; medyan ise sözleşme çağrılarının etkisiyle 0,00035 XLM civarındaydı. Temmuz 2026 itibarıyla her defter 1.000 klasik operasyon ve 2.000 akıllı sözleşme işlemi alabiliyordu. Tüm Stellar ücretlerinde olduğu gibi XLM doğrulayıcılara değil, kilitli bir ücret havuzuna gidiyor. Stellar ücretleri ve hızı rehberimiz bunu diğer ağlarla karşılaştırıyor.

State archival: zincir üstü veri için kira

Ethereum, biri yazmanın bedelini ödediği anda sözleşme verisini sonsuza dek saklıyor ve her düğüm bu yükü süresiz taşıyor. Soroban ise state archival adı verilen farklı bir yol izliyor (SDF dokümanları). Her sözleşme verisinin defter sayısıyla ölçülen bir yaşam süresi (TTL) var ve canlı kalmanın bedeli kira.

Üç depolama türü bulunuyor. Temporary (geçici) depolama en ucuzu ve TTL sıfıra indiğinde kalıcı olarak siliniyor; fiyat kotasyonları ya da nonce’lar gibi şeyler için ideal. Persistent (kalıcı) depolama bakiyeler için uygun ve süresi dolduğunda silinmiyor, arşivleniyor. Instance depolama sözleşme genelindeki ayarları tutuyor ve sözleşmenin kendi TTL’ini paylaşıyor. Arşivlenmiş kayıtlar yeniden oluşturulamıyor, yalnızca geri yüklenebiliyor; böylece kimse eski bir bakiyenin yerine gizlice yenisini koyamıyor.

Protocol 23 “Whisk” (Eylül 2025) arşivlemeyi yeniden düzenledi: bir işlemin geri yükleme listesinde yer alan arşivlenmiş kalıcı kayıtlar, sözleşme çalışmadan önce otomatik olarak geri geliyor ve bu listeyi simülasyon senin için dolduruyor. Tasarım doğrulayıcı depolamasını hafif tutuyor ama geliştiriciye bir iş daha çıkarıyor: önemli olan her şeyin TTL’ini uzatmak ya da geri yüklemeler için bütçe ayırmak.

Stellar Asset Contract: yerel varlıklar sözleşmelerle buluşuyor

Soroban’ın kaçındığı baş ağrılarından biri sarmalama (wrapping). Ethereum’da ETH’nin çoğu sözleşmede kullanılabilmesi için önce WETH’e dönüşmesi gerekiyor. Stellar’da ise XLM dahil her varlığın, standart token arayüzünü (SEP-41) uygulayan ve kendisine ayrılmış tek bir Stellar Asset Contract’ı (SAC) var. SDF dokümanları, bir varlık ile SAC’ının “aynı varlığı temsil ettiğini” söylüyor (SAC dokümanları). SAC’ı herkes dağıtabiliyor ve SAC, klasik cüzdanların kullandığı aynı trustline bakiyelerini okuyup yazıyor.

Bunun önemi kolaylığın ötesinde. SAC, ihraççının yetkilendirme ve clawback bayraklarına uyuyor; düzenlemeye tabi ihraççıların kontrolü kaybetmeden token’larını DeFi’ye sokabilmesinin nedeni bu. Örneğin PayPal’ın PYUSD’si, ilk günden Soroban ile çalışsın diye SAC kullanılarak Stellar’da başlatıldı; stablecoin rehberimiz bunu daha ayrıntılı ele alıyor. Tokenize gerçek dünya varlıkları sayfamız da bu uyum katmanının fon yöneticilerini neden çektiğini anlatıyor. Protocol 26 (Mayıs 2026) bir adım daha ileri giderek SAC üzerinden yapılan XLM transferlerinin alıcı hesabını otomatik olarak oluşturmasını sağladı.

Soroban ile EVM karşılaştırması

Ethereum, BNB Chain veya diğer EVM ağlarından gelen geliştiriciler tanıdık fikirlerle ama farklı varsayılanlarla karşılaşacak. SDF’nin tasarım yazısı bunların birçoğunu Ethereum’dan çıkarılan dersler olarak sunuyor; aralarında net bir kural da var: “Sözleşmeye yeniden girişe izin verme” (SDF blogu).

İki uyarı var. Yeniden girişi engellemek klasik bir hata sınıfını ortadan kaldırıyor ama sözleşmeleri kendiliğinden güvenli yapmıyor. Mantık hataları, kötü erişim kontrolü ve oracle sorunları olduğu yerde duruyor. Ayrıca bir EVM uyumluluk katmanı yok; yani Solidity kodunun yeniden yazılması gerekiyor. Stellar’ın ödeme odaklı bir rakiple daha geniş karşılaştırması için XLM vs XRP sayfamıza bakabilirsin.

Lansmandan bu yana protokol güncellemeleri: P29 ve Bell oylaması

Güncellemeleri doğrulayıcılar oyluyor ve her biri oylama geçer geçmez yürürlüğe giriyor. Soroban devreye girdiğinden beri sözleşme platformu epey değişti:

• Protocol 21 (Haziran 2024): passkey cüzdanları için secp256r1 imza doğrulaması ve maliyet modelinde iyileştirmeler.
• Protocol 22 (Aralık 2024): sözleşme constructor’ları ve BLS12-381 kriptografisi.
• Protocol 23 “Whisk” (Eylül 2025): birleşik event’ler, state archival değişiklikleri ve paralel sözleşme yürütme.
• Protocol 25 “X-Ray” (Ocak 2026): sıfır bilgi ispatlarının yapı taşları olan BN254 ve Poseidon hash’leme.
• Protocol 26 “Yardstick” (Mayıs 2026): ele geçirilmiş defter kayıtlarının doğrulayıcı konsensüsüyle dondurulması, kontrollü 256 bit matematik ve SAC iyileştirmeleri.
• Protocol 27 “Zipper” ve 28 “Adapter” (Temmuz ve Eylül 2026): akıllı hesaplar için kimlik doğrulama delegasyonu, ardından harici olarak yönetilen sözleşme yürütülebilirleri ve sparse-map fonksiyonları.
• Protocol 29 (1 Ekim 2026): yalnızca güvenlik düzeltmeleri, yeni CAP yok.

Sırada Protocol 30 “Bell” var ve henüz devrede değil. Ana ağ oylaması 23 Kasım 2026’ya planlandı ve tarihler değişebilir. Bell; muxed sözleşme adresleri, host fonksiyonu olarak ML-DSA kuantum sonrası imza doğrulaması ve milisaniyelik defter zaman damgaları getirecek (Bell güncelleme rehberi). SDF, normal hesap imzalarının Ed25519 olarak kalacağını ve Bell’in tek başına defterlerin yaklaşık beş saniyeden daha hızlı kapanmasını sağlamayacağını belirtiyor.

Geliştirici araçları ve fonlama

Araç seti derli toplu. Stellar CLI sözleşmeleri derliyor, test ediyor, dağıtıyor ve çağırıyor; anahtarları ve ağları da yönetiyor. SDF’nin web aracı Stellar Lab, hiçbir yerel kurulum gerektirmeden Mainnet, Testnet ve Futurenet’te sözleşme yükleyebiliyor, dağıtabiliyor, çağırabiliyor ve simüle edebiliyor. Stellar RPC, yeni geliştiriciler için önerilen veri API’si. İstemci SDK’ları JavaScript, Python ve daha fazlasını kapsıyor; Stellar Wallets Kit de uygulamaları Varial (eski adıyla Freighter), LOBSTR ve xBull gibi Stellar cüzdanlarına bağlıyor.

Güvenlik tarafında SDF, Ocak 2025’ten Aralık 2026’ya uzanan iki yıllık bir OpenZeppelin ortaklığı imzaladı. Ortaklık; denetlenmiş bir Stellar sözleşme kütüphanesini, 40 denetçi-haftalık denetimi ve bir bug bounty programını kapsıyor (SDF duyurusu). SDF’nin Soroban Security Audit Bank programı, uygun projeleri yüzde 5 katkı payıyla denetim firmalarıyla eşleştiriyor; kritik, yüksek ve orta seviye bulgular 20 iş günü içinde düzeltilirse bu katkı payı iade ediliyor.

Fonlama ağırlıklı olarak Stellar Community Fund üzerinden yürüyor. Build kategorisi proje başına 150.000 dolara kadar XLM sunuyor; daha küçük Instaward’lar ise yerel ambassador grupları aracılığıyla dağıtılıyor. Ödülleri topluluk üyeleri oyluyor. Son turların her biri kabaca 1,2 ile 2,2 milyon dolar arasında ödeme yaptı. Örneğin SCF #29, 39 projeye yaklaşık 2,2 milyon dolar dağıttı.

Pan-chan diyor ki

Stellar Lab ile testnet’te başla, her çağrıyı simüle et ve CLI’yı ancak ondan sonra ana ağa yönlendir. Bedava testnet XLM’i, pahalıya patlayan bir dersten her zaman iyidir.

Güvenlik dersleri: YieldBlox oracle olayı

Soroban’ın bugüne kadarki en pahalı dersi, çekirdek bir sözleşmedeki hatadan gelmedi. 22 Şubat 2026’da bir saldırgan, Blend üzerinde YieldBlox DAO’nun işlettiği bir borç verme havuzunu hedef aldı. Havuz teminatı Reflector oracle’ı üzerinden fiyatlıyordu; oracle da Stellar DEX’teki sığ bir USTRY/USDC piyasasından veri çekiyordu. Tek bir işlem, USTRY’nin raporlanan fiyatını yaklaşık 1,05 dolardan yaklaşık 106,73 dolara çıkardı. Saldırgan ardından şişirilmiş teminat karşılığında kabaca 10,2 milyon dolarlık XLM ve USDC borç aldı (Blockaid olay sonrası analizi).

Blockaid saldırganın cüzdanlarını tespit ettikten sonra Tier-1 doğrulayıcılar bu adreslerden gelen işlemleri reddetmek için koordine oldu ve yaklaşık 48,07 milyon XLM (yaklaşık 7,3 milyon dolar) “karantinaya” alındı. Blockaid müdahalenin içinde yer aldığı için rakamlarını bu gözle okumakta fayda var. Geliştiriciler için çıkarılacak dersler klasik DeFi dersleri: teminatı asla sığ bir piyasadan fiyatlama, zaman ağırlıklı veya çok kaynaklı veri akışları kullan ve likiditesi düşük varlıklara maruziyeti sınırla. Stellar DeFi rehberimiz olayı kullanıcı tarafından ele alıyor.

Asya’daki Soroban geliştiricileri

Asya’da doğrulanmış Soroban faaliyeti mütevazı ama büyüyor. 2026’da SDF ve eğitim platformu Rise In, 60.000 dolara varan ödüllerle bir APAC Stellar Hackathon düzenledi. Güneydoğu Asya’daki ekiplerden Soroban üzerinde DeFi, ödeme, cüzdan ve fiat giriş/çıkış (on/off-ramp) uygulamaları geliştirmeleri istendi; yerel destek verildi ve Filipinler, Vietnam ve Endonezya’da yüz yüze finaller yapıldı (BitPinas). Kurumsal tarafta ise Ekim 2026’da SDF’den stratejik yatırım alan Singapurlu Marketnode, Stellar üzerindeki tokenize fonları Asya-Pasifik yatırımcılarına dağıtıyor. Düzenleyici tarafı pazar pazar Asya merkezimizde takip ediyoruz.

Ho Chi Minh City’de ya da Bandung’da bir geliştirici için pratik yol, dünyanın her yerindekiyle aynı: Rust öğren, testnet’te yayına al, SCF’ye başvur ve gerçek para devreye girmeden önce denetim yaptır. Önce ağı anlamak istersen Stellar Lumens nedir sayfasıyla başla; TTL, SAC ve trustline gibi terimler için de Stellar terimler sözlüğümüzü açık tut.

Keşfetmeye devam et

🌀 DeFi ve dApp'lerStellar'da DEX, AMM, borç verme ve getiri.Rehberi oku 🏦 RWA tokenizasyonuStellar'da tokenize edilen fonlar, bonolar ve kredi.Rehberi oku 📘 XLM nedirTarihçesinden ücretlere, Stellar ve XLM'in açıklaması.Rehberi oku 📖 SözlükSade Türkçeyle açıklanmış kırk Stellar terimi.Rehberi oku