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

✅ 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

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 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

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ş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

✅ 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)