Pages:
Author

Topic: AELF ($ELF) Blockchain (RESMİ ANA KONU) - ANA AĞ (MAINNET) TARİHİ: 10 ARALIK - page 19. (Read 27302 times)

member
Activity: 598
Merit: 10
Aelf Chainlink Oracle ile Entegre Olacak



10 Eylül 2019'da Aelf, karmaşık akıllı sözleşmeler için kurcalamaya karşı korumalı veriler sağlayan merkezi olmayan bir oracle ağı olan Chainlink’i entegre ediyor olacaktır. Entegrasyon, Aelf Blockchain için bir oracle oluşturmak için Chainlink teknolojisini kullanır (Bir oracle, zincir içi akıllı sözleşmeleri kendi yerel Blockchain’inin dışındaki "zincir dışı" verilerle besleyen bir araçtır). Chainlink Oracle, Aelf Blockchain'e giren ve çıkan herhangi bir verinin güvenliğini ve güvenilirliğini sağlayacaktır – Blockchain’i mevcut bir ağa uyarlanırken genellikle 'en zayıf' bağlantı olarak kabul edilen şeyi güçlendirir. Bu, yalnızca Aelf’deki akıllı sözleşmelerin dünyadaki veri kaynaklarına ve API'lere güvenli bir şekilde bağlanmasına izin vermekle kalmayacak; aynı zamanda Ethereum, Google Cloud, Zilliqa ve diğerleri gibi Chainlink ekosistemindeki diğer ağlara bağlantı da sağlayacaktır.

Chainlink, akıllı sözleşmelere dış veri sağlayabilen ilk merkezi olmayan oracle çözümüdür. Sonuç olarak akıllı sözleşmelerin güvenliği ve determinizmi, gerçek dünyadaki dış olayların bilgisi ve genişliği ile birleştirilebilir. Chainlink; marketteki, sıcaklıktaki, planlardaki/programlardaki veya diğer halka açık verilerdeki değişikliklere otomatik olarak yanıt verilmesini gerektiren gerçek hayattaki birçok uygulamalarda kritik olan herhangi bir harici API'ye erişim ile akıllı sözleşmeler sağlar.

Zincir dışı veriler, Blockchain’e yazılmadan önce manipülasyona veya hataya açık olabilir. Aelf’in işletmelere ve uygulamalarına hizmet etmeye odaklandığı göz önüne alındığında dış dünyayı Aelf Blockchain eko sistemi ile güvenli bir şekilde köprülemek ve girdi verilerinin kurcalamaya karşı korunmasını garanti etmek son derece önemlidir. Aelf için oracle inşa etmede iş birlikçi çaba, işletmelere ağımızın güvenirliği konusunda daha fazla güven aşılayacaktır.

Harici veri almaya ek olarak Chainlink oracle düğümü, Aelf verilerini diğer ekosistemler ve ağlar boyunca hem zincir içinde hem de zincir dışında diğer taraflara güvenilir bir şekilde sağlayacaktır. Aelf Kurucu Ortağı ve COO’su Zhuling Chen, yeni entegrasyonu şöyle açıkladı:

“Aelf, işletmelere kapsamlı ve gerçek dünyadan bir çözüm sunmaya devam etmekten heyecan duyuyor. Bu entegrasyon, Aelf Enterprise (Kurumsal) platformunu kullanan tüm müşterilerimize en yüksek kaliteyi, güvenliği ve güvenilirliği sağlamadaki bir sonraki adımdır.”

Chainlink Global İş Geliştirme Başkanı Daniel Kochis, “Aelf ile iş birliği yaparak Chainlink, topluluklarının akıllı sözleşmelerine ve kurumsal kullanım durumlarına zincir dışı uç noktalardan kanıtlanabilir şekilde doğru verileri sağlamak için heyecan duyuyor.” ifadelerini kullandı.

Aelf hakkında:

Aelf, iş dünyasında Blockchain öncülüğünü yapan çok zincirli bir ağ ve akıllı sözleşme platformudur. Aelf’in blok zinciri; kendi uygulamalarını oluşturma zorunluluğu olmadan işletmelere uygulamalarını halka açık zincir alanında veya kendi özel zincirlerinde çalıştırmalarını sağlayacaktır. Aelf ekosisteminde her bir uygulamanın yüksek performansı güvence altına almak için kendi kaynakları olacaktır. Aelf’in tokeni (ELF), yakın zamanda Huobi’nin HB10 fonu tarafından köklü platformuna dayanarak en güvenilir 10 yatırımdan biri olarak seçildi. Aelf, ilk test ağı sonuçlarını yaklaşık 15000 saniye başına işlem (TPS) olarak duyurmuştu.

Chainlink hakkında:

Chainlink; akıllı sözleşmelerin zincir dışı veri yayınlarına, web API'lerine ve geleneksel banka ödemelerine güvenli bir şekilde erişmesini sağlayan merkezi olmayan bir oracle ağıdır. Chainlink, Gartner gibi önde gelen bağımsız araştırma firmaları tarafından sürekli olarak en iyi Blockchain teknolojilerinden biri olarak seçilmektedir. Büyük işletmelere (Google, Oracle ve SWIFT) ve önde gelen akıllı sözleşme geliştirme ekiplerine yüksek güvenlikli ve güvenilir Oracle’lar sağladığı çok iyi bir şekilde bilinmektedir.

KAYNAK: https://medium.com/aelfblockchain/chainlink-network-to-connect-with-aelf-in-new-partnership-77533e18206c


member
Activity: 598
Merit: 10
Merkle Ağacı (Merkle Tree) - Bu nedir ve neden kullanılır?



Kripto para ve Blockchain teknolojisine yatırım yapmak bir şeydir, ancak Blockchain'in nasıl çalıştığını tam olarak anlamak bir başka şeydir. Aelf ekosistemi de dahil olmak üzere birçok Blockchain’de ağa dahil edilen teknolojinin bir eseri Merkle Ağacı'dır. Bu ağın birçok parçası olmasına rağmen Merkle Ağacı, doğrulama sürecinde verimliliği ve güvenilirliği nasıl sağlamayı planladığımızı belirlerken anlaşılması gereken önemli bir unsurdur.

Merkle Ağacı yeni bir şaşırtıcı keşif değildir, sadece Blockchain içinde değil güvencesiz veya P2P ortamında kullanılan oldukça yaygın bir şekilde kullanılan test edilmiş ve gerçek bir sistemdir. Aslında bu konsept, 1979'a ve Blockchain’in bir fikir olmasından önceye dayanıyor. Bilgisayar bilimcisi Ralph Merkle'den sonra adlandırılmıştır.

Basit bir ifadeyle bir Merkle Ağacı; çok fazla veri alır, bu verilerin ne olduğunu açığa çıkarmadan içinde tutulan verinin gerçekliğini/doğruluğunu kanıtlayabilen basit bir karakter dizisine sıkıştırır. Sıkıştırılmış bir dosyaya (.ZIP veya .RAR) benzer şekilde eğer belirli bir standarda göre doğru bir şekilde adlandırılırsa, kullanıcı sıkıştırmayı çıkartmadan ve açmadan içerdiği dosyaları tanıyabilir. Bu karakter dizisine (başlık) bir karma (hash) adı verilir. Karma; tek yönlü bir işlevdir, yani aynı verileri koyarsanız her zaman aynı karmayı alırsınız, ancak bu karmayı alamazsınız ve orijinal verileri çıkaramazsınız.



“Ağaç” kavramı, bilim genelinde yaygın bir fikirdir ve birbirinden dallanan ebeveynleri (parent) ve çocukları (children) içeren bir yapıya atıfta bulunur. Bu durumda, tüm yapraklar (İşlemler / bloklar) ile başlamanız ve bir ebeveyn karma (Merkle Root) için geri dönmeniz anlamında baş aşağı bir ağaçtır. Şekil 1.1'de görüldüğü gibi, Merkle Ağacına dahil edilmeden önce iki kez karmalanan işlemlerle başlıyoruz. 1-100 blok L1’e, 101–200 blok L2’ye, 201–300 blok L3’e, 301-400 blok L4’e karmalar gibi işlemlere sahip olabiliriz. Bunlar daha sonra ağacın alt dalına karmalanır. Örneğin, L1 bloğu karma 0-0’a karmalanmıştır.

Bu şema, ikili ağaç dediğimiz şeyi göstermektedir. Bu, her bir ebeveynin maksimum iki çocuk dalına sahip olabileceği anlamına gelir. Teknik olarak bunu artırabilirsiniz ama ikili ağaçlar en yaygın olanıdır. Karma 0-0 ve 0–1’e sahip olduktan sonra bu, ‘ebeveyn’ karmasına karmalanır (Hash 0). Buna Merkle Root (Kök) denilen en üst karmaya gelinceye kadar devam edilir.

Bu sürecin güvenlik, hız ve verimlilik dahil olmak üzere birçok avantajı vardır. Verileri yoğunlaştırmak için bu işlemi kullanarak, her karmayı Merkle Ağaç Kökü ile eşleştirerek herhangi bir gerçek veriyi açığa çıkarmadan çok hızlı bir şekilde doğrulanabilir. Blockchain’in merkezsizleşmiş yönü ile bağlantılı olarak oluşturulan Merkle ağacının karmaşıklığından dolayı bu karmalar içinde bulunan verilerin değiştirilmesini çok zorlaştırır.

Bir ağın hızı bu teknoloji kullanılarak kolayca artırılabilir. Doğrulanacak ve daha sonra geri gönderilecek dosyaları ağ üzerinden göndermek yerine bir bilgisayarın yalnızca çok hızlı bir şekilde doğrulanabilecek karmayı (bunun yalnızca bir karakter dizisi olduğunu unutmayın) göndermesi gerekir. Bir tutarsızlık varsa o zaman alt ağaçların karmaları, kusurlu blok bulunana ve gerektiği gibi değiştirilinceye kadar talep edilir. Bu, bir hata için bütün dosyayı aramaktan çok daha hızlıdır. Tabii ki, bu aynı zamanda kaynakların daha verimli kullanımıdır.

Aelf Merkle Ağacını nasıl kullanır?

Geleneksel anlamda değildir. Normalde Merkle Ağacı bir Blockchain içerisinde kullanılacaktır. Aelf, tüm yan zincirler arasındaki birlikte çalışabilirliği kontrol etmek için Merkle Ağacı'nı kullanıyor olacaktır. Her bir yan zincir, kendi Ağacını yaratacak ve Ana Zincir içinde yer alması için Merkle Köküne sunacaktır. Yan Zincir A Yan Zincir B'den gelen bazı verileri doğrulamak isterse, Yan Zincir A Ana Zincire yaklaşacak ve verileri doğrulamak için orada saklanan Merkle Kökü ile karşılaştırmasını isteyecektir. Ana Zinciri neredeyse her bir Yan Zincirin veri doğrulama için kullanacağı bir arşive ilişkilendirebilirsiniz. Bu konsept, oldukça eşsizdir ve doğrulama sürecini büyük ölçüde geliştirecektir. Çapraz zincir birlikte çalışabilirlik için bir ortam yaratmada etkili bir süreçtir. Özel ve halka açık zincirlerin birbirleriyle konuşmasını ve herhangi bir gizlilik sorunu olmadan verileri doğrulamasını sağlar.

Bu Merkle Ağacı, Aelf tarafından Yan Zincirleri ayırmak için kullanılan Yan Zincir “Ağacı (Tree)” ile aynı değildir. Merkle Ağacı, ana zincir ve diğer yan zincirler ile verileri depolamak ve doğrulamak için kullanılır. Bir Yan Zincir Ağacı, her bir zincirin (dalın) belirli bir kullanım durumu gerçekleştirdiği kendi ağaç benzeri yapısını oluşturan birçok alt zincirlerden oluşabilir. Bu zincirlerden biri yönetmek için aşırı büyük olduğunda, birden fazla zincire bölünebilir.

Merkle ağacı, Aelf ekosisteminin sadece benzersiz değil aynı zamanda bir Blockchain ağının fonksiyon biçiminde devrim yaratan bir başka özelliğidir.

KAYNAK: https://medium.com/aelfblockchain/merkle-tree-what-is-it-and-why-use-it-f823f5b57179
member
Activity: 598
Merit: 10
member
Activity: 598
Merit: 10
Aelf ortaklıklarının özeti - Kim, Ne ve Neden



Ağustos 2018'de Aelf, Testnet sonuçlarını yaklaşık 15000 TPS (saniye başına işlem) olarak gururla duyurmuştu. O zamandan bu yana ağı 10 ay sonrasına kadar iyileştirmeye devam ettik ve Aelf Kurumsal (Enterprise) Beta Platformu piyasaya sürüldü. Bu süre zarfında Aelf; Blockchain ekosistemimizde geliştirilen yenilikçi teknoloji için birçok ödül ve küresel sertifikasyonlar aldı ve ortaklıklar kurdu. Bu makale, bu iş birliğinin nasıl gelişeceğine dair basit bir açıklama ile birlikte her ortaklığın bir özetini sunacaktır.

Partnerlikler

Amaten (Ağu 2019) - Amaten Japonya'daki en büyük hediye kartı borsasıdır. Yıllık 110 milyon ABD Doları gelir elde eden Amaten; Amazon, Apple, Google, Rakuten, Netflix, Nintendo, Playstation ve Spotify gibi 25'ten fazla şirketten hediye kartı sunuyor.
Bu ortaklık, aelf Enterprise platformunda inşa ederek hediye kartı endüstrisinin dijital varlıklara dönüşümünü gösterecektir. Bu, Amaten'in uluslararası bir şirket olarak gelişmesini ve 340 milyar dolarlık uluslararası piyasaya girmesini sağlayacaktır. Bu yeni gelişme; hediye kartlarının düzenlenme, satın alınma ve değiş tokuş şeklini değiştirecektir.

Poseidon Network (Mayıs 2019) - Poseidon Network, ağ içeriğinin bant genişliğini dağıtılmış düğümler ve dijital kimlik bilgileri aracılığıyla optimize eden bir karma Blockchain uygulama platformudur. Token ödülleri biçiminde, kullanıcıların kendi bant genişliğine katkıda bulunmaları teşvik edilir; böylece ağdaki her terminal cihazı bir önbellek düğümü ve bant genişliği, depolama ve bilgi işlem gücü gibi kaynakları paylaşabilen bir PaaS platformu haline gelir.
Bu ortaklık, Poseidon'un Akıllı Sözleşmelerini Aelf Kurumsal Platformunda dağıttığını gösterecektir. Aelf ve Poseidon; gelecek nesil içerik dağıtımının dünya lideri olmaya hazır, istikrarlı ve verimli bir altyapı birlikte oluşturacaktır. Poseidon'un CEO'su Light Lin; Aelf’i seçmelerinde temel nedenlerin, Poseidon’un başarısında kritik olan paralel işleme ve kaynak ayrımı özelliklerinin yanı sıra Aelf’in merkezsizleşmiş ve şeffaf özellikleri olduğunu açıkladı.

VCC Borsası (Mayıs 2019) - VCC, Vietnam'ın ilk devlet dostu dijital varlık alım satım platformudur. Bittrex ve Signum Capital tarafından desteklenen borsa, 7/24 müşteri desteği ile hem mobil uygulama hem de web sitesi aracılığıyla Vietnam pazarına destek verecektir.
Bu ortaklık Aelf'in yerel etkinlikler ve hükümet yetkilileri gibi etkili insanlarla olan ağlarla iş birliği yaparak Vietnam'daki varlığımızı arttırmasını sağlıyor. VCC'nin varlığı aracılığıyla Aelf, yerel geliştirici topluluğunun büyümesine yardımcı olacak ve Vietnam'ı Blockchain’in benimsenmesi ve gelişimi için bir merkez haline getirmeye yardımcı olacak.

Stratejik İş Birlikleri

Orange Telco (Temmuz 2019) -
Orange, 2018'de yıllık 45 Milyar Dolar'ın üzerinde geliri olan Avrupa'nın en büyük telekom operatörlerinden biridir. Şirket, dünya çapında 256 milyon müşteriye destek vermek için 150.000'den fazla kişiyi istihdam etmektedir.
Orange, ticari bir atılım bulmak için yeni çıkan teknolojileri araştırıyor. Birden fazla toplantıda Orange, Aelf teknolojisinin finans, e-ticaret, ödeme ve diğer sektörlerde uygulanabileceğine inanıyor. Ayrıca, Aelf’in çapraz zincir teknolojisinin, Pekin ofisinde toplantıları takip etmek için temel etken olduğunu açıkladılar. Gelecekte, her iki taraf da kendi alanlarındaki gelişmeleri aktif bir şekilde paylaşmak ve birlikte inovasyonda daha fazla ilerlemek için birlikte çalışmayı amaçlamaktadır.

Decentraland (Aralık 2018) - Decentraland, Ethereum ağı üzerine kurulu bir sanal gerçeklik platformudur. Platform, kullanıcıların ARSA (LAND) denilen sınırlı bir sanal arazi parsel arzı aracılığıyla temsil edilen kendi dijital alan ve varlıklarını tam mülkiyetle kazanmalarını sağlamak için Blockchain teknolojisi ve akıllı sözleşmeler kullanır.
Bu stratejik iş birliğinde Aelf topluluğu, ELF tokenlerini para birimi olarak kullanarak yeni ARSA için Aralık ayı açık arttırmasına katılabildi.

Destek

Amazon Web Servisleri (AWS) (Mayıs 2019) -
AWS, on binlerce küresel ortak ve milyonlarca aktif müşteriyle dünyanın en büyük bulut bilişim platformu sağlayıcısıdır.
AWS, kullanıcıların görüntülerini dağıtmalarına ve birkaç basit komutla Aelf tabanlı sistemler başlatmalarına olanak sağlayan Amazon Machine Image (AMI) aracılığıyla bir BaaS sağlayıcısı olarak Aelf’i listeledi. Bu listelenme aracılığıyla Aelf; artık Netflix, NASA, AirBnB, Time Inc, Lionsgate ve Dow Jones gibi şirketlere görünürdür. Aelf, AWS'de çapraz zincir özelliği ile listelenen ilk Blockchain platformudur.

Microsoft Azure (Temmuz 2019) - Microsoft Azure, diğer tüm bulut sağlayıcılara kıyasla daha fazla bölgeye sahip dünyanın önde gelen bulut bilişim platformu sağlayıcılarından biridir. Microsoft Azure'un geliri, büyüme açısından Microsoft tarafından önde gelen ürün olarak yılda %76 oranında büyüdü.
Microsoft Azure, Aelf’i bir BaaS sağlayıcısı olarak listeledi ve Aelf platformunun görünürlüğünü binlerce ticari müşteriye getirdi. Şimdi Aelf’i görecek isimlerden bazıları NBA, UPS, FedEx, BMW, Walmart, Coca-Cola, Toyota, Fujitsu, RioTinto, Samsung ve Toshiba'dır. Kullanıcılar artık Aelf Blockchain’de Azure aracılığıyla kolay ve verimli bir şekilde dağıtabilirler.

Potansiyel Gelecek İş Birlikleri

Gelecekte açıklayacağımız iş birlikleri ve ortaklıklar olacak. Bu makaleyi periyodik olarak güncelleyeceğiz.

Önceki Ortaklıklar

• İnovasyon/Yenilik İttifakı: İnovasyon ittifakı, Start-Up’lardan büyük şirketlere kuruluşlar için Blockchain benimseme yolunu hızlı bir şekilde izlemeye yardımcı olabilecek büyük uluslararası Blockchain oyuncular koalisyonu yaratıyor. Bu ortaklar; Blockchain teknolojisinin keşfedilmesi ve benimsenmesi ile ilgilenen tüm işletmelere danışmanlık desteği, değerli kaynaklar, endüstri anlayışı ve deneyimi sağlayacaktır. Bu ittifak, oyun dünyasından kurumsal finans endüstrisine kadar tüm endüstriler için geçerli olacaktır. Diğer örnekler ise tedarik zinciri ve sigortadır.

• Decent: Aelf ve Decent; gelecekte yeşil içerik alanlarının kontrol edilebilirlik, esneklik ve verimlilik göz önünde bulundurularak inşa edilmesi için anlaştı.

• Youlive: Youlive, merkezi olmayan bir gerçek zamanlı içerik paylaşım platformudur. Ekip; yüksek kullanılabilirlik, ölçeklenebilirlik, yüksek eşzamanlılık ve düşük gecikme süresi elde etmek için gelişimini Aelf teknolojisine dayandırmayı planlıyor.

• Theta: Aelf, Theta’nın özel satış öncesi destekçilerinden biridir ve uzun vadeli stratejik ortağıdır. Aelf, Theta Labs'in E-spor ve medya endüstrisinde oluşturduğu ekosistem ve teknoloji liderliği için Blockchain’de merkezsizleşmiş video medyasının bir yeni çığırını oluşturmak için Theta ile ortaklık kurmaya karar verdi. Aelf, Theta'yı yalnızca ortaklık şeklinde desteklemekle kalmayacak, aynı zamanda Theta ile uzun vadeli bir teknoloji ve pazarlama iş birliğini başlatacaktır.

• U Network: U Network, dünyadaki ilk içerik değeri tahmin platformudur. Düşünmeler ve güçlü iş mantığı ve endüstri dağılımının kabul edilmesinden sonra Aelf, U Network ile birlikte çalışmaya karar verdi. Aelf ve U Network, yeni nesil içerik değeri tahmin platformu oluşturma, Blockchain teknolojisi üzerine inşa etme ve küresel içerik yaratıcılarını, değer kâşiflerini ve topluluk tanıklarını cezbetme hedefi için birlikte çalışacaktır. Aelf ve U Network arasındaki ortaklık, Aelf Blockchain teknolojisinin İçerik Değeri Tahmin Endüstrisi’nde ticarileşmesini gerçekleştirecek ve Aelf’in endüstriyel ekosistem ile gelecek nesil blockchain ağını oluşturma hedeflerinde atılan bir adım olacaktır. Gelecekte Aelf, hizmet kapasitelerini geliştirmek için çeşitli işletmelerle iş birliğine devam edecektir. Böylelikle Aelf, ayrıca Blockchain endüstrisi için teknolojinin uygulanması konusunda değerli deneyimler ve araştırmalar sağlayacaktır.

• DATx: DATx, Cosimo Vakfı tarafından başlatılan ve reklam verenlerin parçalanmış kullanıcı davranışsal veri dağınıklığını ortadan kaldırmasına yardımcı olan ve önde gelen bir küresel reklamcılık platformu olan Avazu ile iş birliği aracılığıyla kullanıcıları doğru bir şekilde hedefleyen bir Blockchain’dir. Bu, şirketlerin hem kurumlara hem de tüketicilere yarar sağlayan, anlamlı ve etkili reklamlar sunmalarına daha kolay olanak sağlayacaktır.

• Content Neutrality Network (CNN): CNN, Blockchain’in konsensüs mekanizmaları ve akıllı sözleşmeler gibi gelişmiş özellikleri aracılığıyla mevcut içerik sistemlerinde var olan çeşitli sorunları çözen Blockchain teknolojisine dayanan bir yenilikçi içerik ekosistemidir. CNN ve Aelf birlikte; gelecekte daha açık, verimli ve güvenilir bir içerik çağı oluşturmayı hedefliyor.

• Oracle Chain: Dünyanın bir EOS ekosferinde kurulu ilk uygulaması olan OracleChain, Blockchain teknoloji hizmetlerini çeşitli gerçek hayat senaryoları ile verimli bir şekilde birleştirerek Oracle (oracle machine) ekosisteminin taleplerini karşılamalı ve böylece bu muazzam onlarca milyar dolar değerinde piyasanın derinliklerine inmek gerekir.  EOS platformuna dayanan merkezi olmayan bir Oracle teknoloji platformu olarak, otonom PoR (Proof-of-Reputation) & Deposit mekanizması benimsendi ve diğer Blockchain uygulamaları için temel bir hizmet olarak kullanıldı.

• Cortex:
Cortex'te açık kaynaklı ve rekabetçi mekanizmaların doğası gereği akıllı bir etken olarak en iyi model, Blockchain ağının zekâ seviyesini artırmak için hayatta kalacaktır. Aelf, daha iyi bir kullanıcı tanıtımı elde etmek için Cortex ile stratejik iş birliğine ulaştı. Cortex'in ana misyonu, kullanıcıların Cortex Blockchain'deki akıllı sözleşmeleri kullanarak çıkarabilecekleri Blockchain’de state-of-the-art machine-learning modellerini sağlamaktır. Cortex’in hedeflerinden biri, kullanıcıların platformda görevlerini yayınlamalarına olanak sağlayan bir makine öğrenme platformunun uygulanmasını da içerir: AI DApps (Yapay Zekâ Merkezi Olmayan Uygulamalar). Bunun da ötesinde Cortex projesi, teşvikler ve toplu/ortak iş birliği için mekanizmalar önermektedir. Herkes zincirdeki modeli sunup optimize edebilir ve ödüllendirilebilir. Bu, kullanım için daha fazla AI model geliştirme ekibini veya insanını cezbedecektir. Aelf, daha iyi bir kullanıcı tanıtımı elde etmek için Cortex ile stratejik iş birliğine ulaştı.

• FairGame: Fair.Game, Blockchain teknolojisine dayalı dünyanın ilk adil oyun platformudur ve resmi zincirde çalışan bir Blockchain oyununu başlatarak dünyada ilkler arasında yer aldı. Fair.Game, gelecekte çeşitli Blockchain oyunlarını başlatacaktır. Fair.Game, dünya çapındaki yüzlerce çevrimiçi oyuncuya Blockchain yetenekleri sunmak için oyun pazarını genişletmek üzere global premium oyun sağlayıcılarının Blockchain yeteneklerini entegre etmesine yardımcı olacak doğrulanmış bir SDK aracı piyasaya sürecektir. Aelf, Fair.Game ile bir ortaklık imzaladı ve özel ELF Şehri (ELF City) açıldı.

• Republic Co: Republic, yenilikçi Start-up’lara ve ICO'lara herkesin 10$ kadar az yatırım yapabileceği bir yatırım platformudur. Republic, akredite yatırımcılar için dünyanın en büyük çevrimiçi yatırım platformu olan AngelList'in mezunları tarafından kurulmuştur. AngelList, öz kaynak kitle fonlaması sağlayan JOBS Yasasını geçmekte etkili oldu.

• Celer Network: Celer Network, İnternet ölçeğini zincir dışı ölçeklendirme teknikleri ile mevcut ve gelecekteki Blockchain’lere getiren tutarlı bir teknoloji ve ekonomik mimaridir. Saniyede milyarlarca güvensiz, güvenli ve özel zincir dışı işlem gerçekleştirebilir. Celer Network, Blockchain'in gücünü tamamen ortaya çıkarmak ve merkezsizleşmiş uygulamaların inşa edilmesinde ve kullanılmasında görev yapmaktadır.

• CertiK: CertiK, akıllı sözleşmelerin ve Blockchain ekosistemlerinin hatasız ve hacker/bilgisayar korsanlarına karşı dayanıklı olduğunu matematiksel olarak kanıtlamak için bir resmi doğrulama yapısıdır. Doğrulamayı ölçeklendirmek için CertiK, bu tür başka türlü yasaklayıcı bir ispat görevini küçük olanlara ayırmak için katman tabanlı bir yaklaşım geliştirdi. Bu küçük kanıtlama yükümlülükleri CertiK işlemlerinde kodlanabilir ve daha sonra katılımcılar tarafından merkezsizleşmiş bir tarzda kanıtlanıp onaylanacaktır. CertiK ledgerleri, doğrulanmış akıllı sözleşmelerin ve doğrulanmış Blockchain ekosistemlerinin baştan sona doğruluğunu ve güvenliğini sergilemek için sertifikalar olarak çalışır ve bunları tamamen güvenilir kılar.

• CGS:
Connect Global Strategies, Dubai merkezli bir kripto ve yatırım danışmanlığı ve iş geliştirme acentasıdır; ana işletmelere ve finansal aktörlere Blockchain ve kripto para birimi sektörüne başarılı bir şekilde girmek ve bu alanda gelişmek için gerekli bilgileri sağlar. Gelişmekte olan kripto para pazarındaki yatırım fırsatlarını ultra yüksek net değerli bireylere ve işletmelere tanımlayan stratejik danışmanlık hizmetleri ve yardımı sunan Connect Global Strategies, Dubai'de ve daha geniş Ortadoğu ekonomisinde Blockchain yeniliğinin ve benimsenmesinin bir etmenidir.

• Cred: Aelf, dünyanın önde gelen şifreleme kredisi sağlayıcısı olan Cred (eski adıyla Libra Credit) ile stratejik bir ortaklığa ulaştı. İki taraf, Blockchain endüstrisindeki finansal hizmetler ve kriz yönetimi bilgisi hakkında fikir alışverişinde bulundu. Ayrıca Cred, resmen ilk fon yönetimi servis sağlayıcısı olarak Aelf İnovasyon İttifakına katılacaktır. Cred, ittifaktaki üye şirketlere esnek kredi ve kredi ürünleri sağlayacaktır.

• HyperExchange: Aelf, merkezi olmayan çift zincirli ekosistem HyperExchange ile stratejik bir ortaklık kurdu. HyperExchange’in HX zinciri, resmi olarak ELF pledge madenciliğini destekleyecektir.


KAYNAK:
https://medium.com/aelfblockchain/summary-of-aelf-partnerships-who-what-and-why-e0f5c540f333

member
Activity: 598
Merit: 10
Aelf Teknik Konuşmalar: Aelf’in Akıllı Sözleşmeler Tarafından Yönetilen Teşvik Programları

Bölüm 5




AElf Blockchain teşvik sözleşmesi (Kâr Sözleşmesi) arayüzü ve uygulama fikirleri

Teşvik Programına Genel Bakış

Ekonomik modeli başarılı bir şekilde uygulayabilmek için, teşvik ve ödül dağıtımını yönetmek için özel olarak tasarlanmış bir akıllı sözleşmeye ihtiyacımız vardır.

Teşvik (temettü paylaşma) programı esasen bir token dağıtım merkezi olarak işlev görür. Her bir teşvik programının oluşturucuları, programda katılımcıların adreslerini veya programa katılmakla ilgili diğer bilgileri kaydeder ve her alıcı için ağırlığı belirler. Her ödeme süresi boyunca program, teşvikleri (tokenleri) her kayıtlı katılımcının adresinin (ayrı bir hesap adresi veya teşvik programındaki sanal bir adres) belirtilen ağırlıklara göre dağıtacaktır. Dağıtılacak tokenlerin tümü ya ELF'e dönüştürülür ya da doğrudan her alıcının adresine aktarılır. Her bir teşvik raundu tamamlandıktan sonra, raunt sayısı bir artırılır.

Tanımlar:

Bir Teşvik Programı - Teşvik Akıllı Sözleşmesi tarafından oluşturulan bir Blockchain’in token dağıtım merkezi.

Teşvik Programları Oluşturucuları - Teşvikler almak için katılımcının adresini kaydetme yetkisine sahiptir.

Katılımcının Adresi - Aelf ekosisteminde teşvik tokenleri alabilen bir hesap adresi.

Not: Katılımcıların adreslerini program ile kaydetmeleri gerekmektedir, çünkü teşvik serbest bırakıldığında adresler otomatik olarak hesaplarına kaydedilmeyecektir (bkz. “kâr”).

Teşvik Programının Sanal Adresi - Her bir teşvik programı, yalnızca programın oluşturucusunun ilgili kâr kimliği (profit ID) aracılığıyla çalıştırabileceği sanal bir adres belirler. Bu adres yalnızca teşvikleri serbest bırakmak için kullanılır ve buna karşılık gelen halka açık/kamu-özel anahtar çifti yoktur (çatışma adreslerinin olasılığı ihmal edilebilir).

Alt Kâr Maddesi (Sub-Profit Item) - Her teşvik programı, başka bir programda bir alt teşvik programı olarak tasarlanabilir. Alt teşvik programları, diğer teşvik programları tarafından ağırlık tahsis edilebilir; diğer teşvik programları teşviklerini serbest bıraktıklarında, alt teşvik programının sanal adresi için bir token oluştururlar.

Teşvikleri Elde Etmek - Teşvik almaya hak kazanan bir katılımcının beklenen ödüllerini almak için bir işlem göndermeleri gerekmektedir. Bu, çok fazla kayıtlı alıcı adresinden kaçınmak ve teşvik işlem yürütme zaman aşımını serbest bırakmak içindir.

Ağırlık - Ağırlıklar, her katılımcının adresinin alması gereken teşviklerin yüzdesini yönetmek ve daha fazla esneklik sağlamak için kullanılır (yani katılımcı ağırlığı/tüm katılımcıların toplam ağırlığı). Gerektiğinde, belirli teşvik programlarının toplam ağırlığının sınırları belirlenecek ve ağırlığın bir sabit (alt) teşvik programına tahsis edilmesi sağlanacaktır. Bu, programların hem sabit hem de değişken teşvik yapılarından oluşmasını sağlar. Ana teşvik programı teşvikleri serbest bıraktığı sürece sabit alt teşvik programları, teşviklerin belli bir oranını alabilir. Örneğin; DApp geliştiricileri tarafından dağıtılan sözleşmeler, teşvikin belirli bir yüzdesini Hazine'ye katkıda bulunmayı seçebilir.

Teşviklerin Serbest Bırakılması - Bir teşvik programının sanal adresindeki bir bakiyenin ELF'e dönüştürülmesi işlemi, bir Bancor sözleşmesi yoluyla gerçekleşecek ve aktarıcı/gönderen teşvik adresini alacaktır.

Raunt Periyodu - Raunt periyodunun uzunluğu, her bir teşvik maddesi tarafından kontrol edilir. Teşvikin serbest bırakılmasından sonra, raunt periyodu 1 artar.

Hazine - Bu, Aelf ekosistemindeki en büyük teşvik programı olabilir. Blok üretim teşviklerinin, sözleşme işlem ücreti teşviklerinin ve sözleşme kâr teşviklerinin bir alt programı olarak kullanılabilir. Ayrıca; sanal adresinin bakiyesini önceki raundun blok üreticisine, doğrulama düğümlerine ve Aelf düğüm seçimine katılan seçmenlere dağıtmak için genel bir teşvik programı olarak da kullanılabilir.

Arayüz

Bir Teşvik Programının Oluşturulması:




Bir teşvik programı oluştururken bir katılımcının adresinin teşviki alması için zaman aşımını ve State DB'nin depolama yükünü azaltmak için ilgili teşvik bilgisini silen süre sonunu belirleyebilirsiniz.

Ek olarak teşvik program oluşturucusu teşvikleri serbest bıraktığında, mevcut rauntta teşviklerin ne kadarlık kısmının serbest bırakılacağını belirleyebilirler. Eğer oluşturucu her bir rauntta teşvik programının sanal adresi üzerindeki mevcut bakiyenin tamamını serbest bırakmak istiyorsa, is_release_all_balance_everytime_by_default değerini true olarak ayarlayabilir. Teşvikler dağıtıldığında, serbest bırakma miktarı 0 olarak ayarlanır.

Alt teşvik programlarının kaydedilmesi:



RegisterSubProfitItem, alt teşvik programları eklemek ve karşılık gelen ağırlıkları tahsis etmek için kullanılır.

Ağırlık yönetimi:



Aşırı/Fazla işlemlerden kaçınmak için yığın yönetimi ağırlık arayüzleri sağlanmalıdır.

Teşviklerin eklenmesi:



Herhangi bir para birimi, belirli bir teşvik programına belirli miktarda token eklemek için kullanılabilir. Periyod 0 (boş) olduğunda token, teşvik programının sanal adresine (büyük defter adı verilebilir) eklenir. 0'dan büyük bir periyod belirtildiğinde bu token, belirtilen hesap için hesabın sanal adresine eklenir.

Teşviklerin Serbest Bırakılması:



Periyod, teşviklerin serbest bırakılması için belirlenen raunttur; serbest bırakma, daha erken bir rauntta gerçekleşemez. Teşvik programının oluşturucusunun teşvikin iki kere serbest bırakılması ile sonuçlanan iki aynı işlemi göndermesini engellemek için sözleşme denetimi için serbest bırakma periyodunun dâhil edilmesi gerekmektedir. Miktar 0 olarak ayarlandığında ve teşvik programı is_release_all_balance_everytime_by_default tarafından true olarak oluşturulduğunda, teşvik programının sanal adresindeki tüm bakiyeler bu anda serbest bırakılacaktır. Buradaki total_weight (toplam_ağırlık), teşvik programındaki daha sonraki rauntlar için hazırlanır; çünkü daha sonra serbest bırakılan teşviklerin mevcut toplam ağırlığı, bu raunt toplam ağırlığını kullanamaz. Toplam ağırlık sadece önceki bir raundun toplam ağırlığına ayarlanabilir. Örneğin; 6. rauntta program, 5. raunttaki teşvik katılımcı listesinde kayıtlı adresler için teşvikleri serbest bırakacaktır. Bu nedenle 5. raundun toplam ağırlığı, 6. raunt için ReleaseProfitInput parametresine geçirilmelidir.

Teşviklerin alınması:



Bir katılımcının teşvikini alabilmesi için, teşvik maddelerinin benzersiz kimliğini/tanımasını sağlaması ve hak ettiği tüm teşvikleri toplaması gerekir.

KAYNAK: https://medium.com/aelfblockchain/aelf-tech-talks-aelfs-incentive-programs-managed-by-smart-contracts-aaf420240a43





member
Activity: 598
Merit: 10
Aelf Enterprise (Kurumsal) Revize Edildi: Aelf Enterprise 0.8.0 Alfa (Alpha) Resmi Olarak Yayınlandı



Aelf Enterprise 0.8.0 Alpha; tam bir Blockchain sistemi, geliştirme kitleri, geliştirme belgeleri/dokümantasyonları, destekleyici altyapı ve hizmetleri içeren kapsamlı bir Blockchain çözümüdür.

Aelf Enterprise 0.8.0 Alpha Sürümü Sistem İçeriği

1.Aelf Enterprise

• aelf V0.8.0 alpha
• DevKit V0.8.0 alpha (geliştirme kitleri)

2.Aelf Harici Uygulamalar
• aelf Blockchain Tarayıcı V0.8.0 alpha
• aelf Tarayıcı Mysql eklentisi V0.8.0 alpha
• aelf Kâşifi V0.8.0 alpha
• aelf Cüzdan V0.8.0 alpha
• aelf JS SDK V3.2.13
• Nodejs V0.1.7’de aelf CLI

3. Aelf Tarayıcı Uzantısı V0.8.0 alpha
Yeni sürüm Aelf Enterprise 0.8.0 sürümü, aşağıdaki özellikler dâhil olmak üzere Aelf Enterprise 0.7.0 beta sürümündeki önemli özellikleri günceller:

• Geliştirilmiş Blockchain sistem stabilitesi
• Daha hızlı ve daha verimli işlem yürütme
• Tamamlanmış ve eksiksiz akıllı sözleşme sistemi


Aelf Enterprise 0.8.0 alpha sürümü aşağıdaki yeni özellikleri ve optimizasyonları içerir:
1. Yeni İşlevler/Fonksiyonlar


Yerli makine paralel işleme fonksiyonu:
• Paralel olarak işlemlerin yürütülmesi

Sözleşme güvenlik kontrol fonksiyonu:
• Güvenli olmayan bağımlılıklar kullanılıyorsa, sözleşmenin güvenliğinin öncelikle kontrol edilmesi

Basit ağ keşfi:
• A düğümü B düğümüne bağlandıktan sonra A ve B düğümü, senkronizasyon düğümü verilerini değişir

Sözleşme dağıtım İzin mekanizması:
• Sistem, sözleşme dağıtımının izinlerini kısıtlayabilir

GetMerklePath arayüzü eklendi
Rastgele (Random) sayı standardı

2. Optimizasyon

Optimize edilmiş çapraz zincir senkronizasyonu:
• Çapraz zincir iletişiminin stabilitesini ve çapraz zincir kullanılabilirliğini sağlamak
• Çapraz zincir modülleri için optimize edilmiş kod

Optimize edilmiş ağ aktarımı:
• Temel olarak optimize edilmiş stabilite sorunları ve çatallanma olasılığınının azaltılması ile ilgilidir

Optimize edilmiş konsensüs:
• Üreten blok ritminin ayarlanması, böylece çatallaşma olasılığı düşürülür
• Konsensüsün rastgele sayı standardında uygulanan optimize
• LIB'i iki kez doğrulamak için optimize edilmiş konsensüs algoritması

Sözleşmeler arası çağrı optimizasyonu:
• Proje uygulanmasının optimize edilmesi, sözleşmeler arası çağrı uygulama zorluğunu azaltmak, sistem bakımını kolaylaştırmak ve geliştiricilerin başlama zorluğunu azaltmak

Optimize edilmiş Keystore ve komut satırı araçları

Dağıtım sözleşmesi sırasında oluşabilecek durum tutarsızlığı düzeltildi


İstikrarı etkileyen diğer sorunlar düzeltildi:
• CPU kullanımı gibi aşırı kaynakların işgali
• Doğrulama hatasından kaynaklanan hatalar
• Diğer hatalar

Bölünmüş zincir tarama ve depolama prosedürleri

Nodejs aracılığıyla uygulanan CLI araçları

Entegrasyon özelliklerine giriş

1. Aelf enterprise

aelf V0.8.0 alpha https://github.com/AElfProject/AElf

• Yüksek Performanslı Akıllı Sözleşme Çalışma Zamanı
• Konsensüs Sistemi
• Çoklu Token Sistemi
• Oylama sistemi
• Çapraz Zincir Sistemi
• Web API

DevKit (geliştirme kitleri)

• Boilerplate
https://github.com/AElfProject/aelf-boilerplate

1.TestKit
2.BenchmarkKit
3.IDE entegrasyonu

• Belgeler https://docs.aelf.io/
• Öğreticiler https://docs.aelf.io/main/main
• Videolar

1.1 aelf 0.8.0 Alpha



aelf Enterprise 0.8.0 alpha; minimize edilmiş Blockchain çekirdeği (kernel), DPoS konsensüs mekanizması, akıllı sözleşme sistemi, oylama sistemi, token sistemi ve temel çapraz zincir sistemi ile eksiksiz bir Blockchain sistemiyle tam bir Blockchain ticari çözüm setidir.

Yüksek Performanslı Akıllı Sözleşme Çalışma Zamanı

• Sözleşme yürütme seviyesi: Protobuf’a dayanarak grpc gibi bir akıllı sözleşme yürütme ortamı uygulandı. Tüm nesnelerin girdi ve çıktıları ve depolanması Protobuf yüksek performanslı serileştirme işlemine dayanır. Durum depolaması, redis gibi yüksek performanslı bir dağıtılmış veri tabanı kullanır.
• Genel sözleşme yapısı: grpc eklentisi ile oluşturulan kodlar, bir grpc sunucusuna eşdeğer performansları gösterir.
• Sözleşme Kontrolü: Bloklar içinde paralel yürütme, AKKA kümeleri üzerinden gerçekleştirilebilir.

Konsensüs Sistemi
• Güvenlik: Gizli Paylaşım algoritması, seçilen tüm düğümlerde dağıtılmış rasgele sayıların üretilmesini sağlayabilir. Her turdaki blok üretim sırası; üretilen rasgele sayılarla belirlenir, böylece düğüm gizli anlaşması ve kötü niyetli davranış olasılığını azaltır.
• Verimli: Düğümlerin ⅔'ü bir bloğu doğruladıktan sonra blok, geri ters çevrilemez blok olur ve veriler çatal tarafından ters çevrilmeden zincire kalıcı olarak sabitlenir.

Çoklu Token Sistemi
• Sözleşme sistemine dayanarak Blockchain çapraz zincir sağlayabilen dâhili bir Token Sistemi uygulanır. Tüm varlıklar; zincirler arasında ihraç edilebilir, transfer edilebilir ve kilitlenebilir.

Oylama sistemi
• Sözleşme sistemine dayanarak bir evrensel oylama sistemi, işlevseldir ve çevrimiçi yönetişimi ve ikincil gelişmeyi kolaylaştırır.

Çapraz Zincir Sistemi
• Çapraz zincir sistemi, bir zincirdeki herhangi bir verinin farklı bir zincire iletilmesi için bir yol sağlar. Sistem; Merkle ağacı kök indeksine dayanmaktadır ve ana zincirde depolanan veri miktarı, yan zincir sayısındaki değişiklikten bağımsızdır. Bu, tüm sistemin çok seviyeli ana zincir/yan zincir indekslemesi elde edebileceği ve böylece kolaylıkla ölçeklenebileceği anlamına gelir.

Web API
• Yüksek performanslı bir ASP.Net Çekirdek sunucusu, yüksek performanslı etkileşimli bir yapı ile sonuçlanır.

1.2 DevKit

https://github.com/AElfProject/aelf-boilerplate

Enterprise sürüm; Geliştirme Şablonları ve Öğreticileri, Geliştirici Kılavuzu, TestKit, BenchmarkKit ve IDE Entegrasyonunu içerir

• Geliştirici Kılavuzları: Aelf sisteminin ve API dokümantasyonunun ayrıntılı bir tanıtımını sağlar
• TestKit: Geliştiricilerin sözleşmeleri hakkında kısa bir test yapmasına izin verir
• BenchmarkKit: Dahili performans testi durumları sağlar
• IDE Entegrasyonu: Geliştiricilerin, geliştirme sırasında akıllı sözleşmelerin hatalarını ayıklamalarına izin verir ve birim test kodu kapsamı istemi sağlar

Geliştiriciler, hızlı bir şekilde Aelf temelli Blockchain sistemleri kurabilir ve sağlanan geliştirme kitlerine ve araçlarına dayalı olarak Dapp‘ler oluşturabilirler. Ek olarak geliştiriciler, geliştirici dokümantasyonu aracılığıyla sisteme kendilerini tanıtabilirler.

2. Aelf Harici Uygulamalar

- Aelf Blockchain tarayıcı https://github.com/AElfProject/aelf-block-scan
• Zincir tarama programı, geliştiricilerin zincirdeki verileri zincir dışında kolayca depolamasını ve böylece geliştirici geliştirme maliyetlerini düşürmesini sağlar.
• Uygulamayı ilgili veri tabanına eklemek gerekir, topluluk varsayılan MySQL ekleme sürümü olarak aelf-scan-MySQL sağlar.

- Aelf Tarayıcı MySQL eklentisi https://github.com/AElfProject/aelf-scan-mysql
• Geliştiriciler, MySQL veri tabanına veri eklemek için zincir tarama programını kolayca kullanabilir
• İşlem, blok, TPS, kaynak veri depolaması varsayılan olarak desteklenir

- Aelf Kâşifi https://github.com/AElfProject/aelf-block-explorer
• Blok ve işlem sorguları uygulandı
• Dâhili oylama sisteminin görselleştirmesi yayınladı
• Kaynak işlemlerinin görselleştirilmesi yayınladı

- Aelf Cüzdan https://github.com/AElfProject/aelf-web-wallet
• Yerel olarak depolanan özel anahtar
• Temel token transferi ve işlem kayıtlarını görüntüleme uygulandı
• Aelf sözleşme tokenlerini arayabilir ve ekleyebilir
• İlgili işlem kayıtlarını arayabilir

- Nodejs’de Aelf CLI https://github.com/AElfProject/aelf-command
• Çeşitli komut satırı istemleri sağlar
• Hesap oluşturma, blok bilgisi alma, işlem (trading) bilgisi alma ve sözleşmeleri yayınlama gibi işlevler sağlar.

3. Aelf Tarayıcı Uzantısı

https://github.com/AElfProject/aelf-web-extension

• Özel anahtarları yerel olarak depolar ve bir anahtar yönetim kullanıcı arayüzü sağlar
• Eklenti ve uygulama arasında şifreli iletişim sağlar
• AElf ekosistemindeki DAPP işlem imzalarını destekler
• Kullanıcıların uygulama izinlerini görsel olarak yönetmesini destekler

KAYNAK: https://medium.com/aelfblockchain/aelf-enterprise-receives-an-overhaul-aelf-enterprise-0-8-0-alpha-officially-released-d20fe64d729b



member
Activity: 598
Merit: 10
Aelf Teknik Konuşmalar: Güvenli Bir Şekilde Blockchain’de Rastgele (Random) Bir Sayı Oluşturma (ACS6)

Bölüm 4




AElf rastgele sayı sözleşme standardı (ACS6)

Bu makale; Blockchain sistemlerindeki rastgele sayılar için yaygın çözümlere, rastgele sayılar sağlayan akıllı sözleşmeler için AElf tarafından sağlanan standart arayüzlere ve ACS6 için AEDPoS sözleşmelerinin uygulanmasına odaklanmaktadır.

Blockchain ve rastgele sayı

Blockchain geliştirilmesinde sözleşmeyle ilgili rastgele sayı uygulamaları için birkaç senaryo var: piyangolar, doğrulama kodları, şifre korelasyonları vb.

Blockchain esasen dağıtılmış bir sistem olduğundan, her bir düğümün operasyon sonuçlarının doğrulanabilir olmasını gerektirir. Geleneksel rastgele sayı üretme çözümleri, farklı makinelerde tutarlı sonuçlar üretmeyecek ve tüm düğümlerin aynı rastgele sayıyı üretmesini sağlayacaktır. Bu nedenle, bu tür sistemler ile aşırı gecikmelere neden olmaması mümkün değildir.

Bir Blockchain ağında kabul edilen rastgele bir sayı üretebilmenin açık yararları vardır. Mevcut birkaç seçenek var:

- Merkezi bir parti rastgele sayılar üretir. Rastgele sayılar, güvenilir bir üçüncü tarafça sağlanır (ör: Random.org).

- Taahhüt yöntemi (hash-commit-reveal yöntemi). AElf Whitepaper’da belirtildiği gibi AElf ana zincir konsensüsü, üretim emrini belirlemek için her bloğun hem in_value hem de out_value değerini belirlemek için kullanılır. Blok üreticisi, yerel olarak rastgele bir karma üretir. Out_value = karma (in_value) olduğu yerde bir in_value özel olarak ayarlandıktan sonra vaadi (yani out_value) açıklanır ve rastgele karma değeri in_value daha sonra uygun bir zamanda yayınlanır. Diğer düğümlerin yalnızca out_value == karma (in_value) doğrulaması gerekir. Buradaki in_value rastgele bir sayı olarak düşünülebilir.

- Blockchain durum bilgilerinin bir tohum olarak toplanması ve sözleşmede belirlenmiş bir algoritma ile rastgele bir sayı oluşturulması. Algoritmanın bilinmesi halinde (akıllı sözleşmenin kodu halka açıktır) ve doğru tohum elde edildiğinde, bu program tarafından oluşturulan rastgele sayı daha sonra başarılı bir şekilde tahmin edilebilir.

Merkezsizleşme perspektifinden bakıldığında Taahhüt yöntemi, yukarıda belirtilen seçeneklerden kullanılabilecek tek çözümdür. Bu durumda asıl endişe, rastgele sayıyı üreten kişinin gizlice önceden ifşa etmemesini veya aldatmak için kullanmamasını sağlayarak giderilebilir.

Ancak maalesef ki Blockchain sisteminde bu garanti edilemez: rastgele sayıyı üreten kişinin, örneğin rastgele sayının kumar olarak kullanıldığı gibi, gizli amaçlar için bilgileri kullanmayacağını garanti edemeyiz. Piyango ayarlandığında rastgele sayının üreticisi, oyun başlamadan önce söz verilmiş olsa bile, rastgele sayının açıklamasını askıya alabilir - bu, “tekrar oynama” fırsatına eşittir çünkü eğer bu düğüm bu rastgele sayıyı açıklamazsa, sistem başka bir düğümden başka bir rastgele sayı seçecek veya kumar geçersiz olacaktır.

Ya stokastik sayı üreticilerinin saldırıyı durdurmayı seçmeleri engellenirse? Bir dizi olgun çözüm vardır, Gizli Paylaşım gibi.

Örnek: Şimdi her biri bir halka açık-özel anahtar çiftine sahip olan A’dan E’ye beş kişi vardır. Bu zamanda A, karşılık gelen taahhüdü üreten rastgele bir sayı Random üretir. Aynı zamanda, rastgele sayı Random dört Paylaşım Parçası elde etmek için B, C, D ve E'nin halka açık anahtar ile şifrelenmiştir. Paylaşım Parçaları şifrelendiğinde, B ~ E'de yalnızca iki kişinin Random’ı kurtarabileceği ve Paylaşma Parçaları ile Taahhüdü bir araya getirebileceği garanti edilir. Bu nedenle, A kendi nedenleriyle Random’ın değerini yayınlamazsa bile, B ~ E’deki herhangi iki kişi kendileri tarafından alınan Paylaşım Parçalarının şifresini kendi özel anahtarlarıyla çözebilir ve iki şifresi çözülmüş değeri derleyebilir (A'ya göre şifrelenebilir). Random sonra geri yüklenebilir. Bir veya iki Paylaşım Parçası Random’ı düzeltemediğinde, onlar sadece A'nın en baştan kötü niyetli davranmaya karar verdiğini varsayabilirler - Bu durumda Blockcahin ekonomik sistemine göre, sadece A cezalandırılır. Örneğin, A’nın başvurusunun doğrudan kesilmesi, rastgele bir sayı üreticisinin ödediği marj olarak ifade edilir.

Ek olarak bir bireyin ürettiği rastgele sayıya güvenmemeyi seçebilir, ancak karma değerini uygulama senaryosunda mevcut rastgele sayı olarak hesaplamak için birden fazla kişinin rastgele sayılarını seçebiliriz. Bu şekilde, daha fazla kararlılık ve güvenlik ile bir Blockchain sisteminde rastgele sayılar elde edebiliriz.

ACS6 - Rastgele Sayı Sağlayıcı Sözleşme Standardı

Bir önceki makalede, konsensüs için AElf Blockchain’in sözleşme standardını açıkladık, bu aslında AElf ana zincir geliştiricisinin sözleşme geliştiricileri için konsensüs mekanizmaları uygulaması için tavsiye edilen arayüzdür. Rastgele sayı üretimi ile ilgili olarak, rastgele sayılar sağlayan herhangi bir sözleşme önerisi için uygulanacak bir arayüz olarak ACS6'yı geliştirdik.
Beklendiği gibi ACS6, Taahhüt şemasını soyutlamayı ve sözleşme standardını almayı seçti.

ACS6 kullanımını destekleyen senaryo aşağıdaki gibidir:

Kullanıcılar, emir göndermeye benzer şekilde ACS6 uygulayan bir sözleşme için rastgele bir numara için başvururlar.

ACS6 sözleşmesi uygulanır ve kullanıcının hangi blok yüksekliğinde (H) rastgele bir sayı alabileceği ve kullanıcının rastgele sayı için alabileceği referans T (ayrıca bir karma değeri) dâhil olmak üzere kullanıcıya bazı bilgiler geri döndürülür.

Blockchain yüksekliğinin H yüksekliğine ulaşmasını bekledikten sonra kullanıcı, işlemi rastgele sayı almaya çalışmak için gönderir ve referans T işlemin parametresi olması gerekir.

ACS6 sözleşmesi, referans T'ye göre rastgele bir sayı döndürür.

Kullanıcı H yüksekliğinden önce rastgele sayı almaya çalışırsa, çağrı yürütme için başarısız olur ve yüksekliğin henüz gelmediğini belirten bir Onay İstisnası alır.

Yukarıdaki senaryoya göre, ACS6'yı aşağıdaki gibi tasarladık:



Kullanıcı rastgele bir sayı için başvuru yapmak için bir RequestRandomNumber işlemi gönderir. Sözleşmenin istek için bir token_hash oluşturması ve ardından tokeni kullanıcıya rastgele sayı elde edebileceği blok yüksekliği ile birlikte kullanıcıya geri döndürmesi gerekir. Yüksekliğe ulaşıldığında kullanıcı, uygun bir rastgele sayı elde etmek için alınan token_hash'ı kullanarak GetRandomNumber işlemini gönderir. Bir sözleşme olarak bu yöntem uygulanırken kullanıcı tarafından oluşturulan referanslar önbelleğe alınmalıdır. Bir haritanın (map) anahtarı olarak haritanın değeri, kendi veri yapısını sözleşmenin rastgele sayıları uygulamasına göre tanımlamalıdır.

Örneğin AEDPoS sözleşmesi ACS6'yı uyguladığında, Haritanın değeri şöyle tanımlanabilir:



Round_number, kullanıcı tarafından uygulanan rastgele sayıyı üretmek için her bir CDC tarafından yayınlanan hangi previous_in_value değerinin kullanılması gerektiğini belirtir. Emir, emirin raundun CDC'si tarafından paketlenen rastgele numara için başvurduğu RandomNumberProviderControl işlemidir (önceki yayınlanan daha sonra turda gereklidir). We_in_value, rastgele sayı üretimi için ham maddedir. Expected_block_height, kullanıcının beklemesi gereken bloğun yüksekliğidir.

ACS6 için AEDPoS sözleşmesinin uygulanması

AEDPoS konsensüsü ilerletme sürecinde benimsenen hash-commit-reveal yaklaşımı nedeniyle her bir CDC için sıradan blokların (ekstra bloklardan farklı olarak) üretilmesi sırasında yayınlanan previous_in_value değeri, doğrudan rastgele sayılar üretmek için ham madde olarak kullanılabilir. Herhangi bir düğüm yeni bir blok yürütmeden önce, yeni yayınlanmış prior_in_value doğrulaması (yani doğrulama karması (hash) (previous_in_value) == previous_out_value) gerçekleşir. Blok en iyi zincirle başarılı bir şekilde senkronize edildiği sürece, yayınlanan previous_in_value öğesinin hileli davranışı konusunda endişelenmeye gerek yoktur.

Bu bölümün uygulanmasının yalnızca ACS6'nın tanımının tamamlanmasından kısa bir süre sonraki bir girişim olduğunu ve bundan sonra herhangi bir zamanda önemli değişiklikler olabileceğini unutmayınız.

Tek endişe, CDC komplosudur. Bu nedenle AEDPoS rastgele sayı üretmeyi uyguladığında, rastgele sayı üretmek için yalnızca bir CDC’nin previous_in_value değerini kullanmaz aynı zamanda beşli kümeler kullanır:



Bir kullanıcı AEDPoS'dan rastgele bir sayı talep ettiğinde, geçerli raundun yayınlanabilir previous_in_value değerinin yayınlandığından emin olmak için yalnızca geçerli raundun son dilimine (ekstra blok dilimi) kadar bekleyebilir. Bu raunda yeni eklenmiş bir CDC varsa (belki az önce çatallaşmayı çözdüler), yayınlayacak bir previous_in_value sahip olmayacaklar veya yerel önbelleğe alma sorunları nedeniyle previous_in_value yayınlayamamış olabilirler. İlave blokların dilimine gelince previous_in_value değerleri, gizli paylaşımın ortaya çıkarma aşamasını tamamlar. Restore edildi - Eğer kullanıcıların rastgele sayılar almak için ortaya çıkarma aşamasından önce GetRandomNumber işlemlerini göndermelerine izin verirsek, ortaya çıkarma evresinden önce ve sonra elde edilen rastgele sayılar ciddi sorunlara neden olabilecek kadar tutarsız olabilir.



Kullanıcılar referanslarıyla rastgele sayılar almaya çalıştığında AEDPoS, kullanıcılar rastgele sayılar için başvurduktan sonra CDC'ler tarafından yayınlanan beş previous_in_values değeri toplar, bu beş karma ile bir karma değerini hesaplar ve bunları kullanıcılara rastgele bir sayı olarak geri döndürür.




Daha sonra, bu iki yönteme BVT test durumları eklenmiştir (AElf sözleşmelerinin test edilmesi için bir yapı vardır). Bir kod üreteci, bir sözleşme yöntemi çağırabilecek bir Stub oluşturmak için kullanılabilir. Stub, kullanıcı tarafından gönderilen işlemleri bir Blockchain’de simüle edebilir ve her işlem ayrı olarak bir bloğa paketlenir.

Zincirin başında simüle edilmiş herhangi bir kullanıcının Stub’ı, uygun bir RandomNumberOrder elde edip edemediğini kontrol etmek için RequestRandomNumber işlemini gönderir. Gerekli sözleşmeler test durumu yürütülmeden önce çok sayıda işlem aracılığıyla (şu anda 19) dağıtıldığından RequestRandomNumber yürütüldüğünde blok yüksekliği 20'ye ulaştı.



Belli bir yükseklikten (bir round süresi) sonra simüle edilen kullanıcı, rastgele sayıyı almak için GetRandomNumber işlemini gönderir. Sonraki test durumları normal blok işlemi için CDC’nin ilk raundunu simüle eder ve ayrıca ExpectedBlockHeight'tan önce ve sonra GetRandomNumber’ı göndermeyi dener. Yüksekliğe ulaşılmadığında, işlem yürütme başarısız olur ve “Rastgele(random) sayı hâlâ hazırlanıyor” hata mesajı ortaya çıkar. İkinci GetRandomNumber gönderildiğinde, işlem yürütme başarılı olur ve kullanılabilir rastgele sayı döndürülür; ve üçüncü GetRandomNumber, rastgele sayı hakkındaki bilgiler AEDPoS sözleşmesi tarafından silindiği için gönderilir (boşluk mekanizması tasarrufu), böylece boş bir karma (hash) değeri döndürür.




KAYNAK: https://medium.com/aelfblockchain/aelf-tech-talks-generating-a-random-number-on-blockchain-securely-acs6-37e355522c72
member
Activity: 598
Merit: 10
Aelf'e Çin Elektronik Standardizasyon Enstitüsü (CESI) tarafından bir sertifika verildi. Bu neden ve nasıl Aelf için bir dönüm noktasıdır?




member
Activity: 598
Merit: 10
Japonya’nın en büyük hediye kartı borsası Aelf ile partner oldu

Amaten, Blockchain ağ sağlayıcısı Aelf ile ortaklaşa tokenize edilmiş hediye kartları çıkaracaktır.



Japonya’nın en büyük hediye kartı borsası, bir sonraki büyüme aşamasını teşvik etmek için Blockchain kullanmayı planlıyor.

Hediye kartları için ikincil bir pazar olan Amaten, 20 Ağustos'ta yayınlanan açıklamaya göre, Singapur merkezli bulut bilişim Startup’ı Aelf ile ortak olduğunu duyurdu. Borsa, Aelf’in kurumsal odaklı Blockchain platformunu kullanarak operasyonlarını uluslararası olarak ölçeklendirmeyi planlıyor.



2012 yılında kurulan Amaten, Japonya’nın hediye kartı borsa hacminin yüzde 40’ını elde etmek için büyüdü ve yıllık yaklaşık 110 milyon dolar gelir elde ediyor. Küresel ölçekte, hediye kartı endüstrisi, 340 milyar dolarlık bir piyasaya girdi.

Hediye kartları Aelf platformunun yönettiği dijital varlıklara dönüştürerek firma, “hediye kartlarının çıkarılması, satın alınması ve değiş tokuşu ile ilgili köklü değişikliklere” önem veriyor.

Amaten Başkanı Tom Kanazawa, “Hediye kartları için kullanılan mevcut sistem ve teknoloji, tamamen modası geçmiştir ve 90'ların ortasına kadar uzanmaktadır.” ifadelerini kullandı.

“Hâlâ temel temel eksikliklerden zarar görmektedir ve çok elverişsizdir. Hediye kartı endüstrisinin Blockchain için mükemmel bir kullanım alanı olabileceğine inanıyorum.”



Aelf Blockchain, bir hediye kartı ihracının ve sahiplik değişimlerinin değişmez bir kaydını sağlayacak ve böylece Amaten platformunun şeffaflığını artıracaktır.

Kanazawa, “Biz, Aelf ile ortaklık kurmayı seçtik çünkü hizmetlerimizi hızlı ve en uygun maliyetli bir şekilde oluşturmak için ihtiyaç duyduğumuz ölçeklenebilirliği, özel yan zincirleri ve akıllı sözleşme modüllerini sunuyorlar.” ifadelerini kullandı.
Ayrıca firma, Blockchain’in harcanmamış hediye kartı miktarını azaltabileceğini ileri sürüyor.

Aelf’in Kurucu Ortağı ve COO’su Zhuling Chen, “Amaten ile ortaklık aracılığıyla, geleneksel endüstrilerde Blockchain çözümlerinin benimsenmesine öncülük etmeyi umuyoruz.” ifadelerini kullandı.

Daha fazla bilgi için aelf.io ve amaten.io (Japon hediye kartı borsası için amaten.com) adreslerini ziyaret edebilirsiniz

KAYNAK: https://medium.com/aelfblockchain/japans-largest-gift-card-exchange-partners-with-aelf-ce145891c42f

Aelf ile Amaten arasındaki ortaklıkla ilgili basında yer alan diğer haberler:

- Coindesk --> https://www.coindesk.com/japans-largest-gift-card-exchange-expanding-internationally-with-blockchain-firm
- Yahoo Finance --> https://finance.yahoo.com/news/age-digital-asset-exchanges-japans-070000988.html
- Markets Insider --> https://markets.businessinsider.com/news/stocks/new-age-of-digital-asset-exchanges-japan-s-largest-gift-card-exchange-pioneers-blockchain-expansion-1028458092
- CoinTelegraph --> https://cointelegraph.com/news/japans-largest-gift-card-marketplace-launching-blockchain-gift-cards
- CryptoBriefing --> https://cryptobriefing.com/aelf-amaten-card-exchange/
member
Activity: 598
Merit: 10
🔊 Yıllık 110 milyon dolar ciro elde eden Japonya'nın en büyük hediye kartı ticaret platformu olan Amaten, Aelf Blockchain'de altyapısını genişletiyor olacak.

https://twitter.com/aelfblockchain/status/1163694759975612421
member
Activity: 598
Merit: 10
Aelf Teknik Konuşmalar: Geliştiricinin GetConsensusCommand'ı Elde Etmesi

Bölüm 3



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

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

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

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

AEDPoS Süreci

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

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

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

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



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

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

ConsensusCommand

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



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



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



Açıklama:

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

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

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

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

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

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

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

GetConsensusBehaviour

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

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



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

GetConsensusCommand — UpdateValueWithoutPreviousInValue

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

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

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



GetConsensusCommand — UpdateValue

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

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



GetConsensusCommand — NextRound

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

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

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

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




GetConsensusCommand — NextTerm

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



GetConsensusCommand — TinyBlock

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

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




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

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



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

Olası optimizasyon talimatları

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

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

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



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

Sun Network nedir?

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

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

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

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

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



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

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

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

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

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



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

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



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

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

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

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

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

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

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

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

KAYNAK: https://medium.com/aelfblockchain/sidechains-trons-sun-network-when-compared-with-aelf-loses-it-s-sparkle-7fd1beca8769
member
Activity: 598
Merit: 10
Kürşat, gayretine hayranım. Ekipten misin?

Görüşleriniz ve desteğiniz için Teşekkürler Smiley Aelf'in Türkiye moderatörlüğünü yapmaktayım.
Aynı şeyi söyleyecektim, hakkaten azimli birisiniz. Ms azure'ye GoChain de dahil olmuştu ama pek bir faydası olmadı.
Başarılar dilerim

Desteğiniz ve görüşleriniz için çok Teşekkürler Smiley
legendary
Activity: 2128
Merit: 1148
Kürşat, gayretine hayranım. Ekipten misin?

Görüşleriniz ve desteğiniz için Teşekkürler Smiley Aelf'in Türkiye moderatörlüğünü yapmaktayım.
Aynı şeyi söyleyecektim, hakkaten azimli birisiniz. Ms azure'ye GoChain de dahil olmuştu ama pek bir faydası olmadı.
Başarılar dilerim
member
Activity: 598
Merit: 10
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
member
Activity: 532
Merit: 22
Aelf sürekli olumlu işler yapıyor ve ekibi gelişim içinde. Bütün aktivitelerini tamamladıktan sonra mutlaka daha yüksek değerlere gelecek gibi duruyor. Özellikle airdrop dağıtma mantığı çok guzeldi ama ben çok uğraşmak istemedigim için bıraktım.
member
Activity: 598
Merit: 10
AELF Haftalık Gelişim İlerleme Raporu (5 Ağustos — 11 Ağustos)

Özet: Merkle Tree uygulaması optimize edildi



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

Fonksiyon:

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

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

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

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

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