[Aelf Geliştirici Topluluğu]
Bölüm 2
ACS: AElf sözleşme standardı, AElf akıllı sözleşmeleri geliştirirken kullanılması gereken bir arayüzdür.
Tüm ACS'ler, protobuf servisi tarafından tanımlanır. Bu makale özellikle, herhangi bir konsensüs sözleşmesi uygulanırken ACS’lerden biri olarak kullanılması gereken ACS4’e bakacaktır. Bu makale, bir konsensüs standart arayüzünün ve bir konsensüs sözleşmesinin uygulanması için AElf tarafından sağlanan diğer destek araçlarının uygulanabilirliğine odaklanmaktadır.
Soyut konsensüs düşünce
Başarılı bir Blockchain konsensüsünün perspektifinden bakıldığında, biz üç yönden ilgi duyuyoruz:
- Kim blok üretebilir? Örneğin, PoW konsensüs herkesin güç rekabetine katılmasına izin verirken, PoS ve DPoS konsensüs belirli kısıtlamalar uygulamalı
- Bir düğüm bir blok üretmeye uygunsa, ne zaman üretilmeli ve hemen yayınlanmalı mı
- Tam bir blockchain düğümü olarak biri, bir bloğun meşruluğunu nasıl doğrular?
Bu üç nokta için, kolayca üç tür arayüz düşünebiliriz:
- Açık (public) anahtarla ilişkilendirilmiş üreticinin bir blok oluşturmaya uygun olup olmadığını belirlemek için açık anahtar girilmesi... PoW konsensüsü bu durumda daima doğru (true) döndürür. Uygun düğümler kısıtlandığından DPoS çoğu kullanıcı için yanlış (false) döndürür.
- Açık anahtarı girilmesi… açık anahtarın bir blok oluşturabildiği sonraki zamanın zaman damgasını döndürür veya açık anahtarın şu anda bir blok oluşturabildiğini döndürür.
- Tam düğüm blok başlığını aldıktan sonra, ondan çıkarılan konsensüs verilerini girilir ve yukarıdaki 2 ilgili blok bilgisinin parçaları doğrulanır. PoW konsensüsünün şimdiki zamanın yasallığını doğrulaması için gereken şey budur ve DPoS konsensüsünün yeni bloğun üreticisini doğrulaması gerekir. Bloğun yasallığı, üreticinin zaman dilimine saygı gösterip göstermediğine ve doğrulama sonuçlarına bağlı olacaktır.
Ek olarak blok başlığında konsensüs verilerinin elde edilmesi için, tam düğüm tarafından doğrulama için gerekli olan gibi, bu verinin üretilmesi için bir yöntemin blok üreticisine sağlanması gerekmektedir.
AElf Ekosisteminde Uygulama
Öncelikle, AElf’in ana zincirinin konsensüsü DPoS’tur. Her ne kadar bu makale genel konsensüs arayüzünü tartışsa da kaçınılmaz olarak (AE) DPoS ortamı hakkında daha fazla şeyler içerecektir.
Konsensüs sözleşme standardı üzerindeki tüm arayüzler salt okunurdur, çünkü verileri elde etmek için WorldState'i değiştirmeye gerek yoktur. (WorldState, Ethereum'da bir kavramdır.)
Not: AElf, sözleşmenin durumunu State DB olarak depolamak için kullanılan veritabanına başvurur; buna ek olarak Chain DB, bloğun içindeki işlemler de dahil olmak üzere bloğun kendisini saklamak için kullanılır.
Arayüz 1 ve arayüz 2, yeni ve birleşik bir arayüz elde etmek için ACS4'te birleştirildi.
NextBlockMiningLeftMilliseconds'ın değeri, ExpectedMiningTime ve geçerli saat (arayüzün çağrıldığı zaman) arasındaki farka bağlıdır.
LimitMillisecondsOfMiningBlock, sistemin bu blok için ne kadar kullanıcının bu blok tarafından paketlenebileceğini belirleyen paketleme için ayırdığı zamandır (paketlenmiş kullanıcının işlemi göndermesi ne kadar sürer).
Hint alan, bazı ayrı durumları geçmek için kullanılır. PoW'da olduğu gibi seçilen konsensüs protokolüne bağlı olarak, bu alan gerekli olmayabilir. AEDPoS; Normal Blok, Ekstra Blok ve Küçük Blok gibi bazı blok tiplerini tanımlar (sadece az miktarda konsensüs bilgisini günceller). Bunların Hint'e yansıtılması gerekir - konsensüs sözleşmesi yalnızca blok üreticisine ne kadar önce bloğu oluşturmaya başlayabileceğini değil, aynı zamanda hangi blok türünün üretilmesi gerektiğini ve farklı blokların farklı konsensüs bilgileri ile güncelleneceğini de söylemelidir. Ayrıca Hint alanının tanıtılması, diğer konsensüs protokollerini uygulamak için daha fazla olanak sağlayabilir.
Bu arayüz, zincirin başında yerel en iyi dalda yeni bir bloğu senkronize edecektir (bloğun kendisi tarafından oluşturulup oluşturulmadığına bakılmaksızın) ve blok üreticisi, kendi bloğunu gerçekleştirmeden önce doğrulama sırasında mevcut zamanın kendi slotunu aştığını (yani ValidateConsensus Be) anlayacaktır. Daha sonra ForeExecution arayüz çağrılır.
Çağrıdan sonra Konsensüs Hizmeti, NextBlockMiningLeftMilliseconds'ı konsensüs zamanlayıcısına iletecek ve süre dolduğunda üretim bloğunun mantığını tetikleyecektir.
Zamanlayıcıdaki zamanın herhangi bir zamanda üzerine yazılabilir. Aslında yeni bir blok her senkronize edildiğinde, zamanlayıcı yeniden başlatılır.
Arayüz 3 ile ilgili olarak, ACS4 iki arayüze ayrılır
Aelf Blockchain’de her blok yürütmeden önce ve sonra, blok başlığını doğrulamak için yukarıdaki iki arayüzün uygulanması çağrılır. Doğrulama mantığı, ACS4'ü uygulayan sözleşmededir ve doğrulanan verilerin State DB'ye dayanması gerekir.
Not: Blok başlıklarındaki konsensüs bilgilerini doğrulayamadığınız için, son konsensüs bilgileri için doğrulama desteği sağlamak üzere en sonuncu konsensüs bilgilerini bir konsensüs sözleşmesinde saklamanız gerekir.
Doğrulanan veriler State DB'ye dayandığından ve ACS4 arayüzleri salt okunur olduğundan, State DB'yi güncellemek için ayrı bir işlem oluşturmanız gerekir (Blockchain özellikleri, WorldState veya State DB'nin güncellenmesi; işlemi yürüterek yapılmalıdır).
Böylece blok başlığı bilgisi üretmek için bir yöntem sağlamanın yanı sıra, ACS4'ün State DB'deki konsensüs bilgisini güncelleyebilen bir (bir dizi) işlemi geri döndürmesi gerekir. Bu işlem, bir sistem işlemi olarak üretilir ve daha sonra paketleme işlemi sırasında önce bloğa eklenir. Sistem işlemleri, sıradan işlemlerden önce yürütülür; böylece sıradan işlemler, en son güncellenen sistem tarafından sağlanan bilgilerle gerçekleştirilir, örneğin: hash-commit-reveal stratejisi altındaki rasgele sayılar. Aelf'de her blok, en az bir konsensüs sistemi işlemi içerir.
ACS4'ün son iki arayüzü, güncellenen konsensüs bilgisi ile ilgilidir
AElf’in çekirdek modül kodunda GetInformationToUpdate Consensus, blok başlığı oluşturma sırasında çağrılır ve bu arayüz tarafından döndürülen veriler, blok alıcısı için konsensüs bilgisini doğrulamak için blok başlığının Ekstra Verilerinden biri olarak kullanılır. “The Generate Consensus Transactions” arayüzü, blok başlıkları oluşturulduktan sonra sistem işlemlerinin daha fazla üretilmesi sürecinde çağrılır. Ek olarak “Validate Consensus After Execution” arayüzü, esasen sadece konsensüs sistemi işlemlerini gerçekleştirdikten sonra bloklardaki konsensüs bilgisinin tutarlılığını ve State DB'deki konsensüs bilgilerini doğrulamak ve blok üreticilerinin “hataya sapmasını” önlemek içindir.
ACS4 için tam kod “https://github.com/AElfProject/AElf/blob/dev/protobuf/acs4.proto” adresinde yer almaktadır. Bu makale veya ACS4 veya diğer AElf konsensüs bileşenleriyle ilgili öneriler ve GitHub'daki mesajlar özel notlar ve hatta teklifler dikkate alınacaktır.
Bu, AElf blockchain konsensüs sözleşme standardı ACS4'e genel bir giriştir. Bir sonraki makale, AEDPoS konsensüsünde en karmaşık GetConsensusCommand arayüzünün uygulanmasını tanıtacaktır.
KAYNAK: https://medium.com/aelfblockchain/aelf-consensus-contract-standard-acs4-aelf-developer-community-8824e5d24913