Bitcoin Forum
October 29, 2020, 08:52:20 PM *
News: Latest Bitcoin Core release: 0.20.0 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 [17] 18 19 20 21 22 23 24 25 26 27 28 29 »
321  Local / Alternatif Kripto-Paralar / Re: AELF ($ELF) Blockchain (ANA KONU) on: September 06, 2019, 05:06:04 AM




322  Local / Alternatif Kripto-Paralar / Re: AELF ($ELF) Blockchain (ANA KONU) on: September 02, 2019, 02:50:03 PM
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

323  Local / Alternatif Kripto-Paralar / Re: AELF ($ELF) Blockchain (ANA KONU) on: August 30, 2019, 09:32:53 AM
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





324  Local / Alternatif Kripto-Paralar / Re: AELF ($ELF) Blockchain (ANA KONU) on: August 26, 2019, 01:45:32 PM
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



325  Local / Alternatif Kripto-Paralar / Re: AELF ($ELF) Blockchain (ANA KONU) - Aelf Kurumsal 0.7.0 Beta Microsoft Azure'da! on: August 24, 2019, 08:26:42 AM
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
326  Local / Alternatif Kripto-Paralar / Re: AELF ($ELF) Blockchain (ANA KONU) - Aelf Kurumsal 0.7.0 Beta Microsoft Azure'da! on: August 22, 2019, 09:15:09 AM
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?




327  Local / Alternatif Kripto-Paralar / Re: AELF ($ELF) Blockchain (ANA KONU) - Aelf Kurumsal 0.7.0 Beta Microsoft Azure'da! on: August 21, 2019, 07:58:45 AM
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/
328  Local / Alternatif Kripto-Paralar / Re: AELF ($ELF) Blockchain (ANA KONU) - Aelf Kurumsal 0.7.0 Beta Microsoft Azure'da! on: August 20, 2019, 06:29:50 AM
🔊 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
329  Local / Alternatif Kripto-Paralar / Re: AELF ($ELF) Blockchain (ANA KONU) - Aelf Kurumsal 0.7.0 Beta Microsoft Azure'da! on: August 18, 2019, 11:06:33 AM
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

330  Local / Alternatif Kripto-Paralar / Re: AELF ($ELF) Blockchain (ANA KONU) - Aelf Kurumsal 0.7.0 Beta Microsoft Azure'da! on: August 16, 2019, 04:56:43 PM
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
331  Local / Alternatif Kripto-Paralar / Re: AELF ($ELF) Blockchain (ANA KONU) - Aelf Kurumsal 0.7.0 Beta Microsoft Azure'da! on: August 16, 2019, 04:04:14 PM
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
332  Local / Alternatif Kripto-Paralar / Re: AELF ($ELF) Blockchain (ANA KONU) - Aelf Kurumsal 0.7.0 Beta Microsoft Azure'da! on: August 15, 2019, 12:55:39 PM
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
333  Local / Alternatif Kripto-Paralar / Re: AELF ($ELF) Blockchain (ANA KONU) - Aelf Kurumsal 0.7.0 Beta Microsoft Azure'da! on: August 13, 2019, 06:26:28 PM
334  Local / Alternatif Kripto-Paralar / Re: AELF ($ELF) Blockchain (ANA KONU) - Aelf Kurumsal 0.7.0 Beta Microsoft Azure'da! on: August 13, 2019, 06:41:56 AM
ADRES --> https://t.me/aelf_turkish

335  Local / Alternatif Kripto-Paralar / Re: AELF ($ELF) Blockchain (ANA KONU) - Aelf Kurumsal 0.7.0 Beta Microsoft Azure'da! on: August 12, 2019, 09:54:12 AM
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
336  Local / Alternatif Kripto-Paralar / Re: AELF ($ELF) Blockchain (ANA KONU) - Aelf Kurumsal 0.7.0 Beta Microsoft Azure'da! on: August 12, 2019, 09:52:40 AM
Kürşat, gayretine hayranım. Ekipten misin?

Benim bildiğim kadarıyla Kürşat Hocam, aelf in Türkiye sorumlusu. Şimdiye kadar başka başlıkta post attığını hiç görmedim. Sadece aelf ile ilgili tanıtımı var. Aelf ekibinin sürekli çalıştıgini onun sayesinde öğrenmiş oluyoruz. Boğa sezonu gelirse altcoinlere belki ciddi bir değere çıkabilir.

Görüşleriniz için teşekkür ediyoruz Smiley
337  Local / Alternatif Kripto-Paralar / Re: AELF ($ELF) Blockchain (ANA KONU) - Aelf Kurumsal 0.7.0 Beta Microsoft Azure'da! on: August 12, 2019, 09:09:41 AM
🔊 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!

338  Local / Alternatif Kripto-Paralar / Re: AELF ($ELF) Blockchain (ANA KONU) - Aelf Kurumsal 0.7.0 Beta Microsoft Azure'da! on: August 09, 2019, 08:50:05 PM
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/developers-are-using-aelf-to-build-apps-and-win-awards-at-chinas-largest-hackathon-af12b0fd8a41
339  Local / Alternatif Kripto-Paralar / Re: AELF ($ELF) Blockchain (ANA KONU) - Aelf Kurumsal 0.7.0 Beta Microsoft Azure'da! on: August 08, 2019, 10:35:26 AM
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.
340  Local / Alternatif Kripto-Paralar / Re: AELF ($ELF) Blockchain (ANA KONU) - Aelf Kurumsal 0.7.0 Beta Microsoft Azure'da! on: August 08, 2019, 10:00:14 AM
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/aelf-consensus-contract-standard-acs4-aelf-developer-community-8824e5d24913



Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 [17] 18 19 20 21 22 23 24 25 26 27 28 29 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!