Teknoloji Haberleri
DH Anasayfa
İndirim Kodu
Ara
Popüler
Foruma Git
Hakkımızda
Destek
Mobil Sürüm
Standart Site Görünümü
Aşağı Git
Tüm Forumlar
Finans Forumları
Kripto Para ve Madencilik
Diğer Kripto Para Birimleri
AELF ($ELF) Blockchain (RESMİ ANA KONU)
Bu konudaki kullanıcılar: 1 misafir
527
Cevap 11227
Tıklama 0
Öne Çıkarma
Cevap 11227
Tıklama 0
Öne Çıkarma
-
Cevap: AELF ($ELF) Blockchain (RESMİ ANA KONU) (6. sayfa)
Cevap Yaz
Konuya Özel
|
🔊 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 |
< Bu ileti mobil sürüm kullanılarak atıldı >
|
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. < Resime gitmek için tıklayın > 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. < Resime gitmek için tıklayın > 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.” < Resime gitmek için tıklayın > 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/ |
< Bu ileti mobil sürüm kullanılarak atıldı >
|
Aelf Enterprise (Kurumsal) Revize Edildi: Aelf Enterprise 0.8.0 Alfa (Alpha) Resmi Olarak Yayınlandı < Resime gitmek için tıklayın > 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 alphahttps://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) • Boilerplatehttps://github.com/AElfProject/aelf-boilerplate 1.TestKit 2.BenchmarkKit 3.IDE entegrasyonu • Belgelerhttps://docs.aelf.io/ • Öğreticilerhttps://docs.aelf.io/main/main • Videolar 1.1 aelf 0.8.0 Alpha < Resime gitmek için tıklayın > 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 eklentisihttps://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âşifihttps://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üzdanhttps://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 CLIhttps://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 |
< Bu mesaj bu kişi tarafından değiştirildi Kursa1903 -- 26 Ağustos 2019; 16:56:40 >
|
Aelf Teknik Konuşmalar: Aelf’in Akıllı Sözleşmeler Tarafından Yönetilen Teşvik Programları Bölüm 5 < Resime gitmek için tıklayın > 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ı: < Resime gitmek için tıklayın > 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: < Resime gitmek için tıklayın > 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: < Resime gitmek için tıklayın > 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: < Resime gitmek için tıklayın > 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ı: < Resime gitmek için tıklayın > 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ı: < Resime gitmek için tıklayın > 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 |
|
Aelf ortaklıklarının özeti - Kim, Ne ve Neden < Resime gitmek için tıklayın > 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 |
|
Merkle Ağacı (Merkle Tree) - Bu nedir ve neden kullanılır? < Resime gitmek için tıklayın > 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. < Resime gitmek için tıklayın > “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 |
|
🔊 Aelf (ELF), BCNEX'de listelenmiştir. İşlem Çiftleri: ELF/BTC, ELF/ETH ve ELF/USDT Adres:https://www.bcnex.net/en/exchange/trade/ELF_BTC https://twitter.com/aelfblockchain/status/1170989719443795968 https://twitter.com/bcnex_net/status/1170988711690948608 < Resime gitmek için tıklayın > |
|
🔊 ELF, Crypto.com uygulamasında listelenmiştir. https://twitter.com/cryptocom/status/1171320189075378178 < Resime gitmek için tıklayın > |
|
Aelf'in resmi Türkiye Telegram grubu olanhttps://t.me/aelf_turkish adresinde "Aelf Puan Yarışması" olarak adlandırılan yeni ve ödüllü bir topluluk etkinliği bugün itibariyle başlayacaktır. Tüm detaylar içinhttps://t.me/aelf_turkish adresini ziyaret edebilirsiniz. < Resime gitmek için tıklayın > |
|
Merkezi Olmayan Uygulamalar (Dapps) Blockchain Benimsenmesini Olumlu mu Yoksa Olumsuz mu Etkiliyor? < Resime gitmek için tıklayın > DApp'ler potansiyel olarak Blockchain’in benimsenmesinde en önemli bileşenlerden biridir. Onlar bir anlamda benimsenmenin gerçek dünyasıdır, bir yazılım parçasından bir çözüme geçişi temsil ediyorlar. DApp’ler nedir? DApp, merkezi olmayan uygulamanın kısaltmasıdır. Merkezi olmayan bir Blockchain üzerinde çalışan herhangi bir uygulamaya teorik olarak dApp denebilir. DApp'lerin çoğunluğu, temel Blockchain’i oluşturanlarla ilişkili olmayan 3. taraflar veya ekipler tarafından geliştirilmiştir. Farklı Blockchainler için tasarlanmış birden fazla varyasyon mevcut olmasına rağmen bir dApp, bir bireysel Blockchain’e özgüdür. Windows ve Apple’da mevcut olabilen bir uygulamaya benzer şekilde, üzerinde çalışması gereken işletim sistemine bağlı olarak ayrı bir yükleyiciye sahip olacaktır. Temel olarak bir dApp’ın eşdeğeri, bir yükleme dosyası aracılığıyla PC'nize veya telefonunuza yüklediğiniz herhangi bir uygulamadır (bazıları etkileşimli bir web sitesi olmasına rağmen) ve temel Blockchain kendi cihazınızın işletim sistemidir. Her şey bir dApp değildir Blockchain üzerinde çalışan bazı uygulamalar, teknik olarak bir dApp olarak sınıflandırılmayabilir çünkü IBM'in izin verilen bir özel Blockchain üzerinde çalışan bir uygulama olan FoodTrust uygulaması gibi tamamen merkezsizleştirilmemiş olabilirler. Genel olarak konuşursak, izin verilen özel bir Blockchain sınırlı ya da merkezsizleşmemiş anlamına gelir ve bazı örnekler basitçe bir veri tabanı olarak sınıflandırılabilir. Aslında, Blockchain teknolojisinin kurumsal düzeyde benimsenmesi için sınırlayıcı faktörlerden biri, Blockchain kullanan herhangi bir uygulamanın tamamen merkezsizleştirilmesi ve dolayısıyla kamuya açık hale getirilmesi gerektiği konusundaki yanlış anlama ile doğrudan ilgilidir. Bu açıkça yanlıştır. Gerçekte Blockchain’de çalışan bir uygulama, tamamen merkezi bir veri tabanı veya tamamen merkezi olmayan bir halka açık ledger ve bunların arasındaki her şey olabilir. DApp'ın Yükselişi Ethereum'un 2015 yılı ortalarında akıllı sözleşmelerin dahil edilmesi ile piyasaya sürülmesi, geliştiricilerin Blockchain özelliklerini kullanan uygulamaları uygun şekilde tasarlayabilecekleri ortamı yarattı. Bundan önce Blockchain kullanımı, tek tek izole edilmiş ve basit bir işlev olarak finansal işlemlerle sınırlıydı. Akıllı sözleşmelerin dahil edilmesi, sadece işlemlerin bir “if then” tasarımda birbirine bağlanmasına izin vermekle kalmadı, aynı zamanda uygulama potansiyelini diğer birçok sektöre ve endüstriye yaydı. dApp gelişiminin 2017'nin etkisi ile hareket etmesi 2 yıl sonrasına kadar değildi. Başka bir 2 yıl ve dApp gelişmesi, artık her gün onlarca dapp çalıştıran çoğu Blockchain platformu ile normdur. State of the Dapps (https://www.stateofthedapps.com/ ) ve Dapp Review (https://dapp.review/ ) tarafından sunulan gibi DApp gelişimini destekleyen Blockchain platformları; Ethereum, Tron, EOS, IOST, WICC, STEEM, Ont, Neo, Loom, Tomo, Nas, Bos, POA, xDai, Klaytn, GoChain'den oluşur. Her bir web sitesi, bu platformlarda mevcut dApp'lerin çoğunluğunu sırasıyla 3.021 ve 3.113 dApp'ler ile listelemektedir. < Resime gitmek için tıklayın > Ethereum en fazla dApp sayısına sahip olmasına rağmen aktif kullanıcıların sayısı, EOS ile karşılaştırıldığında günde 4-8 kat daha düşüktür. < Resime gitmek için tıklayın > < Resime gitmek için tıklayın > dApp Benimsenmesi Daha da şaşırtıcı olan şey hem State of the Dapps hem de DappReview’in istatistiklerine göre, dApp başına ortalama 35-45 kullanıcı ve EOS’un dApp başına yaklaşık 150 kullanıcı ile en başarılı platform olmasıydı. Bu, bu dApp'lerin çoğunun başarısının ciddi şekilde sınırlı olduğunu veya hiç etkili olmadığını gösterir. Aslında DappReview'a göre ilk 5 EOS dApp, aktif EOS kullanıcılarının %70'inden fazlasını oluşturuyor. Bir de bunun üstüne dApp’ların yarısından fazlası kumarhane ve yüksek risk kategorisine giriyor. Marka imajı ve ahlaki duruşlar üzerindeki endişeler nedeniyle bir bütün olarak, birçok kişi ve kuruluşlar bu dApp’ler ve potansiyel Blockchain ile bağlantılarını sınırladığından bu, büyük ölçüde benimsenmeyi sınırlayabilir. < Resime gitmek için tıklayın > Mevcut dApp durumuyla ilgili bir endişe, bunun daha geniş kamuoyuna verdiği zihniyet veya imajdır. Çok sayıda yüksek riskli ve kumarhane / gazino dApp'ler, halkın aklındaki olası Blockchain kullanım durumunu sadece riskli finansal teşvik programlarına daraltabilir. Gerçekte bu, bu teknolojinin uygulanabileceği birçok uygulamadan sadece biridir. En büyük ilerlemelerin bir kısmı, uygulamalarını tamamen merkezi olmayan bir şekilde geliştirmek istemeyen işletmeler tarafından gerçekleştirilmiştir. Avustralya Menkul Kıymetler Borsası (ASX), ana platform olan CHESS'e (https://www.asx.com.au/services/chess-replacement.htm) Blockchain odaklı bir geliştirme şirketi olan Digital Assets aracılığıyla yeni bir yükseltme geliştiriyor. Bu projenin, 2016’dan beri prototip gelişimine rağmen, 2021'den önce tam olarak başlatılması beklenmemektedir. Bu uygulama, platformda kayıtlı kullanıcı olan binlerce kurum ve aracının kullanımına açık olacak ancak uygulama ASX tarafından yönetilecek ve çalıştırılacaktır. IBM, Walmart ile FoodTrust (https://cointelegraph.com/news/national-fisheries-institute-and-ibms-food-trust-work-on-seafood-blockchain-traceability) adlı tedarik zinciri uygulamasını hayata geçirdi ve ABD, Avrupa ve Avustralya da dahil olmak üzere tüm dünyada endüstri genelinde sayısız müşteriye yer verdi. Bu uygulama, aynı zamanda izin verilen bir özel blockchain olarak da çalışmakta ve merkezsizleşmiş değildir. Visa, sınır ötesi ödemeleri kolaylaştıran bir Blockchain esin kaynağı olan Visa B2B Connect'i (https://cointelegraph.com/news/visa-launches-global-cross-border-network-based-on-certain-aspects-of-blockchain) başlattı. Ağ, Hyperledger'ın (https://cointelegraph.com/tags/hyperledger) öğelerini birleştirmiştir ve IBM ile iş birliği içinde geliştirilmiştir. Yukarıdakiler gibi işletmeler tarafından geliştirilen kullanım durumlarının çoğu, Blockchain’in belirli bir sorunu çözmek için geliştirilen daha büyük bir çözümün parçası olması gerçeğinden dolayı kullanıcılar tarafından küresel olarak daha geniş bir benimsenmeyi görecektir. Bu, çözdükleri belirli bir sorun olmadan Blockchain için bir uygulama sağlamak amacıyla geliştirilen dApp'lerin çoğuna zıttır. Benimsenme açısından Blockchain teknolojisini sergilemek için bir dApp geliştirmenin faydalı olduğu zaman geçmiştir. Odak, kendilerini belirli bir endüstri veya bir Blockchain odaklı uygulama için bir yazılım çözümü olarak konumlandıran bir şirketle daha bütünsel olmalıdır. Ek olarak, yazılım çözümlerinin tam olarak ihtiyaçlar doğrultusunda geliştirilmesine olanak tanıyan temel halka açık ve özel Blockchain platform teknolojisinde iyileştirmeler yapılması gerekmektedir. Burası Aelf'in devreye girdiği yerdir. Mevcut işletmeler ve yazılım çözüm sağlayıcıları için doğru Blockchain uygulaması ile çözümlerini geliştirmek için ihtiyaçlarına uygun şekilde tasarlanmış bir tramplen etkisi sağlayacak bir platform geliştiriyoruz. KAYNAK:https://medium.com/aelfblockchain/are-dapps-driving-or-derailing-blockchain-adoption-a2d66cb622a6 |
|
Aelf Blockchain NASDAQ, Google Cloud, Oracle, SAP, Ethereum ve Bitcoin ile iletişim kuracak < Resime gitmek için tıklayın > Aelf; yalnızca iletişim kurma yeteneğine sahip olmayan, aynı zamanda güvenilir ve değişmez veri Oracles’ı aracılığıyla diğer Blockchainler’den ve veri kaynaklarından doğrulanabilir verilere dayanan birkaç Blockchain’den biri olacaktır. Chainlink Oracles ile bağlanarak Aelf Blockchain; NASDAQ, Google Cloud, Oracle ve SAP gibi veri kaynaklarına ve Bitcoin ve Ethereum gibi Blockhainler’e erişime sahip olacaktır. Oracles, veriyi doğrulayarak verinin Aelf Blockchain’e gönderilmeden önce hem güvenilir hem de doğru olmasını sağlar. Bu, ekosistemde çalışan akıllı sözleşmelerin doğruluğunu ve güvenliğini büyük ölçüde artırır. Ek olarak Aelf ekosistemi dışında bu tür güvenilir veriler sağlayarak Blockchain uygulamasının bir çözüm olarak uygulanması, daha önce benzer çözümlerin uygulanması konusunda endişeli olan birçok işletme için gerçekçi bir seçenek haline gelmiştir. Bu neden benzersizdir? Blockchainler doğal olarak diğer veri kaynaklarına veya Blockchainler’e kendi başlarına bağlanma yeteneğinden yoksundur. Bu, belirli sonuçlara veya durumlara dayanarak yürütmeye çalışan akıllı sözleşmeler için çok sınırlı bir mevcut veri setiyle sonuçlanır. Bu temel konuyu hafifletmek için diğer kaynaklardan veri girişine izin vermek için Blockchainler’e bağlı bağlayıcıların geliştirilmesi, bir Oracle şeklinde mevcut olan birçok seçenekle sonuçlanmıştır. Bu Oracles; akıllı sözleşmeden veri talebini alan, arama yapan ve ilgili sonuçları derleyen merkezi bir 3. taraftır. Bu, bir anlamda halka açık bir merkezsizleşmiş Blockchain’in amacını yitirerek bu Oracles’lara büyük ölçüde güven duyulmasını gerektirir. Oracles, Blockchain’deki en zayıf halka haline gelir ve akıllı sözleşmelerin hatalı verilere bir cevap olarak yanlış bir işlem yürütmesine neden olabilecek manipülasyon veya kurcalamaya açıktır. Blockchainler’e gerçek zamanlı veriyi güvenilir ve doğrulanabilir bir şekilde sunan çok az seçenek vardır. Akıllı Sözleşmeler nedir? Bir akıllı sözleşme; merkezsizleşmiş bir Blockchain altyapısında yürütülen belirleyici, kurcalamaya karşı korumalı ve güvenilir bir dijital anlaşmadır. Akıllı sözleşmelerin iki nedenden dolayı standart, günlük sözleşmeler üzerinde üstünlüğü vardır. İlk olarak akıllı sözleşmeler; güvenilir, paylaşılan kayıtlardır. Bireysel tarafların tek bir doğruluk kaydının olmamasından dolayı birden fazla departmanın birbiriyle çelişen iş akışlarına sahip olduğu modern şirketler için bir nimet olan kendi yedek kopyalarını tutmalarına gerek olmadığından çok güvenlidirler. İkinci olarak akıllı sözleşmeler, oldukça belirleyicidir. Geleneksel senaryolarda sözleşmeler, hata veya isteksizlik dışında kararlaştırıldığı gibi yürütülmeyebilir. Akıllı sözleşmeler, tam olarak yazıldığı gibi yürütüldüğü ortamlarda çalıştırılır ve her adımda onay gerektirmez. Önceden belirlenmiş koşullar yerine getirilmişse, anahtar parametreler otomatik olarak yürütülür. Oracles nedir? Yukarıda bahsedildiği gibi Oracles, temel olarak bir Blockchain’i dış veri kaynaklarına, pazar yayınlarına veya web API'lerine bağlayan bir portaldır. Gerçek dünya pazarlarındaki ve web API'lerindeki veri yayınları, genellikle Blockchainler ve akıllı sözleşmeler gibi belirleyici değildir. Oracles, dış ve deterministik olmayan bilgileri bir Blockchain’in belirli koşulları anlayabileceği ve yürütebileceği bir formatta özümseyebilecek bir köprü görevi görür. < Resime gitmek için tıklayın > Aşağıdakiler dahil olmak üzere çeşitli Oracles biçimleri vardır: - Donanım Oracles - Yazılım Oracles - Konsensüs Oracles - Gelen Oracles - Giden Oracles Donanım Oracles, somut fiziksel nesnelerle entegre sensörlerdir. Birincil örnekler, ürünlerin çevresel koşulları gibi verileri Blockchain’e beslemek için RFID etiketlerinin kullanılmasıyla tedarik zinciri takibinde olacaktır. Yazılım Oracles, web API'leri gibi üçüncü taraf kaynaklardan veri çeken ve uçuş durumları ve hava durumu verileri gibi gerçek dünya bilgilerini içerebilen en yaygın formdur. Konsensüs Oracles, merkezsizleşmiş Oracles'e doğru bir adımı temsil eder ve özgünlüklerini ve doğruluğunu belirlemek için çeşitli Oracles'dan gelen verileri özel yöntemlerle toplamaya dayanır. Gelen Oracles, “bu fiyat bir varlık tarafından karşılanıyorsa, bir satış tetikle” gibi yazılım Oracles’ları ile ilgili “eğer bu gerçekleşirse bunu yap” senaryolarını yansıtır. Giden Oracles, akıllı sözleşmelerin üzerinde bulundukları Blockchain ağının dışındaki kaynaklara veri göndermesine olanak tanır ve aynı zamanda Yazılım Oracles’larıdır. Chainlink Çözümü Chainlink, akıllı bir sözleşmeyi tetikleyen bir Blockchain’e dahil edilmeden önce veri doğruluğunu tanımlayan ve doğrulayan merkezi olmayan bir Oracle ağı geliştirmiştir. Chainlink Blockchain, akıllı sözleşmeler tarafından yapılan bireysel veri taleplerine cevap veren oracle düğümlerinden oluşur. Blockchain sistemine 3 bileşen vardır: • İtibar Sözleşmesi • Emir Eşleştirme Sözleşmesi • Toplama Sözleşmesi İtibar Sözleşmesi, oracle servis sağlayıcı metriklerini depolamak ve izlemek için özel bir yöntem kullanır. Emir Eşleştirme Sözleşmesi, bir servis seviyesi anlaşması (Service Level Agreement - SLA) alır ve eş zamanlı olarak oracle sağlayıcılarından teklif alırken SLA'nın veri parametrelerini kaydeder. Toplama Sözleşmesi, oracle sağlayıcısının cevaplarını toplar ve ilk ChainLink sorgusunun son toplu sonucunu hesaplar. Temel olarak bir akıllı sözleşme, Chainlink aracılığıyla SLA şeklinde bir veri talebi yapacaktır ve bu, oracle düğümlerinin her birine yayınlanacaktır. Oracle düğümleri, verileri sağlayacak ve veri talebini tamamlamak için bir teklif sunacaktır. Tüm bunlar Emir Eşleştirme Sözleşmesi tarafından yönetilir, gönderilen veriler daha sonra farklı düğümlerden gelen birden fazla yanıtı karşılaştırarak Toplama Sözleşmesi aracılığıyla doğruluk için karşılaştırılır. Tamamlanan her bir SLA'dan kaynaklanan ilgili bilgiler, İtibar Sözleşmesine geri gönderilecektir ve sonuç olarak alınan teşviki etkileyen her bir düğümün itibarını değiştirir. SLA, kullanıcıların Oracles'ın itibarı veya kaç Oracle’ın dahil edilmesi de dahil olmak üzere istenen veri kümeleri için açık parametreler ve girdiler belirlemesine izin verdiği için bu sistemin temel bir bileşenidir. Zincir dışı verilerden zincir içi verilere geçiş, her bir oracle tarafından bilginin zincir dışından alınması ve doğrulama için zincir içine gönderilmesi ile tamamlanır. Bir veri talebini tamamlamak için kullanılan verilerine sahip olan Oracles, itibarlarına göre ağırlaştırılan LINK adı verilen Chainlink tokenleri ile sağlanır. < Resime gitmek için tıklayın > Hali hazırda Chainlink; Bitcoin, Ethereum ve Hyperledger gibi Blockchainler’in yanı sıra NASDAQ, Google Cloud, Oracle, SAP ve çoklu bankalar gibi diğer veri kaynaklarından da veri çekmektedir. Ek olarak Aelf ile bağlanarak sadece bu kaynakların herhangi birinden gelen veriler, Aelf Blockchain'deki akıllı sözleşmeleri tetiklemekle kalmaz; aynı zamanda Aelf Blockchain'deki veriler artık Ethereum veya Hyperledger gibi Blockchainler de dahil olmak üzere diğer platformlardaki olayları tetiklemek için kullanılabilir. İletişim birlikte çalışabilirlik anlamına mı geliyor? Birçok Blockchain’in geliştirmek istediği özelliklerden biri, çapraz zincir birlikte çalışabilirliğidir. İletişimi tartışırken bu kolayca Blockchain birlikte çalışabilirliği olarak yanlış yorumlanabilir ancak gerçekte onlar aynı şey değildir. Evet, birlikte çalışabilirlik Blockchainler arasında iletişim gerektirir ancak ayrıca bundan da fazlasını gerektirir. Aelf Blockchain, uygun Blockchain birlikte çalışabilirliği özelliğine sahip tam bir çözüm geliştiriyor ve bu, Chainlink’in oracle ağı ile çalışacaktır. KAYNAK:https://medium.com/aelfblockchain/aelf-blockchain-will-communicate-with-nasdaq-google-cloud-oracle-sap-ethereum-and-bitcoin-e6863f3b27a9 |
|
Aelf Teknik Konuşmalar: Bağımlılık Enjeksiyonu Bölüm 1 Yiqi Zhao tarafından yazılmıştır < Resime gitmek için tıklayın > Bağımlılık enjeksiyonu (dependency injection) nedir? Geliştirici topluluğu içerisinde, “bağımlılık” olarak adlandırılan bir konsepte sahibiz. Bir programın bir üçüncü parti kütüphanesini kullanması gerektiğinde, bu kütüphaneyi bağımlılık olarak adlandırılabilir. Fakat “enjeksiyon” nereden geliyor? Bir insana değer bulmak için karşıtına bakmanız gerektiği söylenir. Bağımlılık enjeksiyonunun karşıtı bağımlılık aramasıdır (dependency lookup). Bağımlılık enjeksiyonu ve bağımlılık araması, Kontrolün İnversiyonu (Inversion of Control - IoC) uygulamasının iki yoludur. IoC ve Bağımlılık Enjeksiyonunun temel amacı bir uygulamanın bağımlılıklarını ortadan kaldırmaktır. Bu, sistemi daha ayrışmış ve bakımlanabilir kılar. IoC İlk önce IoC'yi anlamaya çalışalım. Eski bilgisayar programlama günlerine geri dönerseniz program akışı, kendi kontrolünde çalıştırırdı. Örneğin, aşağıdaki akış şemasında gösterildiği gibi basit bir sohbet uygulaması akışını düşünelim. 1- Kullanıcı sohbet mesajı gönderir. 2- Uygulama, diğer taraftan gelen mesajı bekler. 3- Hiçbir mesaj bulunamazsa, 2. adıma gider ya da 4. adıma geçer. 4- Mesajı görüntüler. 5- Kullanıcı çalışmalarına devam eder. < Resime gitmek için tıklayın > Şimdi program akışını yakından analiz ederseniz, bu sıralıdır. Program kendi kendini kontrol ediyor. IoC, programın kontrol akışını yönetecek başka birine devrettiği anlamına gelir. Örneğin, sohbet uygulaması olayını temel alarak yaparsak programın akışı aşağıdaki gibi olacaktır: 1- Kullanıcı sohbet mesajı gönderir. 2- Kullanıcı çalışmalarına devam ediyor. 3- Uygulama olayları dinler. Bir mesaj gelirse, olay etkinleşir ve mesaj alınır ve görüntülenir. < Resime gitmek için tıklayın > Programın akışını görürseniz, sıralı değildir, olayı temel alır. Yani şimdi kontrol tersine çevrildi. Akışı kontrol eden dahili program yerine, olaylar program akışını yönlendirir. Olay akışı yaklaşımı, daha fazla esnekliğe yol açan dolaysız bir başvuru olmadığından daha esnektir. IOC'nin sadece olaylar tarafından uygulandığı sonucuna varmayın. Kontrol akışını geri arama delegeleri, gözlemci modeli, olaylar, DI (Bağımlılık enjeksiyonu) ve başka birçok yolla delege edebilirsiniz. DI (Bağımlılık enjeksiyonu) IOC'nin bir alt kümesi iken IOC genel bir ana terimdir. IOC, uygulama akışının ters çevrildiği bir konseptir. Daha önce bahsedilen iki yöntem, bağımlılık enjeksiyonu ve bağımlılık araması, her yerde kullanabileceğiniz yöntemlerdir. Servis konumlandırıcısını (service locator) Spring Framework’de duymuş olabilirsiniz. Şimdi Servis konumlandırıcısının bir model karşıtı olduğunu düşünen birçok öncüller vardır. Aslında Servis konumlandırıcısı, bağımlılık aramanın somut bir uygulamasıdır. Servis konumlandırıcısı ve bağımlılık enjeksiyonu fikri esasen zıt olmasına rağmen, MS.DI bağımlılık enjeksiyon yapısını uygularken Servis konumlandırıcısını kullanır. Eğer Spring’i kullanmadıysanız, sorun değildir. İkisi arasındaki ilişkiyi açıklamaya çalışalım. Açıkçası, Bağımlılık Enjeksiyonu temel olarak enjekte etme ile ilgilidir. Yığın Taşması (stack overflow) üzerine Bağımlılık Enjeksiyonu konusunda çok ilginç bir cevap vardır. Soru, beş yaşındaki bir çocuğa bağımlılık enjeksiyonunun nasıl açıklanacağıdır: Bir çocuk kendi başına buzdolabından bir şeyler çıkardığında, sorun çıkartabilir. Kapıyı açık bırakabilirler veya anne ya da babanın sahip olmasını istemediği bir şey alabilirler. Hatta sahip olmadıkları veya süresi dolmuş bir şeyi bile arıyor olabilirler. Yapmaları gereken şey “öğle yemeği ile içmek için bir şeye ihtiyacım var” gibi ihtiyacı belirtmek ve sonra ebeveyn, yemek için otururken bir şeylerinin olduğundan emin olacaktır. Bu yüzden doğru yaklaşım, çocuklara neye ihtiyaçları olduğunu sormaktır; o zaman buzdolabından bir şey bulur ve onlara veririz. Bir benzetme yapacak olursak buzdolabından bir şeyler alan çocuklar bağımlılık aramaya benzer; çocuklara yetişkinler olarak bir şeyler sunduğumuzda, bu bağımlılık enjeksiyonudur. Bağımlılık enjeksiyonunu ayrıntılı olarak tartışmadan önce, tasarım modellerinin beş prensibini gözden geçirmemiz gerekir (bazı yerler altı hatta yediden bahseder, ancak bunlar temel olarak beştir). Bu serideki 2. bölümde bu ilkelerin ilk çifti incelenecektir. KAYNAK:https://medium.com/aelfblockchain/aelf-tech-talks-dependency-injection-part-1-a95714f41042 |
< Bu mesaj bu kişi tarafından değiştirildi Kursa1903 -- 20 Eylül 2019; 10:45:59 >
|
Aelf, Huawei Cloud'a Teknoloji Partneri Olarak Katıldı ve Dijital Dönüşüme Yardımcı Olmak için 2019 Huawei Connected Konferansına Davet Edildi! Telekom endüstrisinde bir Blockchain sağlayıcısı olarak Aelf iş birlikleri konusunda Huawei ile görüşmelerde < Resime gitmek için tıklayın > 18 Eylül 2019'da üç günlük Huawei Connect 2019 Konferansı (HC2019), Şangay Dünya Fuar Kongre ve Gösteri Merkezi'nde ve Şangay Dünya Fuar Gösteri Salonu'nda başladı. Bu konferansın konusu “Gelişmiş Akıl, Aklın Yeni İrtifalarını Sağlar” idi. Açılış konuşmaları, yuvarlak masa toplantıları ve alt forum tartışmaları; Huawei Cloud, Akıllı Bilişim, Bağlantı, Ağ Güvenliği, Akıllı Şehirler, Akıllı Ulaşım, Akıllı Finans, Geliştirici ve Kurumsal Hizmetler ve Devlet İşleri ve Eğitim konusundaki konuşmalar için bir platform sağladı. Bir Huawei Cloud teknoloji ortağı olarak Aelf, Huawei Connect 2019 Konferansı’na ve Akşam Yemeği'ne katılmak üzere davet edildi. Liang Chen (Huawei Cloud Global Partner İş Birimi Başkanı), Lim Chee Siong (Huawei Cloud Güney Pasifik bölgesinin Baş Pazarlama Yöneticisi), Kevin Teoh (Huawei Cloud Asya Pasifik İş Geliştirme Direktörü) ve Justin Ching Lee (Huawei Cloud Global Partner İş Birimi Menajeri) yemeğe katıldı. Nancy Yan (Huawei Cloud Asya Pasifik Partner İş Birimi Başkan Yardımcısı), Aelf’i bizzat memnuniyetle karşıladı ve katıldıkları için Aelf ekibine teşekkür etti. Aelf Kurucu Ortağı & COO’su Zhuling Chen, akşam yemeğinde Huawei Cloud Teknoloji Partnerlerinin bir temsilcisi olarak kısa bir konuşma yaptı. “Aelf'in HC2019 endüstri festivaline Huawei Cloud teknoloji ortağı olarak katılması için davet edildiğinden dolayı çok mutluyum. Akıllı dünyanın hızlanmasıyla birlikte, gittikçe daha fazla işletme ve devlet kurumu aklın değerini ve önemini fark etmektedir. Endüstrinin önde gelen merkezi olmayan bulut bilişim platformu olarak Blockchain bulut hizmetlerinin iş birliğini keşfetmek ve optimize etmek, güvenilir bir dijital ekonominin temel taşını oluşturmak ve işletmeler için daha güvenli hizmetler sunmak için Huawei Cloud ile çalışmayı umuyoruz. Güvenilir, verimli ve yüksek kaliteli Blockchain bulut hizmetleri; işletmelerin katlanarak büyümesini mümkün kılıyor.” Zhuling, Blockchain’in Telekomünikasyon Operatörlerine hizmet etme potansiyeli hakkında Liang Chen (Huawei Cloud Global Partner İş Birimi Başkanı) ile uzun bir görüşme yaptı. Aelf, dünya çapında birkaç önde gelen Telekomünikasyon Operatörü ile görüşmelerde bulundu ve Huawei, global olarak Telekomünikasyon Operatörleri için en büyük global yazılım ve donanım sağlayıcısıdır. Bu partnerlik, iki tarafın da uzmanlıklarını geliştirmeleri için karşılıklı olarak yararlı olacaktır. Huawei Cloud’un çapraz zincir projesine dahil edilen aelf Enterprise 0.7.0 Beta; tam bir Blockchain sistemi, geliştirme kitleri için destek, web araçları ve programları için destek gibi özelliklere sahiptir. Geliştiriciler; sağlanan geliştirme kitleri ve araçlarına dayalı olarak uygulamaları hızlıca dağıtabilir. Ek olarak Aelf, kullanıcıların işletmelere ve geliştiricilere kolayca güçlü uygulamalar geliştirmelerine yardımcı olmak için iş mantığını ve uygulama geliştirmeye odaklanmalarını sağlayan bir rehber öğretici sunar. < Resime gitmek için tıklayın > Aelf, iş dünyasının kendi kendini geliştirmesi ve refahını ilerletmek için teknoloji ve ileriye dönük bir endüstri perspektifinden yararlanır. Huawei ve Aelf, kurumsal müşterilerine hizmet etmede iş birliği için daha fazla fırsat keşfetmeye devam edecektir. Sektördeki konumumuzu derinleştirip teknolojik avantajları sağlayarak Aelf, Huawei Cloud ile olan geniş kapsamlı iş birliğimizi daha da güçlendirecektir. Aelf Enterprise Huawei Cloud Adresi -->https://marketplace-intl.huaweicloud.com/product/00301-129125-0--0 KAYNAK:https://medium.com/aelfblockchain/aelf-joins-huawei-cloud-as-technology-partner-invited-to-2019-huawei-connected-conference-to-aid-ac97b095886b |
|
Aelf Teknik Konuşmalar: Bağımlılık Enjeksiyonu Bölüm 2 SOLID Tasarım İlkeleri < Resime gitmek için tıklayın > Bu serinin 1. bölümünde Bağımlılık Enjeksiyonu ve IoC tartışıldı. Bağımlılık Enjeksiyonu derinlemesine girmeden önce, nesne yönelimli tasarım modelinin beş SOLID ilkesini anlamak önemlidir. Bu bölümde ilk üç ilke incelenecektir. 1) Tek Sorumluluk İlkesi (SRP, Single Responsibility Principle) > Bir sınıfın değişmesi için hiçbir zaman birden fazla sebep olmamalıdır. Bir şaka duymuş olabilirsin: - Hata olmadan kod yazdın mı? - Evet, daha önce yaptım: Merhaba Dünya. Bu paragraf bize doğruyu söyler: kod ne kadar basitse, bir hata olması o kadar az olasıdır. Peki kodu nasıl basitleştiririz? Her kod satırını yazarak tek bir şey yapmak için. Uygulamada, bir sınıfın sadece bir şey yapmasına izin verdik. Ve eğer bu sınıfa basit ve sezgisel bir isim verebilirsek, kodun kendisinin bildirilmesi çok iyi olacaktır. Alibaba’nun Java spesifikasyonunun, bir sınıfın bir tasarım deseni kullanıyormuş gibi adlandırma için gereksinimleri olduğunu hatırlıyorum. Tasarım deseninin adını ismin içinde yerleştirmek gerekir. Şu anda, yorumlar gereksizdir ve kod insanların okuması ve bakımı için kolaydır. Tek sorumluluk ilkesinin tanımına geri dönelim. Martin, bir sorumluluğu değişimin nedeni olarak tanımlar ve bir sınıf veya modülün değiştirilmek üzere bir ve yalnızca bir nedeni olması gerektiği sonucuna varır (yani yeniden yazılması). Örnek olarak, bir rapor derleyen ve yazdıran bir modül düşünün. Böyle bir modülün iki nedenden dolayı değiştirilebileceğini hayal edin. İlk olarak, raporun içeriği değişebilir. İkincisi, raporun formatı değişebilir. Bu iki şey çok farklı nedenlerle değişir. Tek sorumluluk ilkesi, sorunun bu iki yönünün gerçekten iki ayrı sorumluluk olduğunu ve bu nedenle ayrı sınıf veya modüllerde olması gerektiğini söylüyor. Farklı zamanlarda farklı nedenlerle değişen iki şeyi birleştirmek/eşleştirmek, kötü bir tasarım olacaktır. Bir sınıfı tek bir endişeye odaklamanın önemli olmasının nedeni, sınıfı daha sağlam ve güçlü kılmasıdır. Yukarıdaki örnekten devam edersek rapor derleme işleminde bir değişiklik olursa, aynı sınıfın bir parçasıysa yazdırma kodunun kırılması daha büyük bir tehlikedir. Ayrıca bir sınıfın tek sorumluluk ilkesine uygun olup olmadığına karar vermek için bir standart vardır. Bu, sınıftaki öğelerin uygunluğuna bağlıdır. Bir yineleyici uygulayan bir sınıfta yazma fonksiyonuna sahip olamazsınız. Bunun hakkında düşünmeyin. En önemseyeceği panonun boyutunu kontrol etmesidir. Başka bir deyişle, panonun kendisi yineleyicilerin sınıfına dahil edilmemeli, yalnızca bir hizmet olarak var olmalı ve Depo modunu kullanmayı düşünebilirsiniz. Yüksek korelasyon, yüksek uyum ve işlevde daha küçük bir granülite anlamına gelir. Burada belirtilen sınıf, bir varlığa veya bir servise başvurabilir. Domain-driven Design kitabında Eric, uygulamadaki nesneleri üç türe ayırır: değerler, varlıklar ve hizmetler. Bir varlık, değerlerin bir kombinasyonu olarak düşünülebilir ve bir hizmet, iş mantığını içeren koddur. 2) Açık Kapalı Prensibi (Open Closed Principle - OCP) > Sınıflar, modüller ve fonksiyonlar gibi yazılım varlıkları; uzantı için açık olmalı ancak varlığın kaynak kodunu değiştirmeden davranışının genişletilmesine izin verebilecek şekilde değişikliklere kapalı olmalıdır. Açık Kapalı Prensipten bahsedersek bu, dekoratör modeli aracılığıyla anlaşılması özellikle kolay olan bir tasarım desenidir. Bir senaryo hayal edebiliriz. Bir süpermarkette yazarkasa sistemi veya bir e-ticaret web sitesi yapıyoruz. Her halükârda emtia varlığı vardır. Emtia varlığı, bir GetPrice (FiyatAl) yöntemine sahiptir ve şimdi ürüne bir indirim işlevi eklemelisiniz. Malın sınıf kategorisinin tek sorumluluk prensibine uygun olduğunu varsayarsak, şu anda üç seçenek vardır: 1. Şimdi ihtiyacınız olan işlevselliği sağlamak için arayüze bir yöntem ekleyin. 2. Sınıfın uygulamasını modifiye edin ve yeni özellikler imzalamak ve sağlamak için önceki yöntemi kullanın. 3. Bir sınıfı tekrar oluşturun, önceki uygulama sınıfını kalıt alın (inherit), önceki yönteme bir katman yerleştirin ve yeni bir uygulama sağlayın. Açık Kapalı Prensibi, üçüncü çözümü seçmemizi önerir. Bunun nedeni arayüzü modifiye ederek, bu arayüzü uygulamak isteyen diğer sınıfların uygulamayı eklemesi gerekir. Bu yeni uygulamanın gereksiz olması muhtemeldir, çünkü tüm ürünler için aynı gün içerisinde indirim yapılması muhtemel değildir. İkinci çözüm, sadece tehlikeli bir operasyondur. Kesinlikle birim testini etkileyecektir (eğer varsa) ve hataların ortaya çıkması gibi büyük bir olasılık vardır. Üçüncü seçenek en güvenli olanıdır. Önceki uygulama için bir dekoratör sağlayabiliriz ve ardından yeni işlevsellik sağlamak için dekoratör çağırabiliriz. Önceki örnekte önceki uygulama, ürünün orijinal fiyatını dekoratörün “indirim dekoratörü” olarak adlandırdığı şeyi döndürmektir ve daha sonra indirimli fiyatı döndürmek için aynı yöntemi çağırır. Önceki uygulama, yapıcı parametreleri vasıtasıyla dekoratöre enjekte edilir. Gerçek kullanım o kadar basit olmayabilir ancak bu, prensibin basit bir açıklamasıdır. Daha sonra enjeksiyonun birleşik kökü hakkında konuştuğunuzda, tekrar Açık Kapalı Prensipten bahsedeceksiniz. 3) Liskov'un Yerine Geçme Prensibi (Liskov Substitution Principle - LSP) > Temel sınıflara işaretçiler veya referanslar kullanan fonksiyonlar, türetilmiş sınıfların nesnelerini bilmeden kullanabilmelidir. Bu en gözden kaçan prensiplerden biri gibi görünüyor. Sorunlara neden olan “is a” tekniğinin klasik örneği daire-elips problemidir (ya da dikdörtgen kare problemdir). Ancak, ben penguen kullanacağım. İlk önce, gökyüzünde uçan kuşları gösteren bir uygulama düşünün. Birden fazla kuş türü olacaktır ve bu nedenle geliştirici, yeni kuş türlerinin eklenmesiyle ilgili kodu “kapatmak” için Açık Kapalı Prensibini kullanmaya karar verir. Bunu yapmak için, aşağıdaki soyut Kuş temel sınıfı oluşturulur: < Resime gitmek için tıklayın > BirdsFlyingAroundApp sürümünün büyük bir başarıdır. İkinci versiyon, kolaylıkla başka 12 farklı kuş türünü ekler ve ayrıca bir başarıdır. Yaşasın Açık Kapalı Prensibi! Ancak, uygulamanın üçüncü sürümü penguenleri desteklemek için gereklidir. Geliştirici, Kuş sınıfından kalıt alan yeni bir Penguen sınıfı yapar, ancak bir sorun vardır: < Resime gitmek için tıklayın > Bir geçersiz kılma yöntemi hiçbir şey yapmazsa veya yalnızca bir istisna atarsa, muhtemelen LSP'yi ihlal ediyorsunuzdur. Uygulama çalıştırıldığında tüm uçan modeller yanlış görünür, çünkü Penguen nesneleri setAltitude yöntemini önemsemez. Penguenler sadece yerde dolaşıyorlar. Geliştirici OCP'yi izlemeye çalışsa da başarısız oldu. Penguen sınıfına uyması için mevcut kodun modifiye edilmesi gerekir. Bir penguen teknik olarak “kuş” iken, Kuş sınıfı tüm kuşların uçabileceğini varsaymaktadır. Penguen alt sınıfı uçuş varsayımını ihlal ettiğinden, Kuş sınıfı için Liskov'un Yerine Geçme Prensibi’ni karşılamıyor. LSP'yi İhlal Etmek Neden Kötüdür? Soyut bir temel sınıf kullanmanın amacı; gelecekte yeni bir alt sınıf yazıp mevcut, çalışan ve test edilmiş bir koda ekleyebilmenizdir. Açık Kapalı Prensibinin özü budur. Ancak, alt sınıflar soyut temel sınıfın arayüzüne uygun bir şekilde bağlanmadığında, mevcut alt kodu gözden geçirmeniz ve hatalı alt sınıfları içeren özel durumları hesaba katmanız gerekir. Bu, Açık Kapalı Prensibinin açıkça ihlalidir. Örneğin, bu kod parçasına bir bakınız: < Resime gitmek için tıklayın > LSP, kodun Kuş nesnesinin gerçek sınıfını bilmeden çalışması gerektiğini söylüyor. Ya devekuşu gibi bir başka uçamayan kuş türü eklemek isterseniz? O zaman mevcut tüm kodunuzu gözden geçirmeli ve Kuş işaretçilerinin gerçekten Devekuşu işaretçisi olup olmadığını kontrol etmelisiniz. İki Olası Çözüm Mevcut kodu modifiye etmeden Penguen sınıfını ekleyebilmek isteyebiliriz. Bu, kötü kalıtım hiyerarşisini LSP'yi karşılayacak şekilde düzelterek sağlanabilir. Sorunu çözmenin çok iyi olmayan bir yolu, isFlightless adlı Kuş sınıfına bir yöntem eklemektir. Bu şekilde, en azından OCP'yi ihlal etmeden uçamayan kuş sınıfları eklenebilir. Bu, şöyle bir kodla sonuçlanacaktır: < Resime gitmek için tıklayın > Bu gerçekten geçici bir çözümdür. Temel sorunu çözmedi. Sadece sorunun belirli bir nesne için var olup olmadığını kontrol etmenin bir yolunu sağlar. Uçamayan kuş sınıflarının uçan sınıfları üst sınıflarından kalıt almadığından emin olmak daha iyi bir çözüm olacaktır. Bu böyle yapılabilir: < Resime gitmek için tıklayın > Kuş temel sınıfı, herhangi bir uçan işlevsellik içermez ve FlightfulBird alt sınıfı, bu işlevselliği ekler. Bu, bazı işlevlerin hem Kuş hem de UçanKuş nesnelerine uygulanmasına izin verir. Ancak, uçamayan olabilecek Kuş nesneleri, FlightfulBird nesnelerini alan işlevlere dönüştürülemez. Bu serideki bir sonraki bölümde, Bağımlılık Enjeksiyonunun son bölümü daha ayrıntılı olarak tartışmadan önce kalan 2 prensip incelenecektir. KAYNAK:https://medium.com/aelfblockchain/aelf-tech-talks-dependency-injection-part-2-c2525376e8e8 |
|
Aelf, BTCManager ile partnerlik kurdu. Yeni partnerlik ile birlikte artık Aelf ile ilgili tüm haberlerihttps://btcmanager.com/ adresinde bulabilirsiniz. < Resime gitmek için tıklayın > |
|
aelf Enterprise (Kurumsal) 0.8.0 Beta Resmi Olarak Yayınlandı < Resime gitmek için tıklayın > aelf Enterprise 0.8.0 beta; bütün bir blockchain sistemi, geliştirme kitleri, geliştirme belgeleri ve destekleyici altyapı ve altyapı hizmetlerini içeren eksiksiz ve tam bir blockchain ticarileştirme çözümü setidir. aelf Enterprise 0.8.0 beta sürümü sistem entegrasyonu 1. aelf Enterprise • aelf Enterprise v0.8.0 beta • DevKit v0.8.0 beta 2. aelf Harici Uygulamalar • aelf blockchain tarayıcı v0.1.6 • aelf tarayıcı MySQL plugin v0.8.0 beta • aelf kaşifi v0.8.0 beta • aelf cüzdan v0.8.0 beta • aelf JS SDK v3.2.17 • aelf JS SDK Çapraz Zincir v1.0.1 • Nodejs v0.1.15’te aelf CLI 3. aelf Tarayıcı Uzantısı V0.8.0 beta Aelf Enterprise 0.8.0 beta sürümünün Aelf Enterprise 0.8.0 alfa sürümüne kıyasla önemli özellikleri şunlardır: • Geliştirilmiş stabilite • Daha eksiksiz ekonomik sistem • Çapraz zincir kabiliyetinin tam seti • Daha eksiksiz çapraz zincir destek araçları Bu güncelleme ve önemli özellikleri aelf Enterprise v0.8.0 beta: AEDPOS Konsensüs Mekanizması: • Rastgele blok sırası • Üretim bloğu mantığı • Konsensüs doğrulama ve hile cezası Ekonomik sistem: • Teklif ve çoklu imzalama mekanizması • Üç oylama modeli (parlamento oyu / birlik oyu / referandum) • Bancor tabanlı TOKEN (çoklu varlık) ticareti • Düğüm seçimi oylama / değiştirme • Temettü / ödeme mekanizması Ana zincir: • P2P ağı ve düğüm yönetimi • Ticaret havuzu • Zincir yönetimi • Blok / işlem doğrulama ve yönetimi • Veri depolama • WebAPI arayüzü • Komut satırı arayüzü • SDK geliştirme (Javascript) Çapraz zinciri: • Alt zincir ve ebeveyn zincir indeksleme mekanizması • Çapraz zincir doğrulama ve çapraz zincir transfer Sözleşme sistemi: • Çalışma süresi (Runtime) • Sözleşme Geliştirme SDK • Sözleşme güvenlik kontrolü • Sözleşme geliştirme standardı (acs) Paralel yürütme: • Kaynak algılama ve gruplama • Gruplar arasında paralel yürütme • Çatışma yönetimi DevKit: Geliştirici Belgeleri • Yeni düğüm yapısı • Yeni çapraz sözleşme çağrıları • CLI kullanım belgeleri güncellendi • WebAPI kullanım belgeleri güncellendi, RPC ile ilgili belgeler kaldırıldı aelf Harici Uygulamalar güncellemesi: aelf Cüzdanı: • Çoklu token durumunda işlem kaydı sorgusunun hatası düzeltildi aelf Kaşif: • Arayüz yeniden yapılandırma, yüzlerce milisaniyede arayüz yanıtı • Mantığın kısmı websocket kullanılarak optimize edilmiştir • İşlem kaydı sorgu optimizasyonu aelf JS SDK Çapraz Zincir: • Çapraz zincir JS SDK eklendi Nodejs’de aelf CLI • Yeni teklifle ilgili yöntemler eklendi Entegrasyon özelliklerine giriş: 1. aelf Enterprise • aelf Enterprise v0.8.0 betahttps://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 — Boilerplatehttps://github.com/AElfProject/aelf-boilerplate — TestKit — BenchmarkKit — IDE entegrasyonu — Belgelerhttps://docs.aelf.io/ — Öğreticilerhttps://docs.aelf.io/main/main 1.1 aelf Enterprise v0.8.0 beta Minimize edilmiş blok zinciri kerneli, DPoS konsensüs mekanizması, akıllı sözleşme sistemi, oylama sistemi, token sistemi ve temel çapraz zincir sistemi dahil olmak üzere tam bir blok zincir sistemidir. 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 Zincirdeki herhangi bir verinin zincir boyunca iletecek bir mekanizma sağlar. Sistem, Merkle Ağaç Kökü endeksine dayanarak uygulanır ve tüm sistem çok seviyeli ana yan zincir endeksini gerçekleştirebilir, böylece ölçeklendirme ve dağıtıklaştırma gerçekleştirilebilir. Web API ASP.Net Çekirdek sunucusu, yüksek performanslı etkileşimli bir yapı gerçekleştirmek için uygulanmaktadır. 1.2 DevKithttps://github.com/AElfProject/aelf-boilerplate 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 Aelf tarafından sağlanan geliştirme kitlerine ve araçlarına dayalı olarak Dapp‘ler oluşturabilirler. ve Aelf’i geliştirici dokümantasyonu aracılığıyla hızlıca tanımaya başlayabilirler. 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ı ile eklemek gerekir, topluluk varsayılan MySQL ekleme sürümü olarak aelf-scan-MySQL sağlar. Aelf Tarayıcı MySQL eklentisihttps://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âşifihttps://github.com/AElfProject/aelf-block-explorer • Blok ve işlem sorguları uygulandı 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 Aelf JS SDKhttps://github.com/AElfProject/aelf-sdk.js • Aelf'in çapraz link/bağlantı transfer arayüzü, geliştiricilerin hızlı bir şekilde başlamasını kolaylaştırmak için kısa ve öz biçimde açıklanmıştır. Nodejs’de Aelf CLIhttps://github.com/AElfProject/aelf-command • Çok fazla sayıda komut istemi sağlanır. • 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-0-8-0-beta-officially-released-38b41622893e |
|
Aelf Teknik Konuşmalar: Bağımlılık Enjeksiyonu Bölüm 3 < Resime gitmek için tıklayın > ## Arayüz Ayrıştırma Prensibi (Interface Segregation Principle - ISP） > İstemciler, kullanmadıkları arabirimlere bağımlı olmaya zorlanmamalıdır. Bir sınıfın diğerine bağımlılığı asgari düzeyde olmalıdır. Bu prensibi izleyerek, birden fazla sorumluluk için yöntemleri tanımlayan şişirilmiş arayüzleri önlersiniz. Tek Sorumluluk Prensibinde açıklandığı gibi, sık sık değiştikleri ve yazılımınızın bakımını zorlaştırdığı için çoklu sorumluluk içeren sınıflardan ve arayüzlerden kaçınmalısınız. Bir çapraz sözleşme çağrısı için Aelf ekibi, AElf Sözleşme Standardı (ACS) adlı bir sözleşme standardı sağladı ve her bir ACS bazı Arayüz tanımlar. Çapraz sözleşme çağrısı yaparken, belirli bir ACS'de hangi arabirimin tanımlandığı konusunda endişelenmenize gerek yoktur. Yalnızca istenen ACS'yi uygulayan bir sözleşme sağlamanız gerekir. Öte yandan her bir sözleşme, birden fazla ACS uygulayabilir. Diğer sözleşmeler tarafından çağrıldığında, yalnızca uyguladığı ACS'lerden biriyle ilgilenebilir. Böylece yalnızca bu ACS'ye dayanırsınız ve bu sözleşmeyi almazsınız. Diğer yöntemler, çapraz sözleşme çağrılarına maruz kalmaktadır. Bu sadece arayüz izolasyonu prensibinin bir açıklamasıdır. Bağımlılık İnversiyon Prensibi (Dependency Inversion Principle - DIP） > Yüksek seviyeli modüller düşük seviyeli modüllere bağlı olmamalıdır. Her ikisi de soyutlamalara bağlı olmalıdır. Soyutlamalar, detaylara bağlı olmamalıdır. Detaylar, soyutlamaya bağlı olmalıdır. Bu tanımın önemli bir detayı, yüksek seviye ve düşük seviye modüllerinin soyutlamaya bağlı olmasıdır. Tasarım ilkesi, adını ilk defa okurken beklediğiniz gibi sadece bağımlılığın yönünü değiştirmez. Aralarında bir soyutlama tanıtarak yüksek ve düşük seviye modülleri arasındaki bağımlılığı böler. Sonuçta iki bağımlılık elde edersiniz: 1.Yüksek seviye modülü, soyutlamaya bağlıdır 2.Düşük seviye, aynı soyutlamaya bağlıdır Bu, olduğundan daha karmaşık gelebilir. Sonuç olarak Açık/Kapalı Prensibini ve Liskov'un Yerine Geçme Prensibini kodunuza uygularsanız, Bağımlılık İnversiyon Prensibi'ni de takip eder. Bir kelimeyle: arayüz odaklı programlama. Arayüzü daha düşük-seviye modülüne koyabilir ve daha sonra bu arayüzün üst-seviye modülde uygulanmasını sağlayabiliriz. Farklı üst seviye modüller arasındaki iletişim, temel modüllerdeki arayüzlerle de yapılır. Örneğin, Log’u yüksek seviye bir modül olarak ele alıyoruz. Temel modülde farklı log seviyelerinin yazdırılması için bazı yöntemler sağlayan tek bir ILogger arayüzü vardır. Özel yazdırma uygulaması log modülüne yerleştirilir. Diğer modüller kayıt yapmak için log modülüne dayanabilir, NLog kullanabilirsiniz, ayrıca log4net kullanabilirsiniz, log modülü bir bağımlılık haline gelir ve hangisini kullanacağımız bu bağımlılığı manuel olarak nasıl enjekte ettiğimize bağlıdır. Peki nasıl enjekte ediyorsunuz? Daha sonra Bileşim Kökünü (Composition Root) tartışacağız. Örnek projede gördüğünüz gibi, yalnızca Açık/Kapalı ve Liskov'un Yerine Geçme Prensiplerini kod tabanınıza uygulamanız gerekir. Bunu yaptıktan sonra sınıflarınız, Bağımlılık İnversiyon Prensibi'ne de uyar. Herhangi bir arayüz soyutlamasını değiştirmediğiniz sürece bu, diğer sınıfları etkilemeden daha yüksek ve daha düşük bileşenleri değiştirmenizi sağlar. # DI, IoC ve DIP arasındaki fark Buradaki DI, DI kapsayıcı değil DI teknolojisidir. Autofac, Ninject, vb. geliştirilmesinde kullandığımız bağımlılık enjeksiyon yapısı, DI kapsayıcına aittir. Bileşim Kökü, bir tasarım desenidir. Bu tasarım desenini kullanmanın anahtarı, Bileşim Kökünün bulunduğu yeri bulmak zorunda olduğumuzdur. Neyse ki, öncekiler bize bir çözüm verdi: uygulama giriş noktasına mümkün olduğu kadar yakın… Peki Bileşim Kökü ne içindir? Kısacası, yapılandırma, bu yanıltıcı olabilir, ancak birleşik kök bir DI kapsayıcısıdır- başka bir deyişle, bağımlı bir ilişki kurar. Yani, bu uygulamada hangi soyut tipin hangi özel tipe tekabül ettiği, bileşim kökünde bir şekilde ayarlanması gerektiğidir. Burada belirtilen soyut tip, C#'da bir arayüz veya soyut bir sınıf olabilir. Aslında, DI uygulama pratiğinde bu şekilde soyutlama yapmak önemli değildir. Soyut türünü yalnızca belirli Tür bağımlılıklarına karşılık gelecek şekilde birleşik kökte ayarlamamız gerekir. Bu ayar doğrudan DI kapsayıcısındaki Register veya AddSingleton gibi yöntemleri çağırabilir. Ancak DI teknolojisinin uygulanması, mutlaka bir DI kapsayıcısının kullanılmasını gerektirmez. Kombinasyon kökleri kavramını "sondan başlayarak" bakış açısıyla yeniden düşünüyoruz: Üretim için kullanılabilecek eksiksiz bir uygulamanın çok sayıda hizmet içermesi gerektiği düşünülebilir ve bu uygulamanın uygulanmasının gevşek bir şekilde birleştirilmesini istiyorsak, arayüz izolasyon prensibi kullanılacaktır. Bir servisteki diğer servisleri kullanmamız gerektiğinde, kodu yazarken hangi servislerin uygulanacağını bilemeyiz, bu nedenle kodda doğrudan bir soyutlama çağırırız. Uygulama çalıştıktan sonra, soyuta yapılan asıl çağrıdan önce bir montaj süreci olmalıdır. Sözde derleme, koddaki soyut türe dayanır ve çalışma zamanında somut bir uygulama sağlar; bu da soyut türler ve belirli türler arasında manuel olarak bir haritalama ilişkisi kurmamızı gerektirir. Birleştirilen kök, ilişkinin manuel olarak sağlandığı yerdir. En kolay konsol uygulaması, çalıştırmak için her bir bileşen arasında iş birliği gerektirecektir. Temel bileşenlere dayanan birçok türde üst düzey bileşen vardır. Şu anda en yaygın kullanılan, yapıcı enjeksiyonudur. Uygulanabilir yapıcı enjeksiyonuna bir arayüz atamazsınız, manuel olarak yeni bir uygulama oluşturmanız gerekir. Bu işlem, soyut türü ve belirli bağımlılık türlerini ayarlamaktır. Açık Kapalı Prensibe tekrar bakıyoruz, belirli bir fonksiyonun modifiye edilmesi gerektiğinde, orijinal uygulamayı değiştiremeyiz, ancak dekorasyon modu ile bir realizasyon sağlayabiliriz ve daha sonra kombinasyon kökünde yeni bir uygulamaya ilgili bağımlılığı ayarlayabiliriz. Sadece kodu eklemeniz ve kombinasyon kökünü değiştirmeniz yeterlidir. Yeni uygulamanın sorunları varsa, eski uygulamanın gerekli olmadığını öğrenene kadar istediğiniz zaman geri çekebilirsiniz. Bu gereksiz ilişkiyi ortadan kaldırmak için bir yeniden düzenleme adımı uygulanmaktadır. İnsanlar, özellikle çalışmalarını başkalarıyla uzlaştırdıklarında, güvenilmez olabilirler. Bu nedenle, yeniden yapılanmadan önce yeterli birim testi eklememiz ve hatta uygulama öncesi birim testleri yazmamız gerekiyor. Test Odaklı Tasarım, birim testinin önce yazılmasını gerektirir, ünite testi başarısız olursa, test başarılı olana kadar uygulama güncellenir. Ancak yazılım geliştirme burada sona eriyorsa, Test Odaklı değil, yalnızca İlk Test Tasarımı olarak adlandırılabilir. Tasarımın özü yeniden yapılanmadır ve tatmin edici bir düzeye dek ayrıklaştırmadır ve test durumu, yeniden yapılanmanın fonksiyonu bozmayacağının önemli bir garantisidir. Bu serinin başında da belirtildiği gibi DI, aslında bir IoC uygulamasıdır, ancak IoC kavramı önerdiği bakış açısına göre daha da yönlendirilmiştir. Birçoğu Hollywood ilkesini duydu: beni arama, ben seni çağıracağım. Bu bir bağımlılık modülü olarak somut bir türdür. Ne zaman ve nasıl çağrılacaklarını önemsemelerine gerek yoktur sadece kendilerinin çağrılması için beklemeleri gerekecektir. Son olarak SOLID'deki DIP, üst seviye modüllerin temel modüllere dayanmaması, hepsinin soyutlamaya dayanması gerektiğini gösterir. Bu açıdan DIP, soyutlamanın derecesine fazla dikkat eder. Yani, özel uygulama ve kodun şekli budur. Ancak aşağı yukarı bu üç kavramın bir fikri ifade ettiğini, rafine edilmesi gereken bir şey varsa arayüz odaklı programlama olduğunu düşünebiliriz. Arayüzü en alta koymak için uygulama en üste yerleştirilir. KAYNAK:https://medium.com/aelfblockchain/aelf-tech-talks-dependency-injection-part-3-2c89a6159056 |
|
💰Yorum Yap & Kazan!💰 📢 Haftalık Dapper (The Dapper Weekly) Twitter Giveaway burada! 1️⃣ Takip et 2️⃣ Retweetle & Beğen 3️⃣ Favori bölümünü yorum olarak belirt (Tüm bölümler tweet altındadır) ⭐️ Bu Giveaway'e sponsor oldukları için Aelf Blockchain'e, State Of The DApps'e ve Dapp Review'a çok teşekkür ediyoruz! Tweet:https://twitter.com/mappopk_crypto/status/1181444710943969281 < Resime gitmek için tıklayın > |
|
Aelf Teknik Konuşmalar: Bağımlılık Enjeksiyonu Bölüm 4 Bağımlılık Enjeksiyonunun (Dependency Injection - DI) Üç Boyutu < Resime gitmek için tıklayın > Bu son bölümde, her biri tamamlayıcı olan bağımlılık enjeksiyon teknolojisinin üç boyutu hakkında kısaca konuşacağız. 1) Nesne kombinasyonu Birleştirilmiş kök, bağımlılıkları yapılandırır. 2) Yaşam Döngüsü Yönetimi Yalnızca kombinasyon kökünün bağımlılığı belirleyen yerleşim olduğunu söyledik. Aslında bağımlılığı ayarlarken bağımlılık enjeksiyonu, ayrıca her nesnenin yaşam döngüsünün yönetilmesini gerektirir. DI uygulanırken, bağımlılıkların birleştirilmiş kök içerisinde ayarlandığını zaten biliyoruz. Ayrıca birleşik nesnenin nesnesine veya yöntemine kompozitör olarak başvurabiliriz. Birleştirici, düzeneğin dayandığı nesneyi ifade eden birleşik bir terimdir. Veya yöntem. Genel olarak bir DI kapsayıcısı, bir birleştiricidir. Birleştiricinin varlığından dolayı nesne, bağımlılıklarının oluşturulmasını yönetmemeye mahkumdur. Bağımlılığın tahribi nedir? Bağımlılıklar zamanında tahrip edilmezse, bellek sızıntısı riski vardır. .NET kullanan herkes GC'nin otomatik olarak kullanılmayacak nesneleri geri kazanacağını bilir ve IDisposable arayüzünü uygularsak, nesneleri kendimiz imha edebiliriz. DI'de, bir nesnenin yaşam döngüsü bir birleştirici tarafından yönetilir. Birleştirici, bağımlı bir nesnenin diğer farklı nesnelerle paylaşılıp paylaşılmayacağına veya nesneyi ne zaman serbest bırakacağına karar verebilir: belirli bir tüketicinin kapsamı dışında mı yoksa tüm tüketicilerin rolü ötesinde mi bırakılacağına karar verebilir. Nesne yaşam döngüsünün yönetimi, bağımlılık enjeksiyonunda en karmaşık problemlerden biri olmalıdır. Bağımlılık enjeksiyonunun uygulanmasını desteklemek için Uzantılar adlı Microsoft’un Repo’suna göz atalım. Bu proje, tüm nesnelerin “ServiceLifetime” da tanımlanan üç yaşam tarzına sahip olduğunu belirtir. Kelimenin kendisi yaşam tarzı ya da iş tarzı anlamına gelir ve bir yaşam döngüsü türüne çevrilmiş gibi görünmektedir. Bu üç yaşam döngüsü tipi, DI kapsayıcısı perspektifinde daha iyi anlaşılabilir, ancak DI kapsayıcısı kullanılmadığında nesne yaşam döngülerini yönetme önerisi de mevcuttur. Bu üç kategori hâlâ geçerlidir: - Singleton. Aynı soyutlama örneği, başvuru boyunca her zaman paylaşılır. - Kapsamlı. Belirli bir rol için bir singleton kullanmak, ancak farklı kapsamlar için farklı örnekler sağlar. - Geçici. Her istek yeni bir örnek döndürür. 3) Intercept Teoride, kod uygulaması SOLID ilkesine uygunsa, dekoratör modunda Cephe yönelimli programlama (Aspect-oriented programming - AOP) uygulanabilir. Genel yaklaşım, önceki XXService için XXServiceDecorator adlı bir alt sınıf oluşturmak, XXService'e XXServiceDecorator'a bir yapıcı parametresi olarak enjekte etmek ve XXServiceDecorator'da genelde, doğrudan çağrı, koşullardan önce ve sonra intercept için XXService yöntemini yeniden uygulamaktır. Son olarak, birleştirilmiş kökte XXService yerine XXServiceDecorator değerini ayarlayın. Not: AOP uygulamanın, Dinamik Interception (dinamik proxy de denir) ve Derleme Süresi Weaving (ayrıca IL Weaving olarak da bilinir) olmak üzere iki yolu vardır. Bu iki konu hakkında inceleme yapmayacağız. # Demo https://github.com/EanCuznaivy/DIDemo?source=post_page-----3015d4a5f7a1---------------------- KAYNAK:https://medium.com/aelfblockchain/aelf-tech-talks-dependency-injection-part-4-3015d4a5f7a1 |
< Resime gitmek için tıklayın >
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.
< Resime gitmek için tıklayın >
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.
< Resime gitmek için tıklayın >
(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ı.
< Resime gitmek için tıklayın >
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