Blockchain Ağlarında Bizans Generalleri Sorunu: İstanbul Bizans Hata Toleransı
Doğu Roma imparatorluğu olarakta anılan Bizans İmparatorluğu denince akla ilk olarak İstanbul geliyor. Günümüzde Blockchain teknolojilerinin merkezinde ise 1982 yılında Leslie Lamport, Robert Shostak ve Marshall Pease’in yazdıkları bir makalede ilk kez konu edinilen Bizans Generalleri Problemi durmaktadır. Aslında şu an piyasada dolaşan bir çok proje bu Bizans Problemine daha iyi çözümler sunduğunu iddaa ettikleri için yaratılmıştır. Blockchain dünyasında Bizans Generalleri Probleminin çözümü olarak tasarlanan algoritmaların genel ismine Consensus mekanizmaları denmektedir. Consensus ismi ise Bizans Generalleri Probleminin ne olduğunun içinde saklıdır.
Bir grup Bizans generali çevreledikleri bir kaleyi ele geçirmek istemektedirler. Başarılı olmak için hepsi aynı anda hücum etmelidir. Ama aralarında hainler vardır. Problem şu; içlerinde varolan bilinmeyen bir kötü aktörle/hainle başarılı bir saldırı başlatmaları gerekiyor. Bu nasıl olacak?
Merkezi bir otorite olmaksızın networkteki herkesin ortak bir uzlaşıya varma ihtiyacı, kötü niyetli katılımcılara karşı doğru uzlaşının sağlanabilmesi ve hata durumlarında sistemin kendi kendini tolere edebilmesi için bu problemin etkin bir şekilde çözülmesi gerekmektedir. Bu sorunun çözümü Consensus Mekanizmaları sayesinde mümkün kılınmaktadır.
Dağıtık sistemler de birçok consensus mekanizması hali hazırda denenmektedir. Bitcoin, Ethereum gibi Public Blockchain ağları Proof Of Work denilen madencilik yapısı ile işleyen bir consensus mekanizması sayesinde nodelar arasındaki iletişimin güvenliğini sağlamaktadır.
Public Blockchain Ağları
Private Blockchain Ağları
Private Blockchain çözümlerinde ise durum biraz daha farklıdır. Özel olan bu ağlarda Proof Of Work yapısının getirdiği elektrik tüketimi gibi dezavantajların üstesinden gelebilmek adına farklı yöntemler denenmektedir. Bu yöntemlerin en çok bilinenleri PBFT(Practical Byzantine Fault Tolerance)’dır.
PBFT hakkında Miguel Castro and Barbara Liskov tarafından 1999 yılında yazılan makale: PBFT
Hyperledger Fabric Blockchain çözümü içerisinde de kullanılan Crash Fault Tolerance, Quorum tarafında Raft Consensus yapısının karşılığıdır. Bu yapılar nodeların hataya düşmesi üzerine kurulu Consensus yapılarıdır ve Bizans Hata toleransını içermezler. Bunun yanında Hyperledger Fabric içerisinde entegrasyonu devam eden PBFT consensus mekanizması ise Quorum tarafında IBFT(İstanbul Bizans Hata Toleransına) eşdeğer niteliktedir.
İstanbul Bizans Hata Toleransı
İstanbul Bizans Hata Toleransı, Practical Byzantine Fault Tolerance’ın modifiye edilmiş bir versiyonudur. JP Morgan’ın geliştirdiği Ethereum tabanlı Private Blockchain çözümü olan Quorum tarafından kullanılmaktadır.
Düğümlerin çoğunluğunun zamanın herhangi bir noktasında doğru olduğu varsayılarak, güvenilmeyen yani zararlı olması muhtemel nodeların da network içerisinde konumlanmasına izin verebilen bir yapıdadır.
IBFT’de ki en önemli şey her bloğun karşılıklı bir anlaşmaya varmak için birden fazla oy kullanma zorunluluğudur. Node’ların hataya düşme olasılığını düşünerek kurgulanan Crash Fault Tolerance gibi yapılar liderin doğru ya da dürüst olduğunu asla varsaymaz(bu yapılar bizans hata toleransını içermezler) Bunun yerine Bizans hata toleransını içeren yapılar , önerilen blokları diğer consensus yapılarında olduğu gibi doğrulayarak işlem yaparlar.(Proof Of Work, vb.).
Projelerde uygulanacak Consensus mekanizmalarını seçerken nodeların(tarafların) özelliklerini iyi analiz etmek gerekir. Mesela IBFT yalnızca nodelar arasında güvenilmeyen aktörlerin olabilme ihtimali var ise ve her zaman onay mekanizmasının güvenilir bir şekilde işlemesi zorunlu ise kullanılmalıdır. Bu ihtiyacın olmadığı durumlarda Crash Fault Tolerance gibi Bizans hata toleransını içeremeyen yapılar da kullanılabilir.
Örnek bir İstanbul Bizans Hata Toleransı Bloğu
> eth.getBlock(2001){difficulty: 1,extraData: “0xd783010702846765746887676f312e372e33856c696e75780000000000000000f89ed594abbcf2086d69783e7c7bd88193860da082ac5a6fb84131cd6969c6eddd7cef61ce42c881566966922ebf530868b8769db1cb2742031a6045ee9dd1857a04654c672bdd3a05d25435ec9caa98a2388ab2cd1c9e91dad900f843b841f829ba18c2d4a55da9b62179f25488ae7205069e79d94cbf2da3b9ecb62746e50620c1ac308b01e0f23d85de147ec25826e8a03560b8efb068fd08894f8d8b5701”,gasLimit: 113962254,gasUsed: 278693,hash: “0x65f173061375a984adc24edec314262f2c47d91ed026d11b0654ecb40747b497”,logsBloom: “0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000”,miner: “0x0000000000000000000000000000000000000000”,mixHash: “0x63746963616c2062797a616e74696e65206661756c7420746f6c6572616e6365”,nonce: “0x0000000000000000”,number: 2001,parentHash: “0xfb307e7034bcf9553308afaf876991e0a6510ccdb4ac9ed5a918475cf7f9e269”,receiptsRoot: “0x1ccca06221387a6e390167e39e1f08647686fe4150891fce5e5073a40d1dced4”,sha3Uncles: “0x1dcc4de8dec75d7aab85b567b6ccd41ad312451b948a7413f0a142fd40d49347”,size: 2708,stateRoot: “0xf0e5b4667d71b8505be207177df97e65a763aa09174da5c28350df279ed519f5”,timestamp: 1521830564,totalDifficulty: 2002,transactions: [“0x7b031bda65dc52d2940ba221d81c3d4287bcc00b41f63693d60828f2fffdb15a”, “0x91da07e8f350b55d1411dbf25ce8c4f675be494c2be73891c562265413d82b15”],transactionsRoot: “0x67e1cd0b9f6bd9973b11c5891a5b9711862191e9571b9b38f7b1eb1ea82b49bc”,uncles: []}
Detaylı Bilgi İçin: https://github.com/ethereum/EIPs/issues/650
