Avalanche Konsensüs Protokolü
Bu yazı, “Konsensüs Protokolleri” yazı serisinin bir parçasıdır, ilk yazıya buradan ulaşabilirsiniz.
“Snowflake to Avalanche” makalesi, 2018 Mayıs ayı ortasında kendilerini yalnızca Team Rocket olarak tanımlayan bir ekip tarafından anonim olarak yayımlandı. Makale, 4 protokolün oluşturduğu bir protokol ailesinden bahsetmektedir. Bu 4 protokol;
- Slush (Sulu Kar — Bulamaç)
- Snowflake (Kar Tanesi)
- Snowball (Kar Topu)
- Avalanche (Çığ)
Makale kendisinden “Kripto para birimleri için yeni metastabil(yarı kararlı) konsensüs protokol ailesi” olarak açıklıyor.
Makale bunun klasik konsensüs protokolleri ve Nakamoto konsensüs protokollerinin önceki ikilisinden ayrı duran yeni bir protokol türü olduğunu iddia ediyor. Makale bunları şöyle açıklamaktadır:
Klasik Konsensüs: Fikir birliğine ulaşmak için tüm düğümlerin diğer tüm düğümlerle iletişim kurması gerekir.
Nakamoto: Her bloğu üretmek için bir liderin (madenci) seçildiği İş Kanıtı yoluyla konsensüse ulaşır.
Avalanche ise, bu iki aileden herhangi bir biçimde bir lider seçmeye gerek kalmadan (dolayısıyla lidersiz), protokolün tüm düğümlerini konsensüse “yönlendirdiğini” söylüyor.
Bu yaklaşım kısmen Avalanche’ın metastabil mekanizması ile elde edilir. Metastabilite ise esasen tüm düğümlerin bir şekilde oylamaya katılacağı şekilde tasarlandığı kavramını ifade eder ve böylece sistem dengede kalmaz (çünkü sistem dengede kalırsa, konsensüs elde edilemez).
Bu sayede klasik ya da Nakamoto konsensüs ile aynı güvenlik seviyesine ulaşır fakat daha hızlı bir şekilde sonuçlandırır. Herhangi bir lidere ihtiyaç duymadan tüm düğümleri bir konsensüse yönlendirerek fikir birliğine vardırır.
Bunu, küçük gruplar oluşturarak ve küçük rastgele örnekler oluşturarak yapar. Bu da sonuçta bir araya gelmeden ve zaman içinde kapsayıcı bir fikir birliğine varmadan önce daha yüksek verim ve paralel fikir birliği yapılmasını sağlar.
Avalanche’in bize sağladığı garantiler;
Emniyet (Safety): Hiçbir güvenilir düğüm çakışan işlemleri kabul etmez.
Canlılık (Liveness): Yapılan tüm işlemler sonunda her doğru düğüm tarafından kabul edilir.
Avalanche’in bize vadettikleri;
Hızlı sonuçlandırma ve düşük gecikme süresi: İşlemi sonuçlandırma yaklaşık 2 saniye sürer. Bu, temel olarak 2 saniye sonra ödemenizin işleme koyulup onaylanabileceği anlamına gelir.
Yüksek verim: Saniyede 1000–10000 işlem.
Direnç: Ağın, katılımcıların yadsınamaz bir fikir birliğine varılacağı konusunda anlaşması gerekmemesi.
Fikir birliği, BFT (Bizans hata toleransı) olmayan Slush ile başlar ve zamanla Snowflake, Snowball ve Avalanche’ı oluştararak BFT ve geri dönülemez bir yapı oluşturur.
Tohumlar fidana, fidanlar ağaca, ağaçlar ormana dönmeli yurdumda — Mahir Dinçer (Yurdumda şarkısı)
Slush: Metastabilite Tanıtımı
Makaledeki analojiye göre; kırmızı ve mavi olmak üzere birbiriyle farklı iki renk arasında bir karar verilmesi şeklinde anlatılır.
Adım adım anlatmak gerekirse;
1- Bir düğüm başlangıçta renksiz bir durumda başlar. Bir işlem(transaction) alındığında, renksiz bir düğüm kendi rengini işlem içinde taşınan renge günceller, ardından ağdaki düğümlerden ağ üzerinde tanımlı k parametresi (örneğin 6) kadar bir düğüm grubu seçer, sorgu iletisi gönderir.
2- Sorgu alındığında, renksiz bir düğüm sorgudaki rengi (örneğin kırmızı) benimser, bu renkle yanıt verir ve kendi sorgusunu başlatırken, mevcut rengiyle yanıt verir.
3- Bu kırmızı düğüm şimdi diğer düğümlerden bir düğüm grubu seçer. (tekrar 6 diyelim). Bu altı tanesi renklendirilmemişler ise kırmızıya güncellenir fakat zaten önceden renk seçtiyse mevcut rengiyle cevap verir yani mavi düğümse mavi ya da kırmızıysa kırmızı olduklarını belirterek yanıt verir.
4- Düğümümüz yeterince yanıt aldığında, önceden tanımlanmış düğüm eşiğinin aynı renk için olup olmadığını kontrol eder. Evet ise kırmızı olarak kalır ya da sorgusuna yanıt veren diğer düğümlerin beklenen eşik kadar mavi yanıt verdiyse maviye döner.
5- Düğüm daha sonra aynı şekilde farklı bir düğüm örneğiyle başka bir sorgu gerçekleştirir. Bu sorgulama, yeterli düğüm aynı rengi seçinceye kadar ağda tekrar tekrar olur.
6- Yeterli zaman verildiğinde, hepsi sonunda aynı renge dönecek ve fikir birliği sağlanacaktır.
Dikkat edilmesi gereken; düğümlerin doğru rengi seçtiklerini ya da rastgele oy vermediklerini bilememizdir, bu yüzden BFT değil diyoruz.
Snowflake: BFT
Snowflake, sisteme bir sayaç ekleyerek Slush’ın BFT olmasını sağlar ve düğümlerin renkleri konusunda daha kararlı olmasını sağlar.
1- Her düğüm bir sayaç çalıştırır.
2- Düğüm her renk değiştirdiğinde sayaç sıfırlanır.
3- Düğümler her başarılı sorguda bu sayıcı 1 artırır.
4- Ağ üzerinde tanımlı β sayısına ulaşıldığında düğümün rengi kesinleşmiştir.
Buradaki ilginç nokta; dürüst düğümlerin iki renk arasında kalma durumdan ziyade bir karara yönelme olasılığının daha yüksek olduğu bir nokta olduğunu göstermektedir. Ayrıca, bir kararın kaçınılmaz olduğu, dönüşü olmayan bir nokta olduğu anlaşılmaktadır. Bizans düğümleri, eşiği (faz kaymasını) geçtikten sonra kontrolü kaybeder ve dürüst düğümler, aynı renkte fikir birliğine varmaya başlar.
Snowball: Güven Eklemek
Snowball, Snowflake üzerine artık güveni inşa etmek için, ayrıca “güven sayaçlarını” ekler. Bu güven sayaçları, kırmızı ya da mavi sonucu veren her sorgudan sonra, düğümün ilgili renk için oluşturulmuş güven sayacını bir arttırır. Geçerli renge olan güveni diğer rengin güven değerinin altına düşerse renkleri değiştirir.
Oyun içindeki hakikati tartışan üç beyzbol hakemi varmış. Birinci hakem, “Gerçekleri görür görmez söylerim” demiş. İkinci hakem, “Gerçekleri olduğu gibi söylerim” demiş. Nihayet, üçüncüsü “Ben söyleyene kadar ortada bir gerçek yoktur” demiş. -Leonard Smith / Kaos
Avalanche: DAG Eklemek
Avalanche, protokole DAG(Directed Acyclic Graph) eklendiği ve kriptopara özelliği kazanması için gerekli kontrollerin yapıldığı son adımdır.
DAG, Yönlü Düz Ağaçlar olarak Türkçe’ye çevrilen, matematiksel grafik gösterim yöntemidir. Grafik üzerindeki noktalar(nodes) birbirine bağlıdır ve noktaları bağlayan kollar(edge) asla bir döngü oluşturmamaktadır. Noktalar ise üç çeşide ayrılır; kaynak, normal ve sink (Türkçe’sini bulamadım)
Not: DAG’lerde kullanılan “node” kelimesini ağ üzerindeki bilgisayar olan “node(düğüm)” ile karıştırılmasını engellemek içi “nokta” olarak çevirdim.
Eğer noktadaki bütün kollar kendisini işaret etmiyorsa bu, kaynak noktasıdır.
Eğer noktadaki bütün kollar kendisini işaret ediyorsa bu, sink noktasıdır.
Her iki türlü kol barındıran noktalara ise normal nokta diyoruz.
Bu bağlamda Avalanche üzerinde oluşturulacak ilk işlem (genesis transaction) bir “sink noktası” olacaktır.
Bundan sonra oluşturulacak işlemler ilk işlemin çocukları(child) olacaktır. Yani ilk işlem sonraki işlemlerin ebevenyni(parent) olacaktır. Şöyle ki; kullanıcı bir işlem(transaction) gerçekleştirdiğinde, DAG üzerinde bir nokta oluşturulur ve bu nokta bir veya birden fazla noktayla ile bağlanır yani parent noktalarını seçer fakat bu transactionların birbiriyle ilişkisel olmasına gerek yoktur, örneğin; transactionların aynı kişi tarafından oluşturulmuş olması gerekmez ya da noktaların birbirinin fonlarına müdahale etme yetkisi de yoktur. Avalanche makalesinde ise işte bu DAG’a eklenecek noktaların parent seçme meselesi ele alınmıştır.
Bir kriptopara oluşturmak istiyorsak çift harcama(double-spending) olmamalıdır. Yani aynı fonu birden fazla kez harcamak istersek bu işlemler birbiriyle çakışmamalı ve sadece bir tanesi geçerli olmalıdır. Bir çakışan işlemin tespiti DAG’ın oluşturulmasından farklıdır, ancak protokolün konsensüs güvenliği için bu çakışmaların kontrol edilmesi gerekir.
Bahsettiğimiz gibi Snowball, çakışan işlemlerde oluşturulan güven miktarını yakalamak için tekrarlanan sorgular ve birden fazla sayaç kullanıyordu(renkler), Avalanche ise DAG yapısından yararlanır ve bir işlemin kökenini kullanır.
Örneğin; bir T transactionı sorgulandığında, T’ye bağlı kolları(edge) izleyerek ona bağlı noktalar bulunur ve bu noktalar da sorgunun bir parçası haline gelir. Sorgu atılan düğümlerden belli bir eşikten(β1) fazlasının olumlu oy kullanıyorsa (mesela 11), işlemin bir chit(biz buna oy diyelim) topladığı söylenir. Düğümler daha sonra bu T transactionun soyunun oy değerlerinin toplamını alarak “güvenlerini” hesaplar.
Makalede yer alan yukarıdaki grafik üzerinden yorumlarsak; T2 transactionının güven değeri(5) T3’ten fazladır. Bu yüzden T2’ye bağlı transactionların(T4, T5, T8, T9) T3’e bağlı olan transactionlardan(T6, T7) daha fazla oy toplaması olasıdır.
Bu işlem Slush, Snowflake ve Snowball’da daha önce tartıştığımız özellikleri kullanır. Düğümler, işlemlerde oy toplamak ve diğer düğümleri yeni işlemler hakkında bilgilendirmek için diğer düğümlerin rastgele örneklerine sorgular gönderir. Düğüm, bir işlemin ve tüm ata işlemlerinin rakip işlemler arasında tercih edildiğini görürse, işlem “şiddetle tercih edilen” hale gelir ve bir evet oyu alır. İşlem veya ataları düğümler tarafından tercih edilmezse oy alamaz.
Alternatif olarak, T transactionı önceden belirlenmiş belli bir eşikten(β2) fazla Snowball güven sayaç değerine (mesela 150) sahipse bu işlem de “tercih edilen işlem” kabul edilir.
Örneğimize göre, düğümler kırmızı ve mavi yerine, işlemin doğru olup olmadığı veya başka bir işlemle çakışıp çakışmadığı konusunda bir karara varır. Bu nedenle Avalanche, çift harcamayı çözmek için DAG üzerinde Snowball yaklaşımını kullanıyor diyebiliriz.
Bu yazıda, Sadece konsensüs yapısını anlatmaya çalıştım ve umarım bu yazı sayesinde Avalanche Konsensüs Protokol Ailesi’ni biraz daha iyi anlayabilmişizdir. Emin Gün Sirer ve takımının geliştirdiği Avalanche konsensüs kullanacak $AVAX’a yer vermedim, bu başka bir yazının konusu olacak.
Ayrıca bu yazı, “Konsensüs Protokolleri” yazı serisinin de son yazısıdır. Belki ileride bonus ya da destekleyici yazılar eklenebilir.
Okuduğunuz için teşekkür ederim.
Hoşça Kalın,
Hakan.
Twitter: hknylcnsy
Referanslar:
- https://avalanchelabs.org/avalanche.pdf
-https://tedyin.com/archive/ava-udc.pdf
-https://medium.com/@vardan.sevan/avalanche-examples-of-consensus-protocols-9ddc5b006264
- https://flatoutcrypto.com/home/avalancheprotocolpart2
