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

✅ Boilerplate, Aelf'in akıllı sözleşmeler ve DApp geliştirmek için kullandığı ortamdır.

Boilerplate, bazı kodları Aelf ile paylaşır ve Aelf düğümünü dahili olarak çalıştırır.

🔊 Aelf Ana Ağ (Mainnet) Lansmanı Yol Haritası Resmi Olarak Yayınlandı!

Aelf Teknik Konuşmalar - Konsensüs ve Standart Yorumlama / Bölüm 1

Blockchain konsensüsü-merkezi olmayan konsensüs

Bir blockchain sistemi çoğunlukla dağıtılmış bir sistemdir, ancak geleneksel olarak dağıtılmış sistemlerden farklıdır. Geleneksel dağıtılmış sistemlerin iki temel önemi vardır:

1. Trafik arttığında, dağıtılmış sistemler dikey veya yatay bölünmeyi takiben belirlenmiş iş senaryolarını desteklemek için birden fazla makine kullanabilir ve böylece sistemin genel kapasitesini artırabilir.
2. Bir işletme kritik olduğunda, tek hata noktalarını ortadan kaldırmak ve devamlı sistem kullanılabilirliğini artırmak çok önemlidir.

Bir blockchain sisteminin iş senaryosu genel bir dağıtılmış sisteminki kadar karmaşık olduğunda yukarıdaki hususlar kesinlikle gereklidir. Ancak blockchain sisteminin değerlendirilmesinin nedeni, genellikle Bizans sorunu olarak adlandırılan kötü amaçlı düğümler durumunda veri tutarlılığı sorununu çözebilmesidir.

Genel olarak, blockchain dünyasında merkezi bir sunucu yoktur. Topluluk üyeleri ve kullanıcılardan oluşan bir P2P ağından oluşur. Ağdaki herhangi bir bireysel düğüme doğrudan güvenilemez ve kötü amaçlı bir düğüm olabileceği düşünülmelidir. Ancak, tamamen dağıtılmış bir sistemde güvene gerek yoktur. Bu aynı zamanda Bizans generaller sorununun merkezi bir liderlik olmadığı varsayımı ile de tutarlıdır. Örneğin, generallerin belirli bir şehre saldırması gerektiğinde, tüm generallerin başka herhangi bir generalin önerdiği saldırı süresi konusunda fikir birliğine varması gerekir. Yani soru şudur ki, generaller tarafından kararlaştırılan saldırı süresi aynı değilse, hatta bazı generaller hain hâle geldiyse, generaller nasıl bir konsensüse ulaşabilir?

Benzer şekilde, blockchain sisteminin P2P ağında tüm düğümler belirli bir işlem üzerinde nasıl bir konsensüse ulaşabilir? Başka bir deyişle, düğümün ilgili veri tabanı bu işleme dayanarak nasıl değiştirilebilir?

Bizans generalleri sorunu ile ilgili 1982 tarihli makalede Leslie Lamport, generaller arasındaki hainler 1/3'ten az olduğunda etkili bir algoritmanın var olduğunu kanıtladı. Hainlerin ne kadar kötü niyetli olursa olsun, sadık generaller her zaman bir anlaşmaya varabilir. Yine de çok fazla hain varsa, tutarlılık garantisi yoktur.

Blok zincir P2P ağında, kötü niyetli düğümlerin sayısının 1/3'ü geçemeyeceğini varsayarsak, aksi takdirde blok zinciri sisteminin istikrarlı ve güvenli bir temel elde edemediğini düşüneceğiz. Buradan en zorlu sorun, kimin verilerinin bir blockchain sistemindeki son fikir birliğine, kötü niyetli düğümlerin sayısının 1/3'ten daha fazla olmamak üzere, ulaşabileceğini seçmektir.

Başka bir bakış açısı: Bir düğüm sağladığı verilerin blok zinciri sistemi boyunca bir fikir birliğine ulaşmasını nasıl sağlayabilir? Blockchain sisteminin geri kalanını sağlanan verileri kabul etmeye ikna etmek için kanıt sağlaması gerekir.

Bu nedenle, bir blockchain sisteminde standart bir konsensüs arayüzünün nasıl tasarlanacağını tartışmaya başlıyoruz.

Arayüz tasarım standardı ve konsensüs (fikir birliği)

Blockchain konsensüs sürecini basitleştirdik:

• A düğümü, P2P ağına yayın yapmak için bir blok hazırlar.
• Bloğu aldıktan sonra P2P ağının diğer düğümleri, bir dizi doğrulama kontrolünden sonra bloğu yerel en uzun zincire koyup koymayacağınıza karar verir.
• Blockchain sistemindeki düğümlerin üçte ikisinden fazlası yerel bir blok yüksekliğine karşılık gelen blok karma değeri ile tutarlıysa, blok zincirinin blok yüksekliği üzerinde bir anlaşmaya varmış olduğu sonucuna varabiliriz.

A düğümünün ve blok zincirinin diğer düğümlerinin tüm konsensüs sürecini tamamlamasına yardımcı olmak için bir hizmet gerekiyorsa, iki tür hizmet mevcut olmalıdır:

• Blockchain dünyasında bir genel/halka açık anahtar kullanmak, A'nın benzersiz kimliğini belirleyebilir. A hiçbir şey bilmiyorsa, A'ya herhangi bir zamanda blok oluşturmaya çalışıp çalışamayacağını ve bir sorgu başlattığında oluşturduğu blokların diğer düğümler tarafından nasıl kabul edilebilir hale getirilebileceğini söylemek gerekir.
• A dışındaki diğer düğümler ağdan bir blok yayını aldığında, tüm açık kaynak düğümler aracılığıyla bir kod tutarlı hizmet uygulayarak bloğun yasal olup olmadığını doğrularlar.

Bir düğüm, bloğun doğrulanması yoluyla bloğun yasal olduğunu biliyorsa, düğümün A tarafından oluşturulan blok üzerinde bir konsensüse ulaştığı söylenir. Tüm düğümlerin doğrulama hizmeti aynı mantığı kullandığından, blockchain ağındaki tüm düğümler bloğun geçerliliğine karşı aynı tutuma sahip olacaktır. Son olarak, daha uzun zincirlerin ortaya çıkması olmadan, bu bloğun bu blockchain P2P ağındaki en uzun zincire eklenmesi konusunda son bir anlaşmaya varılması da öngörülebilir.

Aelf konsensüs genel arayüz standardı

Şimdi, “Arayüz tasarım standardı ve konsensüs” içinde listelenen iki hizmet türüne dayanarak, Aelf konsensüsünün genel arayüzünü tasarlamaya başlıyoruz.

Her şeyden önce, iki tür konsensüsle ilgili hizmetin, diğer bir deyişle blok üretimi ile ilgili talimatları talep eden ve yeni bloğu doğrulayan, salt okunur arayüzler olduğu ve çağrının kendisinin blockchain ağının hesap defteri bilgilerini değiştirmesi gerekmediği açık olmalıdır.

İkincisi, bu arayüzlere aslında Aelf ana zincir kodu denir. Bu nedenle, arayüz tasarımının Aelf ana zincir kodundaki üretim ve doğrulama bloklarının mantığını takip etmesi gerekir. Tabii ki, ana zincir kodunda bile bu arayüzler, konsensüs hizmetlerinde tek tek görünür.

Bir sonraki bölümde iki tür arayüzü tartışacağız.

KAYNAK: https://medium.com/aelfblockchain/a...and-standard-interpretation-pt-1-4cb6d3e5c612

Aelf CEO'su Haobo Ma, Wanxiang Online Hackathon'da (Yazılım Yarışması) bir Seminer’de bulundu

28 Şubat 2020 akşamı Aelf Kurucusu ve CEO'su Ma Haobo, çevrimiçi blockchain hackathon yarışmasında danışman ve mentor olarak canlı bir öğreticide bulundu. Tartışmalar, 'Toplumun gerçek ihtiyaçlarına göre blok zincirinin yerini keşfetme' ile ilgiliydi.

Bu temel düşüncenin ayrıntıları aşağıdadır:

Ekip, 2016'dan beri temeldeki blockchain teknolojisini araştırıyor. Benzersiz blockchain ticari çözümü Aelf Enterprise, MIIT (Sanayi ve Bilgi Teknolojisi Bakanlığı) tarafından onaylandı ve CETSI (Çin Elektronik Teknolojisi Standardizasyon Enstitüsü) tarafından blockchain sistemi sertifikası aldı. Aynı zamanda bazı sosyal ihtiyaçları çözmek ve blockchain dağıtımını sağlamak için ekip, Tianjin Üniversitesi ile iş birliği içinde bir blockchain laboratuvarı kurdu.

Temel teknolojiye odaklanan blok zinciri projelerinin çoğu, Ethereum veya EOS temel kodunda yalnızca sınırlı değişiklikler yaptı ve Aelf, temel katmanı yazmak için .Net kullanılarak sıfırdan geliştirilmiş tamamen bağımsız bir sistemdir. Aelf, diğer platformların yanı sıra Linux üzerinde de derlenebilir ve Aelf gelişimi, her zaman bir mühendislik yaklaşımı ile yapılır. Piyasadaki mevcut blockchain sisteminin modülerizasyonu oldukça zayıftır. Üst işletme kodu ve alt blockchain kodu birlikte karıştırılır. Örneğin bir Ethereum tokeni kavramı, blockchain sistemi ile karıştırılır ve bağlantı birbirine çok bağımlıdır, bu da gerçek modülerleştirmeyi başarmayı zorlaştırır. Ancak Aelf, modüler hale getirilebilir ve olgun bir IDE sağlar. Geliştiriciler; IDE'ye dayalı uygulamalarda hata ayıklayabilir, uygulamalar geliştirebilir veya dağıtabilir.

Aelf'in çapraz zincir özelliklere sahip olduğunu belirtmek gerekir. Aelf genel test ağı, bir ana zincir ve dört yan zincirden oluşan bir dağıtım yapısına sahiptir ve zincirler arasında bağımsız bir dağıtım vardır. Bir zincirdeki herhangi bir veri diğer zincirlere aktarılabilir. A zincirinin işlemi engellenirse, yürütmek için diğer zincirlere kolayca aktarılabilir ve genel işlem verimliliğini artırabilir. Diğer blok zincir sistemleri, genellikle seri olarak yürütülür ve tıkanıklığa yatkındır.

Blockchain sadece bir kavram değildir ve projenin yürütülmesinin uygulama aşamasında merkezsizleştirilmesini sağlamak için kod tasarım kuralları veya iş mantığı yoluyla uygulanmalıdır. Aslında blockchain belirli bir senaryoya özel olarak uygulanmaz. Eğer bir senaryo merkezi bir çözümle çözülebiliyorsa, blok zincirini dahil etmeye gerek yoktur. İyi bir kamu zinciri, kullanıcıları DAPP (merkezi olmayan uygulama) tanıtımının bir parçası olarak DApp'lere katılmaya kendiliğinden teşvik edebilmelidir, kritik olarak kamu zinciri bir engel olamaz.

DApp'ler aslında herkesin zincirin yönetişimine katılması için bir kural belirleyen düşük seviyeli bir protokoldür. DApp'lerin geçerli olması için, tüm tarafları kendi inisiyatiflerine dahil etmeli ve kendi kendine sürdürülebilirlik ve kalkınma için herhangi bir engel oluşturmamalıdır. Yani zincirin içinde ve dışında verilerin tutarlılığını sağlamak için bu, “iyi insanların” olası kötü niyetli davranışları önlemek için zincirde konsensüsü veya teşvik kazanmasını sağlayan bir ekonomik sistem veya teşvik mekanizması gerektirir.

Proje geliştirmeyle ilgili olarak geliştiriciler, çözümleri gerçek sorunlara dayandırmalıdır. Geliştiricilerin yapması gereken şey, herkesi dahil etmek için yerleşik teşvik mekanizmalarına sahip blockchain tabanlı bir sistem tasarlamaktır. Teşviklerin şekli parasal veya diğer finansal faydalarla sınırlı değildir, aynı zamanda katılımcılara bir başarı hissi verebilir. Son olarak, geliştiricinin geçmiş araştırmalar üzerine inşa yoluyla geliştirmesi gerekir, bu nedenle geliştiricinin diğerlerinden öğrenme becerisine sahip olması gerekir.

Bir blockchain ekosisteminin refahı birçok faktörden etkilenir: Birincisi, Blockchain'in geliştirici dostu olup olmadığıdır. Örneğin geliştirici, DApp promosyonlarını herhangi bir engel olmadan devam ettirebilir. İkincisi, önceki blok zinciri sistemleri ile karşılaştırıldığında bu blok zinciri sisteminde bir gelişme olmalı ve basit uygulama, bir gelişimin odağı olmalıdır. Sonuç olarak blockchain nihai olarak sadece teknik insanlar için değil, genel halka yöneliktir.

Bu korona virüs salgını, daha fazla insanın blok zincirinin avantajlarını ve potansiyelini fark etmeleri için bir fırsat olmalıdır. Blockchain endüstrisi hala erken aşamalardadır ve gelecekte daha fazla ilgi görecektir. Kimlik doğrulaması ve kredi sistemi doğrulamasında iyi uygulama potansiyeline sahiptir. Örneğin bir kara kutu olarak Taobao’nun arka uç sistemi, henüz tüccarların kredisi sorununu çözmedi ve çözümün bir parçası olarak blockchain kullanılabilir. Tabii ki de öncül, veri gizliliğini ve güvenliğini sağlamaktır.

Hackathon etkinliğinin ortak sponsoru olarak Aelf, üstün AR-GE pozisyonlarına sahip seçkin geliştiriciler sunmaya kendini adamıştır. Ana ağ lansmanının ardından Aelf, olgun merkezi olmayan uygulamalarını Aelf blockchain platformuna getiren geliştiricilere yaklaşık 3000 USD değerinde token verecektir.

Canlı öğreticinin videosuna “http://so3w.cn/vxm” adresinden ulaşabilirsiniz.

KAYNAK: https://medium.com/aelfblockchain/a...at-the-wanxiang-online-hackathon-e9428fd0f57d

IEEE C/BDL'nin (IEEE Bilgisayar Topluluğu Blockchain & Dağıtılmış Defter Standartları Komitesi) yönetim kurulu üyesi seçildiği için CEO'muz Ma Haobo'yu tebrik ediyoruz.

Aelf, blockchain ve dağıtılmış defter teknolojisinin hızlı standartlaştırılması ve uygulanması için çalışacaktır. 💪

Daha Fazla Standardizasyon ve Daha Fazla Düzenleme!

Aelf, resmi olarak IEEE C/BDL'ye (IEEE Bilgisayar Topluluğu Blockchain ve Dağıtılmış Defter Standartları Komitesi) katıldı.

Aelf; Blockchain Altyapısı, Blockchain Sistemleri ve Dikey Endüstri Çözümlerinin Ar-Ge alanlarında hizmet verecektir!

Aelf Teknik Konuşmalar — Konsensüs ve Standart Yorumlama / Bölüm 2

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/a...and-standard-interpretation-pt-2-c9bbe36ddc32