Decentralized Oracle Networks Kavramına Derin Bir Bakış
İlk yazıda şu ifadeyi kullanmıştım.
Blockchain ağları Galaksileri temsil ediyorsa Chainlink, kendine ait Galaksileri bulunan Bütün Evreni temsil eder.
Yazıya bu kavramı derinleştirerek başlamak istiyorum.
Blockchain’leri temsil eden Galaksiler, içerisinde bulunan gezegenlerin kütlelerinden dolayı birbirlerine çekim uygularlar ve uzay-zaman bükülmeleri ile günümüzde gözlemlediğimiz Gezegen/Galaksi hareketleri ortaya çıkar.
Yeri gelir bu büyük kütleler içerisine çöker (LUNA) ve kara delikleri oluştururlar.
Hatta yeri gelir, “Composability” iddiası ile ortaya çıkan Galaksiler (Solana), tek bir gezegen içerisinde tüm Galaksi nüfusunu barındırmaya çalışır.
Fakat bu Galaksilerin birbirleri ile bir bağı yoktur. Birbirleri ile bir nüfus (veri) alışverişi yapamazlar.
Devamlı büyüyen evren, birbirinden kopuk Galaksilerimiz için keşfedilemez hale gelir. Bu galaksilerin birbirleri ile iletişime geçmesi gerekmektedir.
İşte bu nokta, tüm bu Galaksiler arasında iletişimi sağlayan ve bu Galaksileri daha yaşanılabilir hale getiren büyük bir Oracle ağı kurulur.
Bu Oracle sayesinde Galaksilerimiz birbirinden haberdar olabilecek, yeri geldiğinde eksiklerini kapatacaklardır.
Bölüm 1: Güvenlik Modelleri ve Hedefler
🕸️ Öncelikle bu Oracle’yi (Chainlink), daha işlevsel hale getirebilmek için Decentralized Oracle Networks, DONs adı verdiğimiz yapılara bölmeliyiz. Her DON için ayrı bir görev tanımı bulunmalı. Birisi “Rastgele Bir Sayı üretirken (VRF), bir diğeri “Meyve Sebze Fiyatlarını tüm Galaksiler için aynı yapmalı (Data Feeds).
Bu sayede Oracle’ımız, “Modüler” bir yapıda olacaktır. Her bir DON için kendi consensus modeli, güvenlik varsayımları tanımalıyız. Bu sayede ihtiyaca yönelik olarak yeni DON’lar oluşturabiliriz.
Decentralized Oracle Network terimi, hem oracle nodelarının koruduğu hem de API yapısı olarak tanımlanan oracle network sistemini tüm işlevleriyle kapsamak için kullanılır.
Ledger (𝓛) terimi, DON’un sürdürdüğü veri yapısı ve sağladığı sistemler için kullanılır.
Decentralized Oracle Network bir blockchain değildir, blockchainleri desteklemek için oluşturulmuş yapılardır. Bir DON’un BFT tipi bir consensus kullanması beklenir fakat tercih geliştiricilere bırakılmıştır.
Bir Ledger (𝓛), verilerin/işlemlerin sırasına uygun şekilde sıralandığı bir defter/stateler bütünüdür. Blockchainlerle benzer özelliklere sahiptir. Bir 𝓛 şu özelliklere sahiptir:
Append Only; Bir veri eklendikten sonra değiştirilemez,
Public; Herkese açıktır,
Available; Sadece nodelar veri ekleyebilir ama herkes veri çekebilir.
Bağımsız bir DON yapısı yerine, PoS ile çalışan bir ağın nodeları, aynı zamanda DON nodeları olarak çalışabilecek şekilde de tasarlanabilir.
Fakat DON’ların committee-based bir consensus protokolü sürdürmesi beklenir. Fakat bu sadece bir beklentidir, DON geliştiricileri diledikleri gibi programlama yapabilirler.
Bolstering Trust Model
Chainlink’in önemli bir özelliği, kullanıcıların performans geçmişlerinin merkezi olmayan kayıtlarına dayalı olarak düğümleri seçme yeteneğidir.
İleride bahsedeceğim Staking Mekanizması ve önceki yazıda bahsettiğim Implicit-Incentive Framework ile kullanıcılar, DON’ların güvenliğini ölçme ve artırma yönünde güçlü bir etkiye sahiptirler.
Aynı çerçevede DON’ların kendilerininde katılımcı nodelar üzerinde çeşitli güvenlik gereklilikleri uygulamaları mümkün olacaktır.
Ek okuma yapmak isteyenler paylaştığım floodu okuyabilirler.
Bölüm 2: Bir Decentralized Oracle Network Neler Yapabilir?
Bu bölümümüzde DON’ların tasarım dizaynlarını basit ama güçlü bir biçimde ele alacağız.
DON üzerindeki uygulamalar “executables” ve “adapters” olarak 2 kategoriye ayrılır.
Bir “executable”, önceden programlanmış, akıllı sözleşmelere benzeyen işleyişi sonucu net (deterministic) çıktılar üreten programlardır. Executables, önceden tanımlanmış bir olay meydana geldiğinde programın çağıracağı “initiators” içerir.
“Adapters”, off-chain dünyanın anahtarlarıdır ve “initiator” ya da “executables” içerisindeki core logic tetiklendiğinde çağırılırlar. Davranışları dış kaynaklara bağlı olsa da “initiators” ve “adapters” dediğimiz yapılar non-deterministic davranabilirler.
DON geliştirici arayüzünü ve “executables” ile “adapters”ın işleyişlerini bilgi işlem sistemlerini karakterize etmek için kullanılan 3 kaynakla açıklarız;
- Networking
- Computing
- Storage
2.1) Networking
Adapters, DON üzerinde çalışan executableların DON dışı sistemlerden veri gönderip alabilmesini sağlayan arayüzlerdir. Çift taraflı çalışabilirler. Secure Multy-Party Computation gibi kriptografik işlevleri de kullanabilirler. Bazı örnek tasarımlara göz atalım:
Blockchainler -> Bir adapter, bir blockchain üzerinden nasıl blok, işlem, durum verisi okuyacağını ya da bir blockchaine nasıl işlem, veri gönderebileceğini tanımlar. Mempool işlemleri için de kullanılabilir.
Web Serverları -> Adapterlar, web servislerinden nasıl veri çekileceğine/veri gönderilebileceğine yönelik API’lar sağlar.
External Storage -> Bir adapter, DON dışı bir sunucuya veri yazmak ya da sunucudan veri çekmek için tasarlanabilir.
Diğer DON’lar -> Adapterlar, DON’lar arası veri akışı sağlayabilirler.
DON’un ilk tasarımları sırasında, “building block adapters” adı verilen ve dış kaynaklara bağlanan adaptörler olması beklenir. Ayrıca DON’a özgü adaptörlerin DON düğümleri tarafından sonradan yayınlanmasına izin verilmesi beklenir.
Adaptörlerin (dolayısı ile veri çekilebilecek sunucuların) zamanla daha da yaygınlaştırılması ana amaçtır. Bu noktada en büyük beklendi ise, kullanıcıların Adapter kurabilmesidir.
Bazı Adapterlar, bir DON tarafından kontrol edilen harici kaynakların sürekliliğini ve kullanılabilirliğini sağlayacak biçimde oluşturulmalıdırlar. Örneğin cloud storage bakım gerektiren bir servistir.
Ayrıca bir DON, kullanıcılar ya da executables adına özel anahtarların merkeziyetsiz yönetimini gerçekleştirebilir.
2.2) Computation
Executable yapısı, bir DON içerisinde yer alan kod parçasıdır. İki adet girdi bulunur;
exec = (logic, init)
Logic, net sonuç üreten (deterministic) programın entrypointler bütünüdür.
Init ise belirli tetikleyicileri (initiators) temsil eder.
Executable içerisindeki kod parçasının alacağı tüm girdi veriler, Ledger (𝓛) içerisinde bulunmalıdır.
2.2.1 => Initiators
Initiators, Chainlink nodeları üzerinde gerçekleşen olaylara/mesajlara bağlı olarak “job execution”lara sebep olurlar. Bir DON için de bu durum böyledir ama bir fark olarak, bir initiator spesifik executableları tetikleyebilir.
Bir initiatoru ise, zaman ya da dış bir etken tetikleyebilir.
Initiators, executable’ı bir akıllı sözleşmeden ayıran önemli bir eklentidir. Executable’lar, initiatorların tetiklenmesi sonucu çalışabileceği, initiatorlar ise zamana bağlı olarak tetiklenebilecekleri için otonom olarak çalışabilirler.
Executableları akıllı sözleşmelerden ayıran 2 ana özellik bulunur:
Confidentiality -> Executable’lar, gizli bir hesaplama yapabilirler. Bu gizli hesaplamaların çıktılarının blockchainler ya da dış kaynaklar ile paylaşılması zorunlu değildir.
Supporting Rol -> Executable’lar akıllı sözleşmelere desteklerler. Bu sebeple bazı kısıtlamalara sahiptirler. Örneğin, Executable’lar DON içerisindeki güvenlik varsayımlarına uydukları için akıllı sözleşmeler “guard rails” ile DON’a karşı güvenlik duvarı çekebilirler.
3.3) Storage
Committee-Based bir sistem olan DON’lar, permissionless olan bir blockchain’e göre aynı miktarda veriyi kalıcı olarak çok daha ucuza depolayabilirler. Ayrıca Filecoin gibi dış depolama çözümlerine referans gösterebilir ve bu sistemleri blockchainler ile bağlayabilirler.
State Bloat sorunu için bu çözümler caziptir.
DON’lar verileri kullanış amaçlarına göre node’lar üzerinde ya da dış bir kaynakta tutarlar. Veriyi, Secure Multy Party Computation ya da Fully Homomorphic Encryption ile secret-shared olarak ya da Trusted Execution Enviroment (TEE, bu yapıyı anlatacağım kısaca) kullanarak depolarlar.
DON’ların blockchainler ve akıllı sözleşmeler için bir memory management uygulaması olması beklenir.
3.4) Transaction Execution Framework (TEF)
Transaciton Execution Framework, bir akıllı sözleşmenin Blockchain ve DON ikilisince verimli iletişimi için tararlanmıştır.
TEF, Fair Sequencing Service (FSS) ve Layer 2 ağlarını destekleyebilir. FSS’in ana odaklarındandır.
TEF kullanımı için hedef akıllı sözleşme, bir Hybrid Akıllı Sözleşmeye dönüştürülür. Bu dönüştürme 2 parçadan oluşan bir Hybrid Akıllı Sözleşme oluşturur:
Blockchain üzerinde yer alan, “anchor sözleşme” adı verilen parça,
DON üzerinde, bu akıllı sözleşmeyi tetikleyen bir executable.
Anchor sözleşmemiz varlıkları yönetir, blockchain üzerindeki state/durum değişikliklerini sağlar ve DON hatalarına karşı guard rails çalıştırır.
Executableımız ise işlemleri FSS kullanarak sıralar ve bu işlemlere oracle verilerini ekler.
3.5) Mempool Servisleri
TEF ve FSS desteği ile, DON’a bir application-layer güncellemesi olarak Mempool Services (MS) eklenecek. MS ile beraber Mempool’a düşen Hybrid Smart Contract işlemleri toplanacak. Toplanan işlemler DON’un ilgili executable’larına iletilecek. Burada düzenlenen işlemler hedef akıllı sözleşmeye geri gönderilecek ve yeni işlemler oluşturmak amacıyla kullanılacak.
3.6) Chainlink’in Mevcut Yıldızları
3.6.1 => Off-Chain Reporting (OCR)
OCR, Oracle raporlarını toparlar ve hedef akıllı sözleşmeye iletir. Kısmen BFT Consensus gibi çalışır.
Bir BFT consensus içerisinde nodeların hatalı/sahtekar nodelar, tüm nodeların 1/3'ünden az ise canlılık ve doğruluk sağlanır. Ama dediğim gibi, OCR tamamen bir BFT consensus değildir.
OCR üzerinde node’lar global bir state tutmazlar. Ayrıca Lider Node, sistemin güvenliğini tehlikeye atmadan kararsız davranabilir.
OCR, “medianized aggregation of values” olarak adlandırılan, gelen verilerin ortalamasını alıp ortak mesaja çeviren bir mesaj tipi kullanır. Bu mesaja “attested reports” diyoruz.
Varsayım şudur: Ortalama değer, 2 dürüst node’un verilerinin arasında bir değerdir. OCR, güvenliğini buradan alır.
Lider, onaylanmış bir rapordaki ortalama değer üzerinde doğruluk koşuluna tabii olduğu sürece bir miktar etkiye sahip olabilir.
OCR, BFT’nin sahip olmadığı bazı işlevlere sahiptir:
All-or-nothing off-chain report broadcast (Adillik/Fairness ilkesi): OCR, attested raporun tüm düğümlere aynı anda gönderilmesini ya da hiç gönderilmemesini temel alır. Böylece dürüst nodelar çoğunlukta kalır ve rapor hatasız bir biçimde hedef blockchaine gönderilir.
Reliable Transmission (Canlılık/Liveness ilkesi): Rapor (hatalı ya da eksiksiz olsa bile), hedef akıllı sözleşmeye belirli bir zamanda gönderilmiş olur.
Contract Based Trust Minimization (Doğruluk/Correctness Enforcement İlkesi): Yeni bir rapor, öncekilerden oldukça farklı/hatalıysa, rapor hedef akıllı sözleşme tarafından kabul edilmez. Bu bir “Guard Rails” örneğidir.
3.6.2 => DECO ve Town Crier
DECO ve Town Crier, Chainlink ağlarında kullanılan ve geliştirilen 2 önemli teknolojidir.
Çoğu web servisi TLS kullanarak güvenli bir şekilde kullanıcıların servise ulaşmasını sağlar.
(HTTPS → TLS kullanan HTTP )
TLS özellikli sunucuların çoğunda dikkate değer bir sınırlama vardır. Veriler dijital olarak imzalanmaz. Bir kullanıcı ya da “Prover”, bir sunucudan alınan verileri oracle, akıllı sözleşme gibi bir doğrulayıcıya, “Verifier”a verilerin gerçekliğini garanti edebilecek şekilde sunamaz.
Eğer dijital imzalama varsa, sistemde bir gizlilik sıkıntısı vardır. “Prover”, bazı hassas bilgileri gizlemek isteyebilir ama dijital imzaların ana özelliği mesajın/metnin değiştirilememesi olduğu için bunu yapamaz.
DECO ve Town Crier sayesinde Prover, web servislerinden aldığı veriyi “Verifier”a, bütünlük (integrity) ve gizlilik (confidentiality) ilkelerine bağlı kalarak gönderebilir.
İki sistemin de önemli özelliği, hedef web sunucusunda herhangi bir değişiklik gerektirmemesidir. TLS özellikli bir sunucu ile çalışabilirler.
2 sistem birbirine benzerdir ama güvenlik varsayımları ve uygulamalarında farklılıklar bulunur.
DECO
Bütünlük ve Gizlilik için kriptografik protokoller kullanılır.
DECO kullanarak bir web sunucusuyla iletişim kurulurken, Prover yanı zamanda Verifier ile etkileşimli bir protokol yürütür.
Mevcut tur içerisinde Prover, Verifier’a “D” veri parçasını kanıtlayabilir. “D”nin bazı parçalarını ya da “D”yi ZK-Proof ile de gönderebilir.
DECO’nun tipik kullanımında bir node/kullanıcı, web sunucusundan özel bir oturumla alının “D” verilerini bir DON’daki tüm nodelara iletir. DON’un tamamı “D”yi doğrulayabilir.
Sadece tek bir DON düğümünün, “D”nin kaynağına ulaşımı olsa bile tüm DON “D”yi doğrulayabilir.
Town Crier
Town Crier, Intel SGX gibi Trusted Execuiton Enviroment (TEE) kullanımına dayanır. Kapalı bir kutu içerisinde kullanılamaz ve gizli şekilde execution gerçekleşir.
TEE’yi çalıştıran kişi bile bu kutunun içini göremez, kurcalayamaz.
Town Crier, DECO’nun yaptığı her şeyi fazlasıyla yapabilir. DECO’da tek bir Verifier bulunurken Town Crier sayesinde herkese, public proof sharing yapılabilir. Ayrıca gizli veriler çözülmeden alınıp kullanılabilir.
Town Crier’in olumsuz özelliği ise Trusted Execution Enviroment’e güven duymasıdır.
Serüvenimize burada bir nokta koyuyoruz. Bu yazıyı lütfen dikkatlice okuyarak anlamaya çalışın. Zor günler geride kaldı. Mevcut uygulamalara ve FSS gibi servislerin tasarım detaylarını inceleyeceğiz burdadan sonra.
Yazıyı beğendiyseniz paylaşarak destek olabilirsiniz.
Sağlıcakla kalın.
Alperen Tunçkıran / Chainlink Community Advocate
Twitter : @blockofchain
