Bu makale, Mina Protocol’ün, çoklu katılımcı ve kötü niyetli eşlerin var olması durumunda blockchain stateinin paylaşılabilir olması ve geçerliliğini nasıl sürdürdüğüne dair kısa bir özettir.
Bir blockchain, bir ağ tarafından tutulan dağıtılmış bir defterde, hareketleri ve durum değişikliklerini bir araya getiren bloklardan oluşur. Ek olarak, tüm bloklar, bir blockchaini kurcalanmaya/değiştirilmeye karşı korumak için gerekli olan önceki bloğun hashini de içerir. Bu öğeler bir araya gelerek dijital defteri oluşturur. Ancak bu, zincirin geçerliliğini sürdürmek için tek başına yeterli değildir. Blockchaindeki diğer önemli unsur, defterin herhangi bir merkezi otoritenin kontrolü altına girmemesini sağlamaktır. Bunun sağlanmaması durumunda zincir, merkezi bir yapı tarafından kontrol edilen bir veri tabanına benzer şekilde çalışır.
Bu senaryodan kaçınmak için defteri güncelleme sorumluluğu ağdaki nodelar arasında paylaşılır. Dağıtılan karar verme süreciyle birlikte, tüm katılımcıların defterdeki verilerin veya durumun meşruiyeti üzerinde uzlaşmaya varması için bir yola ihtiyacı vardır. Bu, ağdaki tüm nodeların/eşlerin nihayetinde aynı görüşü paylaştığından emin olmak için bir konsensüs mekanizmasının gerekli olduğu yerdir.
Mina’da konsensüs algoritması, Cardano’nun Ouroboros proof of stake (PoS) algoritmalarından esinlenmiştir. Bu algoritmanın adı, Sanskritçe’de kısa ve öz anlamına gelen Ouroboros Samasika’dır (संक्षिप्त).
Forklar ve konsensüs
Eşler arası bir ağda her nodeun birbirinden bağımsız olması nedeniyle konsensüs, nodeların ortak ve geçerli görüş elde etmesini sağlayan anahtar mekanizmadır. Bir nodeun statei güncellemesi için her node, eşlerinden en son blokları ister. Blokları aldıktan sonra, konsensüsteki kilit aşamalardan biri, belirli bir nodeun, zincirini hangi zincirin veya bloğun üzerine kuracağını seçerek doğru zincire nasıl ulaştığıdır. Bu seçim, ağda geçici bir forkun, yani birçok çakışan zincirin doğmasına neden olabilecek şeydir. Forklar birçok nedenden dolayı ortaya çıkabilir:
- Nodeun çevrimdışı olması
- Ağ gecikmesi
- Protokol yükseltmesi (soft/hard forklar)
- Kötü amaçlı nodelar
- Çoklu teklifler — Ouroboros, Bizans Hata Toleransı (BFT) ile çalışmaz ve seçimler, ağ genelinde değil blok üretici seviyesinde yapılır
Bitcoin’in proof of work (PoW) algoritmasının aksine Mina, forkta kanonik bir duruma ulaşmak için PoS konsensüs algoritmasını kullanır. Mina Protocol’de konsensüs bağlamını anlatmak için için şimdi, ağdaki diğer eşlere göre state senkronizasyonu gerçekleştiren bir nodeun döngüsüne kısaca değineceğiz.
Bir nodeun senkronizasyonu
Bu bölüm, standart bir blockchain nodeu için önyükleme sürecini anlatır ve Mina’ya özgü değildir. Ağa katılan yeni bir node durumunu işleyeceğiz.
Bir node (örneğin X) her zaman ağın genesis bloğu ile başlar.
Genesis bloğu, tüm nodeların ilk state değişimi olarak kabul edebileceği tek bloktur. Genesis blok parametreleri genellikle nodeda sabit kodlanmıştır. X nodeu ağdaki eşlere bağlanırken, bir önyükleme moduna girer ve ağ ile geçerli zincire veya en son geçerli state değişimine eşitlemeye çalışır. Bu süreçte, ağdaki diğer eşler ağın farklı görünüşlerine sahip olabilir. Sonuç olarak, X’e ağdaki tüm olası zincirler veya durum değişimleri sunulur. Geleneksel bir blockchain/kripto para birimi uygulamasında X nodeu, yalnızca en son blokları baz alarak hangi kolun seçileceğini söyleyemez.
Aynı durum, örneğin bir yıldır çevrimdışı olan ve ağa senkronize olmak için yakın zamanda kendini yeniden başlatan bir node için de geçerli olacaktır.
Bir nodeu senkronize etmenin 2. yolu, nodeun çevrimdışı olduğu zamandır. Çevrimdışı olduktan sonra, bir node (örneğin Y) başlatıldığında, n sayıda zincir alır ve şimdi aralarında seçim yapması gereken çok sayıda zincire sahiptir (bunlara aday zincirler diyelim). Şimdi sözkonusu ağ, herkesin katılabileceği merkeziyetsiz bir ağ olduğu için geri alınan bir aday zincirin, genesis bloktan kendi geçmişini yaratan ve geçerli zincire kıyasla daha fazla veya eşit sayıda bloğa sahip kötü niyetli bir nodedan gelen bir zincir olması da söz konusu olabilir. Bildiğimiz gibi bu durum, ağda bir çatallanma yaratır. Bir nodeun, sözkonusu slotta yetkilendirilmemiş ya da PoW gereksinimini karşılamayan bir blok üreticisinin gönderdiği veya geçersiz bir işlem içeren açıkça yanlış bir zinciri kabul etmesini engelleyen yerleşik konsensüs kontrollerine de sahip olduğunu unutmamak önemlidir. Bu tür zincirler her zaman düzgün işleyen bir node tarafından reddedilecektir.
Forklar, ağı geliştirmek/yükseltmek için kasıtlı olarak yapılabilir veya kötü niyetli olabilir. Kötü niyetli bir fork olması durumunda, forkun ne kadar geriye gittiğine bağlı olarak, bunları iki türe ayırabiliriz:
- blockchainin uzun zaman önce çatallandığı uzun menzilli bir fork
- veya forkun en son blokların yakınında oluşturulduğu kısa menzilli bir fork
Aralarında ayrım yapmak, doğru ve kanonik zinciri seçmek için Mina, aşağıdaki yaklaşımı uygular;
- Kısa menzilli ve uzun menzilli fork arasında ayrım yapar
- Fork süresine bağlı olarak, kısa menzilli fork veya uzun menzilli fork kuralını uygular
Bir sonraki bölümde bunları kısaca ele alacağız. Ama bunları açıklamadan önce Mina’daki epoch kavramını anlamak önemlidir.
Kısaca Mina konsensüsü
Mina’nın konsensüse nasıl ulaştığını anlamadan önce, Ouroboros konsensüs algoritmaları ailesindeki epoch kavramını anlamamız gerekiyor. Tüm Ouroboros konsensüs algoritmaları, zamanı slotlara ve epochlara böler. Epoch, Mina ağında meydana gelen olayları ve durum güncellemelerini sınıflandırmak ve tanımlamak için kullanılan ayrı bir zaman dilimidir.
Ağdaki önemli olayları ölçmek için validatörler kümesindeki değişiklikleri (anahtar döndürmeler, yeni validatörler, silinen validatörler) işaretlemek için bir epoch kullanılır. Başka bir deyişle, epochlar stake dağılımları ve rastgelelik arasında sınırlar sağlamak için vardır, böylece ek kurallarla stake dağılımları ve doğrulanabilir rastgele fonksiyon (VRF) rastgeleliği, bir düşman tarafından manipüle edilemez.
Her epoch ayrıca slotlara bölünmüştür. Bu slotlar içerisinde bir blok üreticisi bir blok üretmek üzere seçilebilir. Aşağıdaki diyagramda, sol tarafta mevcut kanonik zincir yer almaktadır. Konsensüs sırasında belirli bir dönem için, 1 ila 4 arasındaki yuvalarda birkaç blok üretilmiştir, ancak yalnızca kanonik blok dikkate alınacaktır. Aynı slotta üretilen birden fazla blok arasında geçerli olanı seçmek ve kanonik zincirin nasıl genişletileceğine karar vermek için zincir seçim algoritması, diğer adıyla ouroboros samasika kullanılır.
Ouroboros konsensüs algoritmaları ailesi, forkları çözmek için genesise kadar uzanan zincir geçmişine dayanır. Ancak Mina bir succinct blockchain olduğu için (önceki blokların tüm geçmişi, özyinelemeli snark kanıtları kullanılarak tek bir sınırlı boyutta birleştirilir), tarihsel bilgimiz yok. Bunun yerine Mina, nodeun ağdaki forkları tanımlamasına yardımcı olmak için epochlar etrafında kontrol noktaları kullanır.
Kontrol noktasına giriş
Mina, aday zincirler arasında karar verirken forkun kısa menzilli mi yoksa uzun menzilli mi olduğuna karar vermek için merkeziyetsiz kontrol noktası adı verilen bir kavram kullanır. Bir fork, n bloktan daha kısa bir süre önce meydana geldiyse kısa menzillidir. Mina bir succinct blochain olduğu için, forkları çözmek için son birkaç yüz bloğun geçmişini baz alır. Ayrıca, son birkaç yüz bloğun bilgileri, üst bloğun konsensüs verileri içinde yer alır.
Bunu başarmak için, her epoch eşit sayıda slot ile üç parçaya bölünür. Epochun ilk 2/3’üne tohum güncelleme aralığı denir, çünkü burası VRF’in başlangıç bilgisinin verildiği yerdir. VRF’i kriptografik bir piyango olarak düşünün. Bir VRF seedi, yinelenen hashler almamamızı sağlar.
Doğrulanabilir Rasgele İşlev (VRF), çıktıların doğru hesaplandığına dair kanıt sağlayan açık anahtarlı bir random sayı üretim fonksiyonudur.
Merkeziyetsiz kontrol noktası fikri, her zincirin her epochta iki kontrol noktası bulundurmasıdır. Bu kontrol noktaları basitçe önceki blokların konsensüs stateinin (state hashi) hashidir ve genesis blokta sabit kodlanmış değerler olarak başlar. Bu kontrol noktaları, bir forkun ne kadar süre önce oluştuğunu tahmin etmek için kullanılır:
- Başlangıç kontrol noktası — Epochun ilk bloğunun state hashi
- Kilit kontrol noktası — Epochun tohum güncelleme aralığındaki bilinen son bloğun state hashi (mevcut blok hariç epochun ilk 2/3’si)
Yukarıdaki state hashlerini kullanarak kontrol edince, aşağıdaki durumlardaki bir fork, kısa menzilli olarak kabul edilir:
- aday zincirlerin fork noktası aynı epochta
- veya fork noktası aynı lock_checkpoint ile önceki epochta
Önceki epochun lock_checkpoint’inden önceki her şey uzun menzilli bir forktur.
Kısa menzilli bir forkumuz olduğunda, en uzun zinciri seçiyoruz. Aksi takdirde, bu bir uzun menzilli forktur ve aday zincirler arasında karar vermek için ek statelere güvenmemiz gerekir. Bu, zincir yoğunluğu adı verilen konsensüs stateindeki bir kısım tarafından halledilir.
Kayar pencere ve zincir yoğunluğu
Özetlemek gerekirse fork, önceki epochun kilit kontrol noktasının ötesinde olduğunda, uzun menzilli bir forkumuz olur.
Uzun menzilli bir fork durumunda, kötü niyetli node sonunda daha yoğun bir zincir oluşturur. Bununla birlikte, kötü niyetli fork gerçek ağdan daha az aktif staked balansa sahip olacağından başlangıçta kötü niyetli node daha düşük bir yoğunluğa (veya kurallı zincire eşit bir yoğunluğa) sahip olacaktır. Bu nedenle, kritik pencere olarak adlandırılan forku takip eden ilk birkaç slottaki yoğunluk farkına güvenebiliriz. Buradaki fikir, dürüst bir zincirin kritik penceresinin yoğunluğunun bu pencerede ezici bir çoğunlukla daha yüksek olması gerektiğidir çünkü bu zincir staked balansın çoğunluğuna sahiptir.
Bu kritik pencere, kötü niyetli bir nodeun ağı forklamaya çalışması durumunda ana zincir daha fazla blok üreteceği için bir süre daha düşük yoğunluğa sahip olacağı zaman dilimidir. Dolayısıyla bu pencerede, dürüst zincirin minimum pencere yoğunluğu daha yüksek olurken, rakip zincirin yoğunluğu çok daha düşük olacaktır.
Uzun menzilli fork kuralı, ağın forku çözmesine izin vermek için kritik pencere yoğunluğu değerini kullanır ve daha yüksek minimum yoğunluğa sahip zinciri seçer. Bununla birlikte, ilgi olması durumunda gelecekteki bir blog yazısında ele almayı planladığımız, bunun nasıl gerçekleştiğine dair pek çok önemli ayrıntı var. Meraklıları için, Mina’nın Ouroboros Samasika konsensüs algoritmasının yapısını anlatmak için güncellenmeye devam eden bir kaynak durumundaki teknik tanım metni daha fazla ayrıntıya giriyor.
Çözüm
Zincir seçimi, stabil bir node işlemi için gereklidir ve ağdaki tüm nodeların fullstateine ilişkin birleşik bir görüşe sahip olmasını sağlar.
Bunun ötesinde, Mina’nın konsensüs stateinin kontrol noktası ve kayan pencere yoğunluğu bileşenleri için birçok özel ayrıntı var. Daha fazlasını öğrenmek istiyorsanız, lütfen yorumlarda bize bildirin.
