Bu yazımda merkezi sistemlerde karşılaşılan bazı sorunlardan bahsettikten sonra dağıtık sistemlerde bu sorunların çözülüp çözülemeyeceğini sorguluyorum. Önce konsensüs kavramını irdeliyorum, sonra “Konsensüs Protokolü Nedir?” sorusunu cevaplamaya çalışıyorum. Son olarak sırayla Klasik, Paxos, Nakamoto ve Avalanche Konsensüs Protokollerini anlatıyorum. Keyifli okumalar.
Tek kişinin yönettiği bir sistem hayal edelim. Bu sistem insanlara belli bir hizmeti sağlıyor olsun. İdeal dünyada müşterinin hizmet talep ettiği yer:
Hata içermez — talep edilen hizmet ne ise o sağlanır.
Saldırıya dayanıklıdır — böylece talep edilen hizmet aksamaz.
Donanımlar sonsuza kadar çalışır — sistem, hizmet talep edilen her anda hizmete açıktır.
Şimdi ideal hizmet beklentilerini de dikkate alarak tek kişinin yönettiği sistem modeline geri dönelim. Tek kişili sistemin başına neler gelebilir? Sistemi yürüten kişi:
Artık hizmet sağlamaktan vazgeçebilir
Yoğun yükü kaldıramayabilir
Saldırıya uğrayabilir
Yaralanabilir
Ölebilir
Yukarıdaki olayların her biri talep edilen hizmetin aksamasına veya durmasına doğrudan etki eder.
Geleneksel bilgisayar sistemleri de tek merkezli (merkezi) bir yaklaşımı benimsemiştir. Sunucu adını verdiğimiz bir makine, sistemin ortasına oturur ve istemcilerden gelen isteklere yanıt verir. Bu modelin adı sunucu-istemci (server-client) modelidir. Bu modelde kararı tek bir taraf verir.
Bu noktada akla şu sorular gelebilir: tek bir merkez gerçek dünyada ideal beklentileri karşılayamıyorsa, çok merkezli bir sistem bunu başarmaya yaklaşabilir mi? Verinin ve sistemin güvenliğinin sağlandığı bir mekanizma çok merkezli bir sistemde mümkün mü?
Fakat bu sorulardan önce sorulması gereken çok önemli bir soru vardır:
“Makineler arasında bir anlaşmaya nasıl varabiliriz?”
Önceki soruları yanıtlayabilmek için önce bu soruya cevap vermemiz gereklidir.
İlk olarak 1970’li yıllarda Leslie Lamport ve Barbara Liskov gibi bilgisayar bilimcilerinin üzerine düşündüğü bu soru dağıtık sistemlerin temeli olan konsensüs kavramını ortaya çıkarmıştır.
Merkezi sistemlerde tüm kararlar tek bir oluşum (entity) tarafından alınır. Örnek olarak tüm şirketler, verileri ve işlemleri kayıt etmek için merkezi bir kayıt defteri (ledger) kullanır. Dağıtık ve bağımsız birçok düğümden oluşan merkezi olmayan sistemlerdeyse kararlar toplu olarak alınır ve dağıtık defterlere (distributed ledger) kaydedilir.
Bilinmesi gereken en temel terimler:
Düğüm (Node): Bir ağda verinin yaratıldığı, alındığı ve transfer edildiği noktalara denir. Blokzincirde düğümlerin temel görevi ağdaki işlemlerin geçerliliğini onaylamaktır. Daha fazla ayrıntı için şu yazıyı inceleyebilirsiniz.
Dağıtık Defter (Distributed Ledger): Birden çok katılımcı, dolayısıyla birden çok düğüm tarafından yönetilen merkezi olmayan bir veritabanıdır.
Konsensüs, ağdaki dağıtılmış düğümlerin ağın belirli bir durumu üzerinde anlaşmaları anlamına gelir. Bu blokzincir özelinde bloğa hangi işlemin kaydedileceği, zincire hangi bloğun ekleneceği üzerine anlaşmaya varmak demektir.
Bir mekanizmanın konsensüse ulaşılabilmesi için üç temel özelliği barındırması gerekir:
Sonlandırma (Termination): Tüm doğru işlemler sonunda bir çıktıyı vermeli — bir sonuca varmalı.
Anlaşma (Agreement): Her düğüm aynı kararı vermeli — tüm karar çıktıları eşit olmalı.
Geçerlilik (Validity): Her çıktı (karar) en az bir girdi tarafından tetiklenmiş olmalı.
Konsensüs protokolüyse ağdaki dağıtık düğümlerin konsensüse nasıl varacaklarını belirler. Yani konsensüs protokolleri, ortak bir anlaşmaya varılması için ağ katılımcıları tarafından uyulması gereken birtakım kurallar tanımlar.
Bir konsensüs protokolünün belirli şartlarda iki önemli özelliği sağlaması gerekir:
Canlılık (Liveness): Doğru istemcilerden gelen istekler eninde sonunda onaylanmalı — tüm düğümler bir konsensüse varmalı.
Güvenlik (Safety): Eğer dürüst bir düğüm bir işlemi kabul ederse (veya reddederse) diğer tüm dürüst düğümler de aynı kararı vermeli.
Konsensüs protokolleri, oylama protokolleri değildir. Ağdaki bir durumun kabul edilmesi için çoğunluğun anlaşması yeterli değildir. Ağdaki tüm düğümlerin anlaşmaya varması gerekir.
Protokolleri anlatmaya başlamadan önce yazının daha iyi anlaşılabilmesi için bilinmesi gereken bazı terimleri paylaşacağım. Terminolojide boğulmak istemeyen okuyucu bu kısımları atlayabilir.
Bizanslı Generali Problemi (Byzantine Generals Problem): 1982 yılında Lamport, Shostak ve Pease tarafından, dürüst olmayan düğümlerin de bulunduğu bir ağda konsensüse nasıl varılabilir sorusunu yönelten problem. Dürüst olmayan manipülatif düğümlere rağmen konsensüse başarılı bir şekilde ulaşabilen protokollere Bizans Hatasına Toleranslı (Byzantine Fault Tolerant) protokoller denir. Problemin aklınızda canlanması için Evrim Ağacı’nın şu videosunu izleyebilirsiniz.
Durum makinesi (State machine): Algoritma tasarlamak için kullanılan matematiksel bir model. Durum makinesi aldığı girdileri sıralı bir şekilde uygular ve bir çıktı çıkarır. Bu işlemler sonucunda kendi durumunu da günceller. Yiyecek-içecek otomatları durum makinesine örnek olarak gösterilebilir.
Durum Makinesi Replikasyonu (State Machine Replication): Birden fazla durum makinesinin Bizans Hatasına Toleranslı olacak şekilde bir ağ oluşturmasına denir.
Asenkron ağ (Asynchronous network): Ağdaki bileşenlerin işleyişi koordine değildir. Ağdaki bir mesaj için eninde sonunda kesin olarak iletilmesi dışında hiçbir gecikme (delay) garantisi yoktur. Yani mesajların iletim süresi belli değildir. Her gün kullandığımız internet asenkron sisteme örnek olarak verilebilir.
İzinsiz ağ (Permissionless network): İsteyen herkesin katılıp düğüm olabileceği ağlardır. Bitcoin ve Ethereum izinsiz ağlara örnek verilebilir.
İzinli ağ (Permissioned network): Tüm düğümlerin kimliklerinin bilindiği ağlardır. Bu ağlara katılmak için izin gereklidir. Hyperledger Fabric ve Facebook Libra izinli ağlara örnek verilebilir.
Klasik konsensüs protokolleri 1970’li dönemlerden bu yana en çok araştırılmış protokol ailesidir. Bu aileye ait protokoller bir temel özellikleriyle diğerlerinden ayırt edilebilirler: point to point iletişim. Bu iletişim türünde karara varmak için tüm düğümler birbirleriyle iletişim kurarlar. Yazının bu kısmında bu protokol ailesinin belki de en önemlisine değineceğim: pBFT (Practical Byzantine Fault Tolerance) konsensüs protokolü. Klasik konsensüs ailesinde yer alan bir başka protokol Tendermint Core’a da kısaca değineceğim.
Bilgisayar bilimcileri Miguel Castro ve Barbara Liskov, pBFT Konsensüs Protokolünü 1999 yılında yayımladıkları makaleyle tanıtmışlardır. Algoritma f kadar Bizanslı düğümün olduğu bir ağda 2f+1 kadar dürüst düğüm bulunduğu takdirde sorunsuz çalışır. Yani sistemin sorunsuz çalışabilmesi için ağın yüzde 33’ünden fazlası kötü niyetli olmamalıdır.
pBFT algoritması bir ağda bulunan düğümlere dağıtılmış durum makinesi olarak tanımlanabilir — bir state machine replication biçimidir. Her düğüm aynı durumu taşır. Protokol asenkron ağlarda çalışmak üzere tasarlanmıştır.
pBFT katılımcıların birbirini tanıdığı ağlar için daha uygun bir konsensüs algoritmasıdır. Diğer bir deyişle pBFT algoritmasının izinli ağlarda kullanılması tercih edilir.
pBFT algoritması temel olarak dört aşamadan oluşur:
İstemci lider (primary) düğüme bir istek gönderir
Lider düğüm bu isteği yedek (backup) düğümlere yayımlar.
Tüm düğümler isteği sorgular ve istemciye yanıt gönderirler.
İstemci farklı düğümlerden gelecek f+1 sayıdaki aynı yanıtı bekler. (burada f ağda bulunabilecek maksimum Bizanslı düğüm sayısıdır)
Bu örnekte C istemciyi, 0 lider düğümü, 1, 2 ve 3 ise yedek düğümleri temsil ediyor. Resimdeki senaryoda 3. düğüm inaktif. İşleyiş resmin yukarısındaki aşamalandırmamıza göre: Request 1. aşama, pre-prepare 2. aşama, prepare ve commit 3. aşama ve reply 4. aşama olmak şeklinde özetlenebilir.
pBFT Konsensüs Protokolünü birinci şahıs Barbara Liskov’dan dinlemek isteyenlere şu videoyu izlemelerini şiddetle öneririm.
Tendermint Core 2014 yılında Jae Kwon tarafından çıkarılan Bizanslı Hatasına Toleranslı (BFT) konsensüs protokolüdür.
Tendermint Core da pBFT algoritması gibi ağın yüzde 33’ünün Bizanslı düğümü olmasına dayanıklıdır. Tenderminti pBFT’den ayıran temel farksa onaylayıcı (validator) adını verdiğimiz düğümlerin ağa blok önermesi ve üzerine oylama yapmalarıdır. Bir bloğun ağa işlenmesi için ağdaki oylama gücünün 2/3’ü kadarını toplaması gerekir. Ağda onaylayıcı düğüm olmak için katılımcılar belli miktarda paralarını kitlemek (stake) zorundadır. Dürüst davranmayan düğümler cezalandırılır.
Tendermint algoritmasında her turda onaylayıcılardan yalnızca biri blok önerir. Belli bir tur için hangi düğümün blok önereceği düğümlerin oylama gücüne yani kitledikleri paraya bağlıdır. Parayı veren düdüğü çalar.
Dikkatin dağılmaması adına Tendermint Core başlığını kısa tutuyorum. İlgili okuyuculara Tendermint dokümantasyonunda Tendermint’in daha geniş bir şekilde incelendiği “What is Tendermint?” yazısını bırakıyorum.
Klasik konsensüs protokollerinde deterministik sona ulaşma (deterministic finality) görülür. Ağdaki işlemlerin sonlanması için tüm düğümlerin onayı gereklidir.
Leslie Lamport’un 1989 yılında temellerini attığı ve 1998 yılında makale olarak yayımladığı Paxos konsensüs protokolü yazının biraz yukarısında belirttiğim protokol olmak için gereken iki şartı (canlılık, güvenlik) sağlar. Bu protokolde ortak karara ulaşmak için ağdaki her bilgisayar birbiriyle iletişim kurar.
“The Paxos algorithm, when presented in plain English, is very simple.” -Leslie Lamport
Paxos terminolojisinde bir düğüm teklif sahibi (proposer) olarak davranır ve protokolü başlatmaktan sorumludur. Teklif sahibi müşterinin isteklerini ağa dağıtan düğümdür. Teklif sahiplerinin yanı sıra ağda teklif sahibinin önerdiği işlem hakkında karar veren düğümler bulunur. Bu düğümlere alıcılar (acceptors) denir. Alıcıların çoğunluğu önerilen işlemi kabul ettiğinde Paxos protokolü sonlanır ve o işleme ait teklif değerini görmek isteyen dinleyici (listener) adını verdiğimiz düğümlere dağıtılır. Orijinal terminolojisine sadık kalmak adına bundan sonra düğümlerden İngilizce adlarıyla bahsedeceğim.
Paxos’ta tek düğüm her rolü üstlenebilir. Yani tek düğüm hem proposer hem acceptor hem de listener olabilir. Bunun yanı sıra Paxos düğümleri “ısrarcı”dır; kabul ettikleri değerleri unutmazlar.
Paxos algoritması dört aşamadan oluşur:
Prepare: Proposer n teklif numarasını seçer ve acceptor düğümlerin çoğunluğuna (%50'den fazla) hazırlan (prepare) isteği gönderir.
Promise: Eğer acceptor’ın eline geçen n sayısı daha önce kabul ettiği her bir teklif numarasından büyükse proposera n’den daha küçük bir sayıyı kabul etmeme sözü verir (promise).
Accept request: Eğer proposer, acceptor çoğunluğundan söz aldıysa artık n nolu teklifini, v mesajıyla birleştirerek bu acceptorların hepsine kabul et isteği (accept request) yollar.
Accept: Acceptor eğer n numaralı kabul et isteğinden önce n’den daha büyük bir hazırlan isteğine söz vermediyse kabul et isteğini kabul eder (accept). Bu işlemi proposera ve listenerlara bildirir. Bir Paxos turu (execution) bitmiş olur.
Paxos algoritmasında “lider-replika” ya da diğer ismiyle “komutan-teğmen” modeli kullanılır. Proposer aslında müşteriden gelen isteği ağa dağıtan düğümden başkası değildir. Bu durumda proposer bir acceptor düğüm olup lider özelliği gösterir.
Paxos algoritmasının hata vereceği senaryo şu şekildedir:
İki proposer ağda aynı anda aktifse, en yüksek teklif numarası için dönüşümlü olarak teklif yollayarak birbirlerinin mesajlarını engelleyebilirler. Bu sorun çözülene kadar Paxos sona ermez. Konsensüs protokolleri için en önemli iki özellikten biri olan canlılık (liveness) bu senaryoda ihlal edilir. Bu sorun ancak proposerlardan birinin durumu fark edip diğer proposerın işleminin kabul edilmesi için ağa biraz zaman vermesiyle çözülebilir.
Paxos protokolü sistemdeki acceptor düğümlerin yarısı kadar Bizanslı düğümlerine dayanıklıdır. Yani protokolün sorunsuz çalışması için f kadar Bizanslı düğüm varsa f+1 kadar dürüst düğüm olmalıdır.
Paxos konsensüs algoritmasıyla karara varılan ağda bulunan acceptor düğümü sayısı arttıkça bu düğümler arasında konsensüse varma süresi artar. Dolayısıyla bu protokol birbirini tanıyan az sayıda düğüm için birebirken herkese açık olacak bir altyapıya sahip değildir. Yani Paxos konsensüsü de klasik konsensüs gibi izinli (permissioned) ve düğüm sayısı az olan ağlarda daha yüksek verim sağlar.
Paxos konsensüs protokolünde de klasik konsensüs protokollerde görüldüğü gibi deterministik sona ulaşma (deterministic finality) görülür.
Paxos konsensüs algoritması Bizans düğümü içeren ağlarda anlaşmaya nasıl varılacağına çözüm getiren ilk protokol olmasıyla çok önemlidir. Paxos ve Klasik konsensüsün eksik kaldığı noktalarıysa Nakamoto Konsensüs Protokolü tamamlamıştır.
Nakamoto ve Avalanche Konsensüs Protokolü başlıklarıyla alakalı önemli terimler:
Güvensiz (Trustless) sistem: Katılımcıların, sistemin işlemesi için birbirlerini veya üçüncü bir tarafı bilmelerine veya birbirlerine güvenmelerine gerek olmayan sistemlerdir. Daha detaylı bilgiye buradan ulaşabilirsiniz.
Dedikodu Protokolü (Gossip Protocol): Bir ağda bulunan düğümlerin “kulaktan kulağa” iletişim kurarak bilginin ağda yayılmasını sağladıkları protokoldür. Her düğüm rastgele bir düğüm seçer ve seçtiği düğüme durum bilgisini aktarır. Her düğüm birbiri ile iletişim kurmadığından zaman karmaşıklığı point-to-point iletişime göre daha azdır.
Senkron ağ (Synchronous network): Ağdaki bileşenlerin işleyişleri koordinedir. Senkron sistemlerin genelinde bu koordinasyon düğümler arasında bir saat senkronizasyonuyla sağlanır. Her bir turda, ağdaki bileşenler (düğümler) aynı işlemleri yaparlar. Örneğin bir turda mesajları diğer düğümlere yayımlarken diğer turda mesajları alıp işleyebilirler.
Şimdiye kadar incelediğimiz Klasik ve Paxos konsensüs protokolleri **“Makineler arası anlaşmaya nasıl varabiliriz?”** sorusuna başarıyla cevap verebilmişti. Fakat bu iki protokol şu sorunun cevabını verebilmekte yetersiz kaldı:
“Birbirinden bağımsız çok sayıda makinenin oluşturduğu bir ağda anlaşmaya nasıl varabiliriz?”
Bu sorunun cevabını ilk kez Satoshi Nakamoto 2009’da yayımladığı Bitcoin whitepaperıyla verdi. İlk kez Bitcoin whitepaperında bahsedilen Nakamoto Konsensüs Protokolü, Bizans Hatasına Toleranslı (BFT) olan ilk blockchain konsensüs protokolüdür. Nakamoto Konsensüsü Bitcoinin yanı sıra Ethereum, Monero ve Litecoin gibi proof-of-work mekanizmasını kullanan birçok blockchain ağının da konsensüs protokolüdür.
Nakamoto Konsensüs Protokolü ismi sonradan verilmiştir. Bitcoin whitepaperında protokol için herhangi bir isimlendirme geçmez.
Nakamoto konsensüsünün işleyişini Satoshi 6 aşamada açıklar:
Yeni işlemler ağdaki tüm düğümlere yayınlanır.
Her düğüm yeni işlemleri bir bloğun içerisinde toplamaya başlar.
Her düğüm kendi bloğu için bir iş kanıtı (proof-of-work) bulmaya çalışır. İş kanıtı aslında kriptografik bir bulmacadır.
Bu bulmacayı çözen ilk düğüm (lider) diğer tüm düğümlere kendi bloğunu yayımlar.
Eğer bu bloğun içerisindeki tüm işlemler geçerliyse diğer düğümler bu bloğu kabul eder.
Düğümler bloğu kabul ettiklerini zincirde o bloktan hemen sonra gelecek blok üzerine çalışmaya başlayarak gösterirler.
Bu aşamalarda Nakamoto konsensüsün büyük bir parçası olan ve konsensüsü birlikte tamamlayan iki unsur göze çarpar: İş Kanıtı (Proof of Work) ve En uzun zincir kuralı (Longest chain rule).
İş kanıtı, katılımcıların ağda söz sahibi olmak için belirli matematiksel problemleri çözmesine dayanan bir sybil direnç (sybil resistance) mekanizmasıdır. Böyle bir mekanizmanın oluşturulmasındaki temel mantık sybil saldırılarına (ağı birden fazla sahte kimlikle kontrol etme girişimi) dayanıklı bir ağ oluşturmaktır. Proof-of-work getirdiği işlem gücü gerekliliğiyle ağda kimlik oluşturma maliyetini arttırır. Bitcoin’den önce Hashcash gibi proof-of-work mekanizmasını kullanan denemeler olmuştur. Fakat Bitcoini geçmişteki başarısız proof-of-work denemelerinden ayıran şey Nakamoto konsensüsünün kullandığı en uzun zincir kuralı (longest chain rule) olmuştur.
Sybil direnç mekanizmaları hakkında daha detaylı bilgi için şu yazıya göz atabilirsiniz. Ayrıca sybil direnç mekanizmaları ile konsensüs algoritmaları arasındaki farkı anlatan şu threade de göz atmanızı öneririm.
En uzun zincir kuralına göre düğümler her zaman en uzun zinciri doğru kabul edip o zincire blok eklemek için çalışırlar.
Aşağıdaki görsel üzerinden kuralı anlatmaya çalışalım:
Bir düğüm blokzincire 6a bloğunu yayınlarken bir başka düğüm aynı anda 6b bloğunu yayınlamış olsun. Ağdaki bu duruma çatallanma (fork) denir.
Bu anda ağdaki geri kalan düğümlerden bazılarına 6a bloğu önce ulaşmışken kalanlarına 6b bloğu önce ulaşır.
Düğümler hangi blok kendilerine önce ulaştıysa onun üzerine çalışmaya başlarlar ama diğer dalı olur da o dal daha uzun olursa diye bir kenarda tutarlar.
Eşitlik dallardan hangisine önce blok eklendiğine göre bozulur. Örneğimizde eşitlik 6a lehine bozulmuş olsun. Yani zincirimiz 6a’dan devam etmiş olsun.
Bu durumda 6b üzerine çalışan düğümler bu dal üzerinde çalışmayı bırakıp 6a dalına geçerler.
Bu kural Bitcoin’in yüksek sayıda katılımcı için ölçeklenebilir ve Bizans Hatasına Toleranslı ilk blockchain ağı olmasını sağladı. En uzun zincir kuralı ağ katılımcılarının ağa güvenmesini sağladı, katılımcılar arasında güven oluşturdu.
Nakamoto konsensüs algoritması ağlara, klasik protokollerde görülen deterministik sona ulaşmanın (deterministic finality) aksine olasılıksal sona ulaşma (probabilistic finality) sağlar. Bu genesis blok haricinde blokzincirde kayıt edilmiş her bloğun çok az da olsa küçük bir olasılıkla geri döndürülebilmesi demektir. Bunun sebebi ağda point-to-point iletişimin kurulmamasıdır. Nakamoto Konsensüs gossip protokolünü kullanır. Bu protokolle önceki konsensüs türlerinde bulunan onaylayıcı düğüm sınırını ortadan kalktı. Bitcoin’in izinsiz (permissionless) bir ağ olmasını sağladı.
Olasılıksal sona ulaşma fenomenine rağmen blokzincirde bir bloğu bile geri döndürmek yarısından fazlası dürüst düğümlerden oluşan bir ağda imkansızdır. Yani yeteri kadar merkeziyetsizliğin sağlandığı bir ağda işlemlerimizin geri döndürüleceğinden kaygılanmamıza gerek yoktur :)
Bitcoin’de kendinden sonra 6 blok gelen bloklar olasılıksal olarak finalize olmuş sayılır.
Nakamoto konsensüs algoritmasında klasik konsensüsten farklı olarak iş kanıtıyla bir lider mutlaka seçilir. Birden fazla lider çıkması durumunda da ağ çatallanır fakat yine de fikir birliğine varılır.
İlgilisine Nakamoto ile Paxos konsensüs algoritmaları arasındaki benzerliklere değinen şu yazıyı bırakıyorum.
Bitcoin senkron bir ağdır. Proof-of-work algoritmasıyla birlikte ağda 10 dakikada bir blok bulunur.
Nakamoto Konsensüsü dağıtık sistemlerdeki en temel sorunlara getirdiği çözümlerle hem dijital para birimlerinin önünü açtı hem de modern kriptografi alanında devrim yarattı.
Sırada son protokol olan Avalanche Konsensüs Protokolü var.
Team Rocket adında anonim bir ekip 2018 yılının Mayıs ayında “Snowflake to Avalanche: A Novel Metastable Consensus Protocol Family for Cryptocurrencies” adlı makaleyi yayınladı. Bu makale dünyaya yeni bir konsensüs protokol ailesini tanıttı: Snow protokol ailesi.
Bu yazıyı hazırlarken 2018’de yayınlanan makaleyi değil 2020 Ağustos’unda yayınlanan ve ilkinin daha kapsamlı hali diyebileceğimiz “Scalable and Probabilistic Leaderless BFT Consensus through Metastability” adlı makaleyi esas aldım.
Makale Snow protokol ailesini “lidersiz ve Bizans hatasına toleranslı metastabil (yarı kararlı) konsensüs protokol ailesi” olarak tanımlar.
Pokemon animesinde Team Rocket, dizinin ana karakteri olan Satoshi’nin baş düşmanıdır.
Snow protokol ailesi de Nakamoto Konsensüsü gibi ağdaki iletişimi sağlamak için gossip algoritmasını benimsemiştir. Dolayısıyla, protokol ağa deterministik değil olasılıksal sona ulaşma (probabilistic finality) sağlar. Metastabil mekanizmayla ve ağdaki düğümlerin tekrar tekrar gruplanmasıyla (repeated sampling) ağın ortak bir karara varması sağlanır. Şimdi pek anlam ifade etmese de bu tanım protokolün işleyişini anlattıkça daha anlaşılır olacaktır.
Avalanche protokolü Klasik, Paxos ve Nakamoto konsensüslerinin aksine lidersizdir.
Nakamoto konsensüsünün ana bileşenlerinden birinin “proof-of-work” algoritması olduğunu hatırlayalım. Snow konsensüsü Nakamoto konsensüsünde görüldüğü gibi kendi içinde bir sybil direnç mekanizması bulundurmaz. Protokol her türlü sybil direnç mekanizmasıyla uyumludur, yine de en uyumlu olduğu mekanizmanın makalede “proof-of-stake” olduğu belirtilir. Bu özelliğiyle Snow protokol ailesi çevre dostudur, harcadığı enerji “proof-of-work” sistemlere göre çok daha azdır.
Snow protokol ailesi dört protokolden oluşur:
Slush (Sulu Kar)
Snowflake (Kar Tanesi)
Snowball (Kartopu)
Avalanche (Çığ)
Şimdi protokolün sulu kardan bir çığa nasıl dönüştüğünü adım adım inceleyelim.
Metastabilitenin tanımlandığı aşamadır. Slush protokolü, Snow protokol ailesinin en temel yapıtaşıdır. Protokol Bizans Hatasına Toleranslı (BFT) değildir.
Düğümlerin kararlarını kırmızı ve mavi olmak üzere iki farklı renkte belirttiğini varsayalım.
Bir düğüm renksiz olarak başlar. İstemciden işlem alındığında düğüm, rengini istemciden gelen mesajın rengine günceller ve ağdan rastgele bir şekilde k sayıda düğüm seçer. Bu düğüm grubuna sorgu mesajı gönderir. Bu örnekte k sayımız 10 olsun. Düğümse kırmızı olsun.
Sorgu mesajını alan bir başka renksiz düğüm, rengini mesajdaki renge (kırmızıya) günceller ve kendi sorgu mesajını başlatır. Sorgu mesajını alan fakat hali hazırda rengi bulunan düğümse mesaja kendi rengiyle cevap verir.
Sorguyu başlatan düğüm gönderdiği sorgu mesajına gelen cevaplara bakar. Eğer yanıtların yarısından fazlası yani en az 6 tanesi maviyse, düğüm rengini maviye günceller. Eğer kırmızı cevaplar çoğunluktaysa baştaki rengi olan kırmızıda kalır.
Ağdaki düğümler bu adımları m kere tekrarlar. m adımın sonunda düğümün rengi neyse artık son kararı o renktir.
Yeteri kadar zaman verildiğinde ağdaki düğümlerin hepsi tek bir renge dönecektir. Diğer bir deyişle ağdaki tüm düğümler tek bir renkte anlaşmaya varacaktır.
Slush protokolü kırmızı ve mavi düğümlerin arasındaki dengenin günün sonunda bozulacağını varsayar. Metastabilite (yarı kararlılık) özelliği de buradan gelir. Protokolün Bizans Hatasına Toleranslı olmamasının sebebi ağdaki Bizanslı düğümlerin sistemi dengede tutarak ağda bir karar alınmasını engelleyebilmeleridir.
Sırada elimizdeki sulu kar parçasını Bizans Hatasına Toleranslı bir kar tanesine dönüştürmek var.
Snowflake’te Slush’a bir sayaç eklenir. Bu sayaç bir düğümün belli renge olan kararlılığını kaydeder ve ağın Bizans Hatasına Toleranslı olmasını sağlar.
Her düğümün bir sayacı (counter) vardır.
Her renk değişiminde sayaç sıfırlanır. Düğümümüz başta renksizken kırmızıya dönmüş olsun. Sayaç ilk durumda sıfırı gösterir.
Bir tur Slush uygulandıktan sonra düğümümüzün seçtiği gruptan yine kırmızı kararı çıksın. Sayaç 1’i gösterir. Bir tur daha kırmızı karar çıksın. Sayaç şimdi 2’yi gösterir. Düğümümüz şimdi daha koyu bir kırmızıdır, daha kararlıdır.
Sayaç önceden belirlenmiş bir β değerine ulaştığında artık son kararını vermiştir. Ne renginde ne de kararlılığında bir değişiklik olmaz.
❓ Sistem dengesini kaybetse de geri denge haline dönemez mi? Bu durumda işlemler sonlanmaz?
💡 Ağın kararı çoğunluk tarafa doğru eğildikçe, kararın azınlık tarafa doğru yönelme ihtimali üssel olarak azalır. Denge çok küçük farkla bile kaybedildiği anda sistemin geri denge haline dönme ihtimali çok düşüktür.
Şimdi sırada kar tanesine hafıza ve güven ekleyerek onu kartopuna dönüştürmek var.
Snowball, Snowflake’teki sayaçlara bir de güven sayaçlarını (confidence counters) ekler.
Düğümler her mesajdan sonra mesajdan aldığı renge göre o rengin güven sayacını bir arttırır.
Diğer renge olan güven sayısı, mevcut renge olan güven sayısını geçerse düğüm renk değiştirir.
Snowball, Snowflake’teki güvenliğe bir geliştirmedir. Düğümlere bir tür karar geçmişi mekanizması ekler. Düğümler verdikleri kararları hatırlar.
Kartopuna Yönlü Düz Ağaçlar (Directed Acyclic Graph (DAG)) ekleyerek onu çığa dönüştürürüz.
Avalanche’ın Snowball protokolüne Yönlü Düz Ağaçlar (DAG) eklenerek tamamlandığını söyledik. Önce DAG’ın ne olduğunu inceleyelim sonra Avalanche’ın bunu önceki protokollerle nasıl birleştirdiğine bakalım.
DAG bilgisayar biliminde veri modellemesi için kullanılan bir grafik gösterim yöntemidir. Gösterim köşeler (vertex) ve kollardan (edge) oluşur. DAG’ler yönlüdür (directed) çünkü kollar tek yöne doğru ilerler. Düzdür (acylic) çünkü kollar bir döngü oluşturmaz, başladığı köşeye geri dönmez. DAG yapısında her bir köşe bir işlemi temsil eder. Köşeler birden fazla işlem taşımaz, yani blok yapısı göstermez.
Blokzincirlerde bir bloğun önceki blok özetini taşıması gibi DAG’lerde de her işlem ağda kabul görmek için kendinden önce gelen işlem bilgisini taşımalı. Resim 9’dan örnekleyelim: d işlemi onaylanmak için kendinden önce gelen e işlemini işaret etmeli.
Sink (Türkçeye çukur olarak çevrilebilir) bağlantılı olduğu tüm kolların kendisine işaret ettiği köşedir. Avalanche’ta tek bir sink köşesi vardır. Bu sink ağın genesis vertexidir, ağdaki ilk işlemin bulunduğu köşedir.
DAG’de bir işlem (bir köşe), kendine bağlı olup kendinden önce gelen işlemlerin çocuğu (child), kendine bağlı olup kendinden sonra gelen işlemlerinse ebeveynidir (parent).
DAG’ı sürdürebilmenin önündeki en büyük zorluk “çatışan işlemler” (conflicting transactions) arasında seçim yapmaktır. Kriptoparalar çerçevesinde düşündüğümüzde aynı parayı harcayan işlemler çatışır. Çatışan işlemlerden sadece bir tanesinin kabul edilmesi gerekir.
Avalanche bu soruna her çatışan işlem grubunda (conflict sets) Snowball protokolünü çalıştırarak çözüm bulmuştur. Snowball tekrarlı sorgu sistemi ve sayaç sistemlerini kullanarak çatışan işlemlerin ayrı ayrı topladıkları güven oylarını kaydederken, Avalanche DAG yapısını ve çatışan işlemlerden sonra gelen nesilleri kullanır.
Ağa bir T işlemi yollayalım. Ağdaki bir düğüm T’den gelen sorgu iletisine sadece şu durumda olumlu cevap verir: T ve ona bağlı önceki nesil işlemlerin hepsi kendi çatışan işlem gruplarında tercih edilen seçenek olmayı başardılarsa. Eğer belli bir eşik değerinden fazla düğüm olumlu oy kullandıysa T işlemimiz bir “chit” kazanır.
Kendi de dahil olmak üzere kendinden sonra gelen nesillerdeki toplam chit sayısı o işlemin “güven” (confidence) değerini belirler.
Görseldeki her bir taralı alan bir çatışan işlem grubunu temsil eder. Bu demek oluyor ki taralı alanlardan sadece birer işlem kabul edilir.
⚠️ DAG yapıları blokzincirlerden farklıdır. Bu sebeple DAG’lar akıllı kontrat çalıştıramazlar. Avalanche Snowman konsensüs protokolüyle bu soruna çözüm getirmiştir. Snowman “doğrusal Avalanche” olarak tanımlanabilir. Bunun sebebi akıllı kontrat işlemlerinin katı bir sıralamaya ihtiyaç duymasıdır. Snowman blokzincir yapısı gösterir.
Yazımda önce “Konsensüs Protokolü Nedir?” sorusunu cevaplamaya çalıştım, sonra da bugüne kadarki temel konsensüs protokollerini -sırayla Klasik, Paxos, Nakamoto ve Avalanche’ı- anlattım.
Bir sonraki yazıda görüşmek üzere.
Bu yazının hazırlanma sürecinde aklıma takılan sorulara sabırla cevap veren Hakan Yalçınsoy’a teşekkür ederim. Bana sosyal medya hesaplarımdan ulaşarak yazıda hata bulunduğunu düşündüğünüz kısımları belirtebilir veya aklınıza takılan soruları sorabilirsiniz.
Twitter: memduhbayramm & ODTÜ Blockchain
https://cybersecurity.seas.wustl.edu/ning/paper/consensus19.pdf
https://cdn.relayto.com/media/files/LPgoWO18TCeMIggJVakt_tendermint.pdf
https://www.the-paper-trail.org/post/2009-02-03-consensus-protocols-paxos/
https://hknylcnsy.medium.com/konsensüs-protokolleri-ae1f7269648
https://hknylcnsy.medium.com/avalanche-konsensüs-protokolü-d6ceea06cec8
https://blog.itublockchain.com/consensus-ve-blockchain-8a7ae7d72eda
https://bitcoinmagazine.com/guides/what-is-nakamoto-consensus-bitcoin