AELF ($ELF) Blockchain (RESMİ ANA KONU)

You're welcome! @katesmith

👉 Bugün o gün! Bana Herhangi Bir Şey Sor (AMA) etkinliğimize katılın!

⏱ Ne zaman? Bugün Türkiye saati ile 13:00'da!
🖥 Nerede? Aelf'in reddit kanalı: https://reddit.com/r/aelfofficial/
📍 Kim? Sorular CEO Haobo Ma ve COO Zhuling Chen tarafından cevaplanacaktır
🖇 Nasıl? Bize herhangi bir şeyi sor!

Aelf Blok Gezgini

1.1 Genel Bakış

Aelf Blok Gezgini, ana zinciri ve yan zinciri izlemek için kullanılır ve kullanıcıların belirli bilgileri aramasına ve Aelf ekosistemine katılmasına izin verir.

1. Arama: dakika başına işlem sayısı, blok yüksekliği, toplam işlem hacmi, toplam token sahibi sayısı, düğüm uygulamaları, yan zincirler gibi temel veriler;
2. Sorgu: blok yüksekliği, işlem kimliği ve cüzdan adresleri hakkında spesifik bilgiler;
3. Ağ Katılımı: Düğüm seçimlerine katılma, kaynak satın alma ve sözleşmeleri görüntüleme gibi eylemlerle Aelf ekosisteminin büyütülmesi.

1.2 Blok Gezgini Adresleri

Ana Zincir: https://explorer-test.aelf.io
Yan Zincir 1: https://explorer-test-side01.aelf.io/

1.3 Blok Gezgini Arayüzü

1.3.1 Tüm Ağ Durumunu Görüntüleme

1.3.2 Sözleşmeleri ve Geçmişi Görüntüleme

1.3.3 Blok Bilgilerini ve Ayrıntılı İşlemleri Görüntüleme

1.3.4 Adresleri Kontrol Etme

1.3.5 Düğüm Seçimine Katılma ve Oy Verme

1.3.6 Kaynak Satın Alma

Kullanıcılar; Aelf’in Blok Gezgini aracılığıyla zincir içi yönetişim için RAM, CPU, NET ve STO kaynaklarını satın alabilirler.

KAYNAK: https://medium.com/aelfblockchain/aelf-block-explorer-55eb3bcddfb8

NightELF, Aelf Gezgin İnşasına katılmak için bir araçtır.
- APP yetkisini yönetebilir ve APP'ı Uzantıları kullanması için yetkilendirebilirsiniz
- Chrome Web Mağazası'nda Aelf'i arayarak ve Chrome'a Ekle butonuna tıklayıp yükledikten sonra bir cüzdan oluşturabilirsiniz.

✅ Talimatlar: https://docs.browser-extension.aelf.io/

Aelf Teknik Konuşmalar - AEDPoS Sözleşme Uygulama Yorumlaması - Bölüm 1

Aelf konsensüs sözleşme standardında, beş arayüzü üç gruba ayrılabilir:

• Herhangi bir düğüm için konsensüs komutu, herhangi bir zamanda sözleşmeden istenebilir;
• Programlayıcı geri sayımının sona ermesinden sonra etkin blok süresini alan düğüm, sözleşmeden konsensüs verilerini alır ve bu verilere dayanarak bloğu üretir.
• Bir düğüm yerel blok zincirine bir blok eklediğinde, konsensüs verileri üzerinde bir dizi doğrulama için blok bilgisini konsensüs sözleşmesine gönderir.

Konsensüs Komutu Alınması (Get Consensus Command)

Bu yöntemin genel mantığı aşağıdaki gibidir:

Bu uygulamada, kod blok zincirinin çalışmaya başlaması için zaman damgasını aldıktan sonra, get consensus komutu iki adıma ayrılır:

1. Round bilgisine ve zincirin bir ana zincir mi yoksa bir yan zincir mi olduğuna göre, genel anahtarın bir sonraki blokta ne tür blok üretmesi gerektiğini belirleyecektir. Bu burada Konsensüs Davranışı olarak tanımlanmaktadır.
2. Geçerli bir Konsensüs Davranışı alabiliyorsanız, Konsensüs Komutunu daha fazla toplayabilir ve sonuç olarak döndürebilirsiniz.

Konsensüs Davranışı Alınması

Aelf yan zinciri ve ana zincir arasındaki fark, yan zincirlerde üretim düğümleri seçimi (yani Konsensüs Davranışı) gibi işlemlerin olmamasıdır. Birleştirilmiş Madencilik tasarım modunda yan zincir, ana zincirin üretim düğümlerini paylaşır. Bu nedenle, üretim düğümü seçimleri ve diğer işlerle ilgili sözleşmelerin yalnızca ana zincirde dağıtılması gerekir.

Konsensüs Davranışı Sağlayıcı Tabanı, ana zincir ve yan zincirler için Konsensüs Davranışının uygulama mantığını paylaşır.

İlk olarak, AEDPoS konsensüs tasarım mekanizmasını ve blok üretim sekanslarını kısaca tanıtacağız. AEDPoS blok üretim döngüsünün Raunt temelli iken DPOS konsensüsü altında, blokların bir dizi seçilmiş proxy düğüm tarafından üretildiği iyi bilinmektedir. Her turda her bir üretim düğümüne rastgele bir Zaman Slotu atanır. Sadece tahsis edilen zaman diliminde üretim bloğu yasal kabul edilebilir. Üretim düğümlerinin tahsis sırası, bir önceki turda üretilen rastgele sayılarla belirlenir. Son turun rastgele sayısını doğrulamak için üretim düğümünün son turda rastgele bir sayının karma değerini yayınlaması ve ardından rastgele sayının karma değerinin son turda yayınlanan karma değerine eşit olup olmadığını doğrulamak için geçerli turda son turun rastgele sayısını yayınlaması gerekir. Bu doğrulama mekanizması, AEDPoS Konsensüs Taahhüt Planının rasgele sayısını doğrulamak için de kullanılır. Her turun son üretim düğümü Zaman Slotundan sonra bir sonraki bilgi turunu başlatmak için kullanılan ek bloklar üretmek için ek bir Zaman Slotu vardır.

Bu nedenle, Konsensüs Davranışı elde etmede üretim düğümü için uygulama mantığı nispeten açıktır:

1. Düğüm bu turda bir blok üretmediyse:
2. Geçerli zaman ayrılan Zaman Aralığını geçtiyse, önce Konsensüs Davranışını belirlemek zorunda değilsiniz, sadece “Nothing” döndürün.
3. Geçerli zaman ayrılan Zaman Aralığına ulaşmadıysa, UpdateValue adlı Konsensüs Davranışı'nı döndürün. Aslında Konsensüs Davranışı, konsensüs verilerini güncellemek için kullanılır.
4. Düğüm bu turda zaten bloklar ürettiyse, küçük bloklar üretip üretemeyeceğini değerlendirin (her Zaman Aralığı art arda 8 blok üretebilir):
5. Eğer mümkünse Konsensus Davranışı, TinyBlock'u yürütür;
6. Değilse, geçerli raundu sonlandırmak için geçerli düğüme bir Zaman Aralığı atayın:
7. Geçerli düğüm bu geçerli tur için önceden belirlenmiş Ek Blok Üretim Düğümü olursa, o düğüme rauntta son zaman aralığının arkasında bir zaman aralığı atanır.
8. Geçerli düğüm belirtilen Ekstra Blok Üretim Düğümü değilse, geçerli turun son zaman aralığından sonra ilgili turdaki zaman aralığı geçerli turdaki sırasına göre atanacaktır. Belirtilen ekstra blok üreticisi çatallanma veya bağlantı kesilmesi nedeniyle bloktan zamanında çıkamazsa, mevcut düğüm turu geçerli düğümle bitirme şansına sahiptir.

Zaman aralığını kaçırıp kaçırmadığınızı belirleme yöntemi Turdadır:

Yan zincir için rayı sonlandırmak istiyorsanız, doğrudan NextRound'a geri döndürün:

Bir üretim düğümü için geçiş süresi 7 gün olarak tasarlanmıştır, bu nedenle zamana göre bir sonraki kampanya turuna girilip girilmeyeceğine karar vermek gerekir. Şu anda Konsensus Davranışı, NextTerm'i yürütmektedir:

Bunlar arasında NeedToChangeTerm karar kuralı şudur: Düğümlerin en son blok zaman damgasının üçte ikisinden fazlası son zaman damgasından 7 günden fazla ise, doğru (true) döndürür.

Konsensüs Komutunun Birleştirilmesi

Konsensüs Davranışı aldıktan sonra, Konsensüs Komutunu aşağıdakilere dayanarak birleştirebilirsiniz:

Konsensüs Komutunun birleştirmeden önce bir yargıya varmalıyız: son üç turda bloklar üreten sadece bir tane üretim düğümü varsa, bu ağda veya tüm zincirde yanlış bir şey olması gerektiği anlamına gelir. Bloklar derhal askıya alınır ve senkronize ağdaki diğer blokların Konsensüs Hizmetini tekrar tetiklemesi için beklememiz gerekir.

Ardından, gelen Konsensüs Davranışına göre ilgili politikayı seçebilirsiniz:
• FirstRoundCommandStrategy (İlk tur için Özel İşleme Stratejisi)
• NormalBlockCommandStrategy (UpdateValue öğesine karşılık gelir)
• TerminateRoundCommandStrategy (NextRound ve NextTerm'e karşılık gelir)
• TinyBlockCommandStrategy (TinyBlock'a karşılık gelir)

Uygulama mantığını görmek için NormalBlockCommandStrategy (UpdateValue'ya karşılık gelen) stratejisini kullanıyoruz:

Bu strateji, tahmini blok süresini elde ederek bir Konsensüs Komutu örneğini birleştirir ve yürütür. Strateji uygulama mantığının geri kalanı aşağı yukarı aynıdır.

KAYNAK: https://medium.com/aelfblockchain/a...plementation-interpretation-pt-1-35f109529db2

Aelf Teknik Konuşmalar — AEDPoS Sözleşme Uygulama Yorumlaması — Bölüm 2

Konsensüs Verileri Oluşturma - Konsensüs Ekstra Verilerini Alma (GetConsensusExtraData) & Konsensüs İşlemleri Oluşturma (GenerateConsensusTransactions)

Düğüm, Konsensüs Komutunu elde ettikten sonra yerel konsensüs zamanlayıcısını ArrangedMiningTime bilgilerine göre güncelleyecektir. Geri sayımdan sonra bloklar oluşturulur. Bloktaki konsensüs bilgileri iki yerde bulunur. Biri, Blok Başlığındaki fazladan veriler (biri konsensüs verisi olan ikili dizilerin bir listesi), diğeri ise hash (karma) değeri Blok Başlığına kaydedilen bir sistem işlemi olarak konsensüs işlemidir ve işlem ile ilgili veriler Blok Gövdesine kaydedilir.

Blok başlığındaki bilgiler GetConsensusExtraData çağrılarak oluşturulur ve konsensüs işlemi GenerateConsensusTransactions çağrılarak oluşturulur.

AEDPoS her iki uygulama için kaçınılmaz olarak aşağıdaki yöntemleri kullanır:

İlk olarak, deserileştirmenin girdi bilgilerinin Aelf ConsensusTriggerInformation aracılığıyla başlatılması gerekir. İkinci olarak, Konsensüs Davranışına göre farklı konsensüs verileri güncellenebilir.
Şimdi ilgili NextRound yöntemine bakalım:

Bu turda güncellenen konsensüs verilerine dayanarak bir sonraki bilgi turunu oluşturun ve daha sonra birkaç bloğun üretim bilgilerini güncelleyin.

GetConsensusExtraData, sadece bu yöntemin return değerini kullanır. GenerateConsensusTransactions bir Konsensüs işlemi oluşturmak için return değerini yeniden işlemek zorundadır (GetConsensusBlockExtraData'nın bool tipi parametresi, bir işlem oluştururken daha ayrıntılı bilgileri doldurmak için kullanılır):

Konsensüs bilgilerinin doğrulanması – ValidateConsensusBeforeExecution (Yürütmeden Önce Konsensüs Doğrulaması) & ValidateConsensusAfterExecution (Yürütmeden Sonra Konsensüs Doğrulaması)

Blok doğrulaması, halen mevcut bloğun üretim motivasyonuna dayanmaktadır - Konsensüs Davranışı. ValidateConsensusBeforeExecution'da farklı IHeaderInformationValidationProvider (Başlık Bilgisi Doğrulama Sağlayıcısı)'ın farklı Konsensüs Davranışlarına göre eklenmesi gerekir.

IHeaderInformationValidationProvider şu anda aşağıdaki türlere sahiptir:

• Sürekli Blok Doğrulama Sağlayıcısı - ContinuousBlocksValidationProvider (Düğümlerin sürekli olarak çok fazla blok üretmesini önler)
• Lib Bilgi Doğrulama Sağlayıcısı - LibInformationValidationProvider (Geri döndürülemez blok bilgilerinin doğru olduğunu doğrular)
• Madencilik İzni Doğrulama Sağlayıcısı -MiningPermissionValidationProvider (Düğümün engelleme iznine sahip olup olmadığını doğrular)
• Bir Sonraki Tur Madencilik Sırası Doğrulama Sağlayıcısı - NextRoundMiningOrderValidationProvider (Bir sonraki turda blok üretim sırasının doğru olduğunu doğrular)
• Tur Sonlandırma Doğrulama Sağlayıcısı - RoundTerminateValidationProvider (Bir sonraki temel bilgi turunun doğru olup olmadığını kontrol eder)
• Zaman Aralığı Doğrulama Sağlayıcısı - TimeSlotValidationProvider (Bloğun doğru zaman diliminden üretilip üretilmediğini doğrular)
• Güncelleme Değeri Doğrulama Sağlayıcısı - UpdateValueValidationProvider (Her bir düğüm tarafından güncellenen konsensüs bilgilerinin yasal olup olmadığını doğrular)

ValidateConsensusAfterExecution uygulamasının yalnızca konsensüs işleminden sonra gerçekte güncellenen konsensüs bilgilerinin (önemli bölüm) Blok Başlığı Ekstra Verilerindeki konsensüs bilgileri ile tutarlı olup olmadığını kontrol etmesi gerekir:

Blok başlığındaki konsensüs bilgileri ek bilgiler basitleştirildiğinden (Gizli Paylaşım ile ilgili bilgileri içermemesi gibi), ValidateConsensusAfterExecution'ın basitleştirilmiş içeriği uygun şekilde tamamlaması gerekir. Son olarak, StateDB'deki mevcut bilgi turunun tamamlanan bilgilerle tamamen tutarlı olup olmadığını doğrudan doğrulamak. Doğrulama, daha önemli konsensüs verileriyle de ilgilidir ve diğer gereksiz veriler için bazı uyarlamalar yapar. Bu nedenle GetHash (Karma Al)'te RecoverFromUpdateValue (Güncelleme Değerinden Kurtarma), RecoverFromTinyBlock (Minik Bloktan Kurtarma) ve GetCheckableRound (Kontrol Edilebilir Tur Alınması) çağrılır.

KAYNAK: https://medium.com/aelfblockchain/a...plementation-interpretation-pt-1-2ac13f08e84d