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

🔊 Aelf mimarı Guanglei Deng, ailevi nedenlerinden dolayı görevinden resmi olarak ayrıldı. Guanglei, Aelf gelişimine yardım etmeye devam edecek ve Aelf GitHub hakkında teknik danışman olarak değerli önerilerde bulunacak.

Aelf COO'su ve Kurucu Ortağı Zhuling Chen:

Guanglei'yi yeni bebeği için tebrik ediyor ve kendisini Aelf geliştirici topluluğunun bir parçası olarak görmekten mutluluk duyuyoruz. Bir başka harika geliştirici olan Anıl, bize iki ay önce katıldı ve şimdi Guanglei'den sonra akıllı kontrat incelemesi üzerinde tam hızda çalışıyor!

Tüm harika işler için teşekkürler Guanglei!

AELF Haftalık Gelişim İlerleme Raporu (5 Ağustos — 11 Ağustos)

Özet: Merkle Tree uygulaması optimize edildi

Geçen Haftanın İlerleme Güncellemesi (11 Ağustos 2019)

Fonksiyon:
- [Tamamlanan] Eş yayın mantığı optimizasyonu, en yavaş eş nedeniyle yayın tıkanıklığı sorunu çözüldü
- [Tamamlanan] Merkle Tree uygulaması optimize edildi
- [Devam eden] Sözleşme güncellemeleri sırasında ortaya çıkabilecek durum tutarsızlıkları düzeltilmesi
- [Devam eden] Ağ bağlantısı ve doğrulama mantığı optimize edilmesi #1943
- [Devam eden] Ağ güvenliği ile ilgili sorunlar
- [Devam eden] Ekonomik Sistem optimizasyonu çalışması #1936
- [Devam eden] Çapraz zincir bağımlılık senkronizasyonu sorunu düzeltilmesi
- [Devam eden] Sözleşme güvenlik sorununun kontrol edilmesi ve düzeltilmesi

Test:
- [Tamamlanan] Çapraz zincir işlem otomasyon senaryosu geliştirildi
- [Devam eden] Ağ modülü birim testinin iyileştirilmesi, mevcut kapsama oranı: 90%
- [Devam eden] Çok sayıda işlemin stabilite testi (uzatılmış çalışma süreleri)
- [Devam eden] Düğüm dışı değerlendirmesi (Ekonomik Sistem otomasyonu senaryosu, uzatılmış çalışma süreleri ve sorun giderme)

Diğer:
- [Devam eden] GitHub’daki Sorunların Düzeltilmesi:
· #1937, #1938, #1934, #1925, #1924, #1918, #1913; çevrimiçi ortamın doğrulanması

Bu Haftanın Planı:
- Çapraz bölge, çoklu düğüm, çapraz zincir stabilite değerlendirmesi ve sorun çözme
- Güvenlikle ilgili sorunların değerlendirilmesi ve optimize edilmesi
- [Yinelenen] TODO uygulanması ve sorunlardaki hataların düzeltilmesi

KAYNAK: https://medium.com/aelfblockchain/aelf-development-progress-report-august-5th-august-11th-ae7f171c9cfd

Hiç bir şey anlamadım :'( ne işimize yarayacak bu sistem?

Aelf, Blockchain’in ticari olarak benimsenmesi için yüksek performanslı bir platform sağlamayı hedefleyen, merkezi olmayan, kendini geliştiren bir bulut bilişim Blockchain ağıdır. Çeşitli ticari gereksinimler için bir Blockchain altyapısı kurmak için, Aelf çapraz zincir iletişim ve kendi kendini yöneten yönetişim ile yüksek verimli birçok zincirli paralel işlem sistemi sağlar.

İşinize yarayacak bir örnek --> Siz, Mainnet (ana ağ) ile birlikte Aelf sisteminde ELF tutarak yani staking yaparak ödüller kazanabileceksiniz. Ayrıca delegeler için oy verebileceksiniz ve bunun için de ödüller kazanabileceksiniz.

Merak ettiğiniz başka sorular varsa bu konuda ya da Telegram grububumuzdan her zaman sorabilirsiniz.

Aelf, Blockchain’in ticari olarak benimsenmesi için yüksek performanslı bir platform sağlamayı hedefleyen, merkezi olmayan, kendini geliştiren bir bulut bilişim Blockchain ağıdır. Çeşitli ticari gereksinimler için bir Blockchain altyapısı kurmak için, Aelf çapraz zincir iletişim ve kendi kendini yöneten yönetişim ile yüksek verimli birçok zincirli paralel işlem sistemi sağlar.

İşinize yarayacak bir örnek --> Siz, Mainnet (ana ağ) ile birlikte Aelf sisteminde ELF tutarak yani staking yaparak ödüller kazanabileceksiniz. Ayrıca Aelf, DPoS konsensüs mekanizmanı kullanmaktadır yani delegeler için oy verebileceksiniz ve bunun için de ödüller kazanabileceksiniz.

Aelf ile ilgili merak ettiğiniz başka sorular varsa bu konuda ya da Telegram grubumuzdan her zaman sorabilirsiniz.

ADRES --> https://t.me/aelf_turkish

Aelf kullanım durumu 101: Tedarik zinciri ürün takibi

Herhangi bir Blockchain projesi, sadece gerçek bir dünya problemine sağladığı çözüm kadar kullanışlıdır. Bu seri, farklı endüstrilere ve gerçek bir değişiklik yapmak için aelf platformunun nasıl kullanılabileceğine inceliyor olacaktır. Her kullanım durumu, doğrudan gerçek şirketlerden alınan gerçek örnekler vererek derinleştirilecektir.

Tedarik zinciri, yıllık milyarlarca dolara mal olan bazı büyük çaplı sorunların yaşandığı bir endüstridir. En büyük iki sorun, "izole edilmiş veri siloları" ve "izlenemeyen, kötü belgelenmiş ve manipüle edilebilir veriler" dir. Aelf'de bir tedarik zinciri ürünü izleme ekosistemi uygulaması oluşturmak, dâhil olanlar için bu sorunları çözecektir.

Aşağıda, mevcut tedarik zinciri sistemlerinin ilave faydalarla Blockchain nasıl uygulanabileceğini gösteren Aelf platformu üzerinde oluşturulmuş varsayımsal bir uygulama bulunmaktadır. Bu, birçok mevcut yönü alır ve bunları bir Blockchain çözümüne uygular.

Uygulamaya Genel Bakış

Uygulamayı işletmelerin, perakendecilerin ve sektördeki diğer kişilerin uygulamayı kullanmasını sağlayacak doğru çerçeveyle geliştirmek için buna basit bir Blockchain çözümünden ziyade karma bir web zihniyetiyle yaklaşmamız gerekir. Uygulamanın hem özel hem de halka açık olan birden fazla Blockchain bağlanması ve bunlarla etkileşim kurması gerekir.

Bir şirket uygulamayı kullanmaya başladığında, onlar için sektördeki rollerine bağlı olarak bir hesap oluşturur. Örneğin; bir nakliye firmasına bir nakliye hesabı verilecek, bir perakendeci bir perakende hesabı ve bir üretici ise kendi türünde bir hesap alacaktır. Her hesap, iç veri yönetimi için onlar için oluşturulmuş özel bir Blockchain’e sahip olacaktır. Her bireysel özel Blockchain, her hesap türü için üst halka açık/karma zincirin bir alt zinciri olacaktır. Daha sonra her bir üst zincir, tüm ağın güvenliğini denetleyen uygulamanın genel ana zincirine bağlanacaktır. Çok daha şeffaf ve güvenli bir ağ sağlamanın yanı sıra, bu uygulamayı kullanmadan bağlanmak isteyen sektördeki diğer şirketlere kolay erişilebilirlik sağlamak için ana zincirin halka açık olması önemlidir.

Her hesap benzersiz bir özel zincire sahip olacağından veri görünürlüğünü tam olarak kontrol edeceklerdir üst zincirde hâlâ kaydedilmesi nedeniyle onu kötü niyetli olarak değiştiremeyeceklerine rağmen. Özel bir zincirden belirli bir dönemde her bir blok, merkle ağacı konsepti kullanılarak tek bir karma (merkle kökü) üretilip üst zincire kaydedilmek üzere gönderilene kadar karıştırılır. Veri türüne ve uygulama tasarımına bağlı olarak bu, daha fazla sıkıştırılabilir. Ve bu, belirli bir hesap türü içindeki birden fazla özel zincirden bloklar için tek bir karma (hash) ile sonuçlanır.

Uygulamanın hesap sahiplerinin düzenli aralıklarla kolayca veri girebilmesi için basit ve kullanımı kolay bir arayüze ihtiyacı olacak. İdeal olarak uygulama, veri giriş süreçlerinin mevcut kullanılan veri kayıt ekipmanı ile entegre edilmesini sağlayan ve böylece minimum ayarlamalar gerektiren belirli API'lere sahip olacaktır. Üst zincir üzerine kaydedilen merkle kökleri nedeniyle uygulama; ekosistem içerisinde mevcutsa, tedarik zincirindeki bir sonraki aşamadan yüklenen verileri doğrulamak için yeterli bilgiye sahip olacaktır.

Örnek 1: Bir üretici XX ağırlığında ve YY renginde üretilen 100 birim A ürününü kaydeder. Her birim, bloklarda ve merkle kökünde dâhil edilmiş benzersiz bir tanımlayıcıya sahiptir. Nakliye şirketi aynı veriyi kaydeder; bu, her iki üst zincire gönderilen merkle köklerinin aynı ürün grubuyla ilgili olduklarını gösteren benzersiz tanımlayıcıları paylaştığı ve her iki tarafın da doğru şekilde kayıt yaptığını sağlayan verilerle eşleştiği anlamına gelir. Daha sonra varış yerindeki depo, sadece 80 adet ürün A ve 20 adet B ürününü kaydeder. Bu, benzersiz tanımlayıcıları ancak farklı verileri içerdiğinden otomatik olarak işaretlenen Blockchain’e eklenir. Gerekirse ambarın mal girişini yaptığı gün aynı zamanda bir çözüm süreci uygulanır. Bu, stok seviyelerindeki ve ürün tiplerindeki hata riskini en aza indirir.

Yukarıdaki örnek, yalnızca tarafların her biri uygulama ekosistemindeyse veya en azından verilerin ağ tarafından okunmasına izin vermek için yüklenmiş bir API'ye sahipse otomatiktir.

Ana zincirin her bir üst zincirden ve harici veri sağlayıcılardan API kümesi aracılığıyla tüm verilere erişmesini sağlayarak bir hesap sahibi, tedarik zincirinde bulunduğu yere bakılmaksızın bir konumdaki belirli bir ürünle ilgili tüm bilgilere erişebilir.

Örnek 2: Bir perakendeci az önce 100 birim Ürün A ve 200 birim Ürün B siparişi aldı. Mağazada stokları yoktur, bu yüzden hesaplarına giriş yaparlar ve bu ürünleri sağlayan depoyu kontrol ederler. Depoda hâlâ eksik 50 birim B ürünü vardır. Basitçe ana zincirden depo üst zincirinde Ürün B için karşılık gelen tanımlayıcısına sahip diğer merkle kökleri aramasını isteyerek normalde tedarik zincirinde olmayan diğer depoları arayabilirler. Buradan stokları olan sadece 2 depo bulunduğunu görebiliyorlar ancak başka bir ülkedeler, bu nedenle perakendeciye ulaşmak biraz zaman alacaktır. Daha sonra ana zincirden sevkiyat üst zincirini, özellikle yerel depolarına teslim ediliyor olanları kontrol etmelerini ister. Buradan yeterli stok olduğunu ve ulaşmaları XX gün kadar süreceğini görebilirler. Bu uygulamayı kullanarak, stok seviyelerini veya kayıtlarını kontrol eden üçüncü taraflara güvenme zorunluluğu kalmadan birkaç dakika içinde siparişi doğrulayabilirler. Ayrıca, stoğun tam olarak ihtiyaç duydukları ve doğru olduğu konusunda %100 kesinlik ile siparişi doğrulayabilirler.

Bunun bu kadar basit bir şekilde yapılabilmesinin nedeni, ana zincirin hem ekosistemdeki hem de dışındaki diğer tüm Blockchainler ile iletişim kurabilmesidir.

Bir ürünün hatalı, tehlikeli veya yanlış üretilmiş olduğu tespit edildiğinde; geri çekme (çağırma) yapılması gerekir. Şu anda bir perakendecinin, tedarikçinin veya dağıtıcının sorunun nerede oluştuğunu ve hangi ürünlerin etkilendiğini değerlendirmek için gereken tüm verilere verimli bir şekilde erişmesini sağlayan hiçbir yöntem yoktur. Mevcut süreç, tüm tedarik zincirindeki birçok tarafın birlikte çalışmasını gerektiriyor

Örnek 2'ye benzer şekilde uygulama ile ana zincirin birden fazla üst zincirden ve diğer Blockchainler’den okuma kabiliyeti, bir hesap sahibinin bir ürünün benzersiz tanımlayıcısını kullanarak birkaç dakika içinde bir iz çalıştırmasını sağlar. Diğer tarafların kendi verileriyle yanıt vermesini beklemede gecikme yoktur, ayrıca alınan verilerin güvenilirliği veya doğruluğu ile ilgili herhangi bir endişe de yoktur.

Örnek 3: Bir elektrik tedarikçisi, bilgisayar ünitesi A yüklü olan herhangi bir aracın elektrik yangını riski altında olduğunu keşfetmiştir. Risk ile sonuçlanan en son güncellemeden bu yana A Ünitesini satın alan tüm araç üreticilerini takip etmeyi ve izlemeyi tanımlamak için uygulamayı kullanırlar. A ünitesi yüklü olan her aracı ve bu araçların satıldığı veya satılmış olduğu bayileri otomatik olarak izleyen uygulama aracılığıyla bir geri çekme isteği gönderirler. Bu bilgiler daha sonra izleme talebini onaylayan hem satıcıya hem de araç üreticisine gönderilir. Bu onaylanarak sistem, kendi özel Blockchainler’ine bağlanır, verileri alır ve araçlara sahip olan her bir kişiye geri çekme istekleri gönderir. Bu yöntemle geri çekme talepleri, sorunun tanımlanmasından sonraki 24 saat içinde gönderilmiştir.

Bu örnek sadece çapraz zincir okunabilirliğinin değil, aynı zamanda Blockchain A’daki bir eylemin Blockchain B, C ve D üzerindeki bir eylemi başlatabildiği çapraz zincir birlikte çalışabilirliğinin faydasını göstermektedir. Başlatıcı, insan onayına ihtiyaç duymadan bile acil eylemin gerçekleştiğinden emin olabilir ve bu isteklerin hızını ve yanlışlığını büyük ölçüde azaltır.

Bu makalenin amacı için IBM research tarafından sağlanan maliyet tahminlerini değer değerlendirme araçları için kullanacağız.

Not: IBM’in Değer Değerlendirme Aracı (https://food-trust-roi.mybluemix.net/index.html), bozulabilir ürünler ve mallar için tasarlanmıştır.

Yıllık geliri 1 milyar dolar olan bir üretici, 38 milyon doların üzerinde tek bir geri çekme maliyetine sahip olabilir. Bazı durumlarda ise tek geri çekme işlemlerinin maliyeti 4 milyon doların üzerindedir.

Blockchain ekosistem uygulamasının kullanılmasıyla bu maliyetler büyük ölçüde azaltılabilir. Tedarik zinciri verimsizliği ile yılda yarım milyon doların üzerinde tasarruf sağlanabilirdi.

Üzerine durulması gereken son şey, uygulamanın neden her hesap sahibi için bireysel özel Blockchainler oluşturduğudur. Bu yapılarak şirketin yüklenen verilerini kimin görebildiğini veya göremediğini merak etmesine gerek kalmaz, verilerinin ne kadarının ve hangi yönlerinin üst zincir veya ana zincir tarafından aranabileceğini seçme yeteneğine sahiptirler. Buna ek olarak, mevcut ekosistemden çıkmaları ve başka bir ağa katılmaları gerektiğine karar vermeleri durumunda hesaplarını ağdan kaldırarak ve zincirlerini yeni ağa bağlayarak bunu yaparlar. Ancak, verilerini iki ağ üzerinde zararlı bir etkisi olmadan paylaşabilecekleri için orijinalden kopmalarına gerek yoktur.

Blockchain için bu kullanım durumu; Aelf'in benzersiz ölçekleme yeteneği ve ağaç benzeri bir yapıya sahip hibrit ekosistemler yaratması, hem halka açık hem de özel zincirleri çapraz zincir birlikte çalışabilirliği kullanma çekirdek yeteneği ile karıştırması sayesinde mümkündür.

KAYNAK: https://medium.com/aelfblockchain/aelf-use-case-101-supply-chain-product-trace-5928022dd5df

Yan Zincirler: Tron’un Sun Network’ü Aelf ile karşılaştırıldığında ışıltısını kaybediyor

11 Ağustos’ta TRON network, Sun Network olarak adlandırılan bir yan zincirleme ölçeklendirme çözümü açıkladı. Güvenliği ve verimliliği geliştirdiği ve enerji tüketimini azalttığı söyleniyor. Sun Network’ün Ağustos ayının başlarında yayınlanacağı bekleniyordu, ancak şimdi Eylül ayı ortasında bekleniyor. Bazı özellikler Aelf’e benzerdir ve bu makalede Aelf ile bu yeni yükseltmeler karşılaştırılacaktır.

Sun Network nedir?

Bu ağ, uygulama odaklı bir yan zincir ve çapraz zincir iletişimi olan DAppChain gibi bazı ölçeklendirme çözümleri içerecektir. TRON bloğuna (https://medium.com/@Tronfoundation/sunnetwork-code-v1-0-officially-launched-dappchain-mainnet-coming-soon-122c10fb713f) göre, bu yükseltme iki önemli özelliğe sahiptir.

“Öncelikle, MainNet'teki akıllı sözleşme işlemlerinin TPS'sini geliştirmeye ve işlem ücretini düşürmeye odaklanarak akıllı sözleşme işlemlerini destekliyor. İkinci olarak yan zincir; farklı geliştirici gruplarının gereksinimlerini karşılayan yan zincir teşvikleri, işlem oranları, işlem onay hızı ve diğer parametreler gibi daha fazla özelleştirilebilir gereksinimleri destekleyebilir.”

DAppchain özelliğinin sınırsız ölçeklendirme kapasitesi sağlayabildiği söyleniyor. DPoS Konsensüsünü kullanacak ve Ana Zincir Ağ Geçidi (MainChain Gateway) aracılığıyla çapraz zincir iletişimine imkân verecektir.

Bu, Aelf ile nasıl karşılaştırılır?

2017 yılında geliştirilecek olan Blockchain ekosisteminin teknik yapısını ve bileşenlerini açıklayan Aelf Whitepaper (https://aelf.io/gridcn/aelf_whitepaper_TR.pdf?v=1) yayınlandı. Projeye ilişkin ilk genel bakış, Aelf'in ana hedeflerinin tartışıldığı belgenin ikinci bölümünde bulunabilir.

5 hedef listeler ve birincisi ticari kullanım için özelleştirilebilir işletim sistemidir. Tasarım, bir Blockchain sisteminin temel fonksiyonlarını içeren temel bir Aelf Kernel içerir - minimum uygulanabilir Blockchain sistemi. Müşteriler, daha sonra temel Blockchain’i özel gereksinimlerine uyacak şekilde değiştirebilir ve değişiklik kolaylığı için modüler bir tasarımdan faydalanabilirler. Teknik dokümantasyona göre, TRON’un DAppChain'in ikinci özelliği, ‘Yüksek derecede Özelleştirilebilir Bir Yan Zincir’dir. Bu bölümde açıklanan diğer tek şey, bunun TRON ana zincirinden farklı olmasıdır.

Aelf'in ikinci hedefi, Çapraz Zincir Etkileşimi ile ilgilidir. Whitepaper’da belirtildiği gibi:

“Aelf; Bitcoin, Ethereum ve diğer Blockchain sistemleri ile etkileşime girebilir.”

Bu, Aelf ekosistemindeki her bir yan zincir arasındaki birlikte çalışabilirliğe ektir. Aelf Blockchain’in birlikte çalışabilirliği, sadece diğer yan zincirlerden gelen verilerin okunmasına izin vermekle kalmaz; ayrıca belirli bir Blockchain’deki bir eylemin başka bir eylemi veya alternatif bir Blockchain’deki akıllı sözleşmeyi tetiklemesini sağlar.

Bunun aksine TRON DAppChain, yan zincirlerin yalnızca ana zincirle etkileşime girme ve hatta yalnızca aralarındaki varlıkları transfer etme kabiliyetine sahip görünüyor.

(https://tron.network/sunnetwork/doc/guide/#_4-cross-chain-details)

Aelf’in üçüncü amacı, Aelf modelinin Blockchain ekosistemine getireceği gelişmiş performansı göstermektedir. Aelf; paralel işleme, küme düğümleri ve veri tabanı ayrımı dâhil olmak üzere Blockchain’in genel performansını iyileştirmek için birkaç yaklaşım kullanmıştır. Bu, saniye başına işlemi (TPS) 15.000'e çıkardı.

TRON, TPS’lerini 2.000 TPS olarak zirveye çıkardı. Sun Network Dokümantasyonuna (https://tron.network/sunnetwork/doc/guide/#_2-dappchain-features) göre, DAppChain ilavesi TPS'de sonsuz bir artışa izin veriyor:

“TRON ekosisteminin tamamının TPS’si, yan zincir sayısının artışı ile 2000*SideChainNum (yan zincir sayısı) değerine ulaşabilir.”

Bu, her yan zincir hâlâ sadece 2.000 TPS'ye ulaşabildiği için mantıksızdır. Unutulmaması gereken ana unsur, her bir yan zincirin 2.000 işlemin tamamını kullanabilecek kendi uygulamasına sahip olmasıdır.

Bu hatalı mantığı Aelf ile karşılaştırırsak, TRON'daki 10 yan zincir her biri 2.000 kez 10 veya 20.000 işlem gerçekleştirebilir. Ancak bu sayı, Aelf’de 15.000 kez 10 veya 150.000 işlem olur.

Bunlar; Sun Network'ün temel unsurlarıdır ve bahsi geçen başka özellikler olmasına rağmen, herhangi bir Blockchain projesinde beklenebilecek şeylerdir. Ancak bu, Aelf için son değildir. Aelf Blockchain’de hâlâ başka iki benzersiz hedef vardır.

Protokol güncellemesi; ağın yeni özellikler eklemesini, hatta Konsensüs Protokolünün güncellemesini hatta yükseltmesini sağlayarak ve çıkmaz durumlardan ve protokol anlaşmazlıklarından kaçınarak ağın uzun ömürlü olmasını garanti eden bir özelliktir.

Özel Zincir Modülü; müşterilerin tam gizlilik, kontrol ve mülkiyet ile kendi yan zincirlerini oluşturmalarına izin verir. Bu; verilerin, süreçlerin ve stratejilerin duyarlılığı nedeniyle kurumsal benimseme için mevcut olması gereken kritik bir özelliktir. Şu anda Sun Network, bu özellikten veya eşdeğer bir şeyden bahsetmiyor.

Sun Network DAppChain güncellemesini inceledikten ve Aelf’in teknolojisiyle karşılaştırdıktan sonra, Aelf'in TRON tarafından belirtilmeyen bazı benzersiz özelliklere ek olarak benzer özellikler sağladığı anlaşılıyor. Bu yeni yükseltmede geliştirilen her özellik, 2 yıldan fazla bir süre önce Aelf Whitepaper'da yer almıştır ve teknik ekibimiz tarafından yıllar süren gelişme görmüştür.

KAYNAK: https://medium.com/aelfblockchain/sidechains-trons-sun-network-when-compared-with-aelf-loses-it-s-sparkle-7fd1beca8769

Aelf Teknik Konuşmalar: Geliştiricinin GetConsensusCommand'ı Elde Etmesi

Bölüm 3

GetConsensus Command arayüzü, bir halka açık anahtarın bir sonraki üretim bloğunun zamanı gibi bilgileri elde etmek için kullanılır.

AEDPoS uygulamasında giriş, sadece bir halka açık anahtardır ve arayüz uygulama yönteminin çağrı süresi başka bir referanstır (aslında önemli bir giriş). AElf Blockchain’de sistem salt okunur işlemleri çağırdığında, sözleşme yürütmenin bağlamı kendisi tarafından oluşturulur. Çağrı süresi, C#'daki kendi fonksiyon kütüphanesi ile DataTime.UtcNow tarafından üretilir ve sonra sözleşme yürütülmesine geçirilen protobuf tarafından sağlanan zaman damgası (Timestamp ) veri tipine dönüştürülür.

Aslında yapılacak işlemin salt okunur bir işlem olup olmadığına bakılmaksızın mevcut sözleşme yürütme bağlamından geçen zaman damgası, Context.CurrentBlockTime aracılığıyla sözleşme kodunda elde edilebilir.

Bu makale, öncelikle AEDPoS konsensüsünün GetConsensusCommand'a nasıl ulaştığını inceleyecektir. Bundan önce, AElf konsensüsüne aşina olmayanlar için AEDPoS sürecinin kısa bir tanıtımı olacaktır.

AEDPoS Süreci

DPoS’un temel kavramı üzerinde duralım. AElf'in ana zincirinin şimdi 17 oy ile seçtiğini varsayalım. Bunu (geçici olarak) AElf Çekirdek Veri Merkezi veya CDC (Core Data Center) olarak adlandıracağız (Eos'ta BP'ler (Blok Üreticileri - Block Producers) kavramına karşılık gelir).

Bu CDC'ler, referandumla belirli bir blok yükseklikte (veya zaman noktasında) doğrudan ilk 17 adaydan elde edildi. İlk 17 aday tekrar sayılır ve CDC yeniden atanırsa, “Term” olarak adlandırılır.

Her bir aşamada tüm CDC'ler, raunt bloklar halinde üretilir. Her rauntta 17 + 1 zaman dilimi vardır ve her bir CDC, rastgele olarak ilk 17 zaman diliminden birinde bulunur. Son zaman dilimi, bu raunttaki ilave blokların üreticisi tarafından üretilir. İlave blok üreticileri, her bir CDC tarafından bu rauntta yayınlanan rastgele sayıya dayanarak bir sonraki bilgi raundunu başlatır. 18 slottan sonra bir sonraki raunt, bir döngü tamamlanarak başlar.

Bir raundun veri yapısı aşağıdaki gibidir:

AEDPoS sözleşmesinde bir harita yapısı vardır. Anahtar, bir uzun tür Raunt Sayısıdır. 1’den 18’e her değer, yukarıda belirtilen raunt yapısıdır. CDC tarafından oluşturulan her blok, konsensüs ve blok üretimini teşvik etmek ve konsensüs doğrulaması için bir temel sağlamak için mevcut veya bir sonraki bilgi raundunu günceller.

Teknik detaylarla ilgileniyorsanız, AElf Whitepaper’ın 4.2.4. bölümünü (https://aelf.io/gridcn/aelf_whitepaper_TR.pdf?v=1) inceleyebilirsiniz. Uygulama detayları için, AEDPoS Konsensüs Sözleşme projesini Github'da (https://github.com/AElfProject/AElf) inceleyebilirsiniz.

ConsensusCommand

ConsensusCommand’in yapısı, AElf Konsensüs Sözleşme Standardı'nda belirtilmiştir:

AEDPoS konsensüs için Hint, daha sonra CDC’nin ne tür blokların üretileceğini gösterir. Özel bir veri yapısı ile Hint sağlarız, AElfConsensus Hint:

Blok türleri aşağıdaki gibi Behaviour (Davranış)'a dâhil edilmiştir:

Açıklama:

UpdateValue ve UpdateValueWerPReviousInValue, CDC'nin belirli bir rauntta üreteceği ortak bir bloğu temsil eder. CDC'nin güncellemeye odaklandığı konsensüs bilgisi; bu rauntta previous_in_value, out_value generated ve bu rauntta out_value üretmek için kullanılan in_value kod parçalarını içerir (CDC, 16 şifre parçalarını in_value ve diğer CDC’nin halka açık anahtarı ile şifreleyecektir). Diğer CDC'ler yalnızca kendi özel anahtarlarıyla şifresini çözebilir. Şifresi çözülen parçaların sayısı belirli bir seviyeye ulaştığında, orijinal in_value değeri ortaya çıkar. Bu, Shamir’in gizli paylaşımının bir uygulamasıdır. Diğer CDC'ler, yalnızca kendi özel anahtarlarıyla onların şifresini çözebilir. Şifresi çözülen parçaların sayısı belirli bir seviyeye ulaştığında, orijinal in_value ortaya çıkar. Bu, Shamir’in gizli paylaşımının bir uygulamasıdır.

Not: Ayrıntılar, Google’da bulunabilir ve AElf ana zinciri, ECDH ile uygulanır.

Ek olarak, blok üretim davranışını tetiklemek için actual_mining_times’a bir zaman damgası eklenir. UpdateValueWithoutPreviousInValue ve UpdateValue arasındaki fark, şu anki/mevcut raunt ilk raunt olduğundan ya da az önce değiştirildiğinden (yeni bir CDC oylandı) in_value (previous_in_value)’nun son raundunun bu kez yayınlanmasının gerekmemesidir.

NextRound, CDC'nin bu raundun ilave blok üreticisi olduğunu (veya belirtilen ek blok üreticisi olmadığında çözümü) temsil eder ve bir sonraki bilgi raundunu başlatır. Bir sonraki bilgi raundunda, her bir CDC için slot düzenlemesi ve kurallarla belirtilen bir sonraki raunt için ilave blok üreticileri bulunmaktadır.
NextTerm, NextRound ile benzerdir. Ancak ilk 17 seçimi tekrar hesaplar ve yeni CDC listesine dayanarak bir sonraki bilgi raundunu başlatır.

Hiçbir şey, giriş halka açık anahtarın bir CDC olmadığını keşfetmektir.

TinyBlock, CDC’nin yeni konsensüs bilgisini güncellediğini ancak zaman dilimi henüz geçmediğini ve fazladan birkaç blok üretmek için zamanı olduğunu gösterir. Şu anda her zaman dilimi, sekiz küçük parçaya kadar üretebilir. Bu yaklaşımın avantajı, blok doğrulamanın verimliliğini geliştirmek ve arttırmaktır (Eos'a benzer).

Özel dikkat gerektiren bir zaman dilimi sorunu vardır. AEDPoS Genesis Bloğunda ilk konsensüs bilgi raundunu oluşturmayı seçtiğinden (yani tüm ilk CDC zaman dilimleri vb.) ve Genesis Bloğu her düğüm için tamamen tutarlı olması gerektiğinden, konsensüs bilgisinin ilk raundu birleşik bir süre atanmalıdır (Aksi takdirde, Genesis Bloğunun karma (hash) değerleri farklı olacaktır). Şimdi 0001 yılında saat 0:00’tır. Bu, ilk raunt için son derece yanlış bir zaman dilimi ile sonuçlanacaktır (tüm CDC'ler 2000’den fazla yıl ile zaman dilimlerini kaçıracak). Bu nedenle ConsensusCommand'in ilk raundu elde edilirken özel işlem yapılacaktır.

GetConsensusBehaviour

AEDPoS sözleşmesinde GetConsensusCommand yöntemini ConsensusCommand'a geri döndürmek için ilk önce giriş halka açık anahtarı ve arama süresini temel alarak AElfConsensusBehaviour elde edilir. Sonra AElfConsensusBehaviour, diğer bilgiler arasında bir sonraki blok süresini belirlemek için kullanılır.

Buradaki mantık, göreceli olarak açıktır ve bir grafik ile açıklanabilir.

Kodun tamamı için Aelf’in GitHub ana sayfasını (https://github.com/AElfProject/AElf) inceleyebilirsiniz.

GetConsensusCommand — UpdateValueWithoutPreviousInValue

AElfConsensusBehaviour.UpdateValueWithoutPreviousInValue’nun ana işlevi, yalnızca bir taahhüt aşaması içeren ancak ortaya çıkarma aşamasını içermeyen Taahhüt Şeması'nı (WiKi girişi) uygulamaktır. Her bir seansın ilk raundu olan (zincir yeni başladığında birincisi dâhil) konsensüs Madencilik Süreci aşamasına karşılık gelen CDC, bu döngünün ilk bloğunu oluşturmaya çalışacaktır.

İlk rauntta birinci raunddaysak, bu rauntta AEDPoS konsensüsünün Round.real_time_miners_information’dan bilgilerinden halka açık anahtarlar sağlayan CDC'nin sırasını okumamız gerekir. Blok zamanının order * mining_interval milliseconds.Mining_interval’dan sonra varsayılan olarak 4000 ms'ye kadar olmasını bekliyoruz.

Aksi takdirde expect_mining_time doğrudan Round bilgisinden okunur ve consensusCommand buna göre döndürülür.

GetConsensusCommand — UpdateValue

AElfConsensusBehaviour.UpdateValue, Taahhüt Şeması’nda bir ortaya çıkarma aşamasını ve yeni bir taahhüt aşamasını içerir. Konsensüs Madencilik Sürecine karşılık gelen aşama, her bir seansın ikinci raundudur ve ondan sonra CDC, bu raundun ilk bloğunu oluşturmaya çalışır.

Doğrudan okuma, expected_mining_time alanı mevcut raundun raund bilgisindeki CDC'nin halka açık anahtarına karşılık gelir.

GetConsensusCommand — NextRound

AElfConsensusBehaviour.NextRound, mevcut rauntta CDC tarafından yayınlanan bilgilere göre bir sonraki raunttaki her CDC'nin dizisini ve karşılık gelen zaman aralıklarını oluşturacak ve RoundNumber'ı bir sayı geriye doğru itecektir.

Bu rauntta ilave blokların üreticisi olarak belirtilen CDC için, bu raunttaki ilave blokların üretilen zaman dilimini okumak yeterlidir.

Belirlenen ekstra blok üreticisinin hattı terk etmesini veya bloğu başka bir çatallanma için bırakmasını önlemek için (ağ kararsızlığı durumunda çatallanma meydana gelir), diğer tüm CDC'ler de bir CDC tarafından üretilen herhangi bir ilave bloğa senkronize edildikten sonra duracak olan ilave blokların üretimi için farklı bir zaman dilimi alacaktır. CDC'ler, çatışmalardan etkilenmemek için zamanlayıcılarını sıfırlamaya devam edecektir.

Özel işlemin ilk raundu için: AElfConsensusBehaviour.UpdateValueWeaPGeviousInValue.

GetConsensusCommand — NextTerm

AElfConsensusBehaviour.NextTerm, yeni seansın ilk raundu için bilgi üretmek üzere mevcut seçim sonuçlarına dayanarak 17 CDC'yi yeniden seçecektir. İlk seansın ilk raundu, AElfConsensusBehaviour.NextRound ile özel olarak işlem görmez.

GetConsensusCommand — TinyBlock

AElfConsensusBehaviour.TinyBlock iki durumda oluşur:
1- Şu andaki mevcut CDC, önceki rauntta ilave blok üreticisidir. NextRound işlemlerini içeren bloklar ürettikten sonra, aynı zaman diliminde yedi bloğa kadar üretmeye devam etmesi gerekir.
2- Mevcut CDC, UpdateValue işlemlerini içeren blokları az önce üretti ve aynı zaman diliminde yedi bloğa kadar üretmeye devam etmesi gerekir.

Temel değerlendirme mantığı; eğer mevcut CDC son ilave bloğun üreticisi ise, 4000ms'lik bir zaman dilimini sekiz 500 ms'lik zaman dilimine bölecek ve dağıtacaktır. Aksi takdirde, ilk durum için doğrudan öncekine dayalı olacak ve üretilen blok sayısı için makul bir zaman dilimi ayıracaktır.

Son olarak blok yürütme süre sınırının tekrardan ayarlanması

Bir sonraki üretim bloğunun zamanını Behavior'a göre hesapladıktan sonra, bir sonraki hızlı zamanın negatif olması mümkündür (şu anki zamanın bir sonraki bloğun teorik zamanını aşması). Bu durumda blok paketleme süresi sınırı, 0 olarak ayarlanabilir. Son olarak sistem işlemleri oluşturna, ağ gecikmeleri ve benzeri işlemler için belirli bir zaman ayırmak amacıyla blok yürütme süresi sınırı bir katsayı (optimize edilen) ile çarpılır.

Yukarıdaki kodun tamamını Github'da (https://github.com/AElfProject/AElf/tree/dev/contract/AElf.Contracts.Consensus.AEDPoS) inceleyebilirsiniz.

Olası optimizasyon talimatları

Mevcut mantık optimizasyon koşullarına bağlı olarak, kod okunabilirliğini artırmak için mümkünse bir fonksiyon olarak uygulanabilir.
Kodları incelemekten ve herhangi bir hata veya öneriyi geliştirme ekibimize göndermekten lütfen çekinmeyiniz.

KAYNAK: https://medium.com/aelfblockchain/aelf-tech-talks-developers-take-on-getconsensuscommand-e4b68f5d3c0e