Content uploaded by Hakan Atabas
Author content
All content in this area was uploaded by Hakan Atabas on Feb 24, 2022
Content may be subject to copyright.
1
Cerberus
Radix İçin Geliştirilmiş Bir BFT Konsensus Protokolü
Türkçe Çeviri: Hakan Atabaş
ceo@geliyoo.com
Florian Cäsar
florian@radixdlt.com Daniel P. Hughes
dan@radixdlt.com
Josh Primero
josh@radixdlt.com
Stephen J. Thornton
steve@radixdlt.com
3 Mart, 2020
v1.01
Öz
Cerberus, durum makinesi replikasyonu (SMR) sorununa karşı geliştirilmiş, bir bölümlenmiş Bizans Hata
Toleransı programıdır. Genellikle SMR protokolleri komutların global sıralamasının yapılmasını sağlar.
Cerberus ise durum bölümlemesine yeni bir yaklaşım getiren bir kısmi sıralama düzeneğine sahiptir. Bu
yaklaşım komutlara ilişkin konsensus işlemlerinin birçok düğüm boyunca büyük ölçekte güvenli bir
biçimde senkronize edilirken sayesinde optimist duyarlılık ve doğrusal ileti karmaşıklığı
korunabilmektedir. Cerberus, küresel ölçekte merkeziyetsiz kamusal ağlar dahi olmak üzere birçok alanda
kullanımı hedeflenen bir dağıtık defter teknolojisi (DLT) olan Radix’e uygun bir çekirdek olarak
tasarlanmıştır.
1
Giriş
Konsensus protokolleri, güvenilir olmayan makinelerin oluşturduğu bir ağda durum makinesi replikasyonu
(SMR) gerçekleştirmek için gereklidir. Geniş bir kullanım alanına sahip olmasına ve uzunca bir süredir
kullanımda olmasına karşın, dağıtık defter teknolojileri içerisinde SMR gerçekleştirebilecek konsensus
protokollerine yoğun ilgi mevcuttur. Bu ağların küresel ölçekte merkeziyetsiz kamu platformlarından, kritik
işletme destek uygulamaları kadar birçok kullanım alanı mevcut olmakla birlikte oldukça yüksek işlem
kapasitesine gerek duymaktadır. Mevcut konsensus protokollerini bu denli ölçeklendirilebilir kılma yönünde
genişlemek ve adapte etmek güç olmuştur.
Biz Cerberus’u, Radix DLT ağı dahil olmak üzere, bu tür yüksek gereksinime sahip DLT ağlarında özel bir
kullanıma sahip yeni bir ölçeklendirilebilir konsensus protokolleri olarak sunmaktayız.
Parellelştirme Yoluyla Ölçeklendirme
Günümüzde çoğu konsensus protokolü komutların (örneğin işlemler veya etkinlikler) sıralanması için aynı
yöntemi kullanır. Komutlar tek bir zaman çizgisi boyunca sıralanır ve bir blok zincirinde veya benzer bir
sistemde depolanır. Bu işleme aynı zamanda “global sıralama” adı verilir. Global sıralama genellikle, bir akıllı
kontratının doğru şekilde işlenmesinin sistem içerisinde tahmin edilemez bir şekilde herhangi başka bir duruma
bağlı olduğu geleneksel, eylemsel“Turing bütünlüğüne sahip” akıllı kontrat sanal makineleri sunan DLTler için
gereklidir. Konsensus işlemini yüksek sayıda komutun işlenebilmesi için koordine etmek genellikle yüksek
iletişimsel ek yük medana getirir ve sonucunda elde edilmesi mümkün kapasiteyi kısıtlar.
Durum bölümlemesi, kapsitenin artırılması için konsensus sözleşmesinin paralelleştirilmesini sağayan bir
tekniktir. Ancak bu paralelleştirme yalnızca kullanılan bölümleme yöntemi ilgili olmayan komutları, güvenli
bir şekilde parallel olarak işlenebilmesi için ayırabiliryor ise mümkündür. Böylesine bir bölümleme yöntemi
global sıralama gereksiniminin getirdiği tek zaman çizigisiyle çakışmaktadır.
Bu eksiği kapatmak adına Cerberus, yalnızca ilgili etkinliklerin sıralanmasını mecbur kılan birden çok
senkronize zaman çizgisi kullanmaktadır. Cerberus bunu başarmak için konsensus ve uygulama katmanlarına
yönelik, akıllı kontrata benzer işlemler için dahi global sıralama gerektirmeyen bir yaklaşım geliştirmeiştir. Bu
da konsensusların, kapasite kısıtlamalarını azaltan bir durum bölümlemesi ile güvenli bir şekilde
paralelleştirilebilmesine olanak tanır.
2
Uygulama Katmanı Etkileşimi
Uygulama katmanında global sıralama gereksiniminin ortadan kaldırılabilmesi için tipik bir “akıllı kontrat”
eliştirme yöntemine bir alternatif gereklidir. Biz farklı bir yaklaşımın mümkün olmakla kalmadığına, ayrıca
konsensustan global sıralama yükünü kaldırmaktan da öte faydaları (bu bültende bahsedilmemiştir)
olduğuna inanıyoruz. Bu alternatif yaklaşım, DLT’nin kulanışlı işlevselliğini, birbirinden işlevsel olarak
bağımsız bileşenlere bölmektedir.
Radix’in uygulama katmanı olan Radix Engine bu şekilde çalışan bir uygulama katmanına bir örnektir. Radix
Engine bir geliştiriciye işlemsel işlevleri “varlığa yönelik” biçimde tanımlama olanağı sağlar. Kimlikler, para,
ürünler ve mülk gibi gülük işlemler “sınırsız” akıllı kontrat kodu içerisinde değil, birbirinden bağımsız olarak
güncellenebilen ayrı işlevsel bileşenler olarak modellenir. Radix Engine bu bileşenleri ayrı sonlu durum
makinelerine çevirebilmekte ve bunlar da daha sonra kolaylıkla Cerberus’un anlayabileceği bir bölümlenebilir
dile çevrilebilmektedir. Dolayısıyla Radix Engine bir işlemi Cerberus’a, açık gereksinimleri olan birtakım
durum makinesi güncellemesi olarak gönderebilmektedir.
Cerberus, böyle bir uygulama katmanıyla mümkün kılınan bu büyük oranda tanesel kısmi sıralamadan
faydalanmak için tasarlanmıştır ve büyük oranda paralelleştirilebilmesini sağlamaktadır.
İlgili Çalışmalar
Bitcoin’in, dağıtık defter teknolojilerinin (DLT) ve akıllı kontrat platformlarının ortaya çıkması konsensus
protoklleri üzerinde sürekli araştırma yapıldığı yeni bir çağ başlattı. Bitcoin tarzı “Nakamoto” konsensusu
[1][2], PBFT tarzı konsensus [3][4], rastgeleleştirilmiş konsensus [5][6] vb. son zamanlarda meydana gelen
gelişmeler, temel konsensus yaklşaşımlarında kullanıcılara sağladıkları güvencelere karşın birbirinden farklı
sorunlara sahip ilerlemeleri temsil etmektedir.
Cerberus’un konsensus paralellerştirilmesinde kaydetiği ilerleme bir lider bazlı Bizans hata toleranslı (BFT)
konsensus yaklaşımını temel alır. Durum makinesi replikasyonu (SMR) için geliştirilmiş BFT protokolleri
yüksek istikrar sağlar (elde bulunabilirliğe karşın) ve Lamport, Shostak ve ark.’ın çalışmalarına [7] kadar uzanan
bir geçmişe sahiptir. BFT protokolleri için PBFT asıl ddnüm noktası olmuştur [8].
PBFT hazırlık ve onay adı verilen iki aşamaya sahip bir konsensus işleminden faydalanır. Düğümler (veya
konsensus katılımcıla, örneğin merkeziyetsiz bir ağda bulunan bilgisayarlar), kendi aralarından bir “lider” seçer.
Lider, diğer düğümlere yayınlamak suretiyle bir komutta bulunur. 2f+1 (f tolere edilen azami Bizans hatalı
düğümünü ifade eder) komutun geçerliliğini kendi imzalarıyla yanıt vererek tanıdıktan sonra, imzalar bir
“Quorum sertifikası”na (QC) toplanır ve delil olarak diğer düğümlere yayınlanır. 2f+1 gereksinimi, çift oy
kullanan hatalı düğümlerin dahi, çoğunluğu kazanamayacğından emin olur. 2f+1 düğümleri delili tanıyıp
imzalandıktan sonra komut “onaylı” ve nihai Kabul edilir.
PBFT ilk kullanışlı kısmi senkronize BFT protoklünü geliştirmiş fakat günümüzün kamuya açık ağlarınaa ve
küresel bulut sistemlerine yönelik ölçeklendirilebilmeyi sağlamaya çalışmamıştır. Bu büyük ağlara ilişkin
önemli bir nokta, PBFT’nin işlemin devamı için gerektirdiği 2f+1 QC güvencelerinden ötürü,
“görünümdeğişimi” veya lider değişimi için gerekli yüksek ileti karmaşıklığıydı.
Son zamanlarda Tendermint gibi BFT’de meydana gelen gelişmeler, ileti yükünü azaltarak büyük blck
zincirleri bağlamında ilerlemeler kaydetmiştir. 2f+1 QCleri göndermek yerine, yeni lider yalnızca en
yüksek QCsini “genişletmektedir” (yeni teliflerde bu QC’yi temel alır. Kaydadeğer miktarda ileti
yükünden kurtulan bu system, aynı zamanda daha yüksek QC’ye sahip bir düğüme de olanak sağlar.
Dolayısıyla lider, mevcut delilin en yüksek QC’ye sahip olduğunu anlamak için önceden belirlenmiş bir azami
ağ gecikme süresi boyunca bekler ve bu da kilitlenmeleri önler.
Bu süreç sabit bir gecikme süresine sahip
olmasından ötürü ağın tepki süresini artırır ve dolayısıyla kapasiteyi ağın kendi hızından çok sabit bir
zaman aralığıyla kısıtlar.
Daha sonra, HotStuff protokolü [4] daha önceki BFT protokollerine önemli genişletmeler yaptı. HotStuff
optimist duyarlılığı sağlarken ileti karmaşıklığını da hazırlık ve onay aşamalarının arasına bir üçüncüsü olan
ön-onay aşamasını ekleyerek düşük tutmaktadır. Onay öncesi aşaması liderlere oy vermdikten sonra “fikirlerini
değiştirebilme” olanağını sunmaktadır. Yani ağ gecikme süresini bekleye gerek olmadan konsensus yeni
tekliflere geçebilir. Onay öncesi QCleri başarılı bir şekilde toplandıktan sonra onay gerçekleşir.
Bu, eşik imzaları ile de birleşince görünümdeğişimler için dahi “optimist duyarlılık” ve doğrusal ileti
karmaşıklığı sağlar. Biz de Cerberus’un bölümlenmş BFT protokolünü oluştururken HotStuff’ın bu
3
geişletmelerinden ve bunların getirdiği avantajlardan faydalanıyoruz.
Bu Belgenin Kapsamı
Cerberus modelini, kısmi sıralı komutlar için bir bölümleme tekniğine sahip 3 aşamalı bir BFT protokolü
olarak tanımlayarak başladık. Daha sonra kısaca modeli, doğrusal ileti karmaşıklığını sağlarken aynı
zamanda düğümlerin kabiliyetine, paralelleştirmeye ve güvenliğe ilişkin gereksinimlerini karşıladığını
göstermek için analiz ettik. Cerberus protokolünün ayrıntılı özellikleri ve güvenliğine ve canlılığına ilişkin
deliller bu belgenin daha sonraki bir revizyonuna eklenecektir.
Cerberus modelinden sonra Cerberus’un gerçek DLT ağları üzerinde uygulamasından bahsettik ve özellikle
Radix kamusal ağına odaklandık.. Cerberus konsesusunun dışında bulunan ve kullanışlı bir Cerberus temelli ağı
oluşturmak ve kullanmak için gerekli protokolleri sağlamanın yöntemlerini anlattık.
Bu belge Radix ekibi tarafından hazırlanmış bir çalışma belgesidir ve hala araştırması sürmektedir.
Dolayısıyla bazı bölümlerin açımlanması ve revize edilmesi gerekli olacaktır. Her zaman olduğu gibi
yorumlara, işbirliğine ve dönütlere açığız.
2
Model
Genel Bakış
Cerberus durum makinesi replikasyonu (SMR) sorununu çözüyor [15]: birçok düğüm boyunca hata toleranslı
dağıtım. Cerberus BFT tipi konsensus üzerine inşa etmektedir ve BFTlerin iki ana özelliğini korumaktadır:
1.
Eşzamanlılık yokken güvenlik, senkronize canlılık
2.
Elde edebilirlikten çok istikrara önem verme (örneğin senkronize değilken güvenliğe canlılıktan çok
önem verme)
Aynı zamanda temel modelimizde ortak BFT varsayımlarını da takip etmekteyiz. Bu varsayımları
Cerberus modelinin basit bir modelini sunmak amacıyla yapmamıza karşın, bu kısıtlamaların
bazıları uygulamada (özellikle bir statik düğüm setinde) kaldırılabilir. Bunların bazılarından
belgemizin Uygylama bölümünde bahsettik.
• Statik, global olarak bilinen bir düğüm seti
• Kısmi senkronizasyon (örneğin bir global stabilization süresinin ardından tüm iletilerin
ulaştığı bilinmeyen bir eşik mevcut)
• 2f+1 düğümleri protoklü takip eder, f Bizans düğümlerinin sayısıdır (Cerberus
durumunda bölüm başına)
• Bilgisayımsal olarak standart şifreleme ilkelerini kırama kapasitesine sahip olmayan
düşmanlar
• Düğümlerden oyları toplama amaçlı bir pratik eşik imzası
• Doğru düğümler arası iletişim eşler arası, yetkilendirilmiş ve güvenilir
Standard BFT’de istemc, komutları, doğru düğümlerin nihai duruma karar verebilmesi için global olarak
sıralanır. Performans iyileştirmeleri genellikle “dikey” ölçeklendirme veya “tek bir veri yoluna daha fazla komut
sığdırma” üzerine işlemiştir. Pratikte uygulamalar tüm komutların global sıralanmasını gerektirmez; yalnızca
birbirine bağımlı uygulamalar gerektirir.
Cerberus kısmi sıralama uygulayabilmek, yani yalnızca birbiriyle ilişkili komutları sıralamak için
bağımlılıkları belirten bir uygulama katmanına gereksinim duymaktadır. Cerberus’un “bölümleri”
komutlar arasındaki bu bağımlılık ilişkilerini temsil etmektedir. Aralaraında kısmi sıralama ilişkisi
bulunmayan komutlar aynı bölümde de bulunmazlar ve bu sayede paralel bir biçimde uygulanabilirler.
4
E
0
3-
ko
rd
on
S
0
3-
chai
n
S
1
3-
chai
n
S
2
3-
chai
n
S
0
S
1
S
2
S
3
S
4
S
5
E
0
E
2
cmd
S
0
S
1
S
2
S
3
S
4
S
5
*Şekil 1 çeviri: Shard:Bölümler atomic commands: atomic komutlar state changes: durum değişimleri
Şekil 1:
Bölümler (i nce ken arlı daireler) boyunca ilgili bölümlerin durum değ işimler ini gruplayan
ko mutların (kalın kenarlı hap şe kl indekil er) olu şt urduğ u kısmi sırala ma
S0-S5
Komutların bu şekilde bölümlemmesi Cerberus’un her bir bölümü ayrı bir “ “ani” bir Cerberus BFT’si
tarafından isteğe bağlı sayıda bölüm setleri boyunca gönderilen atomic komut onyalarına sahip bir “yerel
Cerberus” BFT örneği” olarak işlemesine olanak tanır. Cerbeus protokolünü üç ana adım ile betimliyoruz:
S0 A) Uygulama katmanında her bir komutun kısmi
S
1
sıralama gereksimlerini biçimlendirerek uygulama
katmanını bölüntüleyin
.
S2
*Shards: Bölümler
B)
Birden fazla “yerel Cerberus” örneğini, basit
geleneksel bir BFT ile paralel özelliklere sahip
bölümler boyunca bir “ani Cerberus” örneği
oluşturacak biçimde birleştirin.
Ani Cerberus BFTsi
*3-chain: üçlü zincir
ani
örnek
C)
Bölümler boyunca ani Cerberus örneklerini
paralelleştirin ve bu sayede ağ boyunca konsensus
işleminin büyük ölçekte ve güvenli bir şekilde
paralelleştirin.
local instance: yerel örnek
cmd
Shard
s
atomic commands
state changes
Shards
Shards
5
E
1
INIT() -> map of shard -> initialShardState
PARTITION(command) -> shards
A)
Uygulama Katmanının Bölüntülenmesi
Konsensusun etkili bir biçimde paralelleştirilebilmesi için Cerberus, uygulama katmanının komutların
kısmi sıralanması için gereksinimleri belirtemesine ihtiyaç duyar. Uygulayıcının uygulama katmanı için
özellikle saf işlevleri belirlemesi gereklidir
1.
Her bölümün başlangıç durumunu belirtin
2.
Komutu kendi bölüm setlerine bölüntüleyin
3.
Bölüm başına aracı sonuçlarına bir komut atayın
4.
Tüm bölümler boyunca yerel bçlüm başına aracı sonuçlarını düşürün.
INIT uygulamanın başlangıçtaki halini ifade eder. PARTITION kısmi sıralamanın doğruluğunun korunması için
bir komutun senkronize olması gereken bölümleri verir. Bir komut uygulanacağında öncelikle MAP ile bölüm
başına aracı sonuçlara atanır. Aracı sonuçlar daha sonra
REDUCE
ile
global sonuca dönüştürülüp komutun tüm
bölümlerinde uygulanır. Bu yaklaşım günümüz nüyük ölçekli dağıtılmış işlem modellerine benzerdir
[9].
Init Partition Map Reduce Apply
Alice's account shard
Banana price shard
Banana supply shard
*Alice's account shard: Alice’in hesabının olduğu bölüm, Banana price shard: Muz fiyatı bölümü
Banana supply shard: Mevcut muz miktarı bölümü, Alice wants to buy 3 bananas for $3: Alice 3$’a 3 muz almak istiyor
Approve: Onayla, Init: Başlangıç, Partition: Bölüntüle, Map: Ata, Reduce: Azalt, Apply: Onayla
Şekil 2: Uygulama katmanı kullanılarak konsensus bölüntülemesi örneği
Örnek olarak basit bir uygulama katmanının “Alice 3$’a 3 muz almak istiyor” komutunu işlediğini düşünün.
Bu komut, her biri mevcut muz miktarını, güncel muz fiyatını ve Alice’in hesap bakiyesini temsil eden bölümlere
bağlanabilecektir1. Komutu almalarının ardından, bölümler bu komutu kendilerine ait aracı sonucu almak için
atayabileceklerdir. Daha sonra Cerberus bu yerel sonuçları tüm bölümlere dağıtacaktır ve bunları azaltma
adımında bir sonraki bölüm durumlarını almak için uygulayacaktır.
B)
Yerel Ceerberus Örneklerinin Ortaya Çıkan Cerberus’a Dönüşmesi
Bu bölümde Cerberus’un atomik biçimde bir komutu önce tek bir bölüm içerisinde konsensus işleminde, sonra
da birçok bölüm içerisinde konsensus işleminde nasıl uyguladığını anlattık.
Yerel Cerberus
HotStuff’ın BFT tasarımı model alınarak tasarlamış tek BFT örneği ile başlıyoruz. Tek bir bölüm üzerinde yerel
Cerberus adını verdiğimiz bu örnek, tek başına HotStuff ile aynı optimist duyralılığı ve doğrusal ileti
karmaşlıklığını sağlar (tek bir blok zincirine uygulandığında). Bu avantajlar, Cerberus’u çok-bölümlü protocol
olarak inşa ederken iyi bir temel teşkil edecek.
1Radix’in bölümleri ataması ve kullanımı Şekil 2’de görülenden farklıdır. Daha fazla bilgi için Uygulama bölümünde “Radix
Motoru”nu okuyunuz.
MA
P(
co
mm
an
d,
sh
ar
d,
sh
ar
dS
ta
te
)
->
lo
ca
lR
es
ul
t
REDU
CE(c
omma
nd,
shar
d,
shar
dSta
te,
loca
lRes
ults
) ->
next
Shar
dSta
te
$3.50
A
pp
ro
ve
$0.50
$1
A
lic
e
w
an
ts
to
bu
y 3
b
a
n
a
n
as f
o
r
$
3
A
p
p
r
o
v
e
$1
5
6
QC cmd
vertex
vertex
vertex
vertex
Özellikle, hazırlık, ön-onay ve onay aşamalarını içeren bir “3-zincirli” BFT ile başlıyoruz. Her aşamada bir
Quorum sertifikası (QC), yani doğrulayıcı düğümlerden gelen imzalar toplamı, gereklidir.
*vertex: vertex, proposal: teklif, prepare: hazırlık, pre-commit: ön-onay
Şekil 3:
Bir yerel Cerberus üçlü zinciri
Bir blok zincirinideki bloklara benzer şekilde, konsensusun her bir aşaması, bir “verteks”in oluşumu ile ifade
edilir (şekil 3’teki mavi yuvarlak köşeli kareler). Bu vertekslerden her biri söz konusu aşamanın QCsini ve ana
verteks bilgisi içerir. Bir yerel Cerberus örneğinde komutu (cmd) içeren verteks, yeni bir teklifi ifade eden
vertekstir (yeni üçlü zincirin başlangıcı).
Çoklu Yerel Cerberus Örneği
Bu bölümde mevcut modele paralel yürütülen n sayıda çoklu yerel Cerberus ekledik. Basit olması için, her
bir örneğin farklı düğümler tarafından işlendiğini varsayıyoruz (yani her bir düğüm yalnızca bir örnee
atanmıştır). Düğümler ve örnekler arasında olan bu iki taraflı atamaların sabit ve her düğüm tarafından
tanındığı vasaryılmıştır
2
.
n0
n1
n2
n3
n4
n5
n6
nm
n
m+1
S0
chains
S1
chains
Sn
chains
Şekil 4:
N sayıda paralel yerel Cerberus örneği üzerinde dağıtılmış düğümler (B olarak ifade edilmiştir)
*chains: zincirler, nodes: düğümler
Ancak bu paralel örnekler pek kullanışlı değildir çünkü henüz senkronize edilmemişlerdir.
Ani Cerberus Örneği
Şimdi sıra çoklu yerel Cerberus örneklerini senkronize etmede. Bunu yapmak için çoklu Cerberus örneklerinin
arasına senkronizasyon ilkelerini eklenir ve senkronize edilmiş kombinasyonu, tek bir bölümlerarası BFT örneği
gibi işleyen tek bir ani Cerberus örneği olarak modellenir.
2 Düğümlerin bölümlere pratikte nasıl atandığı ve dinamik düğüm setleri bu belgenin Uygulama bölümünde tartışılmıştır.
Approve
QCn cmd
QC0 cmd
QC0 cmd
QC1 cmd
S
n
nodes
S
1
nodes
S
0
nodes
7
Bu ani düzey Geleneksel BFT (yani yerel Cerberus örnekleri) ile paralel kavramlarının Ani Cerberus’ta
bulunan çoklu bölüm kavramlarına atanmasıyla elde edilir:
Gelenkesel BFT (Yerel Cerberus)
Ani Cerberus
Lider
Lider Seti
Teklif
Birleştirilimiş Teklif
QC
QC Seti
Üçlü zincir
Üçlü kordon
Ani Lider: Lider Seti
İşlemin ilerlemesi için bir yerel Cerberus örneği her bir görünümde söz konusu bölümden gelen yeni-görünüm
iletileri ile yeni bir lider seçer. Ani düzeyde, bir bölüm seti tarafından seçilen lideler, bütün olarak “lider seti”
adı verilen bir ani lider haline gelir.
Emergent
Leader Set
Local Cerberus
Instance
Şekil 5:
Bir yerel setinin bütünü olan lider seti
*Local Cerberus Instance: Yerel Cerberus Örneği, Leader: Lider, Emergent Leader Set: Ani Lider Seti
Şekil 5’te mevcut örnekte olduğu gibi, iki Cerberus bölümü yeni görünüm iletileri yoluyla yerel liderler seçer (n0 ve
n5 olmak üzere). Sonrasında bu set {n0 ve n5}iki örnek üzerinde lider kabul edilir. Bu noktada hiçbir düğümün
lider setinden haberdar olmadığına dikkat edilmelidir. Elimizdeki yalnızca protokolün betimlenmesi ve analizi
için oluşturulmuş kuramsal bir yapıdır.
Ani Teklif: Birleştirilmiş teklif
Şimdi de “birleştirilmiş teklif” adı verilen, bir liderin yeni bir komut teklifi vermesi sağlayan meknizma
ekelniyor.
Bu durum şöyle bir örnekle açıklanabilir: Bir lider setinde bulunan her bir yerel lider, bu durumda {n0 ve n5, ani
Cerberus örneğinde mevcut tüm düğümlere bir teklif gönderir (gönderilecek bölümler uygulama katmanının
PARTITION fonksiyonunda belirtilir). Sonra düğümlerden her biri lider setindeki her bir yerel liderden alınan
her bir teklifi alır ve onları birleştirerek bir birleştirilmiş teklif oluşturur.
Komutlar bölümlenirken, her bir teklif aynı zamanda uygulama katmanının MAP fonksiyonunca sağlanan yerel
aracı sonuçları da içerir.
n1
n2
n0
n3
n4
n6
n5
8
QC0
QC1
result0
cmd
S0 3-chains
result1
E
0
QC0
QC1
result0
cmd
S 3-chains
result1
QC0
aggregate vote
n1
n2
n3
proposal
n4
n6
QC
1
vertex
proposal
aggregate vote
vertices
QC1
Şekil 6: Birbirine denk komutlar içeren bir yerel teklif setinden oluşturulmuş bir ani birleştirilmiş teklif
*Leader: Lider, Result: Sonuç, Local Proposal Vertices: Yerel Teklif Verteksleri, Merged Proposal Vertex: Birleştirilmiş
Teklif Verteksi
Daha sonra bu birlşetirilmiş teklif S0 ve S1 bölümlerinin arasındaki üçlü kordonun başladığı ani düzeyde vertex
görevini görür.
Şekil 7:
Birleştirilmiş teklif zincirin her bir ucuna ekleniyor
*Result: Sonuç, 3-chains: Üçlü zincirler, Braid: Kordon
Ani QC: QC Seti
Şimdi lider setine vertex içerisinde oy toplaması için bir mekanizma ekleniyor. Düğümlerden biri bir
birleştirilmiş teklif aldığında oyunu yerel liderine gönderir. Yerel lider 2f+1 oya sahip olduğunda da bir QC
oluşturur. Yerel liderlerden her biri yerel bir QC oluşturduktan sonra ani görünümde lider seti, her bir bölümdeki
bir QC’den meydana gelen bir ani QC veya bir “QC seti” oluşturur.
*Leader: Lider, New view: Yeni görünüm, Proposal: Teklif, Vote: Oy, Prepare: Hazırlık, Local: Yerel, Vertex: Verteks,
Vertices: Verteksler, Aggregate vote: Toplam oy
Şekil 8:
Tek bir aşamda her bir bölümden toplanan QClerden oluşan komutA için ani QC seti
n1
n2
n3
QC0 cmd result0
proposal
QC
0 cmd
result0
QC1 result1
n4
n6
vertex
QC
cmd result
proposal
local proposal
vertices
9
QC cmd
blank
QC cmd
failure at view v+1
view v+2
result0
cmd
QC1 result1
QC1
S0
QC
0
cmd
QC1
result0
result1
blank
QC0
QC1
S1
view v1 failure at view v1+1 view v1+2
QC0
QC1
result0
cmd
result1
QC0
QC1
QC0
QC1
QC0
QC1
S0
E
0
QC0 result0
cmd
QC1 result1
QC0
QC1
QC0
QC1
QC0
QC1
S1
Ani üçlü zincir: üçlü kordon
Sonra QC seti bir sonraki görünümde lider setine gönderilir ve işlem komutA için bir üçlü zincir
oluşturulana tekrar edilir.
Şekil 9:
İki yerel örnekten oluşmuş bir ani örnekte bir üçlü kordon-kordon
*Result: Sonuç, 3-chains: Üçlü zincir, 3-braid: Üçlü kordon
Bir komut için bir üçlü zincir oluşturulduktan sonra o komut “onaylnamış” kabul edilir.
Ani Hata Hafifletmesi
Bu bölümde bir ani Cerberus örneğinin lider hataları, çatalları ve birleşmeleri karşısında ne yaptığını anlatılmıştır.
Ani Lider Hataları
Bir yerel Cerberus örneğinde bir verteksin herhangi bir görünümde oluşturulamaması durumunda yerine
bir boş vertex atanır. Bu sayede ana/yaslama eşdeğerlik kontrolü başarısız olur. Bir yerel Cererus
örneğinde her bölümün ana verteksi kontrol edilmelidir.
*View: Görünüm, Failure: Hata
Şekil 10:
Yerel Cerberus örneğinde v+2’nin ana verteksi (v+1) v+2’nin gerçerlilik eşdeğerliğine denk
değil (v verteksi)
*View: Görünüm, Result: Sonuç, Blank: Boş, Failure: Hata, Chain: Zincir
Şekil 11
: Cer berus h atası, an a0 ana vertekslerin g eri kal anına v ey a ya sl amala rı na e şdeğer
değil.
10
2
QC cmd
QC
QC
QC
propos
al
vertex
prepare
QC
vertex
pre- com
mit
QC
vert
ex
commit
QC
vertex
B
0
düğüml
er
S
0
nod
es
S
1
nod
es
S
n
nod
es
QC0
c
md
QC
0
QC
0
QC
0
Q
C0 cmd
Q
C
1
QC
1
QC
1
QC1
cmd
QC
1
Q
C
n
Q
Cn cmd
QC
n
Q
C
n
Q
C
n
S
0
n
0
(lea
der
)
n
1
n
2
n0
n3
ne
w
vie
w
S
1
n
4
n
5
(lead
er)
n6
n5
new
view
S
0
n
0
(leader)
n
1
n
2
n
3
QC0
c
md
result0
new view
p
r
o
p
o
s
a
l
QC0
c
md
result0
QC1 result1
S
1
n
4
n
5
(leader)
n6
me
r
g
e
d
p
r
o
p
o
s
a
l
v
e
r
t
e
x
QC
1
cmd
resu
lt
1
new
view
pro
pos
al
local
proposa
l
vertices
QC0
QC1
result0
Ani Çatallar
Tek bir Cerberus örneğinde kilitli vertekslere ve/veya QC sayılarına sahip çatallar karşısında güvenlik ve
canlılık korunur. Bir ani Cerberus örneğinde çatallar yerel örneği dışında oluşabilşeceği için durum daha
karmaşıktır.
*View: Görünüm, Blank: Boş
Şekil 12:
görünüm v+1’deki komut verteksinin “çözmek” gerektiren bir yerel Cerberus örneği çatalı
*View: Görünüm, Result: Sonuç, Blank: Boş, Chain: Zincir
Şekil 13:
S
0
bölümünü görünüm +1’deki komutA’yı ,içeren verteksten “çözmek” için S
1
bölümüne ihtiyaç duyan ani Cerberus
çatalı.
HotStuff’ın ani örnek kontrolü çatallı örneğin daha yüksek miktarda QCsi ni QC’ye eklenerek genişletildi. Bu
durum, bir çatallı örneğin eski ve çakışan bir QC içeren bir teklif aldığında tespit edilir. Çatallı örnek daha sonra
çatallı QC’yi diğer bölümlere ileti olarak gönderir.
*Leader: Lider, New view: Yeni görünüm, Proposal: Teklif, Vote: Oy, Aggregate votes: Toplam oy, Forked: Çatallı, Aggregate
Forked: Toplam Çatallı, Virtual: Sanal
Şekil 14:
Çatallı QC yoluyla bir ani örnekteki bulunan bir örnekler arası çatalın kurtarılması
11
cmd
S0 3-
chains
result1
E0
3-braid
QC0
QC1
result0
cmd
S
3-
cha
ins
resul
t1
1
QC0
aggregate vote
S
0
n
0
(lead
er)
n
1
n
2
n
3
QC
0
n
e
w
v
ie
w
propo
sal
vot
e
pre
par
e
QC
0
S
1
n
4
n
5
(lead
er)
n6
QC
Q
C1
pre
par
e
QC
set
ver
tex
1
new
view
prop
osal
vot
e
p
rep
are
agg
reg
ate
vot
e
loca l
p
r
e
p
a
r
e
Q
C
v
e
r
t
i
c
e
s
QC1
QC0
QC1
result0
cmd
result1
QC0
QC1
QC0
QC1
QC0
QC1
S0
3-
chains
E0
3-braid
QC0 result0
cmd
QC1 result1
QC0
QC1
QC0
QC1
QC0
QC1
S1
3-
cha
ins
QC cmd
blan
k
QC cmd
vie
w v
failur
e at
view
v+1
view
v+2
view
v
0
view
v
0
+1
QC
0
QC
r
e
s
u
l
t
0
cmd
QC1 result1
0
QC1
S0
chain
QC0 c
m
d
QC1
result0
result1
blank
Çatallı yerel QC daha sonra ani QC’ye dahil edilir ve çatalın delili görevini görür. Sonra bu delilden bir “sanal
QC” oluşturulur. Bu sanal QC mevcut QC’den daha yüksek viewNumber’a (görünüm sayısı) sahiptr ve çatallı
QC’nin çatallı olmadığı kısma kadar uzanır.
Şekil 15:
Daha yüksek
viewNumber’a
sahip sanal QC çatallı Ani Cerberus örneğini “çözmek” için kullaılıyor.
Bu şekilde sanal QCler bir dolaylanma düzeyi olarak işlev görür. Şimdi fiziksel QCler içeren QClerden
bahsedeceğiz. Sanal QCler bir ana fiziksel QC’den ve bir isteğe bağlı çatallı QC’den oluşur. Yalnızca ana QC’yi
içeren bir sanal QC ana QC’nin işlevini görür. Basitçe açıklamak adına çatalsız sanal QCler tek bir mavi kutu ile
ifade edilmiştir. Çatallı sanal QCler ise bir sanal düğüme işaret eden yaslama okuna sahip mavi kutular ile ifade
edilmiştir. Şekil 15’te mevcut daiagram buna bir örnektir. For example, Şekil 15 can be reduced to the following
diagram:
*View: Görünüm, Blank. Boş, Virtual: Sanal, Chain: Zincir:
Şekil 16:
Sanal QCler fiziksel QClerin üstünde bir katman işlevini görerek çatal yönetiminin karmaşıklığını
önemli ölçüde azaltmıştır.
Ani Birleştirmeler
Lider seti doğru olduğu ve bir komut teklifinde bulunduğu sürece, canlılığın sağlanması için ilerlemenin sürmesi
gerekmektedir.
12
QC0
QC1
S1
chain
v
i
e
w
v
1 failure at view v1+1 view v1+2
view v
view v+1
view v+2
view
v+3
view v+4
vie
w
v+5
Q
C
cmd
QC cmd
QC cmd
QC cmd
blank
blan
k
blan
k
QC cmd
QC cmd
view
v
0
view
v0 +1
QC0
QC1
cmd
A
result0
result1
view v0
+2
Q
C
0
Q
C
1
view v0 +3
QC
0
QC
1
S0
chain
QC0
QC1
cmd
A
result0
result1
QC0
QC1
QC0
QC1
blan
k
blan
k
blan
k
QC1
cm
d
B
S1
QC1 chain
view
v
1
view v1 +1
view
v1 +2
vie
w
v1
+3
view
v1 +4
view
v1 +5
n
(le
ad
er)
0
aggr
eg
at
e
vo
tes
QC
Virt
ual
QC
0
f
o
r
k
e
d
0
S
0
n1
n2
n3
QC1
new
view
proposal
vote
aggregate
forked
QCs
n
4
S1
n
5
(leader
)
n
6
Local Proposals
*View: Görünüm, Result: Sonuç, Blank: Boi, Local Proposals: Yerel Teklifler
Şekil 17:
Yerel Teklifler çatallanabilmektedir – ö rn ek te olduğu gibi
S1
üzerinde bulunan görünüm
v1+1’de iki vertex bulunduğundan ötürü çatal meydana gelmiştir.
Çatallı tekliflerin çözülebilmesi için yerel tekliflerin birleşmesi üzerinde, yerel tekliflerin arasında çatal olması
durumunda Sanal QC yöntemi kullanılarak kilitli bölümün etkili bir biçimde çözülmesini sağlayacak şekilde
değişiklik yapılır.
Örneğin Şekil 17’de, sırasıyla v0+3 and v1+6 görünümleri içerisinde bulunan VQC0 ve VQC1 çatallanmıştır.
Bunu düzeltmek için VQC1’in fiziksel QCsi bir çatallı QC olarak VQC0’a eklenir. Böylece çatal fiilen ortadan
kalkar.
Modified Local Proposals
*View: Görünüm, Blank: Boş, Modified Local Proposals: Değişiklik Yapılmış Teklifler, Virtual: Sanal
Şekil 18:
Asıl yerel teklif edilmiş sanal QCler çatallandıkça,, teklifler üzerinde çatallı QCler eklenerek
çatal ortadan kalkana kadar değişiklik yapılır. Ardından teklifler normal şekilde birleştirilmeye
devam eder.
Üzerinde değişiklik yapılmış yerel teklifler daha sonra normal şekilde çatallar olamadan birleşebilecek hale gelir.
İşlemin sonucu Şekil 19’da görülebilmektedir.
13
*View: Görünüm, Blank: Boş, Result: Sonuç
Şekil 19:
The merged proposal post-modification cleanly attaches to both zincirs
C)
Ani Örneklerin Paralelleştirilmesi
Bir önceki bölümde birden fazla yerel Cerberus örneğini birleştirerek tek bir Ani Cerberus örneği oluşturan
mekanizmadan bahsedildi. Bu bölümde de birden fazla ani örneğin sabit sayıda bölüm üzerinde
paralelleştirilmesinden bahsedilecek.
Belirli sayıda bölüm üzerinde, S={S0, S1, ...,Sn} için S’in alt setlerinin herheangi biri üzerinde ani örnek
oluşturulabilmektedir. Bunun için gereken, her bir örneğin diğerlerinden ayrışık olmasıdır (aralarında ortak
eleman bulunmaması). Örneğin, {{S0, S1}, {S2}, {S3, S4, S5}}.
Ani örneklerin oluşturulması, uygulama katmanının PARTITION fonksiyonu tarafından işlenecek komut seti ve
bu komutlar üzerinde verilecek sonuçlar tarafından belirlenir.
Aşağıdaki örnekte cmd0-4 bir ani örnek setini ifade eder. cmd0 ve cmd1 ayrışık bölümlerdir ve dolayısıyla
birbirine paralel iki ayrı ani örnek oluşturabilirler. Diğer yandan cmd1 ve cmd2 bölüm S3’te kesişmektedir ve
bundan ötürü bir komutun diğerinden önce uygulanması gerekmektedir (bu durumda cmd1).
PARTITION(cmd0) -> {S0, S1, S2}
PARTITION(cmd1) -> {S3, S6}
PARTITION(cmd2) -> {S , S , S }
2 3 5
PARTITION(cmd3) -> {S4, S5}
PARTITION(cmd4) -> {S6, S7}
Şekil 20:
Cerberus’un S
0
-S
7
bölümleri boyunca cmd0- 4komutlarını paralelleştirmesi
Bölüm setleri isteğe bağlı şekilde boyutladırılabilir ve bu sayede konsensus işleminin büyük ölçekte
paralelleştirilebilmesine olanak tanır. Özellikle, bu tür bir paralelleştirme, güvenlik ve ölçeklendirebilirlik
arasında ayarlanabilir bir denge sağlar. Düğüm başına düşen bölüm sayısını azaltmak paralelliği ve ölçeği artırır
fakat her bir bölümün sahip olduğu doğrulayıcı set boyutunu düşürür. Bu özellik sistemi tasarlayan kişinin
pratikte yüksek güvenlikli bir asgari düğüm başına düşen bölüm eşiği seçmesine ve aynı zamanda fazla sayıda
bağımsız düğüme izin vererek en üst düzey paralelleştirmeyi ve ölçeği sağlamasına olanak tanır.
forked
QC
view v
0
view v0 +1
view v0 +2
virtual
view v0 +2
view
v0 +3
view
v0 +4
blank
blank
blan
k
blank
Virtu
al
QC
0
QC
0
forke
d
QC1
cmd
C
S
0
c
h
a
i
n
QC0
QC1
cmd
resul
t0
A
resul
t1
Q
C
0
Q
C
1
QC0
QC1
Q
C
0
Q
C
1
cmd
resu
lt0
A
result1
QC0
QC1
QC0
QC1
blank
blank
bla
nk
QC1
cm
d
B
Q
C
1
S
1
c
h
ai
n
view
v
1
vi
e
w
v
1
+
1
view
v1 +2
view
v1 +3
view v1 +4
view
v1 +5
14
Analiz
HotStuff’ta olduğu gibi Cerberus’ta da ileti karmaşıklığı yetkilendirici karmaşıklığı ile ölçülür. Yetkilendirici
karmaşıklığı, bir konsensus kararına varılabilmesi için herhangi bir düğüm tarafından alınan yetkilendirici
sayısıdır.
HotStuff sözde, eşik imzaları kullanarak,
O(n) – doğrusal karmaşıklık ve düğüm sayısı
n
3
ile ulaşır.
Cerberus’ta bölümlenmenin hesaba katılması gereklidir. Eşit dağıtılmış bir düğümden-bölüme atama ve tek
bölümlü komutlar için Cerberus HotStuff gibi işlev görmektedir ve bir doğru lider için yetkilendirici
karmaşıklığı T=bölüm sayısı için O(n/T)’dir.Tıpkı HotStuff’ta olduğu gibi T 1’e veya tek bölümlük konsensus
örneğine yaklaştıkça yetkilendirici karmaşıklığı da O(n)’e yakşlaşır.
Ani Cerberus örneklerinde bölümler arası konsensusta bölüm başına ayrı birer QC gereklidir. Bu durumda doğru
liderler için yetkilendirici karmaşıklığı, s=belli bir komutta mevcut bölüm sayısı ve s=1<=sz=T olmak üzere,
O(s * n /T)’dir.
Bu tanımla birlikte bir Cerberus tabanlı ağın kurulumunda ve kullanımında mevcut dengeler değerlendirilebilir.
Fiilen, s/T uygulama katmanının ağ üzerindeki yükü ve n/T güvenlik (bölüm başına daha fazla düğüm) ve
parallelik (bölüm başına daha az düğüm) arasındaki dengeyi ifade eder. Örneğin:
• Uygulamada, bir HotStuff ağında aşırı ileti yüküne sebep olmadan, pratikte yüksek miktarda
güvenlik sağlamak için gereken bölüm başına düğüm örtüşmesini sağlamak için belli bir sayıda
düğüm seçilebilmektedir. Sözkonusu bu set sayısı bir Cerberus ağında mevcut bölüm başına düşen
düğüm sayısına uygulandığında, Cerberus ağının kapasitesi düğüm sayısı ile doğru orantılı biçimde,
her bir bölümün ayrı güvenliğinden taviz vermeden ölçeklendirilebilir.
• Bir uygulama katmanının düşük bir ortalama bağımlılık sayısına sahip komutlar (nispeten basit
işlemler) oluşturudğu varsayıldığında, s’in ileti yükü çok az olur. Dolayısıyla yalnızca alışılmışın
dışında büyük işlemlerde daha fazla ücretin ödendiği bir kamusal ağ kurulması ihtimal dahilindedir.
3
Radix DLT Ağ Ugyulaması
Cerberus çeşitli uygulamalarda kullanılabilecek bir protokldür. Bu bölümde bu kullanım alanları arasında Radix
gibi ölçeklenebilir DLT ağları özellikle ilgi çekmektedir. Bu bölümde Cerberus’un Radix ve potasiyel olarak
diğer diğer DLT ağları üzerinde kurulabilmesine ilişkin sorunlara getirilebilecek genişletilebilir olası tasarruflu
ve makul ölçüde genişletilebilir çözümlerden bahsedilmiştir. Uygulamanın en önemli boyutları ele alınmış
olmasına karşın, çözümler tam olarak belirlenmemiştir ve sorunların ayrıntılı bir listesi verilmemiştir.
Radix çok sayıda ağ kurulum çeşitleri üzerinde çalışması için tasarlanmıştır. Bunlardan en büyük zorluk teşkil
edeni izinsiz kamu ağlarıdır. Bu bölümde bahsi geçen çözümler tüm Radix ağ kurulum türleri için üretilmiş
olmakla birlikte açık katılımlı büyük ağlar özellikle dikkate alınmıştır.
Radix Engine Uygulama Katmanı
Paralelleştirme yapabilmek için Cerberus, komutlar arasındaki bağımlılıkları belirten uygulama katmanına gerek
duyar. Bu bölümde böyle bir uygulama katmanı olan Radix Engine ile Cerberus konsensusu arasındaki ana
etkileşim türlerinden bahsedilmiştir.
Radix düğümlerinden biri bir Cerberus tabanlı Radix defteri ile Radix Engine adı verilen bir uygulama
katmanını birleştirir. Birtakım Radix düğümünün oluşturduğu bir bütün, “evren” adı verilen bir Radix ağı
meydana getrir ve Radix Engine tarafından oluşturulan işlemlere de “atom” adı verilir. Atomlar “partükül” adı
verilen sonlu girdi/çıktı durum makineleri için ayrı ayrı güncellemeler içerir. Bu, çoğu blokzincirinde kullanılan
UTXO modeline benzerdir fakat daha esnek olması adına genişletilmiştir. Tahmin edilebileceği üzere, atomların
atomik olarak Cerberus konsensusu tarafından onaylanması veya reddedilmesi gerekmektedir. Bir atom,
içerisindeki tüm partiküller doğrulandığı takdirde onaylanır; aksi takdirde reddedilir..
Radix Engine atpmları ve bu atomların partikülleri düzgün bir şekilde, ilgili durum değişimlerini belirten
Cerberus komutlarına atanır. Atomların bölümlere atanmasında belirleyici partiküllerdirç Her bir partikül
doğrudan bölüme atanır (Partikül/bölüm adresleme düzeneği Partikül Tanımlayıcıları bölümünde
açıklanmıştır).
3 Similar to other leader-based BFT protocols, the linear message complexity of Cerberus relies on the use of a signature aggregation
scheme (e.g., using BLS signatures).
15
vie
w
v
0
view v0
+1
view v0
+2
virtual
view v0 +2.5
view v0 +3
view v0 +4
blank
blank
blank
bla
nk
Virtual
QC0
cmd
C
S0
chain
blank
bla
nk
blank
Virtual cmd
QC1 B
Virtual
QC1
Dolayısıyla her bir partikül/bölüm, şekil 21’deki gibi görünen bir basit durum makinesidir.
*Init: Başlangıç, Neutral: Nötr, Up: Yuları, Down: Aşağı, Use as output: Çıktı olarak kullanın,
Use as input: Girdi olarak kullanın
Şekil 21: “Partik üllerin” tanımlı sıralı duru mları : nötr (v ar sayıl an), yukarı (etki n), a şağı (k ullanılmış)
Radix Engine tarafından sağlanan ve girdi/çıktı çiftlerini doğrulayan UTXO tabanlı mantığı ele
alındığında,Cerberus’un birden fazla partikülün durumunun (yukarı veya aşağı olarak) güncellenmesi için
atomic onay vermede kuallnılabileceği görülmektedir.
Örnek bir defter Şekil 22’de mevcuttur..
S
0
S
1
S
2
S
3
S
4
S
5
Şekil 22:
kalın kenarlı haplar, kendi bölümleri içerisinde ilgili partikül durum deişimlerini (ince kenarlı
daireler) gruplayan komutları temsil etmektedir.
.
Partikül Tanımlayıcılar
Partiküllerin, Radix Engine’ın temel birimleri olmalarından ötürü, bir tanımlayıcı tarafından kendine has bir
biçimde adreslenebilmesi gerekmektedir. Chainspace’in “Hash-DAG yapısı”ndan [11] esinlenilerek, işlem
geçmişi hazırlanması zor ancak doğrulaması kolay olan işlemlere sahip bir yüksek entegrasyonlu veri yapısı
oluşturmak için tasarlanmış bir atom yoluyla partiküller tanımlanmaktadır.
Partikül tanımlayıcıları partikülleri tanımlamak için, partikülün içinde bulunduğu atomun tanımlayıcısının ve
partikülün, sözkonusu atom içerisinde partküllerin (deterministic) endeksini birleşik sonucunu kullanır. Partikül
tanımlayıcısı, sözkonusu partikül atomda ilk defa belirdiğinde “oluşturulur” ve partikül üzerinde daha sonra
meydana gelen tüm değişimler aynı tanımlayıcıyı kullanır.
*Hash: Sonuç, Atom: Atom, Index: Endeks, Up: Yukarı, Particle: Partikül, Down: Aşağı, Identifier: Tanımlayıcı
Şekil 23:
Partikülün oluşumunda (sol) tanımlandığı üzere partikül tanımlayıcısı (sağ)
16
S1
chain
view
v
1
view v1
+1
Bu partikül tanımlama düzeneği sabit ve denetlenebilir sonuçlar ğüretir ve bu sonuçlar her bir partikülün
oluşturulduğu zamana kadar takip edilebilir. Dahası, partikül tanımlayıcı, oluşturulduğu atomun içeriği değil
kendisi tabanlı olduğu için, aynı içerikli farklı atomlarda oluşturulmuş partiküller arasında eşsizliğin sağlanması
için tek seferlik anahtarlara ihtiyaç yoktur.
Bölüm Atama
Partiküller, partikül tanımlayıcılar temel alınarak bire bir olarak bölümlere atanır. Partiküller bu şekilde bölüm
uzayına dağıtmanın birtakım avantajları mevcuttur:
1.
Bölüm sabit genişlikte, statik ve önceden bilinir olabilir ve bu da karmaşık dinamik bölümleme
işlemlerine gereksinimi ortadan kaldırır.
2.
Partikül tanımlayıcılar neredeyse üniform yayılabileceği için, konsansus işlemi tüm bölümlerde
doğal olarak “yük dengeli” olacaktır.
3.
Tek bir bölüm yalnızca tek bir partikülün durumunu içerdiği için, bir düşmanın saldırıyla veya
kesintiyle herhangi bir bölümü ele geçirme olasılığı düşüktür.
Bu şekilde bi atama işlem yazımlarında iyi düzeyde performans ve gğvenlik sağlar. Ancak, her işlemin tek bir
tanımlayıcı yerine içerik ile adreslenmesinden ötürü bir hesabın bütün işlem geçmişi gibi işlem okuma
sorgularını yapmak daha zordur.
Konsensusun (örneğin bölüm güvenliği, yük dengesi) ve uygulamaların (örneğin kolay hesap sorgusu) birbirleri
ile çelişen gereksinimlerine kapsamlı bir çözüm için iki ayrı çözüm gereklidir ve bu çözümlerin her biri
uygulanacağı alanın ihtiyaçlarına uygun ve diğer alanların ısıtlamalarından bağımsız olmalıdır. Konsensusun
kullandığı bölüm atama, uygulamaların kullandığından, Cerberus’un üstünde çalışacak, teklif edilecek bir sorgu
katmanı yoluyla ayrıştırılır. Bu mimari, ağın üzerinde çalışan arama motorları, internet üzerinde çalışan alanlar,
IPFS [12] veya BitTorrent [13] . üzerinde çalışan sorgular ile benzerdir.
Accounts
(query layer)
Particles
(consensus layer)
*Accounts: Hesaplar, Query layer: Sorgu katmanı, Particles: Partiküller, Consesus layer: Konsensus katmanı
Şekil 24: Hesaplarda ikinci bir endeks kullanan bir sorgu katmanı
Basit bir sorgu katmanı, şekil 24’te de görüldüğü üzere hesaplar üzerinde ikinci bir endeks olarak
çalışabilir. Bu durum, sorgu katmanı güncel partikül aldığı sürece desteklenbilir.
Bu son durumları almak için bazı Pratik çözümler aşağıda verilmiştir:
1.
Sorgu katmanının konsensus katmanındaki her iletiyi gizlice dinlemsi sağlanır ve sonrasında hangi
işlemlerin onaylandığını söyleyebilir.
2.
Sorgu katmanı işlemlerin arasında “sürünebilir”. Pratikte her bir işlem bir diğeri ile bağlantılı
olduğu için bir sürüngen rahatlıkla işlem zincirinde dolaşabilir.
Son durum alındıktan sonra, mevcut herhangi bir dağıtılmış anahtar/değer veri tabanına veya Kademlia [14] gibi
mekeziyetsiz DHTlere sunulabilir.
17
view v1 +2
view v1 +3
vi
ew
v1
+5
vi
e
w
v
0
Radix’te kullanılacak olan sorgu mekanizmasının daha ayrıntılı açıklaması sonraya bırakılmıştır.
Sanal Tek Bölümlü Düğümler
Cerberus, teoride her bir düğüme bir bölüm atar. Uygulamada ise düğümleri, makine başına bir bölüm olacak
şekilde makinelere atamak, bölümler kısa ömürlü ve genellikle aktif olmayan bölümleri temsil ettiği için,
kaynakları verimsiz kullanmak olur. Çoğu makine aynı anda birçok bölüme hizmet edebilecek donanım
kapasitesine sahip olacaktır.
Cerberus’un basitliğini ve doğruluğunu korumak
adına, her bir fiziksel düğümde (örneğin makinede).
isteğe bağlı sayıda tek bölümlü düğümler
sanallaştırılmıştır. Sanal düğümler, birden fazla sanal
düğümün aynı fiziksel makineye (aynı adres ve
kamusal anahtar ile) atanmaları dışında fiziksel
düğümler ile tamamen aynı şekilde çalışır.
*Physical node: Fiziksel Düğüm,
Virtual node: Sanal düğüm
Global Bölüm
Cerberus’ta bölümler farklı düğümlerin, genel istemci talep komutlarının işlenmesinde (örneğin işlemlerin
yerine getirilmesinde) , ağda mevcut toplam konsensus etkinliğinin yalnızca bir alt kümsinde katılım
göstermesine müsade eder. Ancak uygulamada, DLT ağlarında genel istemci taleplerinin dışında bulunan belli
başlı işlevlerde konsensusun ve tüm düğümlerin görünürlüğünü gerektirir (elde tutma yönetimi gibi). Bu yüzden
bu tür işlevleri destekleyen “global bölüm” kavramı geliştirilmiştir. Yukarıda bahsedildiği gibi düğümlerin (ve
makinelerin) belli bir alt kümesine atanabilen sıradan düğümlerden farklı olarak, global bölüm tüm düğümlere
atanabilir. Tüm düğümler özel amaçlı komutlar üzerine konsensusa global bölümde katılım gösterir ve global
bölümün durumunu depolar.
Global bölümde gerçekleşen konsensuslar, tıpkı diğer bölümler gibi, tek bir yerel Cerberus örneği şeklinde
aynı merkeziyetsiz konsensus işlemini kullanır. Global bölüm, genel istemci komutları üzerine konsensus
yürütmek yerine, aşağıda bahsi geçen mevcut düğüm seti ve staking gibi, ağın işleyebilmesi için gereken
global parametreler üzerinde konsensus yürütür.
Ayrıca ağ zamanı gibi kullanışlı ağlar arası işlevlerde de
kullanılabilir.
Radix’te mevcut normal bölümler kısa ömürlü olarak düşünülebilir (sadece yukarı/aşağı partikül
güncellemelerinden oluşan kısa dizilerle ilgili), global bölüm kısıtlı kullanım alanı olan, sürekli çalışma
halinde bir blok zinciri olarak düşünülebilir. Genel ağın komut kapasitesine kıyasla, global bölümün gerek
duyduğu konsensus durum değişiklik sıklığı düşüktür ve dolayısıyla performans üzerinde kaydadeğer bir
etki olmaksızın konsensus yürütlebilir.
Düğümler Setleri ve Erime
Cerberus her bir düğümün diğer düğümlerden haberdar olmasını gerektirir. Ancak, düğümler ağa giriş ve
ağdan çıkış yapmak düğümlerin isteğine bağlı olduğundan ötürü iyi bir DLT ağının erime karşısında
yaakta durabilmesi gereklidir.
Bu dinamik düğüm setini koruyabilmek için global bölümde güncellenen bir
kimlik defteri kullanılır.
Kimlik defteri, düğüm setini ve bölüm atamasını belli bir zamanda yakalaması için bir dönem kullanır. Kesin
tarihler, düğüm setinin sabit olduğu zaman dilimleridir (1 saat, gün vb.). Her bir düğüm mevcut en yüksek
dönemi takip eder ve hepsini iletilerde ve istemci komutlarına dahil eder. Bir dönemin sonunda, tüm
düğümlerin, bir sonraki düğüm seti üzerinde, global bölüm üzerinde terk et ve katıl oylarını toplayarak bir
konsensusa varmaları gerekmektedir.
Sybil’e Karşı Savunma
Kamuya açık bir ağ olarak, bir saldırganın, düğümsetinin kontrolünü ele geçirmesi ve güvenliği/canlılığı istediği
gibi kırabilmesi (bitcoin saldırısının %51’ine eşdeğer) ihtimaline karşı kendimizi savunmamız gerekmektedir.
Casper, Tendermint ve diğerleri gibi, sybil saldırılarına karşı BFT ortamında Hisse Kanıtı (PoS) kullanılması
planlanmaktadır.
view
v1
+4
18
Tüm düğümlerin eşit oy yetkisi olması yerine, doğrulayıcı seçiminde rekabet edebilmek için her bir düğümün,
kaydettikleri hisseye oranla oy yetkisi mevcut olacaktır. Bu durum global bölüm tarafından özel hisseyi koy ve
hisseyi geri al komutları ile devam ettirilecektir. Bütün düğümlerin global bölümün parçası olması gerektiğinden
ötürü, her düğüm bir diğerinin düğümler arası ataması, bölümleri ve hisseleri ile ilgili eksiksiz bilgiye sahip
olacaktır. Bu durum, tüm düğümlerin, hisse kullanan doğrulayıcı setler yoluyla Cerberus içerisinde doğru bir
biçimde konsensus yürütmesini sağlamaktadır.
Cerberus’ta Radix içerisinde PoS’in uygulanmasına ilişkin ayrıntılı açıklama sonraya bırakılmıştır.
DOS’a karşı Lider’in Savunulması
Tarafımızca geliştirilmiş lider seçim sistemi sayesinde, bir sonraki dönemlerdeki lider erkenden bilineceği için
hizmeti engelleme (DOS) saldırılarına karşı özellikle açık durumda olacaktır. Bu duruma karşı geliştrilmiş
birtakım hafifletme stratejileri mevcuttur:
• Gözcü düğümlerin, doğrulayıcılar arasında tam aracı görevi görmesi (TendermintWte olduğu gibi [10])
• Doğrusal yerine ikilenik ileti karmaşıklığını göze alığ lidersiz bir model kullanılması
Bir sonraki liderin daha az tahmin edilebilir olması için rastgeleliğe başvurulması (bu sayede
düşmanın daha az zamanı olması). Bu strateji, hala etkin bir biçimde araştırılmakta olan doğrulanabilir
rastgele fonksiyon kullanımı gerektirir.
Bu stratekilerin Cerberus içerisinde kamuya açık veya özel Radix ağ kurulumlarında kullanılmasına dair daha
ayrıntılı bir analiz, sonraya bırakılmıştır.
İstemci Komut Talepleri
Cerberus, istemci komut taleplerinin, teklifler sırasında seçilmeleri için liderler tarafından bilindiğini
varsaymaktadır. Taleplerin liderlere güvenilir biçimde iletilebilmesi için bir mekanizmaya ihtiyaç vardır.
Beklenen ağ kullanımının özelliklerine bağlı olarak, birkaç ihtimal mevcuttur.
Yöntemlerden en yaygını, istemci taleplerinin geniş çapta paylaşıldığı ve bir beklemede olan talepler havuzunun
yaklaşık olarak senkronize edilmesi yöntemidir (çoğunlukla “mempool” şeklinde bahsi geçer).
Komut Teklif Seçimi
Lider bazlı bir konsensus olan Cerberus, istemci taleplerinin teklif için güvenilir bir biçimde seçilebileceği bir
mekanizmaya ihtiyaç duyar. Cerberus’ta en eski onaylanmamış istemci taleplerini öne çıkaran ve sonunda tüm
istemci taleplerini seçecek bir rastgele seçim sistemi mevcuttur. Canlılığın sağlanabilmesi için Cerberus,
saldırganların tahmin edilebilir seçimlerden faydalanmasına engel olmak amacıyla, düğümlerin çoğunluğunun
bu protokolü takip etmesini öngörür. Ancak, bu şekilde bir teklif seçimi mekanizmasının kullanımının güvenlik
üzerinde değil, yalnızca canlılık üzerinde etkisi olduğu göz önünde bulundurulmalıdır.
4
Teşekkürler
Zalan Blenessey, Alexander Cyon, Matthew Hine, Edgars Nemše, ve Martin Sandiford’a bu belgenin
hazırlanmasındaki yardımlarından ötürü teşekkür ederiz.
19
5
Kaynaklar
[1] Bitcoin: A Peer-to-Peer Electronic Cash System, 2008: https://bitcoin.org/bitcoin.pdf
[2] Casper the Friendly Finality Gadget, 2017: https://github.com/ethereum/research/blob/master/papers/
casper-basics/casper_basics.pdf
[3] Tendermint: Byzantine Fault Tolerance in the Age of Blockzincirs, 2016:
https://allquantor.at/ blockzincirbib/pdf/buchman2016tendermint.pdf
[4] HotStuff: BFT Consensus in the Lens of Blockzincir, 2019: https://arxiv.org/pdf/1803.05069.pdf
[5] Randomized Protocols for Asynchronous Consensus, 2002: http://disi.unitn.it/~montreso/ds/syllabus/
papers/randomized-consensus-survey.pdf
[6] Scalable and Probabilistic Leaderless BFT Consensus through Metastability, 2019: https://
avalanchelabs.org/QmT1ry38PAmnhparPUmsUNHDEGHQusBLD6T5XJh4mUUn3v.pdf
[7] The Byzantine Generals Problem, 1982: https://www.microsoft.com/en-us/research/uploads/
prod/2016/12/The-Byzantine-Generals-Problem.pdf
[8] Practical Byzantine Fault Tolerance, 1999: http://pmg.csail.mit.edu/papers/osdi99.pdf
[9] MapReduce: Simplified Data Processing on Large Clusters, 2004: https://static.googleusercontent.
com/media/research.google.com/en//archive/mapreduce-osdi04.pdf
[10] Tendermint Explained – Bringing BFT-based PoS to the Public Blockzincir Domain, 2018:
https://blog.cosmos.network/tendermint-explained-bringing-bft-based-pos-to-the-public-blockzincir-
domain-f22e274a0fdb
[11] Chainspace: A Sharded Smart Contracts Platform, 2017: https://arxiv.org/pdf/1708.03778.pdf
[12] IPFS - Content Addressed, Versioned, P2P File System: https://ipfs.io/ipfs/
QmR7GSQM93Cx5eAg6a6yRzNde1FQv7uL6X1o4k7zrJa3LX/ipfs.draft3.pdf
[13] Peer-to-peer networking with BitTorrent, 2005: http://web.cs.ucla.edu/classes/cs217/05BitTorrent.pdf
[14] Kademlia: A Peer-to-peer Information System Based on the XOR Metric: https://pdos.csail.mit.
edu/~petar/papers/maymounkov-kademlia-lncs.pdf
[15] Implementing Fault-Tolerant Services Using the State Machine Approach: A Tutorial, 1990: https://
www.cs.cornell.edu/fbs/publications/SMSurvey.pdf