Blockchain Oracles: Hyperledger Fabric üzerinde Non-Deterministik Veri Kullanımı ve Riskleri
Makaleyi konuya uzak olan arkadaşların ve Blockchain, DLT kavramlarını az çok duymuş olanların bile anlayacağı bir yapıda kurgulamak istedim umarım başarılı olmuştur.
Giriş
Oracles kelimesi latince “oraculum” kelimesinden gelmektedir. Eski zamanlarda oracles bir kehanet, ilahi söz gibi güvenilen bilgi anlamını taşımaktaydı. Bu makalede konu edeceğimiz “Blockchain Oracles” kavramını ise bu geçmiş tanımına bağlı ama biraz ironik olarak ondan ayrılan ve Blockchain ağlarında bir çok use-case de karşımıza çıkacak önemli bir sorun olarak görmemiz gerekiyor.
Makalede ilk olarak Oracles kavramını ve Blockchain ağlarında neden ve nasıl kullanıldığını, buna niye ihtiyaç duyduğumuzu anlatacağız. Daha sonra konuyu yine diğer makalelerimizde olduğu gibi genelden özele doğru götürerek , Hyperledger Fabric çözümü içerisinde “Blockchain Oracles” kavramının nasıl konumlandığına ve bunun etkilerine değineceğiz.
Genel olarak bir Blockchain ağında işlemlerin onaylanması ve validasyonu ağa katılan tarafların işlemlerini şeffaf, değiştirilemez ve güvenli bir şekilde yapması için imkan oluşturuyor. Blockchain ağı içerisinde kullanılan akıllı kontratlar aracılığı ile dönen verinin doğruluğu, verinin yalnızca ağ içerisinde bulunduğu durumlarda ve akıllı kontratların işlemleri yürütmek için dış kaynaklardan(external-resources/ex:api) veri çekmek zorunda kalmadığı durumlarda kusursuza yakın bir güvenlik ve şeffaflık sağlıyor.
Peki akıllı kontratımız işlemleri yapmak için harici bir veri kaynağına ihtiyaç duyarsa ne olacak? İşte bu makalenin konusu tam olarak bununla ilgili.
Deterministik vs Non-Deterministik
Burada temel soru tamamıyla deterministik bir yapıda olan Blockchain ağlarında non-deterministik diye tabir ettiğimiz her an değişebilen verilerin kullanımının nasıl olması gerektiğidir.
Blockchain ağları deterministik derken ne demek istiyoruz. Blockchain ağları, birbiri ardına gerçekleşen sıralı ve belirli olaylar zincirinden oluşan bir yapı, bu yüzden deterministik bir yapı olarak karşımıza çıkıyor. Dış dünyadan çektiğimiz bir çok veride ise durum tam tersi, aslında bu tanımı yaparken Blockchain’e neden ihtiyacımız var ve şu an kullandığımız çözümler ile arasındaki temel fark nedir? sorusuna da tatmin edici cevaplar bulabiliriz. Ne demiştik, Blockchain ağları sıralı ve belirli olaylar zinciri ile bize şeffaf ve güvenilir bir ortam sağlıyor. Peki ya esneklik? Esneklik aslında şu an ki hayatımızda çokça varolan fakat esnedikçe de güven sorunlarını beraberinde getiren bir kavram. Şu an kullandığımız veritabanları, apiler, servisler fazlasıyla esnek bir yapıdalar ayrıca bir tedarik zincirinde veya finansal işlemlerde hala o kadar esnek bir şekilde insan gücüne ve formal kağıt işlerine bağlıyız ki bu güven sorunu artık maliyetine katlanılamaz bir hal almaya başladı ve bu esneklikten doğan güven sorununu Blockhain ağları inşa ederek aşmaya çalışıyoruz. Aynı zamanda Blockchain ağlarımızı inşa ederken de daha önce sahip olduğumuz bize esneklik sağlayan verileri(kaynakları) da kullanmaya devam etmek istiyoruz. İşte “Blockchain Oracles”’ı ortaya çıkaran olayın ironik yanı da buradan geliyor.
Bir Fonksiyon Olarak “Blockchain Oracles”
Blockchain bakış açısında aynı giriş parametresi ile aynı değer kümelerini döndürebilmek olması gereken bir durumdur. Çünkü bu deterministik bir fonksiyona sahip olduğumuz anlamına gelir.
f(t0) = Fact + Proof(fact)
Yukarıda gördüğünüz fonksiyon bir “Blockchain Oracle” ının nasıl bir fonksiyon olması gerektiğini göstermektedir
(t0): Zamana bağlı giriş parametresi(Input).
Fact: t0 zamanında bir fact(gerçek) her zaman aynı tutarlı sonucu verir.
Proof(fact): Proof, gerçekliğin(Fact) bir otorite tarafından onaylandığının ve doğru olduğunun delilidir.
Özet olarak “Blockchain Oracles”ın dış dünyadan çekeceğimiz verilerin bir Blockchain ağında güvenli bir şekilde kullanılmasını sağlayan aracı görevi gören güvenilir adaptörler söylemek yanlış olmaz.
Hyperledger Fabric İçerisinde “Oracle” Kullanımı
Evrensel bir Kanal(Channel) oluşturarak, bir data kaynağı(data source) görevi görecek organizasyon yaratmak
HLF’de ilk akla gelen çözüm olarak, bütün tarafların dahil olduğu ve üzerinde koşan (“Oracle” için özel yaratılmış update ve query işlemlerini yapan smart contract) akıllı kontratlar bulunan bir kanal aracılığı ile işlemlerin yapılması ön plana çıkıyor. Burada veri kaynağını kontrol edecek bir organizasyon yaratılarak harici kaynaklardan (api,web service vs.) veriyi çeken akıllı kontrat ile ilgili işlemlerin onaylanması ve imzalanması süreci yürütülüyor.
Bu çözümde veri kaynağını yönetmek için oluşturacağımız organizasyon içerisindeki taraflar yalnızca UPDATE işlemi yapabiliyor. Diğer organizasyonlar ise bu update edilen veriyi yalnızca QUERY fonksiyonunu çalıştırarak onaylayıp, okuyabiliyorlar. (Desrosiers, Olivieri, 2019)
Daha önce anlattığımız fonksiyonu baz alarak yeniden büyük resme dönecek olursak.
f(t0) = Fact + Proof(fact)
Bu çözümde t0 giriş parametresi ledger(defter) de key olarak saklanıyor. Daha sonra facts ise bu anahtar-değer ikilisi(t0-facts) değeri(value) kapsayacak şekilde yine defterde saklanıyor. Fact(gerçek) kanıtı olan proof ise ağ içerisinde oluşan işlem-transaction(tx) olarak karşımıza çıkıyor.
Bu Çözümün Olası Sorunları
Giriş parametresi olarak çekilen değerlerin tamamının ledger(defter)de saklanamaması durumu. Örnekleyecek olursak stok piyasalarda , stock price dediğimiz (tick value, yani t0 zamanında değerli kağıdın anlık değerini gösteren değer)’in belli bir zaman aralığı içerisinde verisinin defterde kaydedilememesi ve buna bağlı olarak tutarsızlıkların yaşanabilmesi durumunu örnek gösterebiliriz.
Çözüm olarak:
- Ağdaki taraflarında onayladığı bir ön tanımlı model ile verilerin belli aralıklarla (REST-request e benzer bir şekilde olabilir) ile data kaynağı olan organizasyona doğru verinin çekilmesi için istekte bulunulması, bundan sonra da dış kaynaklardan veri çeken bu organizasyonun ise veriyi tekrar alıp UPDATE işlemini aralıklarla yapması bu sorunu aşmak için bir çözüm yolu olabilir.
Örneğe dair ek bilgi: Finansal piyasalarda özellikle future-contract işlemlerinde tick-value denilen değiş tokuş edilen kıymetlerin en ufak değerini belirten bir değer vardır. Yapılan her tick hareketi parasal olarak bir değere işaret eder ve yatırımcının kar-zarar dengesini kurmasına olanak sağlar. Kıymetin t0 anındaki değerinin belirlenmesi ve doğru olması bu açıdan çok önemlidir.
Bankalar ve Merkez Bankası Örneği
Daha önceki makalemde de işlediğim konuya yakın bir case üzerinden “Blockchain Oracles” sorunsalını biraz daha açmak ve Hyperledger Fabric 1.4 sürümünden itibaren artık kullanabileceğimiz bir çözüm olan “Convector Suite” den de bu vesileyle bahsetmek istiyorum.
- A Bankası, B Bankası, C Bankasının dahil olduğu bir çok organizasyonlu bir HLF ağı düşünelim.
- A bankası TCMB(Türkiye Cumhuriyeti Merkez Bankası)’den veri çekerek akıllı kontrata bu veriyi giriş parametresi olarak gönderip ağda işlem başlatıyor olsun.
- A, B ve C bankaları da bu akıllı kontratı(chaincode) kendi taraflarında çalıştırıp, endorse(onaylama) ve diğer işlemleri yürüterek sürece dahil olsun.
- Ve her bir taraf kendi tarafında çalıştırdığı bu akıllı kontrat aracılığı ile TCMB’nin verdiği harici API kaynağından veri çekiyor olsun.
Sonuç olarak veriyi çektiklerinde t0 zamanında aşağıdaki sonuçları almaları olası olacaktır.
A Bankası = “1”
B Bankası = “1”
C Bankası = “2”
Yani aldıkları bu sonuçlarla Blockchain ağında işlem yapmaya kalktıklarında veri tutarsızlığı nedeniyle işlemler başarısız olacaktır.
İşte bu sonuç daha önce de bahsettiğimiz dış kaynaklarda(API, WS) çekilen bir çok verinin non-deteministik olması fakat Blockchain ağlarının mutlak deterministik bir yapıda işlemler yapmasından kaynaklanmaktadır.
Eğer TCMB’yi de bu ağa bir organizasyon olarak dahil eder ve TCMB’nin ağ içerisinde sunduğu ve deftere kaydettiği veriyi referans alarak diğer bankaların işlem yapmasını sağlarsak bu soruna bir nevi çözüm üretmiş oluruz aynen bir önceki konu başlığında anlattığımız gibi burada da ilginç bir çıkmazla daha karşılaşma durumumuz olabilir.
Bu durumda şu:
Bu çözümde TCMB’nin çektiği veri tarafların ihtiyaç duyduğu anda değil önceden ağa kaydedilmektedir. Bu durumda bazı caselerde ve anlık veri çekmek zorunda olduğumuz (on demand off-chain data) diye tabir edilen durumlarda bu çözümün yetersiz kalması kesindir. Bu tip durumları aşmak için ise “Blockchain Oracles” lara kesin olarak ihtiyaç duyuyoruz.
Hyperledger Fabric için Convector Suite Çözümü
Convector Suite 2019 yılında bir start-up firmanın HLF ile ilgili geliştirmeler yaparken üretmeye başladığı son olarakta şu repodaki duruma getirdiği bir çözüm.
Convector Suites kullanırken 3 ana bileşene sahip olmamız gerekiyor.
- Akıllı Kontratımız.
- Bir oracle daemon ( zincirden gelen istekleri dinleyen harici web server).*
- Harici veri kaynağı(API , WS gibi).
Adımlar
1- Harici bir dataya ihtiyaç duyduğumuza dair transaction(işlemin) sunulması.
2- Daha sonra akıllı kontratımız(chaincode) oracle daemon aracılığı ile dış kaynaktan veri çekilme ihtiyacını istek olarak iletir fakat bu istekten sonra hemen response dönmesini beklemez.(async)
3- Bu işlemle(tx) ilgili consensus sağlandığında akıllı kontrat kullanıcılara işlemin başarılı olduğuna dair mesajı döner.
4- Harici API, Oracle’ın yaptığı isteğe cevap verir.
5- Oracle Daemon(aslında artık bu adımda dış dünya verileri ile Blockchain ağımız arasında güvenli veri alışverişi yapmamızı sağlayan bir adaptör olarak düşünebiliriz) aldığı istek ile beraber akıllı kontrat içerisindeki callback() fonksiyonunu çalıştırır.
6- Daha sonra da akıllı kontrat dış kaynaktan aldığı veri(input data (t0)) ile işlemleri devam ettirecek fonksiyonu tetikler.
Genel olarak işlem akışı bu yönde oluşuyor. Umarım makale “Blockchain Oracles” konusuna ve projelerimizde büyük resmi kaçırmadan tasarımlar yapmamıza yardımcı olacak bilgileri size az da olsa sağlamıştır.
Bir sonraki makalede Convector Suite kullanarak teknik bir örnek yapmayı düşünüyorum.
Herkese iyi çalışmalar :)
Kaynakça
1- Oracles: Common architectural patterns for Hyperledger Fabric, IBM, L. Desrosiers, R.Olivieri, 11 Mart 2019
