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

Aelf için bir yıllık büyüme ve önemli gelişmelerden sonra, geleneksel işletmeler ve gelişen Blockchain ekosistemi arasındaki engelleri yıkma hedefimiz konusunda kendimizi adamaya devam ediyoruz.

Bu yıl çok şey başardık ve yeni maceralar için heyecanlıyız!

Yazılımcı olarak anlamadığım bir iş nasıl güveniyor insanlar.

Genel olarak kişiler; proje hedefleri, amaçları vs. için Whitepaper'ı (https://aelf.io/gridcn/aelf_whitepaper_TR.pdf?v=1) inceleyerek, bu sürecin gelişimini Github (https://github.com/AElfProject/AElf) sayfasında yer alan kodları vs. takip ederek ve diğer tüm gelişmeleri) partnerlikler, listelenmeler gibi haberleri) sosyal medya hesaplarından takip ederek yatırım kararı almaktadır.

Aelf “En Teknolojik İnovasyon Sistemi” Ödülü ile 2020’deki İlk Ödülünü Aldı

6 Ocak 2020'de “İnovasyona Övgü” temalı 2019 yıllık listesine Guower Finance, Northern Capital, Horman Capital ve LORE Capital birlikte sponsor oldular. Aelf, “En Teknolojik İnovasyon Sistemi” ödüllünü kazandı. Ödül seçimi; 2019 yılında ekonomiye, inovasyon sınırlarına ve dijital ekonomiye yapılan endüstri katkılarını tanıtmayı amaçlamaktadır. Değerlendirme paneli, birden çok alanda yetkili uzmanlardan oluşuyordu; kurumsal etki, profesyonellik, itibar ve endüstri katkısı gibi çeşitli açılardan kapsamlı bir şekilde değerlendirme yapıldı.

Aelf, yenilikçi çapraz zincir iş birliği mekanizmaları ve modüler geliştirme bileşenleri ile paralel bilişimden yararlanan dünyanın ilk blok zinciri olan yüksek performanslı bir ticari Blockchain ağ sağlayıcısıdır. İşletmeler ve geliştiriciler, Aelf ağında ortamları hızlı bir şekilde dağıtabilir ve merkezi olmayan uygulamalar (Dapps) oluşturabilirler.

Uzun zamandır Aelf, mükemmel kullanıcı deneyimi ile yüksek performanslı ve yüksek oranda ölçeklenebilir bir kamu zinciri ekosistemi yaratmaya kendini adamıştır. Ticari kullanıcıların çok çeşitli uygulama gereksinimlerine yanıt olarak Aelf Enterprise(Kurumsal), farklı endüstrilerdeki belirli uygulama senaryoları için özelleştirilmiş çözümler sunabilecektir.

Bu, 2019'un “En Teknolojik İnovasyon Sistemi’dir” ve endüstrinin profesyonel kurumları ve yetkili uzmanları tarafından Aelf mükemmelliğinin büyük bir onayı olarak işlev görür. Aelf; daha gelişmiş Blockchain teknolojilerini araştırmaya ve geliştirmeye, Blockchain uygulamalarının gerçekleştirilmesini teşvik etmeye ve geleneksel endüstrilerin teknolojik yeniliklerle dönüşümünü ve geliştirilmesini sağlamak için çalışmaya devam edecektir.

KAYNAK: https://medium.com/aelfblockchain/a...on-system-as-first-award-in-2020-18bcffae0d86

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

Bu makale Aelf Kıdemli Geliştiricisi Yiqi Zhao tarafından yazılmıştır.

İlk Aelf akıllı sözleşmesi

Bu 4 bölümlük seride bir Aelf akıllı sözleşmesinin geliştirilmesinden bahsedeceğiz.

AELf staging projesi normal olarak başlatılabilir ve bloklar oluşturmak için tek bir düğüm kullanırsa, ilk akıllı sözleşme olan Merhaba Dünya (Hello World) üzerinde çalışmaya başlayabilirsiniz.

AELf akıllı sözleşmelerinin geliştirilmesi için yalnızca C# sözdizimi (Sentaks) gerektirir ve bu sözdizimleri, aşağıdaki öğreticide demo aracılığıyla açıkça gösterilecektir. Minimum programlama deneyimine sahip okuyucular, temel geliştirme sürecini anladıktan sonra akıllı sözleşmeler geliştirmeye başlayabilmelidir.

Şimdi bir akıllı sözleşme projesi oluşturmaya başlayalım.

Henüz akıllı sözleşme projeleri oluşturmayan bir AElf.Boilerplate çözümümüz olduğunu varsayın. AElf.Boilerplate.sln dosyasını VS veya Rider gibi IDE ile açtıktan sonra, dizin yapısı aşağıdaki gibi olmalıdır:

Sözleşme klasöründeki Directory.Build.props dosyası, sözleşme dizinindeki tüm projelerin AELf.Sdk.CSharp'ın aynı sürümüne referansına yardımcı olmak amacıyla oradadır; böylece bir akıllı sözleşme projesi oluşturduktan sonra bir sonraki sürüme el ile bir referans eklemeniz gerekmeyecektir. Ayrıca props dosyası, Protobuf'ta tanımlanan bazı yöntemleri ve yapı kodu oluşturma komut dosyalarını tanımlamak için MSBUILD kullanan AELf.Contract.Tools.targets dosyasını içe aktarır.

Src klasörü; başka bir bölümde açıklanacak olan staging başlatma, sistem sözleşmesi dağıtımı ve simüle edilmiş işlem testi gibi öğeleri içerir.

1. Akıllı sözleşmenin hizmetlerinin ve yapısının tanımlanması (Proto dosyası)

Akıllı sözleşme geliştirmenin ilk adımı, akıllı sözleşmenin harici olarak sağlayabileceği bazı arayüzleri (GRpc'deki hizmetlere karşılık gelen) ve veri yapılarını (GRpc'deki mesajlara karşılık gelen) tanımlamaktır.

AElf akıllı sözleşmelerini geliştirmek için AElf’in Staging’ini kullanırken, sözleşme hizmetlerini ve veri yapılarını tanımlayan proto dosyalarını AElf.Boilerplate projesinin protobuf klasörü altına yerleştirmenizi öneririz:

Protobuf klasöründe, AELf sistem sözleşmesinin proto dosyaları ve bir dizi AELf sözleşme standardı (acs * .proto) dahil olmak üzere önemli sayıda proto dosya bulunduğunu görebiliriz. AELF klasöründe core.proto ve options.proto'yu bulabiliriz, bunlar geliştirme sürecini daha kolay hale getirmek için AELF tarafından tanımlanan genel türler ve uzantılardır. AELF akıllı sözleşme geliştirmesi, kaçınılmaz olarak bu iki dosyanın (ve Google tarafından tanımlanan diğer bazı proto dosyaları) içe aktarılmasını gerektirir.

Yöntemden bağımsız olarak geliştiricilerin protobuf klasöründe hello_world_contract.proto adlı bir dosya oluşturmaları gerekir (bu gerekli olmasa da “sözleşme adı_contract.proto” adlı sözleşmeyle ilgili proto dosyalarını öneririz) ve daha sonra sözleşme hizmetleri ve veri yapıları tanımlamaya başlayabiliriz:

csharp_namespace = “AElf.Contracts.HelloWorld”, karşılık gelen C# kodunun AElf.Contracts.HelloWorld ad alanı (namespace) altında olması gerektiği anlamına gelir.

option (aelf.csharp_state) = “AElf.Contracts.HelloWorld.HelloWorldContractState”, sözleşmenin durumunun HelloWorldContractState sınıfında AElf.Contracts.HelloWorld ad alanı altında tanımlanması gerektiği anlamına gelir.

Hello_world_contract.proto'da iki eylem hizmeti tanımlanır (hizmet çağrıldıktan sonra blok zincirinin durumu değiştirilebilir; bu, çağrıdan sonra küresel defterin (ledger) değişeceği olarak anlaşılabilir): Greet ve GreetTo. Greet, girdinin google.protobuf.Empty türü (boş giriş için yer tutucu olarak anlaşılabilir) olmasını ve çıktının google.protobuf.StringValue (geleneksel string) olmasını gerektirir; GreetTo, girdinin bu proto dosyası için özelleştirilmiş GreetToOutput türünü veren google.protobuf.StringValue olmasını gerektirir.

Ek olarak bir Görünüm (View) hizmeti tanımlanır (yalnızca Blockchain'in geçerli durumunu sorgulamak için bir yöntem olarak kullanılır): Girdinin google.protobuf.Empty türü ve çıktının özelleştirilmiş bir GreetingsList türü olmasını gerektiren GetGreetedList. GreetingsList’in aslında bir string Listeleri olduğunu görebilirsiniz.

İPUÇLARI:

• Google.protobuf.Empty kullanmanın öncülü, google/protobuf/empty.proto’yu içe aktarmaktır.
• Google.protobuf.Timestamp kullanmanın öncülü, google/protobuf/timestamp.proto’yu içe aktarmaktır.
• Google.protobuf.StringValue kullanmanın öncülü, google/protobuf/wrappers.proto’yu içe aktarmaktır.
• (Aelf.is_view) = true seçeneği kullanıldığında hizmetin blok zincirinin durumunu değiştirmeyeceği bildirilir. Bu işlemin Aelf/options.proto’ya aktarılması gerekmektedir (Ayrıca aelf.csharp_state'i kullanmadan önce aelf/options.proto’yu içe aktarmanız gerekir).

Proto dosyası oluşturulduktan sonra, içinde tanımlanan üç hizmeti uygulamaya başlayabiliriz. Bölüm 2’de akıllı sözleşme geliştirilmesi için bu sürece devam edilecektir.

KAYNAK: https://medium.com/aelfblockchain/a...first-aelf-smart-contract-part-1-4b51f5756b24

✅ Aelf blok yüksekliği 9 milyonu aşarak 10 milyona doğru yaklaşmaktadır. Aelf Kaşif (Aelf Explorer) test adresini ziyaret ederek ilgili detayları inceleyebilirsiniz.

➡️ https://explorer-test.aelf.io/

✅ BFSI (Bankacılık, finansal hizmetler ve sigorta) pazarında Blockchain teknolojisinin benimsenmesinin kapsamlı analizinde Aelf, Blockchain teknolojisinin benimsenmesini destekleyen büyük şirketlerin yanında bir ANAHTAR OYUNCU olarak adlandırıldı.

https://www.fortunebusinessinsights.com/industry-reports/blockchain-in-bfsi-market-100608

teşekkürler güzelmiş.

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/a...first-aelf-smart-contract-part-2-c05e5c6f64c6

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.

(👆 DEVAMI 👆 )

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ş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/a...first-aelf-smart-contract-part-3-ca4fb4eb784f

✅ 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 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/h...eves-blockchain-interoperability-a2aea876c035

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