• 📌 YASAL UYARI : Forumunda yer alan bilgi, yorum ve tavsiyelerin hiçbiri "Yatırım Danışmanlığı" kapsamında değildir. Yatırım danışmanlığı hizmetlerini aracı kurumlar, portföy yönetim şirketleri, mevduat kabul etmeyen bankalar, dijital varlık, kripto para borsaları v.b. kurumlarla müşteri arasında imzalanacak yatırım danışmanlığı sözleşmesi adı altında yürütülmektedir. Burada yer alan tüm bilgi, belge, yorum, tavsiye, analizler, haber ve yazılar forum üyelerinin kişisel görüşlerinden ibarettir. Bu nedenle forum içeriklerinde yer alan bilgilere dayanarak yatırım kararı alınması tercih ve beklentilerinize uygun olmayabilir.

    📌 ALTIN ÖĞÜT : Forum sitemizde okumuş olduğunuz bilgiler fikir verme amacı güttüğünü unutmayın! Edindiğiniz bilgileri akıl ve mantık çerçevesinde değerlendirmeniz size kazandırır aksi taktirde doğacak olan her türlü sonuçtan kriptokulis.com sorumluluk kabul etmez.

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



Katılım
21 Mar 2019
Mesajlar
503
Beğeniler
5
Puanları
18
Konum
Türkiye
AELF Haftalık Gelişim İlerleme Raporu (15 Temmuz — 21 Temmuz)

Özet: Ekonomik Sistem temettüsü / maliyet optimizasyonu tamamlandı



Geçen Haftanın İlerleme Güncellemesi (21 Temmuz 2019)

Fonksiyon:

- [Tamamlanan] Ekonomik Sistem temettüsü / maliyet optimizasyonu
- [Tamamlanan] Bağımlılık enjeksiyonu ile ilgili sorunlar düzeltildi
- [Tamamlanan] Diğer düğümlere yayın yapmak için üretim düğümleri mantığı optimize edildi
- [Tamamlanan] Konsensüs Sözleşmesi / Ekonomik Sistem sözleşmesi incelemesi
- [Tamamlanan] Paralel gruplama edinme durumu tutarsızlığı problemi düzeltildi
- [Devam eden] Çoklu düğüm durumunda çapraz zincir stabilite sorunu düzeltilmesi:
• [Devam eden] Çapraz zincir bağımlılık senkronizasyon probleminin düzeltilmesi (sorun yeniden ortaya çıktı)
- [Devam eden] Ekonomik Sistem stabilite değerlendirmesi ve problem çözme
- [Devam eden] Sözleşmeleri dağıtırken kod tutarsızlığının düzeltilmesi
- [Devam eden] Düğüm senkronizasyonu sırasında blok senkronizasyonunun hızlandırılması, kod tamamlandı, incelenecek
- [Devam eden] Ağ modüllerinin kod optimizasyonu, kod tamamlandı, incelenecek

Test:
- [Tamamlanan] Ekonomik Sistem temettüsü / maliyet birim testinin optimizasyonu
- [Devam eden] Yan zincir birim testi iyileştirilmesi, kapsam oranı: %85
- [Devam eden] Konsensüs birim testi iyileştirilmesi, kapsam oranı: %80
- [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] Kod optimizasyonu ile ilgili görevler (#1912, #1888, #1887)

Bu Haftanın Planı:
- Çapraz bölge, çoklu düğüm, çapraz zincir stabilite değerlendirmesi ve problem çözme
- Ekonomik Sistem temettüleri / maliyet optimizasyonu
- [Yinelenen] TODO uygulanması ve sorunlardaki hataların düzeltilmesi

KAYNAK: https://medium.com/aelfblockchain/aelf-development-progress-report-july-15th-21st-b25cab610b06
 
Katılım
21 Mar 2019
Mesajlar
503
Beğeniler
5
Puanları
18
Konum
Türkiye
Özel Blockchainler tedarik zinciri endüstrisi için doğru çözüm değildir!



Tedarik zinciri endüstrisinde, şu anda her oyuncuyu rahatsız eden iki sorun vardır. Bunlar "izole edilmiş veri siloları" ve "izlenemeyen, kötü belgelenmiş ve manipüle edilebilir veriler" dir. Blockchain teknolojisinin 2015 yılında Ethereum'un akıllı sözleşme çözümüyle birçok sektöre tanıtılmasıyla birlikte birçok ekip, tedarik zinciri ağları ile karşılaşanlar da dahil olmak üzere birçok endüstri sorununa uygulanacak gerçek dünya çözümleri geliştirmek için mücadele ediyor.

Mevcut Çözüm Arızalıdır

Son birkaç yıl boyunca ‘çözümün’ hassas verileri korumak için özel Blockchain sistemleri gerektirdiğine inanılıyordu. Halka açık Blockchainler’in doğrudan kimliklere bağlı olmamasına rağmen gizli ticari faaliyetler/operasyonlar için uygun olmadığı düşünülmektedir. Ancak bu, sadece ikinci derece bir çözüm değildir; aynı zamanda takip edilmesi gereken tehlikeli bir kavramdır.
Bir özel Blockchain en iyi şekilde katılımcı şirketler arasında ya da en kötü şekilde tek bir merkezi sunucuda depolanır. Her iki durum tam olarak en güvenli Blockchain çözümü değildir. Yine de zaman zaman şirketler, bu çözümde Blockchain’e sahip olmanın basitçe gizlilik ve güvenlik sağladığına inanıyorlar. Bu gerçeklerden daha fazla olamazdı. Merkezi bir sunucu hâlâ merkezi bir sunucudur ve üzerinde çalışan bir Blockchain olduğu için güvenlik kusurları değişmez.

Bu yaklaşımın daha önce mevcut olmayanı ortaya koyduğu iki açık kaygı vardır. Bu özel Blockchainler, yalnızca kendilerine katılan organizasyonların sayısı kadar kullanışlıdır ve ürün tedariki için bir işletme mevcut ağındadırlar. Yeni bir müşteri ekledikleri veya tedarikçileri, nakliye firmalarını, depoları vb. değiştirdikleri anda, onları özel Blockchain ile almaya ikna etmeleri gerekecektir. Ama eğer zaten başka bir özel Blockchain çözümünün parçasılarsa ne olur? Daha sonra şirketin, verilerini bu yeni Blockchain ağına eklemesi gerekecektir.

Aelf ile yaptığı özel bir röportajda Victoria & Tasmania SCLAA Başkan Yardımcısı Daks Gunaratne, "Tarafların her biri birden fazla tedarik zincirine ve süreçlere katılabilir ve zincirin sahibi kimin olduğu, zinciri kimin başlattığı ve bu yeni yol geliştirilirken hangi dilin kullanılacağı da dahil olmak üzere birden fazla faktöre bağlı olarak birden fazla Blockchain’e katılmak zorunda kalabilir.” ifadelerini kullandı.

Gunaratne, bu soruyu gündeme getiren soruları dile getirdi: “O zaman merak ediyorum, kaç tane Blockchain olacak… yüz binlerce? Blockchain'i uygulamak için kaç farklı araç kullanılacak ve birlikte çalışabilecekler mi?”
Tüm bunlara ek olarak şu anda yönetim standardizasyonu yoktur. Bu, her bir ağın aynı parti tarafından kullanılan başka bir ağ ile sorunsuz bir şekilde bütünleşebilecek ya da bütünleşemeyecek kendi yönetişim biçimlerini uygulamasına neden olur.

Dünyanın dört bir yanındaki şirketler tarafından kullanılan mevcut IT sistemi zaten bu sorunları göstermektedir. Standart olmayan, her tür yazılım çözümü için yüzlerce çeşit var. Bu; şirketlerin tercih ettikleri yazılımları bağlı bir tedarikçinin, satıcının veya diğer partinin tercih edilen yazılımlarına entegre etmek için her yıl milyonlarca dolar harcamasına neden olur.
İkinci kuşku, verilerin yalnızca Blockchain ağındaki en zayıf halka kadar güvenli olmasıdır. Her şirket, verilerini korumak için diğer tüm katılımcı şirketlere güvenmek zorundadır ve herhangi bir veri ihlali zincirdeki herkesi etkiler.
Farklı veri gruplarını izole etmeye çalışan, ilgisiz verileri gören oyuncu sayısını azaltan Hyperledger gibi çözümler var. Fakat bu yaklaşım karmaşıklığa katlanarak arttırır ve bu nedenle de zayıf noktaların kötü niyetli oyuncular tarafından faydalanılması için daha da fazla fırsat yaratır. Ancak tedarik zincirinin karşı karşıya kaldığı her iki sorunu çözmek için Blockchain'i kullanmamızın bir yolu vardır.
Buradaki anahtar kelimeler "Birlikte Çalışabilirlik" ve "kontrollü şeffaflık" tır.



Yeni Hibrit Çözüm

Temelde, tedarik zinciri endüstrisindeki oyuncular iki önemli iyileştirmeden sonra - gıda güvenliğini iyileştirmek ve izleme, sahtekarlık ve veri çatışmalarından kaynaklanan maliyetleri azaltmak (örnek olarak) için ağın tamamında şeffaflığın artmasını istiyorlar. Buna paralel olarak, gizlilik ve yeterli veri kontrolü sağlamaları esastır.

Çözüm, hem özel hem de halka açık Blockchainler’i içeren bir çoklu zincir ekosisteminden oluşuyor. Her şirketin kendileri için tam kontrolü elinde tutan kendi özel Blockchainleri’ini kurması ve yönetmesi mantıklıdır, ancak aynı zamanda tedarik ağlarındaki diğer katılımcılara kolayca değişmez ve doğru verileri paylaşmalarını sağlar. Bu, bir ana blockchain ve API'ler kullanılarak yapılır. Ana zincirin tek amacı, uygun verileri koordine etmek ve paylaşmak ve tüm tarafların genel kurallara uymasını sağlamaktır.



Bu yaklaşım ayrıca aracılara çok pahalıya mal olan güncel çözümlerin aksine bireysel oyuncuların ekosisteme minimum etki veya maliyetle kolayca eklenmesini veya çıkarılmasını sağlar.
Bu yaklaşım sadece tedarik zinciri endüstrisinden daha fazla fayda sağlayacaktır. Temelde, neredeyse her sektörde gerçekleşen hassas verilerin dağıtılmasını veya aktarılmasını gerektiren herhangi bir ağa uygulanacaktır. Aşağıdaki durumu düşününüz:

Büyük bir perakende zinciri, bir çocuk oyuncağında tehlikeli bir kimyasal keşfeder. Sahip oldukları tek bilgi, nereden geldiği ve alındığı tarih olacaktır. Aynı konudan etkilenebilecek tüm oyuncakları geri çağırmak, kayda değer miktarda gelir kaybettirebilir. Kimyasalın nerede ortaya çıktığını ve diğer oyuncakları, diğer partileri veya diğer mağazaları etkileyip etkilemediğini hızlı bir şekilde bilmenin kesin bir yolu yoktur.

Şimdi çoklu zincir çözümünü kullandığımızı hayal edin. Birkaç dakika içinde belirli oyuncakları fabrikaya ve belirli partilere geri döndürebiliriz. Sorunu izole etmek çok uzun sürmez. Sadece bu değil, etkilenen boya setinden etkilenen her bir oyuncak setini görebiliriz. Tehlikeli boya ile oyuncak almış her mağazayı da görebiliriz. Şimdi etkilenen ya da etkilenmeyen ve 3 hafta süren 500.000 oyuncağın geri çağrılması, sadece 10 mağazada 5.000 oyuncağın geri çağrılmasına indirgenmiştir ve %100 doğru olduğumuzu biliyoruz.

Bu çözüm hali hazırda mevcuttur

Blockchain birlikte çalışabilirlik çözümüne gerçek dünya çözümleri sunan birkaç proje var. En belirgin üç tanesi Aelf, Cosmos ve Polkadot'tur. İkincisi, bu çözüme akademik ve teknik bir yaklaşımla yaklaşma eğilimindedir ve çözümün pratik yaklaşımına daha az odaklanır. Cosmos, Tendermint'in yardımıyla yaklaşımını geliştirdi. Temel olarak, diğer Blockchainler’den gelen verileri okumak ve doğrulamak için bir zincir röle (relay) sistemi kullanıyorlar. Cosmos'a benzer şekilde Polkadot, Röle Zinciri adı verilen bir zincir röle sistemi de kullanır. Her üç projenin de yalnızca iki bileşene odaklanan ana zinciri vardır: güvenlik ve tüm bağımsız zincirleri birbirine bağlamak.

Aelf, kurumsal beta platformunun son lansmanı ile 2017'den bu yana işletmeler için böyle bir sistem geliştirmektedir. Ağ katılımcılarının halka açık, özel veya hibrit yan zincirleri kişisel gereksinimlerine en iyi şekilde göre uyarlamalarını sağlayan Cosmos ve Polkadot'a benzer bir “ana zincir + çoklu yan zincir” çözümü kullanıyorlar. Ana zincirin tek amacı, ekosistemin hem iç hem de dış olarak diğer kullanıcılara veri doğrulama ve birlikte çalışabilirlik özellikleri sunarken, ağı denetlemektir. Aelf'in önceki iki projeye göre farklılık gösterdiği nokta, paralel işleme ve küme düğümlerinin kullanılmasıdır. Bu yeni unsurları geliştirerek Aelf, şu anda diğer birçok Blockchain çözümleriyle karşı karşıya olan ölçeklenebilirlik sorunlarını önleyebilmiştir. Aelf'i diğer iki projeden farklı kılan başka bir etken konsensüs protokolündedir; Cosmos ve Polkadot PBFT'yi kullanırken Aelf, ağ ile daha iyi ölçeklendirilmesi amaçlanan bir DPoS protokolü kullanılarak geliştirilmiştir.



Ernst & Young, Microsoft (Trusted Compute), IBM ve Walmart (Trust Food) gibi şirketler hali hazırda farklı çözümler arıyor ya da zaten Blockchain platformlarına sahipler.

Hangi platformun daha hızlı bir şekilde ölçeklendirildiğine bakılmaksızın, yukarıda belirtilen tüm platformların birlikte çalışabilirlik işlevleriyle birlikte var olmaları ve aralarındaki etkileşimle gelişmeleri mükemmel bir şekilde mümkündür.

KAYNAK: https://medium.com/aelfblockchain/p...on-for-the-supply-chain-industry-734a84efa70e
 
Katılım
21 Mar 2019
Mesajlar
503
Beğeniler
5
Puanları
18
Konum
Türkiye
Aelf'deki test uygulaması Çin ordusunun Blockchain'i benimsemesi için kapıyı açtı!

Çin’in Ulusal Savunması’na geçen hafta Team Haizhitian tarafından Aelf Blockchain’de oluşturulan BEHM test uygulaması ile Blockchain teknolojisi ortaya sunuldu. Ulusal Savunma “Çin’in Yeni Bir Çağda Ulusal Savunması” başlıklı yeni bir Whitepaper yayınlanmasıyla açık bir şekilde yenilikçi hırs ve gelişme gösterirken bu, uygun bir zamanda geldi.

Çin’in Ulusal Savunması Yeni Whitepaper Yayınladı

24 Temmuz 2019’da Çin Halk Cumhuriyeti Devlet Konseyi Bilgi Bürosu, “Çin’in Yeni Çağ’daki Ulusal Savunması” başlıklı resmi bir Whitepaper yayınladı. Whitepaper, altı bölüme ayrılmıştır:

1. Uluslararası Güvenlik Durumu
2. Çin’in Yeni Çağdaki Savunma Ulusal Savunma Politikası
3. Çin’in Silahlı Kuvvetlerinin Yeni Çağdaki Görevleri ve Görevleri Yerine Getirmek
4. Çin’in Ulusal Savunması ve Silahlı Kuvvetlerinde Reform
5. Makul ve Uygun Savunma Harcamaları
6. İnsanlık İçin Ortak Bir geleceğe sahip bir Topluluk Oluşturmaya Aktif Olarak Katkıda Bulunmak

Çin’in savunma harcamalarının dökümü ve uluslararası iş birliği faaliyetleri gibi konularla ilgili bir dizi şema ve tablo ek olarak eklenmiştir.

Liberation Army Daily Blockchain Önerir

Bu haftanın başlarında “Liberation Army Daily”, bilgi ağı şebekesini daha da güçlendirmek için tahribat karşıtı kapasitesinin vurgulanması gerektiğini ve ağ güvenliği korumasını tasarlamak için merkezi olmayan bir Blockchain veri tabanı mimarisi kullanılması gerektiğini açıklayan bir yayın yaptı. “Merkezsizleşme” kabiliyeti, herhangi bir düğümün olumsuz etkilenmesi ve hatta tahrip olması durumunda genel ağ işletimi etkilenmeden kalacaktır.

Dağıtılmış, halka açık ve şeffaf ve güvenilir bir defteri olarak bir Blockchain; ağ veya veri tabanındaki değişiklikleri kalıcı olarak kaydeder ve savunma ve askeri alanda birçok potansiyel uygulama vardır. Blockchain teknolojisi; askeri insan kaynakları yönetimi, silah ve ekipman ömrü takibi ve askeri malzeme tedariki ile daha verimli ve güvenli bir şekilde araştırmada kullanılıyor. Blockchain teknolojisinin orduyu bir sonraki teknolojik gelişme çağına taşımaya yardımcı olabileceğine ve daha verimli, güvenli ve zamanında veri yönetimi iyileştirmelerine yardımcı olacağına inanılmaktadır.

Test Blockchain Uygulaması Yolu Açıyor

Son zamanlarda Çin Sanayi ve Bilgi Teknolojileri Bakanlığı ve Çin Blockchain teknoloji Endüstri Geliştirme Forumu tarafından düzenlenen üçüncü Çin Blockchain uygulama Yarışması Hangzhou’da gerçekleştirildi. Çin Gemi İnşa Sistemleri Mühendisliği Araştırma Enstitüsü'nden Team Haizhitian, Aelf Enterprise 0.7.0 beta platformuna dayanan “BEHM: Kaynakların Yakınsaması için Bir Açık Ekipman İş Birliği Destek Platformu” projesini geliştirdi ve üçüncülük ödülü kazandı.



Veri İş Birliği Stratejisinin Optimize Edilmesi

BEHM; hassas verilerin farklı yönetim ve kontrol yönlerini bir “paylaşılan defter” stratejisi ile uygular; veri koruma protokolleri sürekli olarak sağlanırken, belirli verilerin dağıtılmış işlemlerle yayınlanmasını ve dolaşımını garanti eder. BEHM; ayrıca malzeme yönetimi, dağıtım ve talep yönetimi ve sağlık durumu toplanması gibi diğer organizasyonel ihtiyaçları elde etmek için veri iş birliği stratejileri tasarlar.

Silah Yönetiminin Optimize Edilmesi

Ekipman sağlığı durum yönetimi araştırmasına dayanarak BEHM, ekipman sağlığı yönetiminin zahmetli süreci, yedek parça garanti sürecinin uygulanmasındaki bağımsızlık eksikliği, düşük yönetim şebekesi uyumu ve yüksek bağlama derecesi problemleri gibi sorunları çözdü. BEHM, silah ve ekipman yönetimi planları için daha iyi bir çözüm sunan “paylaşılan defterler” ve “Domain’ler arası konsensüs” gibi özelliklere sahiptir.

Askeri Lojistik Akıllılaştırma

BEHM, sistemdeki insanları ve nesneleri otonom ağlar aracılığıyla birbirine bağlayarak merkezi olmayan bir eşler arası ağ oluşturabilir. Ağdaki düğümler, serbest akışlı iletişimi kolaylaştırmak için doğrudan veya dolaylı olarak iletişim kurabilir. Lojistik zincirindeki veri bilgileri, tüm ağ tarafından denetlenen her blokta saklanır. Bir düğümün geçersiz bir işlem gerçekleştirdiği tespit edilirse, etkin sistem işlemlerinin devam etmesini sağlamak için diğer tüm düğümler tarafından reddedilir.



Yeni Bir Kapı Açıldı


Ödüllü BEHM (Kaynak entegrasyonu bir açık ekipman iş birliği garantisi platformu) Blockchain teknolojisi ile ulusal savunma geliştirmenin entegrasyonunda bir adım daha attı ve ulusal savunma bilimi ve teknolojisi endüstrisinde reformu daha da ilerletti.

Whitepaper’da “Çin’in Yeni Çağda Ulusal Savunması” belirtildiği gibi “Bugün dünya, bir yüzyılda görülmeyen köklü değişikliklerden geçiyor. Ekonomik küreselleşme olarak, bilgi toplumu ve kültürel çeşitlilik giderek çok kutuplu bir dünyada gelişiyor. Barış, kalkınma ve kazan-kazan iş birliği zamanın geri dönüşü olmayan trendleri olmaya devam ediyor. Yine de uluslararası güvenlik konusunda belirgin istikrarsızlaştırıcı faktörler ve belirsizlikler vardır. Dünya henüz sakin ve huzurlu bir yer değildir.”

Dijital teknolojinin sürekli gelişmesiyle birlikte, büyük güçler arasındaki rekabet kaçınılmaz olarak dijital alanda ciddi bir şekilde gelişecektir. Geleneksel güvene dayalı ağ savunması stratejileri, günümüzde artan ağ tehditlerinin getirdiği zorlukları çözemedi ve bu nedenle ağ güvenliği korumasını tasarlamak için Blockchain mimarisini kullanmak zorunludur.

Blockchain teknolojisi ile Ulusal Savunma ve Hükümet alanlarındaki kullanım durumları arasında daha yakın bir ilişki görmek heyecan vericidir. Bu iş birliği, birçok projenin politika yapıcılar tarafından belirlenen düzenlemeler ve yapı içinde çalışmayı teşvik etmek istediği bir şeydir. Genellikle gelecekteki iş birliği, araştırma ve nihayetinde benimseme için kapıyı açmak, sadece bir güçlü kullanım durumunu gerektirir. BEHM, fitili mükemmel fırsatta ateşlemiş olabilir.

KAYNAK: https://medium.com/aelfblockchain/t...nas-military-to-adopt-blockchain-be7b09b2769d
 
Katılım
21 Mar 2019
Mesajlar
503
Beğeniler
5
Puanları
18
Konum
Türkiye
AELF Haftalık Gelişim İlerleme Raporu (22 Temmuz — 28 Temmuz)

Özet: Ekonomik Sistem temettüsü / maliyet optimizasyonu tamamlandı



Geçen Haftanın İlerleme Güncellemesi (28 Temmuz 2019)

Fonksiyon:

- [Tamamlanan] Paralel yürütmeden sonra çatışma yönetimi düzeltildi
- [Tamamlanan] Paralel gruplama edinme durumu tutarsızlığı problemi düzeltildi
- [Tamamlanan] Düğüm senkronizasyonu sırasında blok senkronizasyonunun hızlandırılması
- [Tamamlanan] Ağ modülü kod optimizasyonu
- [Devam eden] Ekonomik Sistem stabilite değerlendirmesi ve problem çözme
- [Devam eden] Sözleşme / zincir süreci yükseltme
- [Devam eden] Çapraz zincir işlem sorunu çözüldü, kodu tamamlandı, test edilecek
- [Devam eden] Çapraz zincir bağımlılık senkronizasyon probleminim çözülmesi
- [Devam eden] Merkle Tree uygulamasının optimize edilmesi
- [Devam eden] Sözleşme güvenlik sorununun kontrol edilmesi ve düzeltilmesi

Test:

- [Devam eden] Konsensüs birim testini iyileştirilmesi (ekonomik sistem dalında, henüz geliştirici ile birleştirilmedi):
• [Devam eden] Yan zincir birim testinin iyileştirilmesi, mevcut kapsam oranı: %85
• [Devam eden] Konsensüs birim testinin iyileştirilmesi, mevcut kapsam oranı: %80
- [Devam eden] Yan zincir birim testinin iyileştirilmesi, mevcut kapsam oranı: %92 (başka bir dalda geliştirildi, henüz geliştirici ile birleştirilmedi)
- [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] Kod optimizasyonu ile ilgili görevler (#1912, #1888, #1887)

Bu Haftanın Planı:
- Çapraz bölge, çoklu düğüm, çapraz zincir stabilite değerlendirmesi ve problem çözme
- [Yinelenen] TODO uygulanması ve sorunlardaki hataların düzeltilmesi

KAYNAK:
https://medium.com/aelfblockchain/aelf-development-progress-report-july-15th-21st-b25cab610b06
 
Katılım
21 Mar 2019
Mesajlar
503
Beğeniler
5
Puanları
18
Konum
Türkiye
Microsoft artık Aelf’in tek tık dağıtımını destekliyor - Azure'da Mevcut İlk Birlikte Çalışabilir Blockchain



31 Temmuz’da Aelf’in Enterprise 0.7.0 beta sürümü, resmi olarak dünya lideri kamu bulut bilişim platformu Microsoft Azure'da kullanıma sunuldu. Geliştiriciler; Azure Marketi'nde Enterprise 0.7.0 Beta sürümü ile artık Blockchain uygulamalarını oluşturabilir, yönetebilir ve genişletebilir. Ek olarak Aelf; kullanıcıların iş mantığı ve uygulama geliştirme üzerinde hızlı bir şekilde çalışmaya başlayabilmeleri için destekleyici eğiticiler, akıllı sözleşmeler ve Dapp geliştirme örnekleri sunmaktadır.

Hem Azure hem de Amazon Web Servisleri’nde (AWS) (https://aws.amazon.com/marketplace/pp/B07S2DT928) mevcut olan Aelf, ayrıca bireysel ihtiyaçlara göre örnek kodlar ve uygulama geliştirme kılavuzları içeren bir kütüphane de sunmaktadır. Aelf; işletmelere Blockchain ağlarının temellerini oluşturmalarına, Azure gibi bulut hizmetlerine işlem düğümleri dağıtmalarına ve nihayetinde merkezi olmayan uygulamalar oluşturmalarına yardımcı olma konusunda uzmanlaşmıştır. Blockchain yoluyla yeni iş modellerinin kilidini açmaları için şirketlere yardımcı oluyorlar ve çoklu kurumsal iş bağlantılarının inovasyonunu hızlandırıyorlar.

Aelf, küresel Blockchain ekolojisinin temel taşı olmayı hedeflemektedir ve bunu geliştiriciler ve işletmeler için Blockchain tabanlı uygulamaları hızlı ve güvenli bir şekilde dağıtmaları için kapsamlı Blockchain paketleri oluşturarak gerçekleştirecektir. Aelf, Blockchain yenilikçiliğini sürdürmeye ve Microsoft Azure'daki kullanıcılara daha benzersiz iş avantajları getirmeye devam edecektir.

Aelf kurumsal Blockchain ağı oluşturun ve yönetin:

https://azuremarketplace.microsoft.com/en-us/marketplace/apps/aelf.aelf-enterprise

KAYNAK: https://medium.com/aelfblockchain/m...irst-interoperable-blockchain-is-8b1dafba6abd
 
Katılım
21 Mar 2019
Mesajlar
503
Beğeniler
5
Puanları
18
Konum
Türkiye
Aelf Çin Hükümeti Blockchain Sertifikasyonu ile Alipay ve Lenovo'nun Safına Katıldı

Aelf, Alipay ve Lenovo ilk sertifika alanlardan bazıları…



Bir endüstri gücü hareketinde Çin Hükümeti; doğrudan düzenleyici kontrol kullanmadan, Blockchain endüstrisinde kalite ve istikrar sağlamaya çalışmıştır. Hükümet, Blockchain teknolojisini ve potansiyelini olumlu görüşler ile dikkate alıyor. 2017'den başlayarak 1973 yılında kurulmuş bir devlet kurumu olan Çin Elektronik Teknoloji Standardizasyon Enstitüsü (CESI), Çin'de faaliyet gösteren üst Blockchain projelerinin basınç testini ve belgelendirmesini sağlamak amacıyla Standart Blockchain Sistemi İşlev Testini yürütüyor. Sertifika almak için zorlu engeller o kadar yüksek ki Lenovo, Alipay ve en sonuncusu Aelf dahil olmak üzere dünya genelinde yalnızca 30 proje testi geçebildi.

Bu organizasyonun arkasındaki temel düşünce, teknolojiye olan inançtır. Kripto para biriminin tutucu durumu nedeniyle uluslararası olarak paylaşılan görünüme rağmen, Çin aslında teknolojinin yararlarını ve uygulama potansiyelini anlıyor. 8 Temmuz 2019'da gerçekleştirilen Dijital Finans Açık Araştırma Programının ilk akademik semineri ve açılış töreninde Çin Halk Bankası Araştırma Bürosu Direktörü ve Para ve Finans Bürosu Başkanı Xin Wang, Blockchain’in potansiyeline dayanan finansal çözümleri belirtti.

“Dijital finansal çözümlerin inşasını güçlendirmeliyiz (Blockchain temelli). Gizliliğin korunması ve kötü niyetli saldırılara karşı sistem güvenliği alanlarında mevcut mali altyapıyı içeren çeşitli teknik eksiklikler vardır.”



Standart Blockchain Sistem Fonksiyon Testinin oluşturulması, düzenleyici ve geliştirme çözümleri konusunda Çin'in dünyadaki hükümetlerle karşılaştırıldığında ön planda olduğunu göstermektedir. Birçok hükümet Blockchain projelerini düzenlemek için mücadele ederken, Çin kararlı bir duruş sergilemiş ve daha önce tanımlanmamış teknolojiyi doğrulamak için kapsamlı kılavuzlar ve testler geliştirmiştir. Belgelendirme; genel olarak kamu ve diğer kuruluşlar tarafından, bağımsız olarak onaylamayı yürütecek bilgi ve insan gücü olmadan zor olabilecek projelerin temelini değerlendirmek için kullanılabilecek bir standart sağlar.

Herhangi bir projenin sertifikasyon için başvuruda bulunma zorunluluğu olmasa da başvuruda bulunanlar teknolojinin tüm yönlerinin kalitesini doğrulamak için sıkı bir test ve incelemeye tabi tutulur. Test sürecinin bir parçası olarak uzmanlaşmış devlet kurumlarından yapılan bir ziyaret, 40 sayfanın üzerinde test ve analizden oluşan kapsamlı bir süreci tamamladı. Test, karmaşık ve zordur ve geçiş %60'ın üzerinde bir puan oluşturur. Uygulamadan sertifikasyona kadar süreç yaklaşık 4 ay sürüyor. Son 2 yılda yalnızca 30 proje sertifika aldı.



Aelf, sertifikasyon alan en yeni ve %90'ın üzerinde bir puanla dünya çapında tanınan statüsünü alan ilk uluslararası Blockchain Start-Up’ıdır. Aelf’in CEO’su ve Kurucusu Ma Haobo, “Bu sertifika sadece geliştiricilerimizin değil, aynı zamanda Blockchain platformumuzun da kalitesini ve temel yeteneğini göstermektedir. Büyük işletmelerin müşterilerinin bekledikleri performansta çalışabilmelerini sağlamak için bekledikleri ve gerçekten de talep ettikleri kesin kaliteyi karşılamak için tasarlanmıştır.” ifadelerini kullandı. Bu sertifikasyonun, diğer hükümetlerin sürekli gelişen düzenleyici çözümlerine yardımcı olmak için dikkat etmesi ve kullanması gereken bir şey olduğunu açıkladı.

KAYNAK:
https://medium.com/aelfblockchain/a...ernment-blockchain-certification-44e4c684e021
 
Katılım
21 Mar 2019
Mesajlar
503
Beğeniler
5
Puanları
18
Konum
Türkiye
Aelf Teknik Konuşmalar: Aelf Blockchain’de Bellek İkilemini Çözme

Bölüm 1

Geliştirici: Xin Zhang




Aelf Enterprise (Kurumsal) Blockchain'in test ağı (Testnet) aşaması boyunca sıfırdan kod yazarken beklendiği gibi sayısız gün, sorun gidermek (troubleshooting) ve çok sayıda sorunu çözmek için harcandı. Böyle bir problem, düğümlerin aktif hale geldikten kısa bir süre sonra çökmesine neden olur. Bu makale, Aelf geliştiricilerinin konunun özünü nasıl tanımladığını ve çözdüğünü ele alacaktır.

Arka Plan
Aelf tek düğüm test aşaması sırasında geliştiriciler, düğümün aniden çevrimdışı olduğunu buldu. Kaydı kontrol ettikten sonra işçilerin (işlem yürütme süreci sırasında) tamamen düşürüldüğü, işlemlerin yürütülmesinin durduğu ve bunun sonucunda düğümün çöktüğü anlaşıldı.

Ön teşhis
Düğümler ve tüm çalışanları aynı sunucuda olduğu için bu sorun oldukça olağandışıydı ve bu nedenle ağ iletişimi bir sorun olmamalıydı. Ek teşhisler; ana düğümün, tüm işçilerin ve Lighthouse’ların neredeyse aynı anda çevrimdışı olduklarını ortaya çıkardı. Sorun gidermeye (troubleshooting) devam ettik ve sorunları zabbix aracılığıyla bulduk - sunucunun RAM'i, bir noktada operasyon kapasitesine ulaşmaya yaklaşmış. Zaman damgasına bakıldığında, düğümün arızalandığı zamanla çakıştı.

Temel Sorunun Belirlenmesi
Düğümün bellek kullanımını test etmeye odaklandık. Ön sonuçlar, düğümün uzun süre çalıştığından işlemin sunucunun belleğini sürekli olarak kapladığını gösterdi. Bellek kullanımı, özellikle çok sayıda işlem gönderildikten sonra önemli ölçüde artmaktadır ve en önemlisi de işlemler durduktan sonra bile bellek serbest bırakılmamıştır.

Sorunu yeniden üretme
Öncelikle kullanılan hizmet ortamını tanıtmalıyım: Ubuntu 16.04.5 LTS ve dotnet core versiyon 2.1.402

Düğüm, yaklaşık 90 MB'lik bir temel bellek kullanımına sahiptir.



Düğüme sürekli olarak çok sayıda işlem göndererek, düğüm alış - veriş havuzunu işlemleri biriktirirken ve yürütürken izleyebiliriz (aşağıda gösterilmiştir).



Bir süre sonra, bellek kullanımı 1 GB'a ulaştı.



Bu noktada, işlemlerin yürütülmesi durduruldu. Aşağıda görüldüğü gibi halihazırda alış - veriş havuzunda bulunan tüm işlemler yürütülmüştür.



“Bellek ayak izini izlemeye devam ettik ve bir süre sonra bellek kullanımının azalmadığını ve 1GB kullanım seviyesini koruduğunu tespit ettik.”

Analiz ve Çözüm

Düğümlerimizi analiz etmek için lldb kullanırız.
Bu, ilk önce sunucuya lldb yüklenerek yapılır.
Sudo apt-get install lldb
Yerel ibsosplugin.so lokasyonunun bulunması
Find /usr -name libsosplugin.so
lldb'nin başlatılması ve işleme eklenmesi
Sudo lldb –p 13067
libsosplugin.so yüklenmesi
Plugin load /usr/share/dotnet/shared/Microsoft.NETCore.App/2.1.4/libsosplugin.so
Setclrpath /usr/share/dotnet/shared/Microsoft.NETCore.App/2.1.4/

Bir sonraki nesnenin analiz edilmesi
Dumpheap -stat



Aşağıdaki nesnelerden çok sayıda gözlemledik
AElf.Kernel.TransactionHolder
System.String
AElf.Common.Address
System.Collections.Concurrent.ConcurrentDictionary`2+Node[[AElf.Common.Hash,A Elf.Common],[AElf.Kernel.TransactionHolder,AElf.Kernel.TxHub]]
AElf.Kernel.Transaction
AElf.Common.Hash
Google.Protobuf.ByteString
System.Byte[]


Olağandışı büyük nesneleri tanımlamaya çalıştığımızdan, 1024 bayttan daha büyük nesnelere odaklandık.



Göreceli olarak büyük aynı tipten 4 nesne olduğunu görebiliriz
System.Collections.Concurrent.ConcurrentDictionary`2+Node[[AElf.Common.Hash, AElf.Common],[AElf.Kernel.TransactionHolder, AElf.Kernel.TxHub]][]

MethodTable'a karşılık gelen nesnelere daha fazla bakarak



8 nesneden 4'ünün alışılmadık derecede büyük olduğunu belirledik. Nesne bilgilerini görüntülemek için bunlardan birini seçerek içinde 573.437 değerin depolandığını gördük.



Yukarıdaki analize dayalı karşılık gelen kaynak kodunu kontrol ettik ve şu sınıfı yerleştirdik: AElf.Kernel.TxHub. Bu sınıfın temel rolü, işlem havuzu işlem verilerini depolamaktır. Bu sınıf, işlem verilerini depolamak için 8 ConcurrentDictionary<Hash, TransactionHolder> içerir. TransactionHolder sınıfı; yukarıdaki bellek analizinin sonuçlarıyla tutarlı olan Hash, Transaction, vb. depolar. Dahili mantığa tekrar baktığımızda, tüm işlemlerin işlem havuzuna girdikten sonra TxHub'ta saklandığını ve artık serbest bırakılmadığını gördük. Bundan problemin özünü tespit edebildik.

Bu sorunu çözdükten sonra doğrulama için yukarıdaki adımları tekrar ettik. Etki belliydi. İşlem havuzundaki işlemleri yürüttükten sonra, bellek kullanımı önemli ölçüde azaldı. Bellek kullanımının son sonuçları aşağıdaki gibidir:



Ek olarak bellekteki nesnelerin içeriğine bakarak, toplam nesne sayısının da önemli ölçüde düştüğünü gördük.



Çekirdek sorunu tanımlanmış ve çözülmüş olsa da zaman içinde bellekte hâlâ küçük bir artış olduğunu ve bellekte büyük nesnelerin bulunduğu durumlar olduğunu fark ettik. Kalan (artık) sorunları analiz etmek için daha fazla zaman harcayacağız.

KAYNAK: https://medium.com/aelfblockchain/a...emory-dilemma-on-aelf-blockchain-2c7d10f09a3a
 
Katılım
21 Mar 2019
Mesajlar
503
Beğeniler
5
Puanları
18
Konum
Türkiye
Çin Belediye Hükümet Yetkilileri ve Diğer Bölgesel Liderler Aelf’i Ziyaret Etti



22 Haziran günü Tianjin Belediye Komitesi Bakan Yardımcısı Yin Hejun, Tianjin Jinnan Bölge Partisi Komitesi Sekreteri Hui Liu, Jinnan Bölge Başkanı Yinong He ve diğer yöneticiler; Jinnan Bölgesi Haitang Startup Caddesi'nden birkaç yüksek potansiyel işletmeyi ziyaret etti. Bölge; Tianjin’in yapay zekâ, Blockchain ve Şeylerin/Nesnelerin İnterneti gibi bilim ve teknoloji inovasyonunun yüksek kalitede geliştirilmesine yardımcı olmak üzere tasarlandı ve Pekin-Tianjin-Hebei bölgesinin etkili bir şekilde birleşmesine öncülük etti.

Bölgedeki tek Blockchain şirketi olan Aelf; Tianjin Belediye Hükümeti liderlerinin yanı sıra Pekin Üniversitesi, Tianjin Üniversitesi ve Nankai Üniversitesi'nden temsilciler tarafından yapılan ziyaretleri memnuniyetle karşıladı. Aelf İş Geliştiricisi Chong Li; Aelf'in teknik özelliklerini, parlak noktalarını ve küresel etkisini liderlere ve misafirlere sundu.

“Aelf; küme bilişim, modüler geliştirme ve çapraz zincir iş birliği gibi teknik özelliklere sahip yeni nesil yüksek performanslı ve ölçeklenebilir bir Blockchain sistemidir. Akıllı sözleşme çalıştırma performansı, yaygın Ethereum EVM'den 1000 kat daha hızlıdır.”

Li, Aelf Blockchain'in bir görsel örneği ile şöyle devam etti:

“Şu anda Aelf; işletmeler için tam bir Blockchain çözümü sunan Aelf Enterprise Beta sürümünü yayımladı. Aynı zamanda Aelf; güvenilir, verimli ve güvenli teknolojiler ile endüstrilere, organizasyonlara ve işletmelere hizmet vererek dünya çapında tanınmış birçok işletme ile stratejik iş birliğine ulaştı.”

Aelf teknik ekibi; Aelf Enterprise Beta sürümüne dayalı olarak sözleşme yazma ve dağıtım sürecini, ön uç (front-end ) etkileşimini ve çapraz zincir işlem doğrulamasını gösterdi. Blockchain sisteminin oluşturulması sadece 5 dakikada ve akıllı sözleşme dağıtımı 8 dakika içinde tamamlanarak yüksek derecede teknik kapsamlılık gösterildi.

Sunumun ardından hükümet liderleri ve üyeleri, Aelf’in çapraz zincir teknolojisi ve umutları için takdirlerini ifade ettiler. Tianjin Belediye Komitesi Bakan Yardımcısı Hejun Yin, 2016 yılının başlarında Blockchain’in ilk kez Danıştay tarafından yayınlanan “13. Beş Yıllık Ulusal Bilgilendirme Planında” listelendiğini söyledi. “Şu anda, Çin’in Blockchain endüstrisi hızla büyüyor. Tianjin Belediyesi; Blockchain teknolojisini endüstrinin temel bir inovasyonu olarak kabul ediyor, Blockchain endüstrisi inovasyonunu güçlü bir şekilde destekliyor, geleneksel endüstrilerin yüksek kaliteli gelişimini teşvik ediyor ve endüstriyel dönüşüm ve yükseltmeleri hızlandırıyor. Aelf; aktif olarak yeni endüstrileri birbirine bağlar ve mevcut araştırma ve geliştirme, tanınmaya ve desteklenmeye değerdir.”

Ziyaretin sonunda Tianjin Partisi ve Hükümet delegeleri, Aelf’in Tianjin'deki çeşitli işletmelerle iş birliğini derinleştireceğini ve yeni nesil Blockchain teknolojisinin geliştirilmesinde verimli sonuçlar elde etmeye devam edeceğini umduğunu belirtti. Aynı zamanda, Aelf'in bugüne kadar elde ettiği çığır açan gelişim için yüksek bir tanınma düzeyi ifade ettiler. Gelişmiş Blockchain teknolojisinin tanıtımına devam etmeyi, uygulama gerçekleştirmeyi hızlandırmayı ve Blockchain'in hızlı gelişimini Çin genelinde yaygınlaştırmayı umuyorlar.

Chong Li, Aelf’in temel güçlü yönlerinden birinin yenilik arama ve ticari toplumun ve Blockchain endüstrisinin bir uygulayıcı ve keşifçi tutumu ile köprülenmesini sağlama yeteneği olduğunu söyledi. Aelf’in esas hedefi, topluma teknoloji ile hizmet etmek ve Blockchain gelişiminin ilerlemesine katkıda bulunmaktır.

KAYNAK: https://medium.com/aelfblockchain/c...her-regional-leaders-visits-aelf-777017b1d0e1
 
Katılım
21 Mar 2019
Mesajlar
503
Beğeniler
5
Puanları
18
Konum
Türkiye
AELF Haftalık Gelişim İlerleme Raporu (29 Temmuz — 4 Ağustos)

Özet:
Ekonomik Sistem stabilite sorunu düzeltildi



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

Fonksiyon:

- [Tamamlanan] Ekonomik Sistem stabilite sorunu düzeltildi
- [Tamamlanan] Sözleşme/zincir yükseltme işlemi
- [Tamamlanan] Çapraz zincir işlem sorunu düzeltildi
- [Devam eden] Ekonomik Sistemin Optimize Edilmesi #1936
- [Devam eden] Sansürleme duyurusu nedeniyle oluşan senkronizasyon sorunu düzeltildi, kod tamamlandı, incelenecek
- [Devam eden] Birleştirme durumu tutarsızlığı sorununun düzeltilmesi, senkronizasyon sırasında Block NotLink sorunu oluştu; kod tamamlandı, incelenecek
- [Devam eden] Çapraz zincir bağımlılık senkronizasyon probleminin çözülmesi
- [Devam eden] Merkle Ağacı'nın uygulanmasının optimize edilmesi, gözden geçirme
- [Devam eden] Sözleşme güvenlik sorununun kontrol edilmesi ve düzeltilmesi

Test:
- [Devam eden] Konsensüs birim testini iyileştirilmesi (ekonomik sistem dalında, henüz geliştirici ile birleştirilmedi), mevcut kapsam oranı: %90
- [Devam eden] Yan zincir birim testinin iyileştirilmesi, mevcut kapsam oranı: %93
- [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; kod tamamlandı, inceleme

Bu Haftanın Planı:
- Çapraz bölge, çoklu düğüm, çapraz zincir stabilite değerlendirmesi ve problem çözme (Yakın zamanda tamamlanmış olan Ekonomik Sistemi içerir)
- [Yinelenen] TODO uygulanması ve sorunlardaki hataların düzeltilmesi

KAYNAK: https://medium.com/aelfblockchain/aelf-development-progress-report-july-29th-august-4th-9f1ceb6ae063
 
Katılım
21 Mar 2019
Mesajlar
503
Beğeniler
5
Puanları
18
Konum
Türkiye
Aelf Teknik Konuşmalar: AElf Konsensüs Sözleşme Standardı (ACS4)

[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/a...rd-acs4-aelf-developer-community-8824e5d24913
 
Katılım
21 Mar 2019
Mesajlar
503
Beğeniler
5
Puanları
18
Konum
Türkiye
Geliştiriciler uygulamalar oluşturmak ve Çin’in en büyük Hackathon'unda ödüller kazanmak için Aelf’i kullanıyor



17 Temmuz 2019'da ülkenin dört bir yanındaki geliştiricilerin becerilerini sergilemek üzere 3. Çin Blockchain Geliştirme Yarışması düzenlendi. Rekabetin başarısı, Sanayi ve Bilgi Teknolojileri Bakanlığı Bilgi ve Yazılım Hizmetleri Bölümü (yöneten) ve Ulusal Standardizasyon İdaresinin Endüstri Standartları Departmanı (yöneten) dâhil olmak üzere birçok tarafın verdiği güçlü destek nedeniyle azımsanmayacak derecedeydi. Çin Elektronik Teknolojisi Standardizasyon Enstitüsü, Zhejiang Eyaleti Hangzhou Şehri Xiaoshan Bölgesi, Çin Blockchain Teknoloji ve Endüstri Geliştirme Forumu, Hangzhou Günlük Gazete Grubu (Huamei Holding), Qianjiang Shijicheng Yönetim Komitesi ve Blockchain Teknoloji Uygulama Endüstrisi Birliği (Phoenix) tarafından birlikte ev sahipliği yapıldı.

Yarışmaya ülke genelinden 100'e yakın şirketten, üniversiteden ve bireysel ekipten katılım geldi. Pekin Üniversitesi, Fudan Üniversitesi Blockchain laboratuarı, Çin Gemi İnşa Endüstrisi Sistemleri Mühendisliği Araştırma Enstitüsü ve Tianjin Üniversitesi gibi önemli girişlerin kayıtları dikkate değerdi. Sunumlar; finansal hizmetler, tedarik zinciri yönetimi, kamu yararı kültürü, sosyal eğlence, eğitim ve istihdam ve akıllı üretim gibi pek çok sektör ile çeşitliydi. Bu, bu teknolojinin birçok yaygın endüstride ne kadar üretken olduğunu göstermiştir.

Bu yıl hem proje kalitesi hem de katılımcı proje sayısı açısından yaşanan rekabet, önceki yıllara göre belirgin bir artış gösterdi. Yarı finale çıkan 40 katılımcı takım arasından üç proje, Aelf Enterprise (Kurumsal) platformunu temel Blockchain sistemi olarak kullandı. Bu projeler şunlardı:

• “Çapraz Zincir Teknolojisine Dayalı Çok Platformlu İnceleme Sistemi”
• “Blockchain'e Dayalı Görev Tabanlı Platform Stratejisinin Araştırılması ve Uygulanması”

Her iki proje de Tianjin Üniversitesi'nden Ekipler tarafından sunuldu

• “BEHM: Kaynak Yakınsaması için Bir Açık Ekipman İş Birlikçi Destek Platformu”

Çin Gemi İnşa Sistem Mühendisliği Enstitüsü tarafından sunulmuştur.

Bu projeler Blockchain ile final sunumları için kendi araştırma alanlarını ve ticari kullanım durumlarını birleştirdiler ve bu da üç iyi tanımlanmış gerçek dünya uygulamasıyla sonuçlandı.

İnceleme sürecinde uzmanlar; projeleri tek tek aşağıdaki hususlara bakarak analiz etti, tartıştı ve test etti:

1. Blockchain işlevi
2. Güvenlik
3. Program yürütme
4. Ölçeklenebilirlik
5. Kod okunabilirliği
6. Teknolojik gelişme
7. Uygulama değeri
8. Tanıtım seviyesi

Aelf Enterprise Blockchain platformu üzerine inşa edilen “BEHM: Kaynak Yakınsaması için Bir Açık Ekipman İş Birlikçi Destek Platformu” projesi, Çin Gemi İnşa Endüstrisi Sistemleri Mühendisliği Araştırma Enstitüsü'nden Haizhitian ekibi tarafından sunuldu. Bu proje, üçüncülük kazanarak 40 yarı finalistten içinde dikkat çekti. Tianjin Üniversitesi'nden diğer iki proje de Mükemmellik Ödülü'nü kazandı.

Haizhitian ekibinin proje lideri olan Xingzhou Du; BEHM'yi ekipman sistemi destek / bırakma talepleri, garanti kayıt izlenebilirliği ve materyal dolaşımı ve izlenebilirliği gibi karmaşık gereksinimleri karşılamayı hedefleyen bir proje olarak tanıttı.

“Askeri-sivil entegrasyondaki bir geçmişe sahip olarak, bir kaynak koruyucu ve açıkça iş birlikçi 'ekipman desteği' tedarik zinciri yönetim platformu oluşturabileceğiz. Bu yönün Blockchain teknolojisini kullanmaya değer olduğuna inanıyorum.”

Xingzhou Du, neden temel Blockchain sistemi olarak Aelf’i seçtiklerini yanıtlarken şöyle dedi:

“Aelf yeni nesil bir kamu zinciridir ve çapraz zincir birlikte çalışabilirliği konusunda yıldız bir projedir. Temel tasarım konsepti, “paylaşma kitapları” ve “etki alanları arası konsensüs” gibi tasarım gereksinimlerimizle oldukça uyumludur. Ek olarak Aelf’in açık kaynak kodlu proje arayüzü dokümantasyonu, nispeten eksiksizdir ve geliştirici topluluğunun atmosferi ve teknik desteği son derece samimiydi. Proje hazırlığı sırasında geliştirici topluluğu, teknik sorunlara hızlı bir şekilde cevap verdi. Projemiz hâlâ araştırma aşamasında olmasına rağmen, bu ödül bize daha fazla güven veriyor, bu da bizim için iyi bir başlangıçtır.”

KAYNAK: https://medium.com/aelfblockchain/d...ards-at-chinas-largest-hackathon-af12b0fd8a41
 
Katılım
21 Mar 2019
Mesajlar
503
Beğeniler
5
Puanları
18
Konum
Türkiye
🔊 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!

 
Katılım
21 Mar 2019
Mesajlar
503
Beğeniler
5
Puanları
18
Konum
Türkiye
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/a...ss-report-august-5th-august-11th-ae7f171c9cfd
 
Katılım
21 Mar 2019
Mesajlar
503
Beğeniler
5
Puanları
18
Konum
Türkiye
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
 
Katılım
21 Mar 2019
Mesajlar
503
Beğeniler
5
Puanları
18
Konum
Türkiye
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/...ed-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/s...red-with-aelf-loses-it-s-sparkle-7fd1beca8769
 
Katılım
21 Mar 2019
Mesajlar
503
Beğeniler
5
Puanları
18
Konum
Türkiye
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.

 

En beğenilen konular

Forum istatistikleri

Konular
4,244
Mesajlar
8,417
Kullanıcılar
5,335
Son üye
Ayurmanaayurveda