Hyperledger Mimarisi — Bölüm 1

Hyperledger İşletmeler İçin Blok Zincir Tasarım Felsefesi Ve Consensus Mekanizmaları

Bu döküman, Hyperledger Mimari Çalışma Grubu(MG)’nun yayınladığı makalelerin ilkidir. İzinli blok zinciri ağları için genelleştirilmiş ve referans alınabilecek mimariyi yapısını tanımlarken tüm Hyperledger projelerini modüler ve bütünlük arz eden tasarımlara yönlendirmek amacıyla Mimari Çalışma Grubu’nun önerilerine yer verir. Bu raporlar ayrıca, blok zinciri kullanıcıları ve izinli ağlar üzerinde çalışan geliştiriciler için ürün geliştirme açısından tarafsız bir kaynak görevi görür.

Bu ilk makalede, şunları hedefliyoruz:

1. İzin verilen blok zinciri ağları için genel Hyperledger tasarım felsefesini ana hatlarıyla açıklamak.
2. Yaklaşımımızın esnek ve birlikte çalışabilir kurumsal blok zinciri projelerinin geliştirilmesini nasıl optimize ettiğine değinmek.
3. Mimari Çalışma Grubu MG’nin çalışmaları boyunca tanımlamaya çalıştığı ve çalışacağı izin verilen blok zinciri temel ağ bileşenlerini vurgulamak.
4. Consensus için genelleştirilmiş bir referans mimarisi sağlamak.
5. Hyperledger üzerinde geliştirilen kurumsal blok zincir çözümlerinde kullanılan tüm yapıların genellikle kullandığı mimarilere ve bu mimarilerin farklarına değinmek.

Bu konudaki makale dizisi, Hyperledger ile geliştirilen işletmeler için blok zincir çözümlerinde sıklıkla kullanılan bileşen katmanlarının referans mimarisini açıklama amacı taşımaktadır. Bu bileşenler:

Akıllı Sözleşme Katmanı, İletişim Katmanı, Veri Deposu Soyutlama, Kripto Soyutlama, Kimlik Hizmetleri, Politika Servisleri, API’ler ve Birlikte Çalışma.

Hyperledger Modüler Şemsiye Yaklaşımı

Hyperledger Mimari Çalışma Grubu Hakkında

Hyperledger Mimari Grubu(MG), fikir alışverişinde bulunmak ve alternatif mimari seçenekleri ile değişimleri keşfetmek için Hyperledger topluluğundan sistem tasarımcıları ve geliştiricilerin birlikte çalıştığı çapraz bir forum görevindedir.

Odak noktaları, kurumsal sınıfta oluşturulan dağıtılan defterler için modüler bir mimari yapı geliştirmektir. Bu amaç, ortak ve kritik bileşenleri tanımlamayı, bir işletme blok zinciri çözümünde kullanılan bileşen katmanlarının ve modüllerinin işlevsel bir şekilde ayrılmasını, bileşenler arasındaki ara yüzleri standartlaştırmayı ve defterler arasında birlikte çalışabilirliği sağlamayı gerektirir.

Giriş

İşletme için blok zinciri gereksinimleri değişiklik gösterir. Bazı kullanımlar, hızlı ağ consensus sistemlere ve zincire eklenmeden önce blok onay süresinin kısa olmasına ihtiyaç duyar. Bazense güvenlik daha önceliklidir; bu sebeple işlem onay süreçlerinin kısmen daha gecikmeli olması sorun teşkil etmez. Ölçeklenebilirlik, gizlilik, uyumluluk, iş akışı karmaşıklığı ve hatta güvenlik gereksinimleri endüstriler ve kullanımlar arasında büyük ölçüde farklılık gösterir. Bu gereksinimlerin her biri bu teknoloji için potansiyel olarak benzersiz bir optimizasyon gerekliliği doğurur.

Doğabilecek sorunları öngören Hyperledger; dağıtılmış defterler, akıllı sözleşme sistemleri, müşteri kütüphaneleri, grafik arayüzler, yardımcı program kütüphaneleri dahil olmak üzere bir dizi işletme bloğu teknolojisinin geliştirilmesine ev sahipliği eder ve topluluğu teşvik eder. Hyperledger’ın şemsiye stratejisi, ortak yapı taşlarının modüler bir mimari çerçeveyle yeniden kullanılmasını desteklemektedir. Bu, dağıtılmış muhasebe teknolojisinin (DLT), ortak fonksiyonel modüllerin ve aralarındaki arabirimlerin hızlı bir şekilde entegrasyonunu sağlar. Modüler yaklaşımın avantajları, genişletilebilirliği, esnekliği ve sistemin geri kalanını etkilemeden herhangi bir bileşenin bağımsız olarak değiştirilebilme özgürlüğü tanımasıdır.

Mimariye Genel Bakış

Tüm Hyperledger projeleri, modüler, genişletilebilir yaklaşıma uygun, birlikte çalışabilen, yüksek güvenlikli çözümlere vurgu yapan, özgün bir şifreleme ile token-agnostik bir yaklaşım benimsemiş, API destekli, zengin ve kullanımı kolay, uygulamalara ortam sağlayan bir tasarım felsefesini izler.

Hyperledger Mimari Grubu, işletmeler için blok zincir çözümlerinde kullanılan ortak bileşenleri tespit etmiştir:

• Consensus Katmanı — Ağdaki katılımcılar arasında bir anlaşma sağlamaktan ve bir blok oluşturan işlem setinin doğruluğunu onaylamaktan sorumludur.
• Akıllı Sözleşme Katmanı — İşlem takiplerini ve süreç yönetimini gerçekleştirirken sistemdeki hareketliliğin iş tanıma uygun olmadığını kontrol eder.
• İletişim Katmanı — Paylaşılan bir defter örneğine katılan düğümler arasında ileti aktarımından sorumludur
• Veri Deposu Özeti — Farklı veri depolarının diğer modüller tarafından kullanılmasına izin verir.
• Kripto Soyutlama — Farklı kripto algoritmalarının veya modüllerinin diğer modülleri etkilemeden değiştirilmesine izin verir
• Kimlik Servisleri — Bir blok zincir çözümünün kurulumu sırasında bir güven kökünün kurulmasını, ağ işlemi sırasında kimliklerin veya sistem varlıklarının kaydedilmesini ve taşınmasını sağlar. Ekleme, değiştirme ve iptal gibi işlemlerin yönetiminden sorumludur. Ayrıca, kimlik doğrulama ve yetkilendirme sağlar.
• Politika Hizmetleri — Onay politikası, consensus politikası veya grup yönetimi politikası gibi sistemde belirtilen çeşitli politikaların yönetiminden sorumludur. Çeşitli politikaları uygulamak için arayüzlere bağlanır ve diğer modüllerden yararlanır.
• API’ler — Uygulamaların blok zincirle arayüzlenmesini sağlayarak bir uygulamadan diğerine ulaşan köprüler oluşturur.
• Birlikte Çalışma — Farklı blok zinciri örnekleri arasındaki işbirliğini destekler. Bu belgede, fikir birliğini de keşfedeceğiz. Consensus’un amacı, ağda bir anlaşma oluşturmak ve bloğu oluşturan işlem kümesinin doğruluğunu onaylamaktır.

Consensus Mekanizması

Consensus, bir ağda gerçekleşen işlemlerin ağ katılımcıları veya merkezi karar mekanizması tarafından onaylandığı süreçtir. Mutabakat anlamına gelen Consensus aşağıdaki temel işlevlere sahiptir:

• Onay ve mutabakat politikalarına göre önerilen bir bloktaki tüm işlemlerin doğruluğunu onaylar.
• Yapının düzeni ve doğruluğunun gerektiği gibi işlediğinden emin olur(uygulama genelinde etkilidir.).
• Bir blokta gerçekleşen işlem kümesinin doğruluğunu onaylamak için akıllı sözleşme katmanı ile birlikte çalışır.

Consensus Türlerinin Karşılaştırılması

Consensus, Geçen Zaman Kanıtı (PoET) gibi rastgele seçim tabanlı olabileceği gibi ve İş Kanıtı (PoW) gibi Bizans Hata Toleransı(BHT) temelli oylamaya dayalı bir yöntemle de sağlanabilir. Bu yaklaşımların her biri farklı ağ gereksinimlerini ve hata tolerans modellerini hedeflemektedir.

Rastgele seçim tabanlı algoritmalar, rastgele kazananın bir blok onaylaması ve onayladığı bloğu diğer ağ katılımcılarına iletmesi ile çok sayıda düğüme ölçeklenebilmesi bakımından avantajlıdır. Öte yandan, bu algoritmalar iki “kazanan” aynı anda bir blok önerdiğinde çatallaşmaya neden olabilir. Zincirdeki her bir çatalın çözümlenmesi gerektiğinden onay süresi kimi zaman uzun sürebilir.

Oylama tabanlı algoritmalar daha düşük gecikmeli gerçekleşme oranları bakımından avantajlıdır. Düğümlerin çoğu bir işlemi veya bloğu doğrularsa, fikir birliği olur ve kesinlik oluşur. Oylama tabanlı algoritmalar tipik olarak düğümlerin ağdaki diğer düğümlerin her birine iletiler göndermesini gerektirdiğinden, ağda ne kadar çok düğüm varsa, fikir birliğine varmak o kadar uzun sürer. Bu, ölçeklenebilirlik ve hız arasında bir denge kurulmasına yol açar.

Hyperledger geliştiricileri çözümler işletme ekseninde gerçekleştiğinden genel varsayım blok zinciri ağlarının kısmi güven ortamında çalışacağı yönündedir. Bunu göz önüne aldığımızda, anonim madencilerle standart iş kanıtı (PoW) yaklaşımlarını benimsemediğimizi açıkça belirtmemiz gerekiyor. Değerlendirmemizde, bu mekanizmaya yer vermenin işletmeler için blok zinciri ağları geliştirme sürecinde çok maliyetli ve kaynak tüketen bir yöntem olacağı açıkça anlaşılıyor.

Tablo 1, işletmeler için blok zinciri çözümlerinde consensus mekanizmalarının artılarını ve eksilerini gözler önüne sermektedir.

Tablo 1: İzinli Blok Zincir Ağlarında Kullanılan Consensus Mekanizmaları vs İş Kanıtı(PoW)

Şekil 1: Hyperledger Genel Consensus Süreç Akışı

Consensus ve Diğer Mimari Katmanlarla Etkileşimi

Consensus mekanizmasının farklı şekilde tasarlanabileceği birçok yol varken, blok zincir platformları üzerindeki analizimiz, Şekil 1'de gösterilen sürecin yaygın olarak kullanıldığını göstermektedir. Bu elbette genel bir görünümdür ve farklı Hyperledger yapıları/projeleri bu adımları farklı şekilde uygulamayı seçebilirler.

Hyperledger işletme çözümleri için kullanılan blok zincir yapıları, iki ayrı adım gerçekleştirerek fikir birliğine varır:

1. İşlemlerin sıralanması
2. İşlemlerin doğrulanması

Bu işlemleri mantıksal olarak ayırarak, herhangi bir Hyperledger yapısının herhangi bir Hyperledger consensus modülü ile çalışmasını sağlayabiliriz.

Consensus süreç akışının ilk adımı, işlemleri müşterinin uygulamasından almaktır. Consensus, emir işlemleri için sipariş servisine bağlıdır. Emir hizmeti; geliştirme ve testte kullanılabilecek merkezi bir hizmetten farklı ağ ve düğüm modellerini hedefleyen dağıtılmış protokollere kadar çok farklı şekillerde uygulanabilir. İşlemlerin gizliliğini sağlamak için, emir servisi işlem için geçerli olmayabilir; yani, işlem içeriği karma veya şifreli olabilir.

İşlemler, emir servisine bir arayüz yoluyla gönderilir. Bu hizmet, bir zaman sınırı tanımlayabilen veya izin verilen işlem sayısını belirleyebilen uzlaşma algoritması ve yapılandırma politikasına dayalı işlemleri barındırır. Verimlilik nedeniyle, çoğu zaman bireysel işlemler yapmak yerine, emir verme servisi birden fazla işlemi tek bir blokta gruplayacaktır. Bu durumda, emir hizmeti her bloktaki işlemlerin deterministik bir sıralamasını vermeli ve karşıya o şekilde iletmelidir.

İşlemleri doğrulamak için kurgulanan mutabakat protokolü geçerli iş mantığı ile örtüşmekte ve akıllı sözleşme katmanına bağlı çalışmaktadır. Akıllı sözleşme katmanı, genel politika ve işlem için belirtilen sözleşmeye uyan her işlemi doğrular. Geçersiz işlemler reddedilir ve bir bloğun içerisine dahil edilmez. Potansiyel doğrulama hatalarını iki kategoriye ayırabiliriz: sözdizimi ve mantık hataları. Geçersiz girişler, doğrulanamayan imza ve yinelenen işlem (hata veya tekrarlama saldırıları nedeniyle) gibi sözdizimi hataları için işlem iptal edilmelidir. İkinci hata kategorisi daha karmaşıktır ve işlemin bu hata sonucu onaylanıp onaylanmaması işletme politikasına dayalı olmalıdır. Örneğin, çifte harcama veya sürüm kontrolünün başarısız olmasına yol açacak bir işlem, düşünelim. Sonraki denetim faaliyetleri için bu işlemleri günlüğe kaydetmek isteyebiliriz.

Consensus katmanı, müşteri ve ağdaki diğer meslektaşlarla iletişim kurmak için iletişim katmanını kullanır.

Consensus Özellikleri

Consensus, düğümler arasında anlaşmayı garanti etmek için iki özelliği yerine getirmelidir: güvenlik ve canlılık.

Güven, her bir düğümün aynı girdi dizisini ile aynı sonuçlara ulaşması ve temelde aynı bilgilere sahip olması anlamına gelir. Düğümler aynı işlem serisini aldığında, her düğümde aynı durum değişiklikler meydana gelir. Algoritma burada her bir işlemi bir seferde atomik olarak gerçekleştiren tek bir düğüm sistemi ile aynı şekilde hareket etmelidir.

Canlılık ise, hatalı olmayan her düğümün, iletişimin başarısız olamayacağı her durumda gönderilen her işlemin sonuçlanacağı anlamına gelmektedir.

Hyperledger Yapılarında Consensus Mekanizmaları

İş blok zinciri gereklilikleri sürekli değişeceğinden, Hyperledger topluluğu, modülerliği sağlamak için uygulama yaklaşımlarının yanı sıra çeşitli farklı consensus mekanizmaları üzerinde de çalışmaktadır.

Tablo 2, Hyperledger yapıları arasında kullanılan consensus algoritmalarının karşılaştırmasını sunmaktadır. Hyperledger Fabric’deki Apache Kafka, Hyperledger Indy’deki BHT ve Hyperledger Iroha’daki Sumeragi, saniyeler içinde hata toleransı ve kesinliği sağlayan oy birliğine dayanan bir yaklaşım kullanır. Hyperledger Sawtooth’taki PoET ise uygulamalara ölçeklenebilirlik sağlarken çatallanma olasılıkları nedeniyle gecikmelere de sebep olabilmektedir.

Hyperledger Fabric’teki Consensus

Hyperledger Fabric’teki kullanılan consensus mekanizması, 3 aşamaya ayrılmıştır: Onay, Emir ve Doğrulama.

• Onay, katılımcıların bir işlemi onayladığı politika(n tane imza arasından m tane) ile tanımı kapsamında gerçekleştirilir.
• Emir aşaması, onaylanan işlemleri kabul eder ve deftere taahhüt edilmek doğrulamaya gönderir.
• Doğrulama, emri verilen işlemlerin bir bloğunu alır; önceki aşamaların sağlıklı gerçekleştiğinden ve çift-harcama hatasının bulunmadığından emin olur.

Şekil 2: Hyperledger Fabric’te Olası İşlem Akışı

Hyperledger Fabric, yukarıdaki 3 fazın tümü için isteğe göre eklenebilen consensus model yapısını destekler. Uygulamalar, gereksinimlerine bağlı olarak farklı onay, emir ve doğrulama yöntemlerini kullanabilir. Özellikle, emir servisi API’si BHT-bazlı anlaşma algoritmalarında eklentiye izin verir.

Emir hizmeti API’si iki temel işlemden oluşur: yayın ve teslim.

• Yayın (blob): Kullanıcı uygulamayı kanal üzerinden yaymak için rastgele bir mesaj blobunu yayınlamaya çalışır. Buna, bir hizmete bir istek gönderilirken, BFT bağlamında istek (blob) göndermek de denir.
• Teslim (seqno, prevhash, blob): Emir verme servisi ifade bloğunu belirtilen mesajla birlikte iletmek için negatif olmayan bir tamsayı sıra numarasını(seqno) ve en son gönderilen blobun karmasını(prevhash) çağırır. Başka bir deyişle deliver (), emir hizmetinden bir çıktı olayıdır. Aynı işlem bazen pub-sub sistemlerinde notify () veya BTH sistemlerinde notify() olarak da adlandırılır.

BHT Akıllı, Basitleştirilmiş Bizans Arıza Toleransı (BBHT), BHT Honey Badger, vb. Fabric v1 için, Apache Kafka referans uygulaması olarak kullanıma sunulmuştur. Uygulama kullanım durumları ve hata toleransı modeli, hangi eklentinin kullanılacağını belirlemelidir.

Hyperledger Indy’deki Consensus

Hyperledger Indy’deki consensus, Plenum Bizans Hata Toleransından (Plenum) esinlenen bir protokol olan Yedekli Bizans Hata Toleransına (YBHT) dayanır. YBHT’yi birkaç Plenum örneğini paralel olarak çalıştırdığını düşünün. Aslında tek bir örnekten emir verilen talepler, defteri güncellemek için kullanılır, ancak asıl işlemin gecikme ve veri akışı açısından performansı, diğer örneklerin ortalama performansıyla belirli aralıklarla karşılaştırılır.

Master’ın bozulmuş olduğu tespit edilirse, master rolüne farklı bir örnek atayan bir görünüm değişikliği gerçekleşir. PBFT gibi, YBHT de hatalı düğümleri işlemek için en az 3f + 1 düğüme ihtiyaç duyulur. Şekil 3, 1 hatalı düğümü kaldırabilen, çalışan 2 YBHT benzeri örneğe, bir ana ve bir yedeğe sahip olan 4 düğümden oluşan bir ağı göstermektedir. Her düğüm bir birincil (lider) örneği barındırabilir.

Şekil 3: YBHT’a Bir Bakış

Şekil 4, YBHT’nin farklı bir görünüşünü gösterir. Burada müşteri düğümlere bir istek gönderiyor. Bu isteğin tüm düğümlere gönderilmesi gerekmiyor, çünkü f + 1 düğümlere göndermesi yeterlidir. Müşteri talebini aldıktan sonra, düğümler, diğer tüm düğümlerin talebi bildiği PROPAGATE aracılığıyla bir yayılma işlemi yapar. Her birincil, PRE-PREPARE adlı alınan isteklerden bir teklif oluşturur ve diğer tüm düğümlere geri gönderir. Düğümler birincil teklifini kabul ederse, teklife PREPARE adlı bir mesajla bir onay gönderir. Bir düğüm bir PRE-PREPARE teklifi ve 2f PREPARE mesajı aldığında, teklifi kabul etmek için yeterli bilgiye sahip olunmuş olur ve bir KOMITE mesajı gönderilir. Bir düğüm 2f + 1 COMMIT mesajı aldığında, yeterli sayıda düğüm tekliflerin kabul edildiğine karar verdiğinden, yeterli sayıda düğüm kabul ettiği için talep grubu deftere eklenebilir. Birincil, bir sonraki teklifi göndermeden önce önceki bir teklifin tamamlanmasını gerektirmez.

Şekil 4: YBHT Protokol Aşamaları

Hyperledger Indy, hem emirleri hem de doğrulanmış işlemleri içeren tek bir defterdeki işlemlerini gerçekleştirmek için YBHT kullanır. Bu sistem, yalnızca emir için Bizans Hata Toleransı (BHT) protokolünü kullanan birçok blok zincir ağına benzemez. Bu ağlar, talepler emire dönüştükten sonra gerçekleşen etki alanına özgü bir doğrulama alanı yaratır.

Plenum ve bu nedenle YBHT, defterin durum denilen projeksiyonunu koruma görevindedir. Yapılan tüm geçerli, kabul edilen işlemler bir veritabanında değişkenler ve değerleri topluluğu olarak depolanan durumu değiştirebilir. Tüm bu süreçte veriler Ethereum tarafından belirtilen Merkle Patricia ağacı adı verilen ve kriptografik olarak onaylanmış bir veri yapısında tutulur.

Hyperledger Indy, Dağıtılmış Tanımlayıcıları (DID’ler), geçerli doğrulama anahtarı ve birkaç başka veri de dahil olmak üzere değerlerle durum değişkenleri olarak depolar. Defter işlemlerinin ve sonuçta ortaya çıkan durumun bellekteki kopyası teklif aşamasında otomatik olarak güncellenir. Birincil teklif gönderilirken, birincil olmayanlar geçerli bir teklif kabul edilirken yeniden güncellenir. Teklif emri verilir, daha sonra defter ve sonuçta ortaya çıkan durum taahhüt edilir. Teklif herhangi bir sebepten dolayı reddedilirse, defter ve sonuçta yapılan değişiklikler geri alınır.

Bu iyimser güncelleme, önceki teklifler tamamen emre dönüşmeden birden fazla teklifin mümkün olması için gereklidir. Örneğin, ilk teklif deftere yeni bir kimlik Id1 oluşturan bir istek içeriyorsa ve ikinci teklif Id1 için bir özellik ekleyen bir istek içeriyorsa, durum Id1'in varlığını yansıtmıyorsa, ikinci teklif reddetmiştir. Bu nedenle, ikinci teklif kabul edilmeden önce, ilk teklifteki değişiklikler görünür olmalıdır. Değişiklikler önerilmiş ancak henüz taahhüt edilmemişse, buna kabul edilmemiş bir değişiklik denir. Kaynak: (Aublin and Others, 2013)

Hyperledger Iroha’daki Consensus

Iroha, tüm BHT sistemlerinde olduğu gibi, bir ağdaki çok sayıda Bizans hatalı düğümünü tolere eden Sumeragi adında bir BHT consensus algoritması sunar.

Bu sistemi kurarken Duan, Meling, Peisert ve Zhang (2014) tarafından açıklanan B-Chain algoritmasından büyük ölçüde esinlenilmiştir. B-Chain’de akranları ve kümeleri A’dan B’ye alırken global bir düzen kavramı düşünürüz; A, ilk 2f + 1 eşlerinden ve B geri kalanından oluşur. Bir işlemi onaylamak için 2f + 1 imzaları gerektiğinden, normal durumda sadece 2f + 1 eşleri işlem doğrulamasında yer alır. Kalan akranlar, sadece A kümesindeki akranlarda hatalar bulunduğunda doğrulamaya katılır. 2f + 1 akran proxy kuyruğu olarak adlandırılır. Normal (başarısız) durumlar için işlem akışı, Şekil 5'teki gibi gösterilmektedir.

Şekil 5: Hyperledger Iroha’da Sumeragi ile normal bir işlem akışı

Tipik olarak bir son kullanıcı istemcisiyle arayüzlenecek olan bir API sunucusu olan müşteri, ilk önce öncü doğrulama eşine bir işlem gönderir. Bu lider daha sonra işlemi doğrular, sıraya koyar ve işlemi imzalar. Daha sonra bu işlemi kalan 2f + 1 değerine eşleri doğrulayarak yayınlar. İşlem düğümlerinin sırası hijiri adı verilen sunucu itibar sistemine dayanarak belirlenir. Hijiri, sunucuların güvenilirliğini üç faktöre göre hesaplar. İlk olarak, her sunucunun üyelik servisine kayıtlı olduğu süreye göre. İkincisi, her sunucu tarafından işlenen başarılı işlemlerin sayısına göre. Üçüncüsü, arızaların tespit edilip edilmediğine göre.

Hataları algılamak için her sunucu proxy kuyruğuna bir işlemi imzalayıp yayınladığında bir zamanlayıcı da ayarlar. Bir ara sunucuda bir arıza varsa ve zamanlayıcı kapanmadan önce bir cevap alınmazsa, sunucu işlemi ve imzasını proxy kuyruğundan sonra zincirdeki bir sonraki sunucuya yeniden yayınlar. Proxy kuyruğundaki bir başarısızlık durumu Şekil 6'da gösterilmektedir.

Sumeragi’deki Censensus, bireysel işlemlerde ve işlemin uygulanmasından kaynaklanan küresel durumda gerçekleştirilir. Doğrulayan bir eş ağ üzerinden bir işlem aldığında, aşağıdaki adımları sırayla gerçekleştirir:

1. İşlemin imzasını (veya çoklu imza işlemlerinde imzaları) doğrulama.
2. Varsa, işlemin içeriğini doğrulama. Örneğin, transfer işlemleri mükellef’in hesabını negatif olmayan bir bakiye ile bırakmalıdır.
3. İşlemi geçici olarak deftere uygulama. Bu, küresel devletin Merkle kökünün güncellenmesini içerir.
4. Güncellenen Merkle kökünü ve işlem içeriğinin karma değerini imzalama.
5. İşlemin sonlu bir sipariş listesi olan tasarıyı yayınlama.
6. Düğümleri birbirleriyle senkronize ederken, Merkle ağacının geçerli kısımlarını, kökler eşleşene kadar paylaştırma.

Hyperledger Sawtooth’taki Consensus

Hyperledger Sawtooth, hem piyango hem de oylama algoritmaları için ayarlanabilir bir consensus yapısı sağlar. Varsayılan olarak, Hyperledger Sawtooth, PoET adlı, piyango tabanlı, Nakamoto consensus algoritmasını kullanır. Bitcoin’in PoW’ında olduğu gibi, PoET de, Trusted Execution Environment (TEE) aracılığıyla sağlanan garantili bir bekleme süresine dayanan lider seçiminde bir çekiliş kullanılır (Sandell, Bowman ve Shah, 2016).

Verimli bir şekilde dağıtılmış fikir birliğine ulaşmak için, iyi bir piyango işlevi, Sandell ve ark. (2016) belgesine göre şu özellikleri barındırmalıdır:

• Adalet — Fonksiyon, lider seçimini mümkün olan en geniş katılımcı nüfusuna dağıtmalıdır
• Yatırım — Lider seçim sürecini kontrol etmenin maliyeti, bu süreçten kazanılan değerle orantılı olmalıdır
• Doğrulama — Göreceli olmalıdır. Tüm katılımcılar için liderin yasal olarak seçildiğini doğrulaması kolaydır.

Hyperledger Sawtooth’un şu anki uygulaması, Intel’in Software Guard Extensions (SGX) tarafından sağlanan bir TEE’ye dayanmaktadır. Bu, lider seçim sürecinin güvenliğini ve rastlantısallığını, en popüler “kanıt” algoritmalarının doğasında bulunan güç ve özel donanımın pahalı yatırım gerektirmeksizin elde edilmesini sağlar.

Her PoET onaylayıcısı(validator), liderlik iddiasında bulunmadan önce güvenilir bir fonksiyondan beklemek için rastgele bir zaman ister. Belirli bir işlem bloğu için en kısa bekleme süresine sahip validator lider olarak seçilir. “CreateTimer” işlevi, TEE tarafından yaratılmış olduğu garanti edilen bir işlem bloğu için bir zamanlayıcı oluşturur. “CheckTimer” işlevi zamanlayıcının TEE tarafından oluşturulduğunu doğrular ve zaman aşımına uğradıysa, validatörün liderlik rolünü talep etmeden önce tahsis edilen zamanı beklediğini doğrulamak için kullanılabilecek bir onaylama yaratır.

PoET seçim algoritması iyi bir piyango algoritması için kriterleri karşılamaktadır. Liderlik seçimini, diğer piyango algoritmaları tarafından sağlananlara benzer bir dağılımla, tüm onaylayıcı popülasyonu boyunca rastgele dağıtır. Seçim olasılığı, kaynakların TEE ile genel amaçlı işlemciler olduğu durumlarda, katkıda bulunan kaynaklarla orantılıdır. Yürütme onayı, sertifikanın TEE içinde oluşturulduğunu ve doğrulayıcının ayrılan süreyi beklediğini doğrulamak için bilgi sağlar. Ayrıca, katılım maliyetinin düşük olması, validatör popülasyonunun büyük olma olasılığını artırarak fikir birliği algoritmasının sağlamlığını arttırır.

Sonuç

Bu makele serisinin ilkinde, tüm Hyperledger projeleri tarafından kullanılan modüler mimari çerçeveyi tanıttık ve bu modüler çerçevede fikir birliğinin uygulanabileceği birden çok yolu araştırdık.

Önemli çıkarımlar şunlardır:

1. İzin verilen blok zinciri ağları için kapsamlı Hyperledger tasarım felsefesi, genişletilebilirliği ve esnekliği sağlayan modüler bir yaklaşım izlenmelidir. Bu modüler yaklaşımda, Hyperledger, ortak işlevsel bileşenleri ve bunlar arasındaki ara yüzleri tanımlarız; bu, sistemin geri kalanını etkilemeden herhangi bir bileşenin bağımsız olarak değiştirilmesine izin verilir.
2. Mimari Çalışma Grubu’nun, izin verilen blok zinciri ağları için aşağıdaki temel bileşenleri tanımlamak üzerine çalışmaktadır:

Consensus Katmanı, Akıllı Sözleşme Katmanı, İletişim Katmanı, Veri Mağazası Soyutlama, Kripto Soyutlama, Kimlik Hizmetleri, Politika Hizmetleri, API’ler ve Birlikte Çalışma.

3. Mimari Çalışma Grubu, herhangi bir Hyperledger projesi tarafından kullanılabilecek bir fikir birliği için genelleştirilmiş bir referans mimarisini paylaşma amacı taşımaktadır.

4. Hyperledger Fabric, Hyperledger Indy, Hyperledger Iroha ve Hyperledger Sawtooth’un her biri için referans mimarisi prensipleri yapı ile uygun şekilde tasarlan mıştır.Bu çerçevelerle yaygın olarak kullanılan fikir birliği algoritmalarının karşılaştırılması, Kafka, YBHT, Sumeragi ve PoET dahil olmak üzere algoritmaların güçlü ve zayıf yönlerini hızlı bir şekilde belirlemek için Tablo 1 hazırlanmıştır.

Bu serideki yeni makaleler Hyperledger genelleştirilmiş referans mimarisini, izin verilen blok zinciri ağları için tüm temel bileşenleri kapsayacak şekilde genişletecektir. Serideki bir sonraki kağıt Akıllı Sözleşme Katmanını kapsayacaktır. Hyperledger’ın Mimarlık çalışma grubuna katılmak istiyorsanız, lütfen daha fazla bilgi için Wiki sayfasını ziyaret edin.

Referanslar

Aublin, P., Mokhtar, S.B., & Quéma, V. (2013). RBFT: Redundant Byzantine Fault Tolerance.

Distributed Computing Systems (ICDCS), 2013 IEEE 33rd International Conference on, pp. 297–306. doi:10.1109/ICDCS.2013.53 or http://dx.doi.org/10.1109/ICDCS.2013.53

Cachin, C., & Vukolić, M. (July 7, 2017). Blockchain Consensus Protocols in the Wild. IBM

Research — Zurich. arXiv:1707.01873 or https://arxiv.org/abs/1707.01873v2

Duan S., Meling H., Peisert S., & Zhang H. (2014). BChain: Byzantine Replication with High

Throughput and Embedded Reconfiguration. In: Aguilera M.K., Querzoni L., & Shapiro M. (eds) Principles of Distributed Systems. OPODIS 2014. Lecture Notes in Computer Science,vol 8878, pp. 91–106. Springer, Cham. doi:10.1007/978–3–319–14472–6_7 or http://dx.doi.

org/10.1007/978–3–319–14472–6_7 Kafka 0.11.0 Documentation.

(2017). Retrieved from https://kafka.apache.org/documentation/Plenum Byzantine Fault Tolerant Protocol.

(2016). Retrieved from https://github.com/hyperledger/indy-plenum/wiki

Sandell, P., Bowman, M., & Shah, P.(2016). Blockchain and Its Emerging Role in

Healthcare Related Research. Intel Corporation — Health and Life Sciences Group. https://oncprojectracking.healthit.gov/wiki/download/attachments/14582699/19-Blockchain_Whitepaper_Intel_Final.pdf

Struckhoff, Roger. The Iroha Project to Bring Mobility to Blockchain with Simple APIs.(December 22, 2016). Retrieved from https://www.altoros.com/blog/the-iroha-project-to-bring-mobility-to-blockchain-with-simple-apis/

Iroha Whitepaper. (March 7, 2017). Retrieved from https://github.com/hyperledger/iroha/blob/master/docs/iroha_whitepaper.md

Çeviren: Deniz Özgür

Twitter: https://twitter.com/deniz_zgur