Konsensüs komutunun alınması (Get consensus command)
Örnek olarak A düğümünü almaya devam edelim. Bu, Aelf’in en uzun zincirine 1 Ocak 2020'de 13:59:56'da senkronize edilen bir düğümdür. Yerel ana zincir kodunu değiştirmeden dürüst bir düğüm olan A, bir bloğu senkronize etti. Yani A; ağdaki diğer düğümlerden blokları alır, başarıyla doğrular ve yerel blockchain defteri bilgilerini değiştirir. Yerel en iyi zincir, yerel blok zincirinin veri yapısını korur. Güncellendikten sonra bir olay, Event Bus’a yüklenir. Bu olayın işlevlerinden biri, A düğümüne konsensüs hizmetine ilgili olay aboneliği ve işleme mekanizması aracılığıyla daha sonra ne yapması gerektiğini sormasını hatırlatmaktır. Bu sorgu sırasında “A” ortak anahtarını konsensüs hizmetine verdi.
Konsensüs hizmetinin temel mantığı, akıllı bir sözleşme olarak mevcuttur çünkü kodunun blockchain dünyasındaki her düğüm için tutarlı olmasını sağlar. Değilse, düğümün kötü amaçlı veya sert/mecburi çatallı olmaya çalıştığı anlamına gelir. Birkaç milisaniye karmaşık veya basit hesaplamalardan sonra konsensüs akıllı sözleşmesi, A düğümüne bir ileti geri gönderir. Bu bilgilerin oluşturulması konsensüs mekanizması seçeneklerine göre değişir, ancak herhangi bir konsensüs aşağıdaki yapıya sahip olmalıdır:
• “A” ne zaman blok oluşturabilir?
• “A” blok üretebiliyorsa, “A” daha fazla istekte bulunmak için hangi pozu kullanmalıdır: “A” mevcut konsensüs altında hangi blokları üretebilir? Bu bilgiye burada bir ekstra ipucu verin.
“A” blok üretemezse ne olur? Teorik olarak her düğüm, aslında blockchain dünyasında blok oluşturma potansiyeline sahiptir ancak konsensüs mekanizmasının farklı tasarımı nedeniyle (örneğin POS konsensüsü) bazı blok zincirleri çoğu düğümün blok üretme hakkına sahip olmasını istemez. Bu durumda, sadece 100 yıl sonra A'ya dönme süresini ayarlamanız gerekir, bu biraz abartı olabilir ancak birkaç ay sonra sorun olmayacaktır. “A” yüz yıl dayanabildiği ve bu yüz yılda yeni bir blok oluşturulmadığı sürece... (Herhangi bir geçerli yeni blok senkronizasyonu, A düğümünün blok çıkış zamanını geri kazanmasına neden olur.)
Bu arayüze dayalı bir PoW uygulamanın ne kadar kolay olacağını hayal etmek zor değildir. Zaman “hemen” olarak ayarlandığı sürece, ekstra bilgi istemi boştur.
AELF ana zincirinde konsensüs hizmeti, konsensüs geri besleme süresi bilgilerini öğrenir öğrenmez konsensüs zamanlayıcısını güncelleyecektir. Önceki konsensüs zamanlayıcısı boş değilse, yeni bir zaman noktasıyla doldurulmadan önce tamamlanmamış zamanlama bilgilerini temizlemelidir. Yani, konsensüs zamanlayıcısında yürütülmeyen yalnızca bir konsensüs görevi olabilir ve konsensüs zamanlayıcısı, tek bir nesnedir.
Daha sonra uzun geri sayım vardır.
Düğüm A örneğine dönelim. Diyelim ki A konsensüs sırası için talepte bulundu ve bir zaman aldı: 1 Ocak 2020 14:00, yani dört saniye sonra. Ekstra İpucu: Sonraki tur (bu, AEDPoS konsensüsünün bir ipucudur, yani A bu turun giden sürecini sonlandıracak ve bir sonraki turdaki tüm proxy giden düğümlerin giden sırasını güncelleyecektir.) Bu, zamanlayıcının dört saniye içinde bir üretim bloğu yürüten bir olayı derhal güncellemesi anlamına gelir. Bu dört saniyede ne yaparsın? Diğer düğümler tarafından gönderilen bloklar senkronize edilebilir ve doğrulanabilirse, bu olayın işlemcisini güncellemek için en iyi zinciri kullanın ve sürekli olarak konsensüs servisinden konsensüs komutunu isteyin (bu eyleme kodda TriggerConsensus adı verilir). Buna göre, konsensüs zamanlayıcısı sık sık resetlenir: 3.5 saniye, 3 saniye, 2.5 saniye, 2.5 saniye.
Saat 14:00:00. A düğümü, üretim bloğunu hazırlamaya başlamak için konsensüs zamanlayıcısının kontrolü altındadır. Bu noktada, önceki tasarımımıza göre, daha önce çalışmış olan blok çıkış süresi dışında bir bloğun nasıl üretileceğiyle ilgili bildiği tek bilgi, konsensüs hizmetinin verdiği ek ipuçlarıdır.
Aelf blok zincirinde bu noktada A düğümü, ek bilgi istemini konsensüs hizmetine iletir. İşlemin paketlenmesine ek olarak, diğer iki hizmet çağrılır:
• Konsensüs blok başlık bilgisinin alınması
• Bir Konsensüs sistemi işleminin alınması
Konsensüs komutları istemek için arayüzün işlevlerinden biri, üretilen bloğun doğrulamayı geçmesini sağlamaktır. Aelf’de bir blok için bir dizi doğrulama adımında iki konsensüsle ilgili doğrulama vardır: yürütmeden önce blok başlığının doğrulanması ve konsensüs sözleşmesi durumunun değişiklik bilgilerinin yürütme sonrasında blok başlığındaki bilgilerle tutarlı olup olmadığının doğrulanması.
Basit bir benzetme yaparsak, bir .NET programcısı DNT çevrimdışı salona gider ve kontrol için salon düzenleyicisine davet mesajını gönderir. Bu mesaj, blok başlığına benzerdir; yani davet mesajını alamazsa, organizatör katılmasına izin vermez. Daha sonra, sponsor .Net programcısından cep telefonu numarasını bildirmesini ve bir blok zincir düğümünde bir konsensüs işlemini doğrulamaya benzer olan katılımcıların listesini aramasını isteyecektir. Sadece bu adım doğrulanırsa, .Net programcılar bu salona sorunsuz bir şekilde katılabilir.
Sonuç olarak, hizmetler için get consensus komutu gibi üç arayüze ihtiyacımız var. Protobuf açısından açıklanması:
Zincir güvenliği ve istikrarı için ConsensusCommand'da sadece bir sonraki blok oluşturma süresi (arranged_mining_time) ve Ekstra İpucu (hint) değil, aynı zamanda limit blok üretme süresi (limit_milliseconds_of_mining_block) ve en sonuncu yayın zamanı (mining_due_time) vardır. Son ikisi, belirli bir zaman sınırının aşılması durumunda üretilen bloğun yayınlanmasının gerekmediğini anlamak için blok üretim hizmeti için referans olarak kullanılır (veya diğer düğümler bunu yayınlasa bile, aşağıda ele alınacak arabirim türünün özel uygulamasında garanti edilen doğrulamayı geçemez). Boşuna bir blok oluşturmak, bloğun üretim düzenini bozmaktan daha iyidir.
Blok Doğrulaması
İstek konsensüs komutu ayrıntılı olarak tartışılmaya değerse, blok doğrulamayla ilgili arayüz hakkında övgüde bulunacak hiçbir şey yoktur. Aslında doğrulama mantığı, konsensüsten tamamen farklıdır.
Arayüzün kendisinde yeni bir fikir yoktur. Biri, konsensüs işlemi yürütülmeden önce blok başlığını doğrular. Diğeri ise konsensüs değişikliği durumunun konsensüs işlemi yürütüldükten sonra blok başlığında vaat edilen bilgilerle tutarlı olup olmadığını doğrulamaktır. İki doğrulama arayüzünün giriş parametreleri ikili dizilerdir; yani arayüz, herhangi bir veriyi kabul eder ve doğrulamanın özel uygulamasında seriden paralele çevirmek için sadece konsensüs uygulayıcısına ihtiyaç duyar.
KAYNAK: https://medium.com/aelfblockchain/aelf-tech-talks-consensus-and-standard-interpretation-pt-2-c9bbe36ddc32