🔊 ELF spot marj ticareti artık OKEX'de aktif! 🎉 Heyecan verici promosyonlar ve bonus sizleri bekliyor! 🎁

İlk işlem çiftleri ELF/USDT ve ELF/BTC olacaktır.

Zaman: 21 Şubat 2020 - 3 Mart 2020

https://twitter.com/aelfblockchain/status/1230386602591096833

Etkinlik hakkında daha fazla bilgiyi burada bulabilirsiniz: https://dwz.cn/BMjmQCJz

📢Aelf Ekonomik Sistem ve Yönetişim Whitepaper'ı çıktı📢

1. Ekosistemin bir parçası olarak ödüllendirilecek yüzlerce yol
2. Oluşturmanıza ve geliştirmenize yardımcı olacak geliştiriciye özel destek planları
3. Sistemi geleceğe dönüştürmek için esnek yönetişim modeli

https://aelf.io/gridcn/aelf_economic_system_whitepaper_en_v1.0.pdf?t=1

https://twitter.com/aelfblockchain/status/1229391043075817475

NOT: Bu belgenin Türkçe sürümü kısa bir zaman içinde paylaşılacaktır 😊

Kripto Marşı'nın tam sürümü yayınlanmıştır 🔥🔥🔥 Dinlemek için bağlantıya tıklayabilirsiniz: https://www.youtube.com/watch?v=mvjOYjBDtwo

Kripto Marşı piyasaya sunuşunu desteklemek için Aelf, 1.000 ABD dolarının üzerinde ödül havuzuyla çok sayıda yarışmaya sponsor oldu.

Kripto Marşı Yarışma Detayları için: https://medium.com/@kursataelf/kripto-mar%C5%9F%C4%B1-yar%C4%B1%C5%9Fma-detaylar%C4%B1-b232d80710d7

Merhabalar Hakan Bey, Candybox bounty programı 2019 Eylül itibariyle sona ermiştir. Daha iyi ve yeni bir ödül sistemi ve topluluk etkinlikleri için çalışmalar devam etmektedir. Detaylar netleştiğinde resmi olarak duyurular yapılacaktır. Takipte kalınız 

✅ CoinW Borsası, ELF ana ağ geçişini destekleyeceğini duyurdu.

https://twitter.com/Coinw_exchange/status/1228598437056319488

Bu duyuruyla ilgili Aelf tweeti:

Müthiş! Aelf halka açık/genel test ağı istikrarlı bir şekilde çalışıyor ve test ağımıza katılan tüm borsaları memnuniyetle karşılıyoruz! Hazır olduğunda resmi mainnet lansman sürecini açıklayacağız.

Lütfen Aelf’in ilerlemesiyle ilgili güncel haberleri almak için resmi medya kanallarımızı takip ediniz!

https://twitter.com/aelfblockchain/status/1228605280209866752

Gerçek varlık birlikte çalışabilirliğini içeren ilk cüzdan



Ölçeklenebilirlik, blockchain dünyasında 2018/19 boyunca spot ışığı tuttu ancak yeni bir lider, ölçeklenebilirliği bir tarafa itti – IBC (Inter-Blockchain Communication) veya Blockchainler arası iletişim, dünyanın dört bir yanındaki birçok kişi tarafından uzun süre tartışıldı ve bunu ortaya atan ekip(ler) birçok kişi tarafından blockchain için kutsal kâse bulmuş gibi görülecektir. Bu sıcak konu, 2020'de blockchain endüstrisinde yankılanıyor.

Kullanım durumu geliştirme, yönetişim protokollerinde olduğu gibi hızla ilerlemiştir. Özel blok zincirlerinde bir parçada yazıldığı gibi birçok işletme, bugünün manzarasında blockchain teknolojisini benimserlerse bir veri silosunun izolasyonunu yaşayabilir. IBC, buna ve diğer birçok soruna karşı koyar.

IBC (Blockchainler Arası İletişim)

IBC, bir Blockchain’in başka bir Blockchain ile iletişim kurma yeteneğidir ve iki kategoriye ayrılabilir: Blockchain içi İletişim ve Blockchainler arası iletişim.

IBC'yi Blockchain içi iletişim olarak tartışırken, farklı akıllı sözleşmeler arasındaki tek bir zincir içindeki iletişim ile de ilgili olabilir.

Blockchain İçi İletişim
IBC ile ilgili olarak bu kavram, birçok yan zincir veya Shard’ın gelişmesine izin veren blok zincir ekosistemleri ile ilgilidir. Bir yan zincirin/Shard’ın diğer herhangi bir yan zincir/ Shard ile iletişim kurmasına izin verir. Bu durumda, her iki zincir de normal olarak aynı yönetişim protokolleri ile sağlanır ve aynı ana zincire bağlanır.

Blockchainler Arası İletişim
IBC ile ilgili olarak bu, iki kavramdan en zorudur ve bir blok zincirin başka bir tamamen bağımsız blok zinciriyle doğrudan iletişim kurma yeteneğini temsil eder. Bu, bir Ethereum kullanıcısının Bitcoin ağında bir işlemi başlatması gibi olacaktır.

IBC'nin şu anki sınırlamaları, bir Apple veya Android cihazında oluşturulan herhangi bir dosyayı açamayan veya bunlarla etkileşime giremeyen Windows kullanıcıları ile karşılaştırılabilir. Ya da bir bankanın kullanıcısının fonlarını başka bir bankayla kullanamaması gibi… Bu, bir mağazanın hangi bankayı kullandığını bulmak zorunda kalmanıza ve paranızı ilgili mağazadan satın alma yapabilmek için o banka tarafından kullanılan tokene dönüştürmenize neden olur. Bu, günümüzün bağlantılı dünyasında pratik değildir.

Cüzdanlar için karmaşıklık

Bu konsepti blockchain dünyasına geri götürerek, Bitcoin tutabilen ancak üzerinde çalıştığı platformdan bağımsız olarak herhangi bir uygulamaya bağlanabilen bir cüzdanınız olduğunu hayal edin. Ethereum ağında (veya başka bir platformdaki) satın alma yapabilir veya herhangi bir akıllı sözleşme ile etkileşime girebilirsiniz.

Bu fikir, bunu gerçeğe dönüştürmek için aşılması gereken iki ana engel sunmaktadır. Birincisi, çapraz zincir işlemlerinin birden fazla işlemin iş birliğini içermesidir. Çapraz zincir işleminin tamamlandığından emin olmak için cüzdanın iki işlem başlatması gerekecektir. İşlemlerin göreceli olarak düşük bir zaman dilimi içinde tamamlanması gerekiyorsa, bir dizi doğrulama işleminin / sorgusunun da başlatılması gerekecektir.

İkinci karmaşıklık, çapraz zincir işlemlerinin tamamlanmasında kaçınılmaz olarak meydana gelecek zaman farkından kaynaklanmaktadır. Tipik bir çapraz zincir işleminde B zincirindeki işlemi kabul etmeye başlamadan önce A kullanıcısı, A zincirindeki işlemin geri çevrilemez hale gelmesini beklemelidir. Bu, gerçekçi olmayan uzun bir süre içerebilir.

Aelf Cüzdanı

Aelf geliştiricileri, çoklu varlık birlikte çalışabilirliğini içeren bir cüzdanı başarıyla oluşturdu. Bu, gerçek IBC'ye ulaşmak için önemli bir adımdır. Aelf ekibi, çapraz zincir işlemleri için JS SDK sağlar ve işlemlerin yürütme ayrıntılarını gizler. Uygulama geliştiricileri, araç kütüphanesini tanıtarak ve dört yöntemi çağırarak çapraz zincir işlemlerini tamamlayabilirler.

JS SDK linki：https://www.npmjs.com/package/aelf-sdk-cross-chain

Piyasada Bitcoin, Etheruem, Ripple ve EOS dahil olmak üzere birçok koini tutabilecek atomic cüzdan gibi birçok 'çoklu varlık' cüzdanı vardır. Ancak sadece birkaç cüzdan başarılı bir şekilde çoklu varlık birlikte çalışabilirliği sağlayabilecek bir teknoloji yarattı ve çoğu iddialarını destekleyememektedir. JPMorgan Blockchain Center, Kadena Blockchain ile kendi çözümleri üzerinde çalışıyor ancak henüz geliştirmeyi bitirmedi.

Bu cüzdan teknolojisi blockchain platformlarında kullanılabilir olduğunda, geliştiriciler daha karmaşık ve kritik IBC protokolleri geliştirme temeline sahip olacaklar. Bu, blok zincirinin benimsenmesindeki büyük bir engelin kaldırılmasına yönelik güçlü bir adımdır.

KAYNAK: https://medium.com/aelfblockchain/first-wallet-to-incorporate-true-asset-interoperability-db48a9a653b7

Aelf Enterprise (Kurumsal) 0.9.2 Resmi Olarak Piyasaya Sunuldu



Aelf Enterprise v0.9.2, bir kapsamlı ticari blockchain çözümüdür. Temel uygulamaları ve temel hizmetleri destekleyen tamamen geliştirilmiş bir blockchain ekosistemi, geliştirme paketi ve belgeleri içerir.

Bundan önce Aelf Enterprise v0.9.1, ana ağı başlatmak için gereken tüm işlevleri yerine getirmişti. Aelf Enterprise v0.9.2 daha da optimize edilmiştir. Genel/halka test ağı kodu, yükseltme işleminde gereksiz koda neden olabilecek veri yapısı değişiklikleri nedeniyle temiz bir yükseltme şeklinde Aelf v0.9.2 olarak güncellendi.

Aelf Enterprise 0.9.2 Sürümü Sistem Entegrasyonu

1. Aelf Enterprise
• aelf v0.9.2
• DevKit v0.9.2

2. Aelf Harici Uygulamalar
• aelf Blockchain scanner (tarayıcı) v0.2.4
• aelf Scanner (tarayıcı) Mysql plugin (eklentisi) v0.9.2
• aelf Explorer (Kâşif) v0.9.2
• aelf Wallet (Cüzdan) v0.9.2
• aelf JS SDK 3.2.26
• aelf-bridge 0.0.8
• Nodejs v0.1.36’da aelf CLI

3. Aelf Tarayıcı Uzantısı v0.9.2
Aelf Enterprise 0.9.2'nin temel yeni özellikleri şunlardır:
• Optimize edilmiş yönetişim modelleri
• Optimize edilmiş ortak yönetişim yetkisi
• Optimize edilmiş çapraz zincir indeks ücreti
• Optimize edilmiş özel yan zincir yükleme/şarj modeli

Ayrıntılı Güncellemeler

1.Güncellemeler ve Tanıtım
1.1 aelf v0.9.2 https://github.com/AElfProject/AElf
• Ana/yan zincir dağıtımı için optimize edilmiş sözleşme yetkisi
• Optimize edilmiş yönetişim modeli: Artan olumsuz ve çekimser oylar
• Optimize edilmiş yönetişim yetkisi
• Yükleme/Şarj algoritması ile ilgili acs1/acs8 parametreleri güncellendi
• Optimize edilmiş çapraz zincir işlemleri
• Yan zincirler için yükleme indeksleme ücretleri mantığı geliştirildi
• Optimize edilmiş çapraz zincir indeks ücreti: vadesi geçmiş ücreti destekleme
• Kullanıcının ücretine/yüküne desteklenen tokenler listesi eklenmesi
• Optimize edilmiş üretim düğümleri cezaları: ekonomik ceza belirtildi
• Sözleşme eklenmiş sürüm yönetimi
• Sözleşme yürütme tarafından desteklenen Assembly kaldırma
• Statik analiz sonuçlarına göre optimize edilmiş kod
• Dotnet core 3.1'e yükseltildi ve ABP yapısı güncelledi

1.2 Devkit v0.9.2
• aelf-boilerplate https://github.com/AElfProject/aelf-boilerplate
Aelf nuget paketi v0.9.2 olarak güncellendi
• Geliştirilmiş geliştirici dokümantasyonları https://docs.aelf.io/
Sözleşme arayüzünün ilgili belgelerinin iyileştirilmesi

2. Aelf Harici Uygulamalar Güncellemesi
2.1 aelf-bridge https://github.com/AElfProject/aelf-bridge

Merkezi olmayan uygulamaların (DApp) herhangi bir cüzdan bilgisini depolamasına izin verilmediğinden, cüzdan uygulaması Aelf cüzdan bilgilerini depolar ve doğrudan Aelf zinciri ile iletişim kurabilir. Cüzdan bilgilerini korumak ve DApp'lere zincir ile etkileşim yeteneği sağlamak için Aelf-bridge, cüzdan ile etkileşim için kullanılabilir.

Burada açıklanan cüzdan uygulaması, diğerlerine ek olarak bir mobil (iOS/Android) yerel uygulama ve bir masaüstü uygulaması içerir.

2.2 aelf Explorer https://github.com/AElfProject/aelf-block-explorer
• Güncellenmiş oylama ve kaynak alışveriş mantığı
• Basit kullanıcı arayüzü, daha basit ve daha verimli
• Aelf genel test ağının blok zinciri tarayıcısının adresi:
- Ana zincir: https://explorer-test.aelf.io
- Yan zincir 1: https://explorer-test-side01.aelf.io/
- Yan zincir 2: https://explorer-test-side02.aelf.io/
- Yan zincir 3: https://explorer-test-side03.aelf.io/
- Yan zincir 4: https://explorer-test-side04.aelf.io/
- Yan zincir 5: https://explorer-test-side05.aelf.io/

2.3 Nodejs’de aelf CLI https://github.com/AElfProject/aelf-command
• Teklifle ilgili yöntemler ekleme

KAYNAK: https://medium.com/aelfblockchain/aelf-enterprise-0-9-2-officially-released-6913954496c6
 

🔊 Kripto Marşı'nı duyurmaktan gurur duyuyoruz! Ekibimizin son birkaç aydır üzerinde çalıştığı bir şey! Şarkıda rekor sayıda projeden bahsettik ve dünya çapında benimsenmeyi teşvik etmek için herkesi bir araya getirmeyi umuyoruz!

Teaser'ı dinlemek için linke tıklayabilirsiniz ➡️ https://www.youtube.com/watch?v=u6-Y2d8r7zI

Aelf: Ticari ölçekli işlemleri ve ölçeklendirme olanaklarını ele alan paralel işleme

Gerçek iş dünyasına hizmet eden Blockchainler için en büyük engellerden biri düşük işlem hızıdır. Bu durum geçmişte belirli işlemlerin güçlü mikroişlemciler ile çözülmesinin dakikalar veya saatler alabileceği merkezi bilişim sistemlerinde görülmüştür. Bu, bilgisayar hizmetlerinin neler sunabileceği olasılığını sınırlar. Neyse ki, bilgisayar bilimcileri bilişim performansını iyileştirmek için etkili bir yaklaşım kullanıyorlar: paralel işleme.

Aelf, bağımsız işlemler için paralel işlemeyi kullanır

1. Aelf, işlemlerin statik durumunu analiz eder ve her bir işlemin etkilenen veri aralığını değerlendirir. Şekilde gösterildiği gibi okuma/yazma çakışmaları olmayan işlemler, daha sonra her bir işlemin çıktısını etkilemeyen farklı gruplar halinde kategorize edilebilir.
2. Blok oluşturma sürecinde düğümler, işlemlerin muteksine dayalı olarak farklı gruplara işlemler atar. Bir grup içindeki işlemler sıralı işlemeyi benimserken, tüm gruplar aynı anda işlenir.
3. Diğer işlemler işlenirken veri aralığı değişikliklerinden etkilenen özel işlemler için düğümler, paralel olarak işlenebilecek işlemlere öncelik verir. Yeterli işlem ücretleri ile paralel olmayan bir gruptaki bu özel işlemler sırayla işlenecektir. Aksi takdirde düğümler, bu işlemleri işlemeyi reddedebilir.



Paralel işleme, Amdahl yasası ile tam olarak açıklanabilir.



Yasa, tüm görevin yürütülmesinin iyileştirmenin büyüklüğüne bakılmaksızın sistemdeki kaynakların iyileştirilmesi ile arttığını göstermektedir. Teorik hızlanma, her zaman görevin iyileştirmeden yararlanamayan kısmı ile sınırlıdır.

Hesaplar arasındaki işlemlerin çoğu muteks olduğundan paralel olarak işlenebilir. Ancak mevcut Blockchain teknolojileri, verileri sırayla işleyerek büyük miktarda bilişim kaynağını boşa harcamaktadır. EVM'yi örnek olarak alalım. Tüm veri ve talep gaz ücretleri için sıralı işlemeyi benimser ve düşük işleme verimliliği ile sonuçlanır.

Aelf, bilgisayımsal güç arttıkça ölçeklenebilir performans sağlar

Veri işleme hızının kendisinin optimize edilmesi nihai hedef değildir. Paralel işlemenin önemi ölçeklenebilirlik potansiyelidir.

Hepimiz Ethereum'un ölçeklenebilirliği konusundaki yoğun tartışmaları gördük. Zorluk, Ethereum'daki bir düğümün işlemleri sadece sırayla işleyebilmesidir. Böylece, Ethereum'un tüm işleme hızı en yavaş düğümle sınırlıdır. Böylece, Ethereum'un tüm işleme hızı en yavaş düğümle sınırlıdır.

Cosmos basit bir çözüm sunar. Çok fazla kişi kullandığı için bir bölgede işlem hızınız yavaşlarsa, Hub'a başka bir bölge ekleyip kullanıcıların yarısını o bölgeye yönlendirerek işlem hızınızı iki katına çıkarırsınız. Ancak birim başına işlem işlemelerinin verimliliği, daha fazla bilişim gücü eklendiğinde bile hâlâ sınırlıdır.

Aelf, işlemleri işlemede bulut bilişimi tanıtıyor. Aelf Çekirdeği (Kernel), her düğümün bir bilgisayar kümesinde çalışmasını sağlar. Aelf ekosistemine daha fazla bilgisayımsal güç katıldığında yalnızca sistem güvenliğini artırmakla kalmaz, aynı zamanda işlem hızını orantılı olarak artırır. Şekilde gösterildiği gibi Aelf, okuma/yazma çakışmaları olmayan işlemleri farklı kategorilere ayırır ve daha sonra farklı işlem gruplarını aynı anda işler.

Ancak ölçeklendirme çok boyutlu bir konudur. Bir teşvik mekanizması ve konsensüs mekanizması aracılığıyla ölçeklendirmenin en iyi nasıl elde edilebileceği düşünmeye değerdir. Aelf’in token tasarımı ve konsensüsü, bu alanda ilgi çekici bir keşif sağlamaktadır.

KAYNAK: https://medium.com/aelfblockchain/grid-parallel-processing-to-handle-commercial-scale-transactions-and-possibilities-for-scaling-5d0be76d654a

Aelf Kernel’i (Çekirdek) oluşturmak



Çekirdek, sistemin merkezinde bulunan önemli bir yazılım parçasıdır. Başlıca rollerinden biri de işlemleri göndermektir. Kernel, durumunu “World State” adlı bir yapıda depolar. Her akıllı sözleşmenin durumunu da içeren sistemdeki her hesabın durumlarını içerir. Son haftalarda, çekirdeğin ana bileşenlerini oluşturan devletin depolanması, işlem planlaması ve akıllı sözleşmeler üzerinde duruldu.

Zincirdeki tüm hesapların durumunu içeren World State’i uyguladık. Verilerin bütünlüğü ve doğruluğu, Merkle Ağacı yapısı ile doğrulanır. Sistemimizi farklı veri sağlayıcılarla arayüzlemek için, Aelf'in farklı veri depolama çözümleriyle çalışmasına izin veren veri erişim mekanizması uygulandı.

Zamanlayıcı, çekirdeğin çok önemli bir parçasıdır. Çünkü sorumluluğu, çalışan makineler tarafından yürütülecek işlemleri göndermektir. Belirli işlemlerin diğerlerinden önce tamamlanması gerektiğinden, zamanlayıcı hangi işlemin paralel olarak işlenebileceğini ve işlenemeyeceğini hesaplamalıdır. Tasarım stabilize edildi ve çözüm hayat geçirildi.

Çekirdek, sistemimize yeni akıllı sözleşmeleri dağıtabiliyor. Bir sözleşme dağıtıldıktan sonra kullanıcılar, bu akıllı sözleşmelerde yöntemler çağırabilir. Akıllı sözleşmelerde kod çağıran işlemleri işleyen mekanizmayı uyguladık.

Çekirdek, bir bilişim kümesinde (aynı ağda çok sayıda bilgisayar) çalıştırılacaktır. Daha önce de belirtildiği gibi Zamanlayıcının rollerinden biri, çalışan makineler tarafından yürütülecek işlemleri göndermektir. Bunun çalışması için küme içi iletişimi amacıyla ağ katmanı ve iletişim protokolü uygulanmaktadır.

KAYNAK: https://medium.com/aelfblockchain/building-up-the-aelf-kernel-baaec66b2741

Aelf Ekosistemi Blockchain Birlikte Çalışabilirliğini Nasıl Elde Eder?



Blockchain teknolojisi, Bitcoin'in piyasaya sürülmesinden bu yana on yıl içinde hızla ilerledi. Özellikle son zamanlarda teknoloji, kripto paranın ilk kullanım durumunun ötesinde ilgi ve tanınma kazanmıştır. Blockchain; ticaret finansmanı yerleşimleri, tedarik zinciri yönetimi, dijital kimlik ve sözleşme hukuku gibi çok çeşitli uygulamalar sunmaktadır.

Ancak blockchain sistemleri, şu anda çok yönlü bir işletim sisteminin işlevselliğini sunmamaktadır. Bitcoin ve ondan çatallanan diğer kripto para birimleri tek kullanımlık uygulamalardır. Ethereum gibi dağıtılmış uygulama platformları, bir işletim sisteminin özelliklerini çoğaltmaya çalışmıştır ancak bazı ciddi sınırlamalar vardır.

Bu sınırlamalar arasında hız, güvenlik ve çeşitli spesifik iş gereksinimlerine göre özelleştirme yeteneği eksikliği bulunur. Bu nedenle birçok işletme, izin verilmiş dağıtılmış defterleri tercih ederek merkezi olmayan kamu/halka açık blok zincirlerinin avantajlarından yararlanma konusunda isteksizdir. Bu, blockchain teknolojisinin onları korkutmak için bir şey olduğu anlamına gelmez ancak bunu dikkatli bir şekilde ele alırlar.

Blockchain Manzarası (Landscape) İşletim Sistemi (OS) Öncesi Bilişime Benzer mi?

Microsoft'un Windows'u geliştirene kadar, günlük işletmelerin kelime işleme gibi görevler için bilgisayar kullanmadığını düşünün. İşletim sistemleri kullanıma sunulduktan ve giderek daha kullanıcı dostu hale geldikten sonra, bilgisayarların ticari benimsenmesi ve dolayısıyla uygulamalar artmaya başladı. Geliştiriciler; farklı iş ihtiyaçları için uyarlanmış, belirli amaçlara hizmet eden daha fazla uygulama oluşturmaya başladı.

Blockchain, işletim sistemi öncesi bilgisayarlarla benzer bir sorunla karşı karşıyadır. Birçok farklı işletme türünün kullanımına uyum sağlayabilecek hiçbir işletim sistemi olmadığından, teknoloji bugüne kadar yaygın bir şekilde ticari olarak benimsenmeyi başaramamıştır. İş ihtiyaçları, tek bir Blockchain'in her amaca uygun hale getirilmesi için çok geniş ölçüde değişir.

Örneğin; yasal ve veri gizliliği gereklilikleri sağlanamıyorsa, ticaret finansmanı için anlık anlaşmalara gerek yoktur. Perakendecilerin, Black Friday gibi alışveriş tatillerinde talep edilen zirveleri karşılaması gerekir. Mevcut blockchain altyapısı, diğerinden ödün vermeden bu çelişkili talepleri karşılayamaz.

Neden Aelf Farklıdır?

Aelf, tamamen birlikte çalışabilir ve bu nedenle ticari kullanıma uygun özelleştirilebilir bir blockchain ekosistemi ile bu sorunların üstesinden gelmeye çalışır - blockchain için bir Linux. Sistem güncellemeleri için yönetişim, işlem hızı, ölçeklenebilirlik ve birlikte çalışabilirlik gibi sorunları çözerek temel sistemi sağlıyoruz.

Geliştiriciler, daha sonra belirli iş veya ticari ihtiyaçlar için özelleştirilebilir yan zincirler oluşturmak için Aelf Kernel’i kullanabilirler. Ayrıca Aelf; her bir yan zincirin Bitcoin veya Ethereum gibi diğer blok zincirlerinin yanı sıra birbirleriyle etkileşmesine izin vererek varlıkların, kullanıcıların ve bilgilerin farklı uygulamalar arasında paylaşılmasını sağlamaktadır.

Aelf Birlikte Çalışabilirliği Nasıl Sağlar?

Birlikte çalışabilirliği sağlamak için Aelf, iki yenilikçi özellik kullanır. Yan zincirler, kaynakların ayrımı ve akıllı sözleşme işlevselliği yoluyla ölçeklenebilirlik sağlar. Bunun yanı sıra DPoS protokolü, hızlı işlem onayları ile uyarlanabilir bir yönetişim sistemi sağlar.

Yan zincirler

Aelf, herkese/her şeye uyan tek bir blockchain konsepti üzerinde çalışmaz. Bunun yerine sistem, bir ana zincir omurgasında çalışır ve dallı yan zincirler bir indeksleme sistemi ile ana zincire bağlanır.

İndeksleme sistemi iki tür yan zinciri tanır:
• Bitcoin veya Ethereum gibi yüksek öneme sahip dış zincirler
• Dahili yan zincirler

Ana zincir, akıllı sözleşmelere sahip değildir. Akıllı sözleşmeler, dahili yan zincirler üzerinde geliştirilir. Her bir yan zincir, belirli bir akıllı sözleşme işlevselliği ve/veya iş gereksinimi sunar.

Örneğin; bir yan zincir bir dijital varlık değişimi olarak işlev görebilir, bir diğeri ise varlık depolamasını dijital bir cüzdan olarak işleyebilir. Dijital varlık değişimi yan zinciri çok ağır hale gelirse, farklı dijital varlık türlerini işleyen alt zincirlere ayrılabilir/dallanabilir.

Yan zincirler, sadece ana zincir aracılığıyla birbirleriyle etkileşime girebilir. Bu şekilde bir yan zincirde herhangi bir zirve veya darboğaz yaşanıyorsa, sistemin geri kalanı etkilenmez.

DPoS

Ana zincirde birden fazla yan zincir endekslenmesi, Bitcoin gibi bir blok zincirindeki tipik işlem onayından daha karmaşıktır. Buna ek olarak Aelf, daha karmaşık bir yapıda kurumsal bulut hizmetleri sağlamak üzere tasarlanmıştır.

Bu nedenle PoS veya PoW uygun değildir; bu yüzden ana Aelf blok zinciri, DPoS protokolünü kullanır. DPoS; PoW veya PoS'dan daha hızlı ve daha öngörülebilir olmanın ikili avantajlarını sunarken, aynı zamanda yüksek güvenlik düzeylerine de bağlı kalmayı sağlar.

DPoS'da ELF token sahipleri, madencilik düğümlerini seçer. Madencilik düğümleri, Aelf’in tüm kurallarını uygular ve madencilik ödüllerinin nasıl dağıtılacağına karar verir. Yan zincirler, kendi konsensüs protokollerini benimsemekte serbesttirler ancak madenciliği Aelf ana zinciri ile birleştirmeleri teşvik edilmektedir.

Aelf token sahipleri, 2N + 1 madencilik düğümünü delege eder. N, 8 ile başlar ve her yıl 1 artar. Geleneksel kurulumdan farklı olarak her bir düğüm, biri işlemleri işlemek diğeri veritabanı depolama için olmak üzere iki kümeye bölünmüş bir bilgisayar kümesinden oluşur.

Bir Araya Getirme

Yan zincirlerden yan zincirin genel ekosisteme katkısına bağlı olarak belirlenen ELF tokeni olarak bir işlem ücreti alınır. Bu nedenle en çok katkı verenler, en az ücreti öderler.

Yan zincirler işlem gördükçe ana zincirdeki madencilik düğümleri, yan zincirlerden gelen bilgileri okuyarak bir Merkle Ağacı oluşturur. Ana zincirdeki her blok, daha sonra blok başlığındaki Merkle Tree köklerini kaydeder. Bir yan zincir başka bir yan zincir ile iletişim kurmaya ihtiyaç duyarsa, bunu ana zincir blok başlığını dahil ederek ana zincir aracılığıyla yapabilirler.

Yan zincirler, diğer alt zincirleri endekslemek için kendi dalları içinde oy kullanabilirler. Alt zincirler, istedikleri takdirde birden fazla yan zincir tarafından endekslenmeyi talep edebilir. Yan zincirler, onlardan dallanan alt zincirlerden ücret talep edebilir.

Tamamen birlikte çalışabilir bir blockchain ekosistemi ile Aelf, diğer blockchain altyapısının kullanıcılarının karşılaştığı zorlukların birçoğu tarafından sınırlandırılmayan çeşitli potansiyel iş kullanım durumları sunar. Bunlara finansal hizmetler, dijital kimlik, akıllı şehir ve Nesnelerin İnterneti (IoT) uygulamaları dahildir. Ethereum, EOS veya diğer platformlar üzerine inşa edilmiş mevcut merkezi olmayan uygulamalar; Aelf uygulamalarıyla etkileşime girebilir. Aelf ekosistemine katılmak isteyen şirketler, istedikleri kadar küçük ve ölçekli bir başlangıç yapma fırsatına sahiptir.

KAYNAK: https://medium.com/aelfblockchain/how-the-aelf-ecosystem-achieves-blockchain-interoperability-a2aea876c035

✅ Github commits istatistiklerinin yer aldığı CryptoMiso sitesinde son 12 aylık süreç için Aelf, 257 kripto para arasında 7110 commits ile 2. sıraya yükseldi.

(KAYNAK: https://www.cryptomiso.com)

Aelf Teknik Konuşmalar  -  AElf Akıllı Sözleşme Geliştirme  -  İlk AElf Akıllı Sözleşmesi  -  Bölüm 3



4. Akıllı sözleşmelerin dağıtılması

Referans/Başvuru ekleme

AElf.Boilerplate.Mainchain, csproj dosyasına ekleyerek akıllı sözleşme projesine ve ilgili Proto dosyasına başvursun:



Dto Oluşturulması

İlk olarak, AELF blockchain genesis bloğunun oluşum sürecini kısaca tanıtalım.

Diğer blok zinciri sistemleri gibi AELF'in ilk aşamasında her bir düğüm, bağımsız olarak aynı blok karma ile bir genesis bloğu oluşturacaktır (eğer bir düğüm tarafından üretilen genesis blok karma AELF ana zincirindeki diğer tüm düğümlerinkinden farklıysa, belirli düğüm Aelf ana zincirine farklı bir ana zincir başlattığını gösterir).

Genesis bloğunda bir dizi sistem sözleşmesi, başlatılan sözleşmelere sabit kod ve yapılandırma öğeleri aracılığıyla dağıtılır.

Staging testi sözleşmelerini kullanırken kendi sözleşmenizi genesis bloğunda bir sistem sözleşmesi olarak dağıtabilirsiniz ve yalnızca ilgili Dto'yu sağlamanız gerekir.

Dtos sağlama konumu src / AElf.Boilerplate.Mainchain / GenesisSmartContractDtoProvider.cs dosyasının GetGenesisSmartContractDtos yöntemindedir. Bu yöntem halihazırda diğer sistem sözleşmeler Dto’sunu dağıtmak ve başlatmak için Staging’i içerir. HelloWorld sözleşmesi için yalnızca Dto eklemeniz gerekir.

GenesisSmartContractDtoProvider_HelloWorld.cs adlı bir C# kodu dosyası oluşturmak, bir GenesisSmartContractDto listesini başlatmak ve ilgili bilgileri girmek yeterlidir.



AELf sisteminde her sözleşmede Sistem Sözleşme Adı denilen bir Karma türü benzersiz tanımlayıcı bulunur. Yukarıdaki koddaki Hash.FromString (“AElf.ContractNames.HelloWorld”), HelloWorld sözleşmesinin adıdır. HelloWorld sözleşmesinin tek tanımlayıcısıdır.

Son olarak GenesisSmartContractDtoProvider'ın GetGenesisSmartContractDtos yöntemine GetGenesisSmartContractDtosForHelloWorld'ü ekleyin:



5. Akıllı Sözleşmeleri Test Etmek İçin İşlemleri Otomatik Olarak Göndermek

İlk olarak, AELf ana zincir kodunda bir arayüz tanıtalım: ISystemTransactionGenerator.

Bu arayüz blok paketleme sürecinde etkili olur. Bu arayüzün tüm uygulamalarını inceleyerek bir sistem işlemleri serisi üretilir. Bu sistem işlemleri, ağdan alınan normal işlemler işlem havuzundan alınmadan önce gerçekleştirilecektir. Başka bir deyişle, sıradan işlemler yapılmadan önce Blockchain durumunu değiştireceklerdir. Sıradan işlemler gibi sistem işlemleri de bloklara paketlenir. Fark, sistem işlemlerinin ana zincir kodu tarafından üretilmesi ve gönderenin kendisinin paketlenmiş bloğun düğümü olmasıdır.

Bu nedenle staging işleminde yeni sözleşmeleri test etmek ve “sistem işlemini” özelleştirmek için ISystemTransactionGenerator arayüzünü kullanmak iyi bir yöntemdir. Uygulamada yalnızca işlem yayınlamaya ilişkin kuralları formüle etmeniz gerekir.

ISystemTransactionGenerator arabirimi yalnızca bir yöntem içerir: GenerateTransactions. İmzası:



Bir örneğe bakalım. AELf blok zincirinde konsensüs alışverişi, sistem işlemlerinden biridir ve ilgili uygulama:



Temel olarak ConsensusService'in GenerateConsensusTransactionsAsync yöntemi, işlemler oluşturmak için çağrılır. Oluşturulan işlemler, ref anahtar sözcüğü ile işaretlenmiş olan oluşturulmuş Transactions değişkenine eklenir. Son olarak, bu uygulama sınıfını bileşik köke (XXModule’un ConfigureServices yöntemi) ekleyin ve bir bağımlılık ekleyin.



Buna dayanarak Greet, GreetTo ve GetGreetedList’in üç işlemini otomatik olarak gönderen bir ISystemTransactionGenerator uygulayabiliriz.

Src/AElf.Boilerplate.Tester/TestTransactionGenerator klasöründe, HelloWorldTransactionGenerator adlı bir C# kod dosyası oluşturun ve ISystemTransactionGenerator uygulamasını yapın.

Uygulamadan önce, AELf ana zincir kodunda sağlanan bir hizmeti tanıtmamız gerekir: TransactionResultService. Bir işlem kimliği sağlayarak bir işlemin yürütme sonucunu sorgulayabilir. Bir ITransactionResultService örneği doğrudan yapıcıya enjekte edilebilir.

Staging’de işlemlerin oluşturulması için bir hizmet de sunulmaktadır: TransactionGeneratingService. Uygulanması karmaşık değildir. Sadece AELf.Boilerplate.Tester projesinin kök dizininde GenerateTransactionAsync yöntemi, ana zincir tarafından sağlanan diğer bazı hizmetler aracılığıyla bir işlemi birleştirir ve işlemi döndürür.

Yani, HelloWorldTransactionGenerator şu şekilde uygulanabilir:







Her blok için HelloWorldTransactionGenerator, Greet, GreetTo ve GetGreetedList’in bir YöntemAdı ile üç işlem oluşturacaktır. Hedef sözleşme sistemi adı Hash.FromString'dir (“AElf.ContractNames.HelloWorld”). Önceki blok bir GreetTo işlemi içeriyorsa (eğer (_lastGetGreetedListTxId! = Hash.Empty)), "greeted" kişilerin listesini sorgulamak ve kayda yazdırmak için TransactionResultService kullanın.

HelloWorldTransactionGenerator uyguladıktan sonra src/AElf.Boilerplate.Tester/TesterModule.cs’nin ConfigureServices yöntemine aşağıdaki bağımlılığı eklemeyi unutmayın:



Bunu yaparak, staging düğümünü yeniden başlatarak, konsolda yazdırılan işlem yürütme bilgilerini görebilirsiniz (çünkü sözleşme uygulandığında, bazı kayıtlar Context.LogDebug yöntemi aracılığıyla yazdırılır).

(Bu makaledeki kod, https://github.com/AElfProject/aelf-boilerplate adresinden bulunabilir.)

KAYNAK: https://medium.com/aelfblockchain/aelf-tech-talks-aelf-smart-contract-development-the-first-aelf-smart-contract-part-3-ca4fb4eb784f

Staking - Ücretsiz Kripto Kazanmanın Yeni Yolu



Staking, blockchain projelerine hızla bir endüstri standardı haline gelen Hisse İspatı (POS) konsensüs protokolünün arkasındaki temel kavramdır. PoS, blok zincirlerinin güvenlik ve kaynak verimliliğinden ödün vermeden etkili bir şekilde ölçeklenmesine izin verir. Staking’i dâhil eden projeler Aelf, Dash, EOS, Cosmos, Cardano, Definity ve diğer birçoğudur.

PoW - Neden değişir

İlk olarak PoS'un geliştirilmesine yol açan İş/Emek Kanıtı (PoW) konsensüsünün karşılaştığı bazı konulara bakalım.

1. Aşırı enerji tüketimi - 2017 yılında bitcoin ağı (En Büyük PoW blok zinciri) tarafından kullanılan elektrik miktarı konusunda birçok endişe dile getirildi. O zamandan beri enerji tüketimi %400'ün üzerinde arttı. Bu ağdaki 1 tek işlemin 736.722 Visa işlemiyle aynı karbon ayak izine sahip olduğu ya da 20 ABD hane halkıyla aynı miktarda elektrik tükettiği anlamına gelir.
2. Değişen Elektrik Maliyetleri - Ağdaki herhangi bir madencinin kârı, iki maliyete bağlıdır: donanım ve altyapıyı elde etmek için ilk startup maliyetine ve daha önemlisi söz konusu ekipmanın elektrik kullanımına ilişkin çalışma maliyetine. Elektrik maliyetleri, kWh başına yüzde fraksiyondan 50 sentin (USD) üzerine kadar değişebilir ve bazı durumlarda ücretsizdir. Bir kullanıcı saatte sadece 0.40 USD kazandığında tamamen elektrik maliyetlerine dayanan belirli demografileri açıkça ortadan kaldıracak ve tam merkezsizleşme potansiyelini azaltacaktır.
3. Azalan merkezsizleşme - madencilik ekipmanlarının yüksek maliyeti nedeniyle büyük finansal tabanları olan firmalar, bireysel madencilere kiralamak ya da tamamen kişisel kazançlar için madencilik çiftlikleri kurdular. Bu, ağdaki büyük demografik sıcak noktalarla sonuçlanır ve merkezsizleşme yönünü artık bu yönün gerçekleştirilemeyeceği bir noktaya indirir.
4. Çatışan çıkarlar - Ağda çalışan madencilerin gereksinimleri tamamen donanım, elektrik ve internet bağlantısına sahip olmaktır. Bir madencinin kazanabileceği miktar için herhangi bir sınırlama yoktur ve ağda herhangi bir hisse sahibi olmaları gerekmez ve bu nedenle ağa fayda sağlayabilecek ancak ödüllerini azaltacak yükseltmelere oy vermeleri için çok az teşvik vardır.

Tutarlı Fiat Enjeksiyonu - Madencilerin çoğunluğu fiat para birimi cinsinden elektriğini ödemektedir. KWh başına 0,1 USD tutarında koruyucu bir oranda ağ şu anda yılda 73,12 TWh kullanıyor. Günlük ortalama maliyeti 20 milyon doların üzerindedir. Bu, her gün yaklaşık 20 milyon dolarlık fiat para biriminin bitcoin ağına etkili bir şekilde enjekte edildiği anlamına gelir. Her ne kadar bu konsept elektriğe ne kadar harcandığına bakılmaksızın her gün aynı miktarda bitcoin serbest bırakılacağı anlamında bir miktar kusurlu olsa da, madencilerin gözünden bakarsak, fiat torbalarını düşürüyor ve bitcoin torbalarını artırıyorlar. Bu torba değişikliği, kripto harcamalarını kaçınılmaz olarak teşvik edecek olan bu noktanın özüdür. Bitcoin torbaları arttırılmış ancak fiat torbaları azalmamış olsaydı, bir staking ekosistemde görüldüğü gibi bitcoin harcamak için daha az teşvik edici olurdu.

PoS Değişimleri

PoS protokolünün karşılaştığı farklı sorunlarla başa çıkmak için farklı yaklaşımlar benimsenmiştir. Will Little'un PoS'ta bunu ve daha fazlasını açıklayan mükemmel bir makalesi vardır, onları incelemek için eserinden bir alıntı yapalım:

• Para yaşına dayalı seçim - Peercoin (ilk PoS zinciri) gibi blok zincirleri, madeni paraları dağıtmak için PoW ile işe koyulurlar. Tekelleşmeyi ve %51 saldırılarını önlemeye yardımcı olmak için para yaşını kullanırlar (bir düğüm olarak seçilme olasılığının en yüksek olduğu bir zaman aralığı ayarlayarak) ve NoS problemlerini önlemek için başlangıçta kontrol noktaları uygularlar.

• Rastgele blok seçimi - NXT ve Blackcoin gibi zincirler de kontrol noktaları kullanır, ancak para yaşının stakingi olumsuz etkilediğine inanırlar. İlk dağıtım döneminden sonra (PoW veya başka bir yöntemle) bu zincirler, blok oluşturabilen düğümleri rastgele seçmek için algoritmalar kullanır.

• Ethereum’un Casper protokolü (protokolleri) - Ethereum, PoS'a geçildiğinde/geçtiği zaman ilk dağıtım sorunu hakkında endişelenmek zorunda değildir. Casper daha Bizans Arıza Toleransı (BFT) yaklaşımını benimser ve eğer aldatıcı şeyler yaparlarsa paylarını alarak (“keserek”) düğümleri cezalandırır. Ek olarak, fikir birliği, rastgele atanan her düğümün bir tur sırasında belirli bir blok için oy verdiği çok turlu bir süreçle oluşturulur. Casper, Bizans Arıza Toleransı (BFT) yaklaşımını alır ve eğer aldatıcı şeyler yaparlarsa paylarını alarak (“keserek”) düğümleri cezalandırır. Ek olarak konsensüs, rastgele atanan her düğümün bir tur sırasında belirli bir blok için oy verdiği çok turlu bir süreçle oluşturulur.

• Delegated Proof-of-Stake (DPoS) - Dan Larimer tarafından icat edildi ve ilk önce Bitshares'de (ve sonra Aelf, Steem, EOS ve diğerlerinde) kullanıldı. DPoS, topluluğun bloklar oluşturmak ve doğrulamak için düğümleri çalıştıracak delegeler seçmesini sağlayarak potansiyel PoS sorunlarını ele alır. Daha sonra kötü davranış, topluluk tarafından cezalandırılır.

• Delegated Byzantine Fault Tolerance (DBFT) - DPOS'a benzer şekilde NEO topluluğu (delegeler) düğümleri için oy kullanır, ancak blok üreten ve konsensüs üzerinde anlaşmaya varılan her düğüm yerine her düğümde neler olduğu konusunda 3 düğümden sadece 2 tanesinin anlaşması gerekir ( doğrulayıcılardan ziyade sayman gibi davranır).

• Tendermint - DBFT'nin daha sofistike bir şekli ve Casper'ın öncüsü olan Jae Kwon; 2014 yılında kendi kendini finanse etme ve bir düğüme tokenin topluluk tahsisi (yani bir “doğrulayıcı”) ile orantılı olan dinamik validator setleri, dönen lider seçimleri ve oylama gücünden (yani ağırlık) yararlanan Tendermint’ı tanıttı.

• Masternodes - İlk olarak DASH tarafından tanıtılan masternode PoS sistemi, düğüm olarak nitelendirilebilmek için düğümlerin minimum para eşiğini belirlemesini gerektirir. Genellikle bu; bir ağa yönetişim, özel ödeme protokolleri vb. şeklinde “hizmet” sağlama gereksinimleriyle birlikte gelir.

• Proof of Importance (POI) - NEM, en az 10.000 XEM değerine sahip masternodes stakinglere “önem hesaplama” vererek biraz farklı bir yaklaşım benimser. Bu POI sistemi, daha sonra toplumu etkilemek için zaman içinde olumlu bir şekilde hareket eden aktif düğümleri ödüllendirir.

• “Proof-of-X” - Ve son olarak, PoS dünyasında zekice yaklaşımlar ve staking varyantları bulmak için herhangi bir faaliyet eksikliği yoktur (bazıları diğerlerinden daha ayrıntılıdır).

Stake Yaparak Kazanma

Bu ağlardan nasıl para kazanabileceğini anlamak için bunları 3 kategoriye ayıracağız: Basit staking, Çalışan düğümler ve Oylama.

Basit Staking
Bu, 3 yöntemin en basitidir ve kullanıcı tarafından neredeyse hiçbir işlem yapılmasını gerektirmez. Bazı ağlar, belirli bir cüzdanda token tutarak kullanıcıları ödüllendirecektir. Bu ödüller genellikle minimaldir ancak kazanmanın en kolay yoludur.

Bir düğümü çalıştırma
Bu yöntem en büyük ödülleri sağlar, ancak kullanıcı tarafından en büyük eylemi gerektirir ve büyük olasılıkla sürekli bakım gerektirir. Genel olarak konuşursak, ağlar düğümlerin genellikle binlerce dolarlık belirli bir miktarda token stake yapmasını gerektirir. PoS sistemlerinde bu düğümlerin ağdaki diğer kullanıcılar tarafından oylanması ve destekçilerine güven sağlamaya devam etmesi gerekir. Bazı şirketler, PoW madencilik havuzlarına benzer bir konseptle düğümler kuracak ve kullanıcıların minimum stake miktarına katkıda bulunarak katılmasına izin verecektir.

Oylama
Bu mekanizma, DPoS ağları ile ilişkili olarak çalışan düğümlerle el ele çalışır. Kullanıcıların staking tokenleri oy olarak tercih ettikleri düğümler için kullanmaları önerilir. Her oylama, her bir seçmen için küçük bir miktar ödülün kilidini açacaktır. Düğümler, normalde bu ödülleri bir düğüm çalıştırmak için kendi ödüllerinin bir parçası olarak sağlayanlardır.

Aelf’in DPoS sistemi

Aelf konsensüs protokolü, bir çeşit DPoS kullanır. Ağda düğümlerin iki sürümü vardır, etkin düğümler ve yedek düğümler (henüz resmi adlar açıklanmamıştır). Etkin düğümler ağı çalıştırır ve blokları üretir; yedekleme düğümleri küçük görevleri tamamlar ve etkin düğümlerin çevrimdışı olması veya kötü amaçlı davranması durumunda bekleme durumundadır. Bu düğümler, alınan oy sayısına göre seçilir. Başlangıçta en üstteki 17 düğüm aktif düğüm olarak seçilecek, sonraki 100 ise yedek olarak duracaktır. Her oylama dönemi her düğüm bir önceki dönemden daha fazla veya daha az oy alırsa pozisyon değiştirebilir. Düğüm olarak kabul edilmek için, asgari miktarda (henüz ilan edilmemiş) ELF token miktarı stake yapılmalıdır.



Seçmen olarak katılabilmek için stake miktarının asgari miktarı yoktur. Bir stake yapıldığında tokenler, seçmen tarafından önceden belirlenmiş dönemler için seçilen belirli bir süre boyunca kilitlenir. Kullanıcılar bu kilitli süre dolmadan tokenleri çıkarırlarsa hiçbir ödül alınmaz, ancak tüm zaman dilimi boyunca tokenleri kilitli bırakırlarsa belirlenen ödülü alırlar ve tokenler otomatik olarak bir sonraki kilitli periyoda aktarılır. Sonuç olarak bir seçmen, oy verdikten sonra başka bir işlem yapmadan ödülleri almaya devam edebilir.

Birçok proje; ödülleri adil, iyi teşvik edilmiş ancak dahil olan herkes için sürdürülebilir hale getirmek için düğüm ödülleriyle mücadele etti. Aelf, her bir düğüm için garanti edilen temel gelir ile birden fazla değişkene dayanan bir ödül yapısı ortaya koymuştur. Değişkenler; yeniden seçim sayısını, alınan oy sayısını veya diğer unsurları içerebilir.

Sistem olgunlaştıkça, aktif düğümlerin sayısı artırılacak ve böylece daha çeşitli ve güvenli bir ağ ortaya çıkacaktır.

Çözüm olarak staking; ağ yaratıcıları, kullanıcılar ve yatırımcılar için bir kazan-kazan-kazandır. Kullanıcıların sistemden kazanmaları için giriş noktasını azaltırken, Blockchain ağlarını korumak için çok daha kaynak verimli ve ölçeklenebilir bir protokoldür.

KAYNAK: https://medium.com/aelfblockchain/staking-the-new-way-to-earn-crypto-for-free-7989cc76c16f

Aelf Teknik Konuşmalar - AElf Akıllı Sözleşme Geliştirme - İlk AElf Akıllı Sözleşme - Bölüm 2



2. Bir akıllı sözleşme projesi oluşturulması

Sözleşme klasöründe “AElf.Contracts.HelloWorld” adlı bir dosya oluşturun ve csproj dosyasını aşağıdaki gibi değiştirin:



Geçerli proje bir proto dosyasında tanımlanan bir hizmeti uygulamak istiyorsa, proto dosyasına başvurmak için ContractCode etiketini kullanır.

AELf.Contracts.HelloWorld projesini derlemeden önce, projede HelloWorldContractState adlı bir C# kod dosyası oluşturun (veya Class1'i HelloWorldContractState olarak yeniden adlandırın) ve HelloWorldContractState'in ContractState'ten devralmasına izin verin, aksi halde derleme bir hata ile başarısız olur:

… "HelloWorldContractState" türü veya ad alanı adı, "AElf.Contracts.HelloWorld" ad alanında mevcut değildir (bir başvuru derlemesi mi eksik?)

Başarılı bir şekilde derledikten sonra, projenin dizin yapısı şöyle olmalıdır:



Sözleşme durumunu tanımlamak için HelloWorldContractState.cs kullanılır. Mevcut kod:



Son olarak bu projede hizmet uygulaması sağlamak için bir C# kod dosyası HelloWorldContract.cs verilir ve içindeki sınıflar HelloWorldContractContainer.HelloWorldContractBase ve C #'ın geçersiz kılma mekanizması hizmetlerini uygulamak için kullanılabilir.

HelloWorldContract kodunu uygulamadan önce, bu üç hizmetin işlevlerini analiz ediyoruz.

Greet hizmeti göreceli olarak basittir, yani “Merhaba Dünya!” Çağrıdan sonra işlem yürütme sonucu olarak döndürülür.

GreetTo, Greet'e benzerdir. Ancak döndürülen yürütme sonucu, işlem gönderen tarafından belirtilen diziyi içerir. GetGreetedList, önceki GreetTo işlemlerinin işlem parametrelerinin kaydını sorgulamak için kullanılır. Şimdilik veri temizleme sorunlarını görmezden gelebilirsiniz. Kayıtlar, durum olarak kaydedilmelidir. Bu nedenle, HelloWorldContractState'teki öznitelikler aracılığıyla bir GreetedList öğesinin SingletonState türünü tanımlamanız gerekir:



Yukarıdaki GreetedList için State.GreetedList'i doğrudan HelloWorldContract'ta kullanabilirsiniz. State.GreetedList'i veritabanının girişi olarak düşünebilirsiniz. Bu SingletonState <GreetedList> veritabanı türünün geçerli değerini almak için State.GreetedList.Value kullanınız (SingletonState'in değer özelliğine erişerek AELf sözleşme geliştirme SDK'sı derleme anahtarını tamamlayacak ve önbellek ve veritabanı işlemlerini sırayla okuyacaktır) .

Daha sonra bu üç hizmetin nasıl uygulanacağına bakacağız.



3. Akıllı Sözleşme Test Projesi oluşturulması

TestKit kullanılması

AElf Sözleşmesi TestKit, AElf akıllı sözleşmelerini test etmek için özel olarak kullanılan bir test yapısıdır. Bu çerçevede, bir Saplama (stub) oluşturur ve işlem yürütmelerini simüle etmek için Saplama örneği tarafından sağlanan yöntemleri kullanır (genellikle sözleşmenin Eylem yöntemine karşılık gelir). Ayrıca test senaryosunda işlem yürütme sonuçlarını sorgulamanın yanı sıra (genellikle sözleşmenin Görünüm yöntemine karşılık gelir) sorgular. Bunu takiben, sözleşme yönteminin test görevini tamamlarsınız.

Test klasöründe AELf akıllı sözleşme test projesi olarak bir xUnit projesi oluşturun veya csproj dosyasını şu şekilde değiştirin:



Mevcut projenin gönderme veya sorgulama işlemlerini simüle etmek için bir sözleşme Saplaması kullanması gerekiyorsa, proto dosyasına başvurmak için ContractStub etiketini kullanın.

İpuçları:

• RootNamespace, bu proje altında açıkça bir varsayılan ad alanı belirtir. Varsayılan ad alanı, sözleşme koduyla tutarlı olacak şekilde değiştirilir. Bu gerekli değildir.
• Üçüncü taraf sınıf kitaplığına başvuru eklenip eklenmeyeceğine karar verebilirsiniz.
• Ana zincirin AELf.Contracts.TestKit referansı eklenmelidir. Bu belge yazılırken, AELf'in en son yayınlanan sürümü 0.9.0'dır.
• Bu projenin amacı HelloWorld sözleşmesini test etmek olduğundan, sözleşme projesine bir referans eklememiz gerekiyor.
• Test ortamı başlatıldığında, HelloWorld sözleşmesinin sıfır sözleşmeyle dağıtılması gerekir; bu, sıfır sözleşmenin saplamasını referans almak için ContractStub etiketinin de kullanılması gerektiği anlamına gelir.

Test Modülü

XXModule, kodun ABP yapısı tarafından modüler yönetimi için bir birimdir. Sözleşme testi durum projeleri için AELf varsayılan olarak sözleşmeyi isteğe bağlı dağıtma iznini kapattığından yalnızca ContractTestModule'e güvenmesi gerekir. Test ortamını hazırlarken, sözleşmeyi dağıtmak için izni el ile açmanız gerekir.



Test Base

Test Base, test durumunda kullanılan değişkenleri (sözleşme saplama ve sözleşme adresi vb.) başlatmak ve sözleşmeyi test için dağıtmak için kullanılır.

HelloWorldContractTestBase'de, sıfır sözleşme DeploySystemSmartContract yöntemini çağırarak HelloWorld sözleşmesini dağıttık ve sözleşme testi durumunda HelloWorldContractStub ve HelloWorldContractAddress adlı iki önemli değişkeni başlattık.





Test Durumları

Test Base tamamen hazırlandığında yazı kısmı kolay olacaktır.

Örneğin, test durumunda işlem gönderme işlemini simüle etmek istiyorsanız, HelloWorld sözleşmesinde bir Greet işlemi göndermek istiyorsanız, Test Base'de doğrudan başlatılan HelloWorldContractStub'ı kullanabilir ve await HelloWorldContractStub.Greet.SendAsync (yeni Empty ())'yı çağırabilirsiniz. Çağrı bittikten sonra, dönüş değerini almak için TransactionResult türünde bir değişken kullanılır ve bu işlemin yürütme sonucu denetlenir.

Greet, GreetTo ve GetGreetedList yöntemlerinin üç yöntemi için en temel test örnekleri aşağıdadır:





SendAsync kullanmanın öncülünün test durumu yazılırken ilgili işlemin başarıyla yürütülmesi gerektiğini varsaymak olduğunu lütfen unutmayın. İşlem yürütme hatası istisnasını test etmek istiyorsanız, başka bir yöntem kullanmanız gerekir: SendWithExceptionAsync.



Bu serinin 3. bölümünde, geliştirdiğimiz akıllı sözleşmelerin dağıtımını tartışacağız.

KAYNAK: https://medium.com/aelfblockchain/aelf-tech-talks-aelf-smart-contract-development-the-first-aelf-smart-contract-part-2-c05e5c6f64c6

İlginiz için teşekkürler Tüm karakteristik ve benzersiz özellikleri ile Aelf, gelecek için en önemli blok zinciri projelerinin başında gelmektedir.

Konuya olan ilginiz için çok teşekkürler