Altcointurk  

Geri Git   Altcointurk > > >

AELF ($ELF) Blockchain (ANA KONU)
Cevapla
 
Seçenekler Stil
16.Ağustos.2019, 19:58   #171
KursatAelf
Soft Fork
 
KursatAelf - ait Kullanıcı Resmi (Avatar)
 
Mesajlar: 179
Konular: 2
Üyelik: 18.Ocak.2019
Twitter: KursatAelf
Tecrübe Puanı: 0
KursatAelf is an unknown quantity at this point
Standart

Yan Zincirler: Tron’un Sun Network’ü Aelf ile karşılaştırıldığında ışıltısını kaybediyor

Click the image to open in full size.

11 Ağustos’ta TRON network, Sun Network olarak adlandırılan bir yan zincirleme ölçeklendirme çözümü açıkladı. Güvenliği ve verimliliği geliştirdiği ve enerji tüketimini azalttığı söyleniyor. Sun Network’ün Ağustos ayının başlarında yayınlanacağı bekleniyordu, ancak şimdi Eylül ayı ortasında bekleniyor. Bazı özellikler Aelf’e benzerdir ve bu makalede Aelf ile bu yeni yükseltmeler karşılaştırılacaktır.

Sun Network nedir?

Bu ağ, uygulama odaklı bir yan zincir ve çapraz zincir iletişimi olan DAppChain gibi bazı ölçeklendirme çözümleri içerecektir. TRON bloğuna (https://medium.com/@Tronfoundation/s...n-122c10fb713f) göre, bu yükseltme iki önemli özelliğe sahiptir.

“Öncelikle, MainNet'teki akıllı sözleşme işlemlerinin TPS'sini geliştirmeye ve işlem ücretini düşürmeye odaklanarak akıllı sözleşme işlemlerini destekliyor. İkinci olarak yan zincir; farklı geliştirici gruplarının gereksinimlerini karşılayan yan zincir teşvikleri, işlem oranları, işlem onay hızı ve diğer parametreler gibi daha fazla özelleştirilebilir gereksinimleri destekleyebilir.”

DAppchain özelliğinin sınırsız ölçeklendirme kapasitesi sağlayabildiği söyleniyor. DPoS Konsensüsünü kullanacak ve Ana Zincir Ağ Geçidi (MainChain Gateway) aracılığıyla çapraz zincir iletişimine imkân verecektir.

Bu, Aelf ile nasıl karşılaştırılır?

2017 yılında geliştirilecek olan Blockchain ekosisteminin teknik yapısını ve bileşenlerini açıklayan Aelf Whitepaper (https://aelf.io/gridcn/aelf_whitepaper_TR.pdf?v=1) yayınlandı. Projeye ilişkin ilk genel bakış, Aelf'in ana hedeflerinin tartışıldığı belgenin ikinci bölümünde bulunabilir.

Click the image to open in full size.

5 hedef listeler ve birincisi ticari kullanım için özelleştirilebilir işletim sistemidir. Tasarım, bir Blockchain sisteminin temel fonksiyonlarını içeren temel bir Aelf Kernel içerir - minimum uygulanabilir Blockchain sistemi. Müşteriler, daha sonra temel Blockchain’i özel gereksinimlerine uyacak şekilde değiştirebilir ve değişiklik kolaylığı için modüler bir tasarımdan faydalanabilirler. Teknik dokümantasyona göre, TRON’un DAppChain'in ikinci özelliği, ‘Yüksek derecede Özelleştirilebilir Bir Yan Zincir’dir. Bu bölümde açıklanan diğer tek şey, bunun TRON ana zincirinden farklı olmasıdır.

Aelf'in ikinci hedefi, Çapraz Zincir Etkileşimi ile ilgilidir. Whitepaper’da belirtildiği gibi:

“Aelf; Bitcoin, Ethereum ve diğer Blockchain sistemleri ile etkileşime girebilir.”

Bu, Aelf ekosistemindeki her bir yan zincir arasındaki birlikte çalışabilirliğe ektir. Aelf Blockchain’in birlikte çalışabilirliği, sadece diğer yan zincirlerden gelen verilerin okunmasına izin vermekle kalmaz; ayrıca belirli bir Blockchain’deki bir eylemin başka bir eylemi veya alternatif bir Blockchain’deki akıllı sözleşmeyi tetiklemesini sağlar.

Bunun aksine TRON DAppChain, yan zincirlerin yalnızca ana zincirle etkileşime girme ve hatta yalnızca aralarındaki varlıkları transfer etme kabiliyetine sahip görünüyor.

Click the image to open in full size.

(https://tron.network/sunnetwork/doc/...-chain-details)

Aelf’in üçüncü amacı, Aelf modelinin Blockchain ekosistemine getireceği gelişmiş performansı göstermektedir. Aelf; paralel işleme, küme düğümleri ve veri tabanı ayrımı dâhil olmak üzere Blockchain’in genel performansını iyileştirmek için birkaç yaklaşım kullanmıştır. Bu, saniye başına işlemi (TPS) 15.000'e çıkardı.

Click the image to open in full size.

TRON, TPS’lerini 2.000 TPS olarak zirveye çıkardı. Sun Network Dokümantasyonuna (https://tron.network/sunnetwork/doc/...chain-features) göre, DAppChain ilavesi TPS'de sonsuz bir artışa izin veriyor:

“TRON ekosisteminin tamamının TPS’si, yan zincir sayısının artışı ile 2000*SideChainNum (yan zincir sayısı) değerine ulaşabilir.”

Bu, her yan zincir hâlâ sadece 2.000 TPS'ye ulaşabildiği için mantıksızdır. Unutulmaması gereken ana unsur, her bir yan zincirin 2.000 işlemin tamamını kullanabilecek kendi uygulamasına sahip olmasıdır.

Bu hatalı mantığı Aelf ile karşılaştırırsak, TRON'daki 10 yan zincir her biri 2.000 kez 10 veya 20.000 işlem gerçekleştirebilir. Ancak bu sayı, Aelf’de 15.000 kez 10 veya 150.000 işlem olur.

Bunlar; Sun Network'ün temel unsurlarıdır ve bahsi geçen başka özellikler olmasına rağmen, herhangi bir Blockchain projesinde beklenebilecek şeylerdir. Ancak bu, Aelf için son değildir. Aelf Blockchain’de hâlâ başka iki benzersiz hedef vardır.

Protokol güncellemesi; ağın yeni özellikler eklemesini, hatta Konsensüs Protokolünün güncellemesini hatta yükseltmesini sağlayarak ve çıkmaz durumlardan ve protokol anlaşmazlıklarından kaçınarak ağın uzun ömürlü olmasını garanti eden bir özelliktir.

Özel Zincir Modülü; müşterilerin tam gizlilik, kontrol ve mülkiyet ile kendi yan zincirlerini oluşturmalarına izin verir. Bu; verilerin, süreçlerin ve stratejilerin duyarlılığı nedeniyle kurumsal benimseme için mevcut olması gereken kritik bir özelliktir. Şu anda Sun Network, bu özellikten veya eşdeğer bir şeyden bahsetmiyor.

Sun Network DAppChain güncellemesini inceledikten ve Aelf’in teknolojisiyle karşılaştırdıktan sonra, Aelf'in TRON tarafından belirtilmeyen bazı benzersiz özelliklere ek olarak benzer özellikler sağladığı anlaşılıyor. Bu yeni yükseltmede geliştirilen her özellik, 2 yıldan fazla bir süre önce Aelf Whitepaper'da yer almıştır ve teknik ekibimiz tarafından yıllar süren gelişme görmüştür.

KAYNAK: https://medium.com/aelfblockchain/si...e-7fd1beca8769
__________________
▬▬ ▮ ▮ ▮ ▬▬ Aelf Resmi Türkiye Grubu ---> https://t.me/aelf_turkish ▬▬ ▮ ▮ ▮ ▬▬
KursatAelf isimli Üye şimdilik offline konumundadır   Alıntı ile Cevapla
18.Ağustos.2019, 14:15   #172
KursatAelf
Soft Fork
 
KursatAelf - ait Kullanıcı Resmi (Avatar)
 
Mesajlar: 179
Konular: 2
Üyelik: 18.Ocak.2019
Twitter: KursatAelf
Tecrübe Puanı: 0
KursatAelf is an unknown quantity at this point
Standart

Aelf Teknik Konuşmalar: Geliştiricinin GetConsensusCommand'ı Elde Etmesi

Bölüm 3

Click the image to open in full size.

GetConsensus Command arayüzü, bir halka açık anahtarın bir sonraki üretim bloğunun zamanı gibi bilgileri elde etmek için kullanılır.

AEDPoS uygulamasında giriş, sadece bir halka açık anahtardır ve arayüz uygulama yönteminin çağrı süresi başka bir referanstır (aslında önemli bir giriş). AElf Blockchain’de sistem salt okunur işlemleri çağırdığında, sözleşme yürütmenin bağlamı kendisi tarafından oluşturulur. Çağrı süresi, C#'daki kendi fonksiyon kütüphanesi ile DataTime.UtcNow tarafından üretilir ve sonra sözleşme yürütülmesine geçirilen protobuf tarafından sağlanan zaman damgası (Timestamp ) veri tipine dönüştürülür.

Aslında yapılacak işlemin salt okunur bir işlem olup olmadığına bakılmaksızın mevcut sözleşme yürütme bağlamından geçen zaman damgası, Context.CurrentBlockTime aracılığıyla sözleşme kodunda elde edilebilir.

Bu makale, öncelikle AEDPoS konsensüsünün GetConsensusCommand'a nasıl ulaştığını inceleyecektir. Bundan önce, AElf konsensüsüne aşina olmayanlar için AEDPoS sürecinin kısa bir tanıtımı olacaktır.

AEDPoS Süreci

DPoS’un temel kavramı üzerinde duralım. AElf'in ana zincirinin şimdi 17 oy ile seçtiğini varsayalım. Bunu (geçici olarak) AElf Çekirdek Veri Merkezi veya CDC (Core Data Center) olarak adlandıracağız (Eos'ta BP'ler (Blok Üreticileri - Block Producers) kavramına karşılık gelir).

Bu CDC'ler, referandumla belirli bir blok yükseklikte (veya zaman noktasında) doğrudan ilk 17 adaydan elde edildi. İlk 17 aday tekrar sayılır ve CDC yeniden atanırsa, “Term” olarak adlandırılır.

Her bir aşamada tüm CDC'ler, raunt bloklar halinde üretilir. Her rauntta 17 + 1 zaman dilimi vardır ve her bir CDC, rastgele olarak ilk 17 zaman diliminden birinde bulunur. Son zaman dilimi, bu raunttaki ilave blokların üreticisi tarafından üretilir. İlave blok üreticileri, her bir CDC tarafından bu rauntta yayınlanan rastgele sayıya dayanarak bir sonraki bilgi raundunu başlatır. 18 slottan sonra bir sonraki raunt, bir döngü tamamlanarak başlar.

Bir raundun veri yapısı aşağıdaki gibidir:

Click the image to open in full size.

AEDPoS sözleşmesinde bir harita yapısı vardır. Anahtar, bir uzun tür Raunt Sayısıdır. 1’den 18’e her değer, yukarıda belirtilen raunt yapısıdır. CDC tarafından oluşturulan her blok, konsensüs ve blok üretimini teşvik etmek ve konsensüs doğrulaması için bir temel sağlamak için mevcut veya bir sonraki bilgi raundunu günceller.

Teknik detaylarla ilgileniyorsanız, AElf Whitepaper’ın 4.2.4. bölümünü (https://aelf.io/gridcn/aelf_whitepaper_TR.pdf?v=1) inceleyebilirsiniz. Uygulama detayları için, AEDPoS Konsensüs Sözleşme projesini Github'da (https://github.com/AElfProject/AElf) inceleyebilirsiniz.

ConsensusCommand

ConsensusCommand’in yapısı, AElf Konsensüs Sözleşme Standardı'nda belirtilmiştir:

Click the image to open in full size.

AEDPoS konsensüs için Hint, daha sonra CDC’nin ne tür blokların üretileceğini gösterir. Özel bir veri yapısı ile Hint sağlarız, AElfConsensus Hint:

Click the image to open in full size.

Blok türleri aşağıdaki gibi Behaviour (Davranış)'a dâhil edilmiştir:

Click the image to open in full size.

Açıklama:

UpdateValue ve UpdateValueWerPReviousInValue, CDC'nin belirli bir rauntta üreteceği ortak bir bloğu temsil eder. CDC'nin güncellemeye odaklandığı konsensüs bilgisi; bu rauntta previous_in_value, out_value generated ve bu rauntta out_value üretmek için kullanılan in_value kod parçalarını içerir (CDC, 16 şifre parçalarını in_value ve diğer CDC’nin halka açık anahtarı ile şifreleyecektir). Diğer CDC'ler yalnızca kendi özel anahtarlarıyla şifresini çözebilir. Şifresi çözülen parçaların sayısı belirli bir seviyeye ulaştığında, orijinal in_value değeri ortaya çıkar. Bu, Shamir’in gizli paylaşımının bir uygulamasıdır. Diğer CDC'ler, yalnızca kendi özel anahtarlarıyla onların şifresini çözebilir. Şifresi çözülen parçaların sayısı belirli bir seviyeye ulaştığında, orijinal in_value ortaya çıkar. Bu, Shamir’in gizli paylaşımının bir uygulamasıdır.

Not: Ayrıntılar, Google’da bulunabilir ve AElf ana zinciri, ECDH ile uygulanır.

Ek olarak, blok üretim davranışını tetiklemek için actual_mining_times’a bir zaman damgası eklenir. UpdateValueWithoutPreviousInValue ve UpdateValue arasındaki fark, şu anki/mevcut raunt ilk raunt olduğundan ya da az önce değiştirildiğinden (yeni bir CDC oylandı) in_value (previous_in_value)’nun son raundunun bu kez yayınlanmasının gerekmemesidir.

NextRound, CDC'nin bu raundun ilave blok üreticisi olduğunu (veya belirtilen ek blok üreticisi olmadığında çözümü) temsil eder ve bir sonraki bilgi raundunu başlatır. Bir sonraki bilgi raundunda, her bir CDC için slot düzenlemesi ve kurallarla belirtilen bir sonraki raunt için ilave blok üreticileri bulunmaktadır.
NextTerm, NextRound ile benzerdir. Ancak ilk 17 seçimi tekrar hesaplar ve yeni CDC listesine dayanarak bir sonraki bilgi raundunu başlatır.

Hiçbir şey, giriş halka açık anahtarın bir CDC olmadığını keşfetmektir.

TinyBlock, CDC’nin yeni konsensüs bilgisini güncellediğini ancak zaman dilimi henüz geçmediğini ve fazladan birkaç blok üretmek için zamanı olduğunu gösterir. Şu anda her zaman dilimi, sekiz küçük parçaya kadar üretebilir. Bu yaklaşımın avantajı, blok doğrulamanın verimliliğini geliştirmek ve arttırmaktır (Eos'a benzer).

Özel dikkat gerektiren bir zaman dilimi sorunu vardır. AEDPoS Genesis Bloğunda ilk konsensüs bilgi raundunu oluşturmayı seçtiğinden (yani tüm ilk CDC zaman dilimleri vb.) ve Genesis Bloğu her düğüm için tamamen tutarlı olması gerektiğinden, konsensüs bilgisinin ilk raundu birleşik bir süre atanmalıdır (Aksi takdirde, Genesis Bloğunun karma (hash) değerleri farklı olacaktır). Şimdi 0001 yılında saat 0:00’tır. Bu, ilk raunt için son derece yanlış bir zaman dilimi ile sonuçlanacaktır (tüm CDC'ler 2000’den fazla yıl ile zaman dilimlerini kaçıracak). Bu nedenle ConsensusCommand'in ilk raundu elde edilirken özel işlem yapılacaktır.

GetConsensusBehaviour

AEDPoS sözleşmesinde GetConsensusCommand yöntemini ConsensusCommand'a geri döndürmek için ilk önce giriş halka açık anahtarı ve arama süresini temel alarak AElfConsensusBehaviour elde edilir. Sonra AElfConsensusBehaviour, diğer bilgiler arasında bir sonraki blok süresini belirlemek için kullanılır.

Buradaki mantık, göreceli olarak açıktır ve bir grafik ile açıklanabilir.

Click the image to open in full size.

Kodun tamamı için Aelf’in GitHub ana sayfasını (https://github.com/AElfProject/AElf) inceleyebilirsiniz.

GetConsensusCommand — UpdateValueWithoutPreviousInValue

AElfConsensusBehaviour.UpdateValueWithoutPreviousI nValue’nun ana işlevi, yalnızca bir taahhüt aşaması içeren ancak ortaya çıkarma aşamasını içermeyen Taahhüt Şeması'nı (WiKi girişi) uygulamaktır. Her bir seansın ilk raundu olan (zincir yeni başladığında birincisi dâhil) konsensüs Madencilik Süreci aşamasına karşılık gelen CDC, bu döngünün ilk bloğunu oluşturmaya çalışacaktır.

İlk rauntta birinci raunddaysak, bu rauntta AEDPoS konsensüsünün Round.real_time_miners_information’dan bilgilerinden halka açık anahtarlar sağlayan CDC'nin sırasını okumamız gerekir. Blok zamanının order * mining_interval milliseconds.Mining_interval’dan sonra varsayılan olarak 4000 ms'ye kadar olmasını bekliyoruz.

Aksi takdirde expect_mining_time doğrudan Round bilgisinden okunur ve consensusCommand buna göre döndürülür.

Click the image to open in full size.

GetConsensusCommand — UpdateValue

AElfConsensusBehaviour.UpdateValue, Taahhüt Şeması’nda bir ortaya çıkarma aşamasını ve yeni bir taahhüt aşamasını içerir. Konsensüs Madencilik Sürecine karşılık gelen aşama, her bir seansın ikinci raundudur ve ondan sonra CDC, bu raundun ilk bloğunu oluşturmaya çalışır.

Doğrudan okuma, expected_mining_time alanı mevcut raundun raund bilgisindeki CDC'nin halka açık anahtarına karşılık gelir.

Click the image to open in full size.

GetConsensusCommand — NextRound

AElfConsensusBehaviour.NextRound, mevcut rauntta CDC tarafından yayınlanan bilgilere göre bir sonraki raunttaki her CDC'nin dizisini ve karşılık gelen zaman aralıklarını oluşturacak ve RoundNumber'ı bir sayı geriye doğru itecektir.

Bu rauntta ilave blokların üreticisi olarak belirtilen CDC için, bu raunttaki ilave blokların üretilen zaman dilimini okumak yeterlidir.

Belirlenen ekstra blok üreticisinin hattı terk etmesini veya bloğu başka bir çatallanma için bırakmasını önlemek için (ağ kararsızlığı durumunda çatallanma meydana gelir), diğer tüm CDC'ler de bir CDC tarafından üretilen herhangi bir ilave bloğa senkronize edildikten sonra duracak olan ilave blokların üretimi için farklı bir zaman dilimi alacaktır. CDC'ler, çatışmalardan etkilenmemek için zamanlayıcılarını sıfırlamaya devam edecektir.

Özel işlemin ilk raundu için: AElfConsensusBehaviour.UpdateValueWeaPGeviousInVal ue.

Click the image to open in full size.
Click the image to open in full size.

GetConsensusCommand — NextTerm

AElfConsensusBehaviour.NextTerm, yeni seansın ilk raundu için bilgi üretmek üzere mevcut seçim sonuçlarına dayanarak 17 CDC'yi yeniden seçecektir. İlk seansın ilk raundu, AElfConsensusBehaviour.NextRound ile özel olarak işlem görmez.

Click the image to open in full size.
__________________
▬▬ ▮ ▮ ▮ ▬▬ Aelf Resmi Türkiye Grubu ---> https://t.me/aelf_turkish ▬▬ ▮ ▮ ▮ ▬▬
KursatAelf isimli Üye şimdilik offline konumundadır   Alıntı ile Cevapla
18.Ağustos.2019, 14:16   #173
KursatAelf
Soft Fork
 
KursatAelf - ait Kullanıcı Resmi (Avatar)
 
Mesajlar: 179
Konular: 2
Üyelik: 18.Ocak.2019
Twitter: KursatAelf
Tecrübe Puanı: 0
KursatAelf is an unknown quantity at this point
Standart

👆(Devamı)👆

GetConsensusCommand — TinyBlock

AElfConsensusBehaviour.TinyBlock iki durumda oluşur:
1- Şu andaki mevcut CDC, önceki rauntta ilave blok üreticisidir. NextRound işlemlerini içeren bloklar ürettikten sonra, aynı zaman diliminde yedi bloğa kadar üretmeye devam etmesi gerekir.
2- Mevcut CDC, UpdateValue işlemlerini içeren blokları az önce üretti ve aynı zaman diliminde yedi bloğa kadar üretmeye devam etmesi gerekir.

Temel değerlendirme mantığı; eğer mevcut CDC son ilave bloğun üreticisi ise, 4000ms'lik bir zaman dilimini sekiz 500 ms'lik zaman dilimine bölecek ve dağıtacaktır. Aksi takdirde, ilk durum için doğrudan öncekine dayalı olacak ve üretilen blok sayısı için makul bir zaman dilimi ayıracaktır.

Click the image to open in full size.
Click the image to open in full size.

Son olarak blok yürütme süre sınırının tekrardan ayarlanması

Bir sonraki üretim bloğunun zamanını Behavior'a göre hesapladıktan sonra, bir sonraki hızlı zamanın negatif olması mümkündür (şu anki zamanın bir sonraki bloğun teorik zamanını aşması). Bu durumda blok paketleme süresi sınırı, 0 olarak ayarlanabilir. Son olarak sistem işlemleri oluşturna, ağ gecikmeleri ve benzeri işlemler için belirli bir zaman ayırmak amacıyla blok yürütme süresi sınırı bir katsayı (optimize edilen) ile çarpılır.

Click the image to open in full size.

Yukarıdaki kodun tamamını Github'da (https://github.com/AElfProject/AElf/...nsensus.AEDPoS) inceleyebilirsiniz.

Olası optimizasyon talimatları

Mevcut mantık optimizasyon koşullarına bağlı olarak, kod okunabilirliğini artırmak için mümkünse bir fonksiyon olarak uygulanabilir.
Kodları incelemekten ve herhangi bir hata veya öneriyi geliştirme ekibimize göndermekten lütfen çekinmeyiniz.

KAYNAK: https://medium.com/aelfblockchain/ae...d-e4b68f5d3c0e
__________________
▬▬ ▮ ▮ ▮ ▬▬ Aelf Resmi Türkiye Grubu ---> https://t.me/aelf_turkish ▬▬ ▮ ▮ ▮ ▬▬

Konu KursatAelf tarafından (18.Ağustos.2019 Saat 14:19 ) değiştirilmiştir.
KursatAelf isimli Üye şimdilik offline konumundadır   Alıntı ile Cevapla
20.Ağustos.2019, 09:32   #174
KursatAelf
Soft Fork
 
KursatAelf - ait Kullanıcı Resmi (Avatar)
 
Mesajlar: 179
Konular: 2
Üyelik: 18.Ocak.2019
Twitter: KursatAelf
Tecrübe Puanı: 0
KursatAelf is an unknown quantity at this point
Standart

🔊 Yıllık 110 milyon dolar ciro elde eden Japonya'nın en büyük hediye kartı ticaret platformu olan Amaten, Aelf Blockchain'de altyapısını genişletiyor olacak.

https://twitter.com/aelfblockchain/s...94759975612421
__________________
▬▬ ▮ ▮ ▮ ▬▬ Aelf Resmi Türkiye Grubu ---> https://t.me/aelf_turkish ▬▬ ▮ ▮ ▮ ▬▬
KursatAelf isimli Üye şimdilik offline konumundadır   Alıntı ile Cevapla
21.Ağustos.2019, 11:03   #175
KursatAelf
Soft Fork
 
KursatAelf - ait Kullanıcı Resmi (Avatar)
 
Mesajlar: 179
Konular: 2
Üyelik: 18.Ocak.2019
Twitter: KursatAelf
Tecrübe Puanı: 0
KursatAelf is an unknown quantity at this point
Standart

Japonya’nın en büyük hediye kartı borsası Aelf ile partner oldu

Amaten, Blockchain ağ sağlayıcısı Aelf ile ortaklaşa tokenize edilmiş hediye kartları çıkaracaktır.

Click the image to open in full size.

Japonya’nın en büyük hediye kartı borsası, bir sonraki büyüme aşamasını teşvik etmek için Blockchain kullanmayı planlıyor.

Hediye kartları için ikincil bir pazar olan Amaten, 20 Ağustos'ta yayınlanan açıklamaya göre, Singapur merkezli bulut bilişim Startup’ı Aelf ile ortak olduğunu duyurdu. Borsa, Aelf’in kurumsal odaklı Blockchain platformunu kullanarak operasyonlarını uluslararası olarak ölçeklendirmeyi planlıyor.

Click the image to open in full size.

2012 yılında kurulan Amaten, Japonya’nın hediye kartı borsa hacminin yüzde 40’ını elde etmek için büyüdü ve yıllık yaklaşık 110 milyon dolar gelir elde ediyor. Küresel ölçekte, hediye kartı endüstrisi, 340 milyar dolarlık bir piyasaya girdi.

Hediye kartları Aelf platformunun yönettiği dijital varlıklara dönüştürerek firma, “hediye kartlarının çıkarılması, satın alınması ve değiş tokuşu ile ilgili köklü değişikliklere” önem veriyor.

Amaten Başkanı Tom Kanazawa, “Hediye kartları için kullanılan mevcut sistem ve teknoloji, tamamen modası geçmiştir ve 90'ların ortasına kadar uzanmaktadır.” ifadelerini kullandı.

“Hâlâ temel temel eksikliklerden zarar görmektedir ve çok elverişsizdir. Hediye kartı endüstrisinin Blockchain için mükemmel bir kullanım alanı olabileceğine inanıyorum.”

Click the image to open in full size.

Aelf Blockchain, bir hediye kartı ihracının ve sahiplik değişimlerinin değişmez bir kaydını sağlayacak ve böylece Amaten platformunun şeffaflığını artıracaktır.

Kanazawa, “Biz, Aelf ile ortaklık kurmayı seçtik çünkü hizmetlerimizi hızlı ve en uygun maliyetli bir şekilde oluşturmak için ihtiyaç duyduğumuz ölçeklenebilirliği, özel yan zincirleri ve akıllı sözleşme modüllerini sunuyorlar.” ifadelerini kullandı.
Ayrıca firma, Blockchain’in harcanmamış hediye kartı miktarını azaltabileceğini ileri sürüyor.

Aelf’in Kurucu Ortağı ve COO’su Zhuling Chen, “Amaten ile ortaklık aracılığıyla, geleneksel endüstrilerde Blockchain çözümlerinin benimsenmesine öncülük etmeyi umuyoruz.” ifadelerini kullandı.

Daha fazla bilgi için aelf.io ve amaten.io (Japon hediye kartı borsası için amaten.com) adreslerini ziyaret edebilirsiniz

KAYNAK: https://medium.com/aelfblockchain/ja...f-ce145891c42f

Aelf ile Amaten arasındaki ortaklıkla ilgili basında yer alan diğer haberler:

- Coindesk --> https://www.coindesk.com/japans-larg...lockchain-firm

- Yahoo Finance --> https://finance.yahoo.com/news/age-d...070000988.html

- Markets Insider --> https://markets.businessinsider.com/...ion-1028458092

- CoinTelegraph --> https://cointelegraph.com/news/japan...ain-gift-cards

- CryptoBriefing --> https://cryptobriefing.com/aelf-amaten-card-exchange/
__________________
▬▬ ▮ ▮ ▮ ▬▬ Aelf Resmi Türkiye Grubu ---> https://t.me/aelf_turkish ▬▬ ▮ ▮ ▮ ▬▬
KursatAelf isimli Üye şimdilik offline konumundadır   Alıntı ile Cevapla
22.Ağustos.2019, 12:23   #176
KursatAelf
Soft Fork
 
KursatAelf - ait Kullanıcı Resmi (Avatar)
 
Mesajlar: 179
Konular: 2
Üyelik: 18.Ocak.2019
Twitter: KursatAelf
Tecrübe Puanı: 0
KursatAelf is an unknown quantity at this point
Standart

Aelf'e Çin Elektronik Standardizasyon Enstitüsü (CESI) tarafından bir sertifika verildi. Bu neden ve nasıl Aelf için bir dönüm noktasıdır?

Click the image to open in full size.
Click the image to open in full size.
Click the image to open in full size.
Click the image to open in full size.
__________________
▬▬ ▮ ▮ ▮ ▬▬ Aelf Resmi Türkiye Grubu ---> https://t.me/aelf_turkish ▬▬ ▮ ▮ ▮ ▬▬
KursatAelf isimli Üye şimdilik offline konumundadır   Alıntı ile Cevapla
24.Ağustos.2019, 11:32   #177
KursatAelf
Soft Fork
 
KursatAelf - ait Kullanıcı Resmi (Avatar)
 
Mesajlar: 179
Konular: 2
Üyelik: 18.Ocak.2019
Twitter: KursatAelf
Tecrübe Puanı: 0
KursatAelf is an unknown quantity at this point
Standart

Aelf Teknik Konuşmalar: Güvenli Bir Şekilde Blockchain’de Rastgele (Random) Bir Sayı Oluşturma (ACS6)

Bölüm 4


Click the image to open in full size.

AElf rastgele sayı sözleşme standardı (ACS6)

Bu makale; Blockchain sistemlerindeki rastgele sayılar için yaygın çözümlere, rastgele sayılar sağlayan akıllı sözleşmeler için AElf tarafından sağlanan standart arayüzlere ve ACS6 için AEDPoS sözleşmelerinin uygulanmasına odaklanmaktadır.

Blockchain ve rastgele sayı

Blockchain geliştirilmesinde sözleşmeyle ilgili rastgele sayı uygulamaları için birkaç senaryo var: piyangolar, doğrulama kodları, şifre korelasyonları vb.

Blockchain esasen dağıtılmış bir sistem olduğundan, her bir düğümün operasyon sonuçlarının doğrulanabilir olmasını gerektirir. Geleneksel rastgele sayı üretme çözümleri, farklı makinelerde tutarlı sonuçlar üretmeyecek ve tüm düğümlerin aynı rastgele sayıyı üretmesini sağlayacaktır. Bu nedenle, bu tür sistemler ile aşırı gecikmelere neden olmaması mümkün değildir.

Bir Blockchain ağında kabul edilen rastgele bir sayı üretebilmenin açık yararları vardır. Mevcut birkaç seçenek var:

- Merkezi bir parti rastgele sayılar üretir. Rastgele sayılar, güvenilir bir üçüncü tarafça sağlanır (ör: Random.org).

- Taahhüt yöntemi (hash-commit-reveal yöntemi). AElf Whitepaper’da belirtildiği gibi AElf ana zincir konsensüsü, üretim emrini belirlemek için her bloğun hem in_value hem de out_value değerini belirlemek için kullanılır. Blok üreticisi, yerel olarak rastgele bir karma üretir. Out_value = karma (in_value) olduğu yerde bir in_value özel olarak ayarlandıktan sonra vaadi (yani out_value) açıklanır ve rastgele karma değeri in_value daha sonra uygun bir zamanda yayınlanır. Diğer düğümlerin yalnızca out_value == karma (in_value) doğrulaması gerekir. Buradaki in_value rastgele bir sayı olarak düşünülebilir.

- Blockchain durum bilgilerinin bir tohum olarak toplanması ve sözleşmede belirlenmiş bir algoritma ile rastgele bir sayı oluşturulması. Algoritmanın bilinmesi halinde (akıllı sözleşmenin kodu halka açıktır) ve doğru tohum elde edildiğinde, bu program tarafından oluşturulan rastgele sayı daha sonra başarılı bir şekilde tahmin edilebilir.

Merkezsizleşme perspektifinden bakıldığında Taahhüt yöntemi, yukarıda belirtilen seçeneklerden kullanılabilecek tek çözümdür. Bu durumda asıl endişe, rastgele sayıyı üreten kişinin gizlice önceden ifşa etmemesini veya aldatmak için kullanmamasını sağlayarak giderilebilir.

Ancak maalesef ki Blockchain sisteminde bu garanti edilemez: rastgele sayıyı üreten kişinin, örneğin rastgele sayının kumar olarak kullanıldığı gibi, gizli amaçlar için bilgileri kullanmayacağını garanti edemeyiz. Piyango ayarlandığında rastgele sayının üreticisi, oyun başlamadan önce söz verilmiş olsa bile, rastgele sayının açıklamasını askıya alabilir - bu, “tekrar oynama” fırsatına eşittir çünkü eğer bu düğüm bu rastgele sayıyı açıklamazsa, sistem başka bir düğümden başka bir rastgele sayı seçecek veya kumar geçersiz olacaktır.

Ya stokastik sayı üreticilerinin saldırıyı durdurmayı seçmeleri engellenirse? Bir dizi olgun çözüm vardır, Gizli Paylaşım gibi.

Örnek: Şimdi her biri bir halka açık-özel anahtar çiftine sahip olan A’dan E’ye beş kişi vardır. Bu zamanda A, karşılık gelen taahhüdü üreten rastgele bir sayı Random üretir. Aynı zamanda, rastgele sayı Random dört Paylaşım Parçası elde etmek için B, C, D ve E'nin halka açık anahtar ile şifrelenmiştir. Paylaşım Parçaları şifrelendiğinde, B ~ E'de yalnızca iki kişinin Random’ı kurtarabileceği ve Paylaşma Parçaları ile Taahhüdü bir araya getirebileceği garanti edilir. Bu nedenle, A kendi nedenleriyle Random’ın değerini yayınlamazsa bile, B ~ E’deki herhangi iki kişi kendileri tarafından alınan Paylaşım Parçalarının şifresini kendi özel anahtarlarıyla çözebilir ve iki şifresi çözülmüş değeri derleyebilir (A'ya göre şifrelenebilir). Random sonra geri yüklenebilir. Bir veya iki Paylaşım Parçası Random’ı düzeltemediğinde, onlar sadece A'nın en baştan kötü niyetli davranmaya karar verdiğini varsayabilirler - Bu durumda Blockcahin ekonomik sistemine göre, sadece A cezalandırılır. Örneğin, A’nın başvurusunun doğrudan kesilmesi, rastgele bir sayı üreticisinin ödediği marj olarak ifade edilir.

Ek olarak bir bireyin ürettiği rastgele sayıya güvenmemeyi seçebilir, ancak karma değerini uygulama senaryosunda mevcut rastgele sayı olarak hesaplamak için birden fazla kişinin rastgele sayılarını seçebiliriz. Bu şekilde, daha fazla kararlılık ve güvenlik ile bir Blockchain sisteminde rastgele sayılar elde edebiliriz.

ACS6 - Rastgele Sayı Sağlayıcı Sözleşme Standardı

Bir önceki makalede, konsensüs için AElf Blockchain’in sözleşme standardını açıkladık, bu aslında AElf ana zincir geliştiricisinin sözleşme geliştiricileri için konsensüs mekanizmaları uygulaması için tavsiye edilen arayüzdür. Rastgele sayı üretimi ile ilgili olarak, rastgele sayılar sağlayan herhangi bir sözleşme önerisi için uygulanacak bir arayüz olarak ACS6'yı geliştirdik.
Beklendiği gibi ACS6, Taahhüt şemasını soyutlamayı ve sözleşme standardını almayı seçti.

ACS6 kullanımını destekleyen senaryo aşağıdaki gibidir:

Kullanıcılar, emir göndermeye benzer şekilde ACS6 uygulayan bir sözleşme için rastgele bir numara için başvururlar.

ACS6 sözleşmesi uygulanır ve kullanıcının hangi blok yüksekliğinde (H) rastgele bir sayı alabileceği ve kullanıcının rastgele sayı için alabileceği referans T (ayrıca bir karma değeri) dâhil olmak üzere kullanıcıya bazı bilgiler geri döndürülür.

Blockchain yüksekliğinin H yüksekliğine ulaşmasını bekledikten sonra kullanıcı, işlemi rastgele sayı almaya çalışmak için gönderir ve referans T işlemin parametresi olması gerekir.

ACS6 sözleşmesi, referans T'ye göre rastgele bir sayı döndürür.

Kullanıcı H yüksekliğinden önce rastgele sayı almaya çalışırsa, çağrı yürütme için başarısız olur ve yüksekliğin henüz gelmediğini belirten bir Onay İstisnası alır.

Yukarıdaki senaryoya göre, ACS6'yı aşağıdaki gibi tasarladık:

Click the image to open in full size.

Kullanıcı rastgele bir sayı için başvuru yapmak için bir RequestRandomNumber işlemi gönderir. Sözleşmenin istek için bir token_hash oluşturması ve ardından tokeni kullanıcıya rastgele sayı elde edebileceği blok yüksekliği ile birlikte kullanıcıya geri döndürmesi gerekir. Yüksekliğe ulaşıldığında kullanıcı, uygun bir rastgele sayı elde etmek için alınan token_hash'ı kullanarak GetRandomNumber işlemini gönderir. Bir sözleşme olarak bu yöntem uygulanırken kullanıcı tarafından oluşturulan referanslar önbelleğe alınmalıdır. Bir haritanın (map) anahtarı olarak haritanın değeri, kendi veri yapısını sözleşmenin rastgele sayıları uygulamasına göre tanımlamalıdır.

Örneğin AEDPoS sözleşmesi ACS6'yı uyguladığında, Haritanın değeri şöyle tanımlanabilir:

Click the image to open in full size.

Round_number, kullanıcı tarafından uygulanan rastgele sayıyı üretmek için her bir CDC tarafından yayınlanan hangi previous_in_value değerinin kullanılması gerektiğini belirtir. Emir, emirin raundun CDC'si tarafından paketlenen rastgele numara için başvurduğu RandomNumberProviderControl işlemidir (önceki yayınlanan daha sonra turda gereklidir). We_in_value, rastgele sayı üretimi için ham maddedir. Expected_block_height, kullanıcının beklemesi gereken bloğun yüksekliğidir.
__________________
▬▬ ▮ ▮ ▮ ▬▬ Aelf Resmi Türkiye Grubu ---> https://t.me/aelf_turkish ▬▬ ▮ ▮ ▮ ▬▬
KursatAelf isimli Üye şimdilik offline konumundadır   Alıntı ile Cevapla
24.Ağustos.2019, 11:32   #178
KursatAelf
Soft Fork
 
KursatAelf - ait Kullanıcı Resmi (Avatar)
 
Mesajlar: 179
Konular: 2
Üyelik: 18.Ocak.2019
Twitter: KursatAelf
Tecrübe Puanı: 0
KursatAelf is an unknown quantity at this point
Standart

👆(Devamı)👆

ACS6 için AEDPoS sözleşmesinin uygulanması

AEDPoS konsensüsü ilerletme sürecinde benimsenen hash-commit-reveal yaklaşımı nedeniyle her bir CDC için sıradan blokların (ekstra bloklardan farklı olarak) üretilmesi sırasında yayınlanan previous_in_value değeri, doğrudan rastgele sayılar üretmek için ham madde olarak kullanılabilir. Herhangi bir düğüm yeni bir blok yürütmeden önce, yeni yayınlanmış prior_in_value doğrulaması (yani doğrulama karması (hash) (previous_in_value) == previous_out_value) gerçekleşir. Blok en iyi zincirle başarılı bir şekilde senkronize edildiği sürece, yayınlanan previous_in_value öğesinin hileli davranışı konusunda endişelenmeye gerek yoktur.

Bu bölümün uygulanmasının yalnızca ACS6'nın tanımının tamamlanmasından kısa bir süre sonraki bir girişim olduğunu ve bundan sonra herhangi bir zamanda önemli değişiklikler olabileceğini unutmayınız.

Tek endişe, CDC komplosudur. Bu nedenle AEDPoS rastgele sayı üretmeyi uyguladığında, rastgele sayı üretmek için yalnızca bir CDC’nin previous_in_value değerini kullanmaz aynı zamanda beşli kümeler kullanır:

Click the image to open in full size.

Bir kullanıcı AEDPoS'dan rastgele bir sayı talep ettiğinde, geçerli raundun yayınlanabilir previous_in_value değerinin yayınlandığından emin olmak için yalnızca geçerli raundun son dilimine (ekstra blok dilimi) kadar bekleyebilir. Bu raunda yeni eklenmiş bir CDC varsa (belki az önce çatallaşmayı çözdüler), yayınlayacak bir previous_in_value sahip olmayacaklar veya yerel önbelleğe alma sorunları nedeniyle previous_in_value yayınlayamamış olabilirler. İlave blokların dilimine gelince previous_in_value değerleri, gizli paylaşımın ortaya çıkarma aşamasını tamamlar. Restore edildi - Eğer kullanıcıların rastgele sayılar almak için ortaya çıkarma aşamasından önce GetRandomNumber işlemlerini göndermelerine izin verirsek, ortaya çıkarma evresinden önce ve sonra elde edilen rastgele sayılar ciddi sorunlara neden olabilecek kadar tutarsız olabilir.

Click the image to open in full size.

Kullanıcılar referanslarıyla rastgele sayılar almaya çalıştığında AEDPoS, kullanıcılar rastgele sayılar için başvurduktan sonra CDC'ler tarafından yayınlanan beş previous_in_values değeri toplar, bu beş karma ile bir karma değerini hesaplar ve bunları kullanıcılara rastgele bir sayı olarak geri döndürür.

Click the image to open in full size.
Click the image to open in full size.

Daha sonra, bu iki yönteme BVT test durumları eklenmiştir (AElf sözleşmelerinin test edilmesi için bir yapı vardır). Bir kod üreteci, bir sözleşme yöntemi çağırabilecek bir Stub oluşturmak için kullanılabilir. Stub, kullanıcı tarafından gönderilen işlemleri bir Blockchain’de simüle edebilir ve her işlem ayrı olarak bir bloğa paketlenir.

Zincirin başında simüle edilmiş herhangi bir kullanıcının Stub’ı, uygun bir RandomNumberOrder elde edip edemediğini kontrol etmek için RequestRandomNumber işlemini gönderir. Gerekli sözleşmeler test durumu yürütülmeden önce çok sayıda işlem aracılığıyla (şu anda 19) dağıtıldığından RequestRandomNumber yürütüldüğünde blok yüksekliği 20'ye ulaştı.

Click the image to open in full size.

Belli bir yükseklikten (bir round süresi) sonra simüle edilen kullanıcı, rastgele sayıyı almak için GetRandomNumber işlemini gönderir. Sonraki test durumları normal blok işlemi için CDC’nin ilk raundunu simüle eder ve ayrıca ExpectedBlockHeight'tan önce ve sonra GetRandomNumber’ı göndermeyi dener. Yüksekliğe ulaşılmadığında, işlem yürütme başarısız olur ve “Rastgele(random) sayı hâlâ hazırlanıyor” hata mesajı ortaya çıkar. İkinci GetRandomNumber gönderildiğinde, işlem yürütme başarılı olur ve kullanılabilir rastgele sayı döndürülür; ve üçüncü GetRandomNumber, rastgele sayı hakkındaki bilgiler AEDPoS sözleşmesi tarafından silindiği için gönderilir (boşluk mekanizması tasarrufu), böylece boş bir karma (hash) değeri döndürür.

Click the image to open in full size.
Click the image to open in full size.

KAYNAK: https://medium.com/aelfblockchain/ae...6-37e355522c72
__________________
▬▬ ▮ ▮ ▮ ▬▬ Aelf Resmi Türkiye Grubu ---> https://t.me/aelf_turkish ▬▬ ▮ ▮ ▮ ▬▬
KursatAelf isimli Üye şimdilik offline konumundadır   Alıntı ile Cevapla
Cevapla

Etiketler
aelf, bir, için, olarak, yan

User Tag List

Seçenekler
Stil

Yetkileriniz
Konu Acma Yetkiniz Yok
Cevap Yazma Yetkiniz Yok
Eklenti Yükleme Yetkiniz Yok
Mesajınızı Değiştirme Yetkiniz Yok

BB kodu Açık
Smileler Açık
[IMG] Kodları Açık
HTML-Kodu Kapalı

Forum Jump


Tüm Zamanlar GMT +3 Olarak Ayarlanmış. Şuanki Zaman: 04:33.


Powered by vBulletin® Version 3.8.9
Copyright © 2019 vBulletin Solutions, Inc. All rights reserved.