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

Aelf Çin'de Blockchain’e ve DLT Ulusal Standardı'na Rehberlik Etmeye Yardımcı Oluyor

Aelf, “Bilgi Teknolojileri Blok Zinciri ve Dağıtılmış Defter Teknolojisi (Distributed Ledger Technology – DLT) Referans Mimarisi” Ulusal Standartlar Derleme Toplantısına katıldı.

20 Eylül 2019'da Sanayi ve Bilgi Teknolojileri Bakanlığı CESI (Çin Elektronik Teknolojisi Standardizasyon Araştırma Enstitüsü) tarafından düzenlenen “Bilgi Teknolojileri Blok Zinciri ve Dağıtılmış Defter Teknolojisi Referans Mimarisi” Ulusal Standartlar Derleme Toplantısı Şanghay’da yapıldı. Toplantıya katılmak için Aelf Teknik Ekosistem Direktörü Zongzhe Huang; Çin Halk Bankası’ndan, Çin Menkul Kıymetler Düzenleme Komisyonu’ndan, Nankin ve Fudan Üniversiteleri’nden ve diğer kurum ve kuruluşlardan kıdemli uzmanlarla birlikte toplantıya davet edildi.

Ulusal Standartlar Derleme Toplantısı; Bilgi Teknolojileri Blok Zinciri ve Dağıtılmış Defter Teknolojisi Referans Mimarisinin ulusal standardına odaklandı. Toplantıda, aşağıdaki hususlara ilişkin tartışmalar yer aldı:

• Blockchain referans mimarisinin kullanıcı ve fonksiyonel görünümü

• Kullanıcı görünümü roller, alt roller ve etkinlikleri ve roller arasındaki ilişkileri içerir

• Fonksiyonel görünüm, fonksiyonel bileşenleri ve bunların belirli fonksiyonlarını içerir

• Fonksiyonel bileşenler arasındaki ilişkiler

Uzmanlar ve bilim adamları, “Bilgi Teknolojileri Blok Zinciri ve Dağıtılmış Defter Teknolojisi Referans Mimarisi” konulu titiz bir analiz ve derinlemesine gösteri yönettiler. Huang, nihai karar için oy kullanmadan önce tartışmaya aktif olarak katıldı. Uzmanlar ve bilim adamları; kendi görüşlerini paylaştı, farklı endüstri perspektiflerinden revizyon görüşlerini sağladı ve fikir alışverişi yaptı ve bir sonraki adım için hazırlık planını açıkladılar.

Gelişen bir teknoloji olarak Blockchain; finansal hizmetler, tedarik zinciri yönetimi, eğlence, akıllı üretim, sosyal refah ve eğitim istihdamı alanlarında geniş bir uygulama alanına sahiptir. Blockchain standardizasyonu; Blockchain anlayışını birleştirmeye, çeşitli endüstrilerdeki Blockchain uygulamalarını yönlendirmeye ve Blockchain'in temel teknik konularını desteklemeye yardımcı olur.

Aelf, Blockchain endüstrisinin standardizasyonuna katkıda bulunmak için hem teknik hem de pratik açıdan endüstri standartları tartışmalarına aktif olarak katılmaya ve endüstri standartlarının iyileştirilmesine katkıda bulunmaya devam edecektir.

KAYNAK: https://medium.com/aelfblockchain/aelf-helps-guide-blockchain-and-dlt-national-standard-in-china-4805b538e16a

Aelf Teknik Konuşmalar: Bağımlılık Enjeksiyonu Bölüm 2

SOLID Tasarım İlkeleri

Bu serinin 1. bölümünde Bağımlılık Enjeksiyonu ve IoC tartışıldı. Bağımlılık Enjeksiyonu derinlemesine girmeden önce, nesne yönelimli tasarım modelinin beş SOLID ilkesini anlamak önemlidir. Bu bölümde ilk üç ilke incelenecektir.

1) Tek Sorumluluk İlkesi (SRP, Single Responsibility Principle)

> Bir sınıfın değişmesi için hiçbir zaman birden fazla sebep olmamalıdır.

Bir şaka duymuş olabilirsin:

- Hata olmadan kod yazdın mı?

- Evet, daha önce yaptım: Merhaba Dünya.

Bu paragraf bize doğruyu söyler: kod ne kadar basitse, bir hata olması o kadar az olasıdır.

Peki kodu nasıl basitleştiririz? Her kod satırını yazarak tek bir şey yapmak için. Uygulamada, bir sınıfın sadece bir şey yapmasına izin verdik. Ve eğer bu sınıfa basit ve sezgisel bir isim verebilirsek, kodun kendisinin bildirilmesi çok iyi olacaktır. Alibaba’nun Java spesifikasyonunun, bir sınıfın bir tasarım deseni kullanıyormuş gibi adlandırma için gereksinimleri olduğunu hatırlıyorum. Tasarım deseninin adını ismin içinde yerleştirmek gerekir. Şu anda, yorumlar gereksizdir ve kod insanların okuması ve bakımı için kolaydır.

Tek sorumluluk ilkesinin tanımına geri dönelim. Martin, bir sorumluluğu değişimin nedeni olarak tanımlar ve bir sınıf veya modülün değiştirilmek üzere bir ve yalnızca bir nedeni olması gerektiği sonucuna varır (yani yeniden yazılması). Örnek olarak, bir rapor derleyen ve yazdıran bir modül düşünün. Böyle bir modülün iki nedenden dolayı değiştirilebileceğini hayal edin. İlk olarak, raporun içeriği değişebilir. İkincisi, raporun formatı değişebilir. Bu iki şey çok farklı nedenlerle değişir. Tek sorumluluk ilkesi, sorunun bu iki yönünün gerçekten iki ayrı sorumluluk olduğunu ve bu nedenle ayrı sınıf veya modüllerde olması gerektiğini söylüyor. Farklı zamanlarda farklı nedenlerle değişen iki şeyi birleştirmek/eşleştirmek, kötü bir tasarım olacaktır.

Bir sınıfı tek bir endişeye odaklamanın önemli olmasının nedeni, sınıfı daha sağlam ve güçlü kılmasıdır. Yukarıdaki örnekten devam edersek rapor derleme işleminde bir değişiklik olursa, aynı sınıfın bir parçasıysa yazdırma kodunun kırılması daha büyük bir tehlikedir.

Ayrıca bir sınıfın tek sorumluluk ilkesine uygun olup olmadığına karar vermek için bir standart vardır. Bu, sınıftaki öğelerin uygunluğuna bağlıdır. Bir yineleyici uygulayan bir sınıfta yazma fonksiyonuna sahip olamazsınız. Bunun hakkında düşünmeyin. En önemseyeceği panonun boyutunu kontrol etmesidir. Başka bir deyişle, panonun kendisi yineleyicilerin sınıfına dahil edilmemeli, yalnızca bir hizmet olarak var olmalı ve Depo modunu kullanmayı düşünebilirsiniz.

Yüksek korelasyon, yüksek uyum ve işlevde daha küçük bir granülite anlamına gelir.

Burada belirtilen sınıf, bir varlığa veya bir servise başvurabilir. Domain-driven Design kitabında Eric, uygulamadaki nesneleri üç türe ayırır: değerler, varlıklar ve hizmetler. Bir varlık, değerlerin bir kombinasyonu olarak düşünülebilir ve bir hizmet, iş mantığını içeren koddur.

2) Açık Kapalı Prensibi (Open Closed Principle - OCP)

> Sınıflar, modüller ve fonksiyonlar gibi yazılım varlıkları; uzantı için açık olmalı ancak varlığın kaynak kodunu değiştirmeden davranışının genişletilmesine izin verebilecek şekilde değişikliklere kapalı olmalıdır.

Açık Kapalı Prensipten bahsedersek bu, dekoratör modeli aracılığıyla anlaşılması özellikle kolay olan bir tasarım desenidir. Bir senaryo hayal edebiliriz. Bir süpermarkette yazarkasa sistemi veya bir e-ticaret web sitesi yapıyoruz. Her halükârda emtia varlığı vardır. Emtia varlığı, bir GetPrice (FiyatAl) yöntemine sahiptir ve şimdi ürüne bir indirim işlevi eklemelisiniz. Malın sınıf kategorisinin tek sorumluluk prensibine uygun olduğunu varsayarsak, şu anda üç seçenek vardır:

1. Şimdi ihtiyacınız olan işlevselliği sağlamak için arayüze bir yöntem ekleyin.
2. Sınıfın uygulamasını modifiye edin ve yeni özellikler imzalamak ve sağlamak için önceki yöntemi kullanın.
3. Bir sınıfı tekrar oluşturun, önceki uygulama sınıfını kalıt alın (inherit), önceki yönteme bir katman yerleştirin ve yeni bir uygulama sağlayın.

Açık Kapalı Prensibi, üçüncü çözümü seçmemizi önerir. Bunun nedeni arayüzü modifiye ederek, bu arayüzü uygulamak isteyen diğer sınıfların uygulamayı eklemesi gerekir. Bu yeni uygulamanın gereksiz olması muhtemeldir, çünkü tüm ürünler için aynı gün içerisinde indirim yapılması muhtemel değildir. İkinci çözüm, sadece tehlikeli bir operasyondur. Kesinlikle birim testini etkileyecektir (eğer varsa) ve hataların ortaya çıkması gibi büyük bir olasılık vardır. Üçüncü seçenek en güvenli olanıdır. Önceki uygulama için bir dekoratör sağlayabiliriz ve ardından yeni işlevsellik sağlamak için dekoratör çağırabiliriz. Önceki örnekte önceki uygulama, ürünün orijinal fiyatını dekoratörün “indirim dekoratörü” olarak adlandırdığı şeyi döndürmektir ve daha sonra indirimli fiyatı döndürmek için aynı yöntemi çağırır. Önceki uygulama, yapıcı parametreleri vasıtasıyla dekoratöre enjekte edilir. Gerçek kullanım o kadar basit olmayabilir ancak bu, prensibin basit bir açıklamasıdır.

Daha sonra enjeksiyonun birleşik kökü hakkında konuştuğunuzda, tekrar Açık Kapalı Prensipten bahsedeceksiniz.

3) Liskov'un Yerine Geçme Prensibi (Liskov Substitution Principle - LSP)

> Temel sınıflara işaretçiler veya referanslar kullanan fonksiyonlar, türetilmiş sınıfların nesnelerini bilmeden kullanabilmelidir.

Bu en gözden kaçan prensiplerden biri gibi görünüyor.

Sorunlara neden olan “is a” tekniğinin klasik örneği daire-elips problemidir (ya da dikdörtgen kare problemdir). Ancak, ben penguen kullanacağım.

İlk önce, gökyüzünde uçan kuşları gösteren bir uygulama düşünün. Birden fazla kuş türü olacaktır ve bu nedenle geliştirici, yeni kuş türlerinin eklenmesiyle ilgili kodu “kapatmak” için Açık Kapalı Prensibini kullanmaya karar verir. Bunu yapmak için, aşağıdaki soyut Kuş temel sınıfı oluşturulur:

BirdsFlyingAroundApp sürümünün büyük bir başarıdır. İkinci versiyon, kolaylıkla başka 12 farklı kuş türünü ekler ve ayrıca bir başarıdır. Yaşasın Açık Kapalı Prensibi! Ancak, uygulamanın üçüncü sürümü penguenleri desteklemek için gereklidir. Geliştirici, Kuş sınıfından kalıt alan yeni bir Penguen sınıfı yapar, ancak bir sorun vardır:

Bir geçersiz kılma yöntemi hiçbir şey yapmazsa veya yalnızca bir istisna atarsa, muhtemelen LSP'yi ihlal ediyorsunuzdur.

Uygulama çalıştırıldığında tüm uçan modeller yanlış görünür, çünkü Penguen nesneleri setAltitude yöntemini önemsemez. Penguenler sadece yerde dolaşıyorlar. Geliştirici OCP'yi izlemeye çalışsa da başarısız oldu. Penguen sınıfına uyması için mevcut kodun modifiye edilmesi gerekir.

Bir penguen teknik olarak “kuş” iken, Kuş sınıfı tüm kuşların uçabileceğini varsaymaktadır. Penguen alt sınıfı uçuş varsayımını ihlal ettiğinden, Kuş sınıfı için Liskov'un Yerine Geçme Prensibi’ni karşılamıyor.

LSP'yi İhlal Etmek Neden Kötüdür?

Soyut bir temel sınıf kullanmanın amacı; gelecekte yeni bir alt sınıf yazıp mevcut, çalışan ve test edilmiş bir koda ekleyebilmenizdir. Açık Kapalı Prensibinin özü budur. Ancak, alt sınıflar soyut temel sınıfın arayüzüne uygun bir şekilde bağlanmadığında, mevcut alt kodu gözden geçirmeniz ve hatalı alt sınıfları içeren özel durumları hesaba katmanız gerekir. Bu, Açık Kapalı Prensibinin açıkça ihlalidir.

Örneğin, bu kod parçasına bir bakınız:

LSP, kodun Kuş nesnesinin gerçek sınıfını bilmeden çalışması gerektiğini söylüyor. Ya devekuşu gibi bir başka uçamayan kuş türü eklemek isterseniz? O zaman mevcut tüm kodunuzu gözden geçirmeli ve Kuş işaretçilerinin gerçekten Devekuşu işaretçisi olup olmadığını kontrol etmelisiniz.

İki Olası Çözüm

Mevcut kodu modifiye etmeden Penguen sınıfını ekleyebilmek isteyebiliriz. Bu, kötü kalıtım hiyerarşisini LSP'yi karşılayacak şekilde düzelterek sağlanabilir.

Sorunu çözmenin çok iyi olmayan bir yolu, isFlightless adlı Kuş sınıfına bir yöntem eklemektir. Bu şekilde, en azından OCP'yi ihlal etmeden uçamayan kuş sınıfları eklenebilir. Bu, şöyle bir kodla sonuçlanacaktır:

Bu gerçekten geçici bir çözümdür. Temel sorunu çözmedi. Sadece sorunun belirli bir nesne için var olup olmadığını kontrol etmenin bir yolunu sağlar.

Uçamayan kuş sınıflarının uçan sınıfları üst sınıflarından kalıt almadığından emin olmak daha iyi bir çözüm olacaktır. Bu böyle yapılabilir:

Kuş temel sınıfı, herhangi bir uçan işlevsellik içermez ve FlightfulBird alt sınıfı, bu işlevselliği ekler. Bu, bazı işlevlerin hem Kuş hem de UçanKuş nesnelerine uygulanmasına izin verir. Ancak, uçamayan olabilecek Kuş nesneleri, FlightfulBird nesnelerini alan işlevlere dönüştürülemez.

Bu serideki bir sonraki bölümde, Bağımlılık Enjeksiyonunun son bölümü daha ayrıntılı olarak tartışmadan önce kalan 2 prensip incelenecektir.

KAYNAK: https://medium.com/aelfblockchain/aelf-tech-talks-dependency-injection-part-2-c2525376e8e8

Aelf, BTCManager ile partnerlik kurdu. Yeni partnerlik ile birlikte artık Aelf ile ilgili tüm haberleri https://btcmanager.com/ adresinde bulabilirsiniz.

aelf Enterprise (Kurumsal) 0.8.0 Beta Resmi Olarak Yayınlandı

aelf Enterprise 0.8.0 beta; bütün bir blockchain sistemi, geliştirme kitleri, geliştirme belgeleri ve destekleyici altyapı ve altyapı hizmetlerini içeren eksiksiz ve tam bir blockchain ticarileştirme çözümü setidir.

aelf Enterprise 0.8.0 beta sürümü sistem entegrasyonu

1. aelf Enterprise
• aelf Enterprise v0.8.0 beta
• DevKit v0.8.0 beta

2. aelf Harici Uygulamalar
• aelf blockchain tarayıcı v0.1.6
• aelf tarayıcı MySQL plugin v0.8.0 beta
• aelf kaşifi v0.8.0 beta
• aelf cüzdan v0.8.0 beta
• aelf JS SDK v3.2.17
• aelf JS SDK Çapraz Zincir v1.0.1
• Nodejs v0.1.15’te aelf CLI

3. aelf Tarayıcı Uzantısı V0.8.0 beta

Aelf Enterprise 0.8.0 beta sürümünün Aelf Enterprise 0.8.0 alfa sürümüne kıyasla önemli özellikleri şunlardır:
• Geliştirilmiş stabilite
• Daha eksiksiz ekonomik sistem
• Çapraz zincir kabiliyetinin tam seti
• Daha eksiksiz çapraz zincir destek araçları

Bu güncelleme ve önemli özellikleri

aelf Enterprise v0.8.0 beta:

AEDPOS Konsensüs Mekanizması:
• Rastgele blok sırası
• Üretim bloğu mantığı
• Konsensüs doğrulama ve hile cezası

Ekonomik sistem:
• Teklif ve çoklu imzalama mekanizması
• Üç oylama modeli (parlamento oyu / birlik oyu / referandum)
• Bancor tabanlı TOKEN (çoklu varlık) ticareti
• Düğüm seçimi oylama / değiştirme
• Temettü / ödeme mekanizması

Ana zincir:
• P2P ağı ve düğüm yönetimi
• Ticaret havuzu
• Zincir yönetimi
• Blok / işlem doğrulama ve yönetimi
• Veri depolama
• WebAPI arayüzü
• Komut satırı arayüzü
• SDK geliştirme (Javascript)

Çapraz zinciri:
• Alt zincir ve ebeveyn zincir indeksleme mekanizması
• Çapraz zincir doğrulama ve çapraz zincir transfer

Sözleşme sistemi:
• Çalışma süresi (Runtime)
• Sözleşme Geliştirme SDK
• Sözleşme güvenlik kontrolü
• Sözleşme geliştirme standardı (acs)

Paralel yürütme:
• Kaynak algılama ve gruplama
• Gruplar arasında paralel yürütme
• Çatışma yönetimi

DevKit:
Geliştirici Belgeleri
• Yeni düğüm yapısı
• Yeni çapraz sözleşme çağrıları
• CLI kullanım belgeleri güncellendi
• WebAPI kullanım belgeleri güncellendi, RPC ile ilgili belgeler kaldırıldı


aelf Harici Uygulamalar güncellemesi:

aelf Cüzdanı:
• Çoklu token durumunda işlem kaydı sorgusunun hatası düzeltildi

aelf Kaşif:
• Arayüz yeniden yapılandırma, yüzlerce milisaniyede arayüz yanıtı
• Mantığın kısmı websocket kullanılarak optimize edilmiştir
• İşlem kaydı sorgu optimizasyonu

aelf JS SDK Çapraz Zincir:
• Çapraz zincir JS SDK eklendi

Nodejs’de aelf CLI
• Yeni teklifle ilgili yöntemler eklendi

Entegrasyon özelliklerine giriş:

1. aelf Enterprise
• aelf Enterprise v0.8.0 beta https://github.com/AElfProject/AElf
— Yüksek Performanslı Akıllı Sözleşme Çalışma Zamanı
— Konsensüs Sistemi
— Çoklu Token Sistemi
— Oylama sistemi
— Çapraz Zincir Sistemi
— Web API

• DevKit
— Boilerplate https://github.com/AElfProject/aelf-boilerplate
— TestKit
— BenchmarkKit
— IDE entegrasyonu
— Belgeler https://docs.aelf.io/
— Öğreticiler https://docs.aelf.io/main/main

1.1 aelf Enterprise v0.8.0 beta

Minimize edilmiş blok zinciri kerneli, DPoS konsensüs mekanizması, akıllı sözleşme sistemi, oylama sistemi, token sistemi ve temel çapraz zincir sistemi dahil olmak üzere tam bir blok zincir sistemidir.

Yüksek Performanslı Akıllı Sözleşme Çalışma Zamanı
• Sözleşme yürütme seviyesi: Protobuf’a dayanarak grpc gibi bir akıllı sözleşme yürütme ortamı uygulandı. Tüm nesnelerin girdi ve çıktıları ve depolanması Protobuf yüksek performanslı serileştirme işlemine dayanır. Durum depolaması, redis gibi yüksek performanslı bir dağıtılmış veri tabanı kullanır.
• Genel sözleşme yapısı: grpc eklentisi ile oluşturulan kodlar, bir grpc sunucusuna eşdeğer performansları gösterir.
• Sözleşme Kontrolü: Bloklar içinde paralel yürütme, AKKA kümeleri üzerinden gerçekleştirilebilir.

Konsensüs Sistemi
• Güvenlik: Gizli Paylaşım algoritması, seçilen tüm düğümlerde dağıtılmış rasgele sayıların üretilmesini sağlayabilir. Her turdaki blok üretim sırası; üretilen rasgele sayılarla belirlenir, böylece düğüm gizli anlaşması ve kötü niyetli davranış olasılığını azaltır.
• Verimli: Düğümlerin ⅔'ü bir bloğu doğruladıktan sonra blok, geri ters çevrilemez blok olur ve veriler çatal tarafından ters çevrilmeden zincire kalıcı olarak sabitlenir.

Çoklu Token Sistemi
Sözleşme sistemine dayanarak Blockchain çapraz zincir sağlayabilen dâhili bir Token Sistemi uygulanır. Tüm varlıklar; zincirler arasında ihraç edilebilir, transfer edilebilir ve kilitlenebilir.

Oylama sistemi
Sözleşme sistemine dayanarak bir evrensel oylama sistemi, işlevseldir ve çevrimiçi yönetişimi ve ikincil gelişmeyi kolaylaştırır.

Çapraz Zincir Sistemi
Zincirdeki herhangi bir verinin zincir boyunca iletecek bir mekanizma sağlar. Sistem, Merkle Ağaç Kökü endeksine dayanarak uygulanır ve tüm sistem çok seviyeli ana yan zincir endeksini gerçekleştirebilir, böylece ölçeklendirme ve dağıtıklaştırma gerçekleştirilebilir.

Web API
ASP.Net Çekirdek sunucusu, yüksek performanslı etkileşimli bir yapı gerçekleştirmek için uygulanmaktadır.

1.2 DevKit
https://github.com/AElfProject/aelf-boilerplate
Geliştirme Şablonları ve Öğreticileri, Geliştirici Kılavuzu, TestKit, BenchmarkKit ve IDE Entegrasyonunu içerir
• Geliştirici Kılavuzları: Aelf sisteminin ve API dokümantasyonunun ayrıntılı bir tanıtımını sağlar
• TestKit: Geliştiricilerin sözleşmeleri hakkında kısa bir test yapmasına izin verir
• BenchmarkKit: Dahili performans testi durumları sağlar
• IDE Entegrasyonu: Geliştiricilerin, geliştirme sırasında akıllı sözleşmelerin hatalarını ayıklamalarına izin verir ve birim test kodu kapsamı istemi sağlar

Geliştiriciler, hızlı bir şekilde Aelf temelli Blockchain sistemleri kurabilir ve Aelf tarafından sağlanan geliştirme kitlerine ve araçlarına dayalı olarak Dapp‘ler oluşturabilirler. ve Aelf’i geliştirici dokümantasyonu aracılığıyla hızlıca tanımaya başlayabilirler.

2. Aelf Harici Uygulamalar
Aelf Blockchain tarayıcı https://github.com/AElfProject/aelf-block-scan
• Zincir tarama programı, geliştiricilerin zincirdeki verileri zincir dışında kolayca depolamasını ve böylece geliştirici geliştirme maliyetlerini düşürmesini sağlar.
• Uygulamayı ilgili veri tabanı ile eklemek gerekir, topluluk varsayılan MySQL ekleme sürümü olarak aelf-scan-MySQL sağlar.

Aelf Tarayıcı MySQL eklentisi https://github.com/AElfProject/aelf-scan-mysql
• Geliştiriciler, MySQL veri tabanına veri eklemek için zincir tarama programını kolayca kullanabilir
• İşlem, blok, TPS, kaynak veri depolaması varsayılan olarak desteklenir

Aelf Kâşifi https://github.com/AElfProject/aelf-block-explorer
• Blok ve işlem sorguları uygulandı

Aelf Cüzdan https://github.com/AElfProject/aelf-web-wallet
• Yerel olarak depolanan özel anahtar
• Temel token transferi ve işlem kayıtlarını görüntüleme uygulandı
• Aelf sözleşme tokenlerini arayabilir ve ekleyebilir

Aelf JS SDK https://github.com/AElfProject/aelf-sdk.js
• Aelf'in çapraz link/bağlantı transfer arayüzü, geliştiricilerin hızlı bir şekilde başlamasını kolaylaştırmak için kısa ve öz biçimde açıklanmıştır.

Nodejs’de Aelf CLI https://github.com/AElfProject/aelf-command
• Çok fazla sayıda komut istemi sağlanır.
• Hesap oluşturma, blok bilgisi alma, işlem (trading) bilgisi alma ve sözleşmeleri yayınlama gibi işlevler sağlar.

3. Aelf Tarayıcı Uzantısı
https://github.com/AElfProject/aelf-web-extension
• Özel anahtarları yerel olarak depolar ve bir anahtar yönetim kullanıcı arayüzü sağlar
• Eklenti ve uygulama arasında şifreli iletişim sağlar
• AElf ekosistemindeki DAPP işlem imzalarını destekler
• Kullanıcıların uygulama izinlerini görsel olarak yönetmesini destekler

KAYNAK: https://medium.com/aelfblockchain/aelf-enterprise-0-8-0-beta-officially-released-38b41622893e

Aelf Teknik Konuşmalar: Bağımlılık Enjeksiyonu Bölüm 3

## Arayüz Ayrıştırma Prensibi (Interface Segregation Principle - ISP）

> İstemciler, kullanmadıkları arabirimlere bağımlı olmaya zorlanmamalıdır.

Bir sınıfın diğerine bağımlılığı asgari düzeyde olmalıdır.

Bu prensibi izleyerek, birden fazla sorumluluk için yöntemleri tanımlayan şişirilmiş arayüzleri önlersiniz. Tek Sorumluluk Prensibinde açıklandığı gibi, sık sık değiştikleri ve yazılımınızın bakımını zorlaştırdığı için çoklu sorumluluk içeren sınıflardan ve arayüzlerden kaçınmalısınız.

Bir çapraz sözleşme çağrısı için Aelf ekibi, AElf Sözleşme Standardı (ACS) adlı bir sözleşme standardı sağladı ve her bir ACS bazı Arayüz tanımlar. Çapraz sözleşme çağrısı yaparken, belirli bir ACS'de hangi arabirimin tanımlandığı konusunda endişelenmenize gerek yoktur. Yalnızca istenen ACS'yi uygulayan bir sözleşme sağlamanız gerekir. Öte yandan her bir sözleşme, birden fazla ACS uygulayabilir. Diğer sözleşmeler tarafından çağrıldığında, yalnızca uyguladığı ACS'lerden biriyle ilgilenebilir. Böylece yalnızca bu ACS'ye dayanırsınız ve bu sözleşmeyi almazsınız. Diğer yöntemler, çapraz sözleşme çağrılarına maruz kalmaktadır. Bu sadece arayüz izolasyonu prensibinin bir açıklamasıdır.

Bağımlılık İnversiyon Prensibi (Dependency Inversion Principle - DIP）

> Yüksek seviyeli modüller düşük seviyeli modüllere bağlı olmamalıdır. Her ikisi de soyutlamalara bağlı olmalıdır. Soyutlamalar, detaylara bağlı olmamalıdır. Detaylar, soyutlamaya bağlı olmalıdır.

Bu tanımın önemli bir detayı, yüksek seviye ve düşük seviye modüllerinin soyutlamaya bağlı olmasıdır. Tasarım ilkesi, adını ilk defa okurken beklediğiniz gibi sadece bağımlılığın yönünü değiştirmez. Aralarında bir soyutlama tanıtarak yüksek ve düşük seviye modülleri arasındaki bağımlılığı böler. Sonuçta iki bağımlılık elde edersiniz:

1.Yüksek seviye modülü, soyutlamaya bağlıdır
2.Düşük seviye, aynı soyutlamaya bağlıdır

Bu, olduğundan daha karmaşık gelebilir. Sonuç olarak Açık/Kapalı Prensibini ve Liskov'un Yerine Geçme Prensibini kodunuza uygularsanız, Bağımlılık İnversiyon Prensibi'ni de takip eder.

Bir kelimeyle: arayüz odaklı programlama. Arayüzü daha düşük-seviye modülüne koyabilir ve daha sonra bu arayüzün üst-seviye modülde uygulanmasını sağlayabiliriz. Farklı üst seviye modüller arasındaki iletişim, temel modüllerdeki arayüzlerle de yapılır. Örneğin, Log’u yüksek seviye bir modül olarak ele alıyoruz. Temel modülde farklı log seviyelerinin yazdırılması için bazı yöntemler sağlayan tek bir ILogger arayüzü vardır. Özel yazdırma uygulaması log modülüne yerleştirilir. Diğer modüller kayıt yapmak için log modülüne dayanabilir, NLog kullanabilirsiniz, ayrıca log4net kullanabilirsiniz, log modülü bir bağımlılık haline gelir ve hangisini kullanacağımız bu bağımlılığı manuel olarak nasıl enjekte ettiğimize bağlıdır. Peki nasıl enjekte ediyorsunuz? Daha sonra Bileşim Kökünü (Composition Root) tartışacağız.

Örnek projede gördüğünüz gibi, yalnızca Açık/Kapalı ve Liskov'un Yerine Geçme Prensiplerini kod tabanınıza uygulamanız gerekir. Bunu yaptıktan sonra sınıflarınız, Bağımlılık İnversiyon Prensibi'ne de uyar. Herhangi bir arayüz soyutlamasını değiştirmediğiniz sürece bu, diğer sınıfları etkilemeden daha yüksek ve daha düşük bileşenleri değiştirmenizi sağlar.

# DI, IoC ve DIP arasındaki fark

Buradaki DI, DI kapsayıcı değil DI teknolojisidir. Autofac, Ninject, vb. geliştirilmesinde kullandığımız bağımlılık enjeksiyon yapısı, DI kapsayıcına aittir.

Bileşim Kökü, bir tasarım desenidir. Bu tasarım desenini kullanmanın anahtarı, Bileşim Kökünün bulunduğu yeri bulmak zorunda olduğumuzdur. Neyse ki, öncekiler bize bir çözüm verdi: uygulama giriş noktasına mümkün olduğu kadar yakın… Peki Bileşim Kökü ne içindir? Kısacası, yapılandırma, bu yanıltıcı olabilir, ancak birleşik kök bir DI kapsayıcısıdır- başka bir deyişle, bağımlı bir ilişki kurar. Yani, bu uygulamada hangi soyut tipin hangi özel tipe tekabül ettiği, bileşim kökünde bir şekilde ayarlanması gerektiğidir. Burada belirtilen soyut tip, C#'da bir arayüz veya soyut bir sınıf olabilir. Aslında, DI uygulama pratiğinde bu şekilde soyutlama yapmak önemli değildir. Soyut türünü yalnızca belirli Tür bağımlılıklarına karşılık gelecek şekilde birleşik kökte ayarlamamız gerekir. Bu ayar doğrudan DI kapsayıcısındaki Register veya AddSingleton gibi yöntemleri çağırabilir. Ancak DI teknolojisinin uygulanması, mutlaka bir DI kapsayıcısının kullanılmasını gerektirmez.

Kombinasyon kökleri kavramını "sondan başlayarak" bakış açısıyla yeniden düşünüyoruz: Üretim için kullanılabilecek eksiksiz bir uygulamanın çok sayıda hizmet içermesi gerektiği düşünülebilir ve bu uygulamanın uygulanmasının gevşek bir şekilde birleştirilmesini istiyorsak, arayüz izolasyon prensibi kullanılacaktır. Bir servisteki diğer servisleri kullanmamız gerektiğinde, kodu yazarken hangi servislerin uygulanacağını bilemeyiz, bu nedenle kodda doğrudan bir soyutlama çağırırız. Uygulama çalıştıktan sonra, soyuta yapılan asıl çağrıdan önce bir montaj süreci olmalıdır. Sözde derleme, koddaki soyut türe dayanır ve çalışma zamanında somut bir uygulama sağlar; bu da soyut türler ve belirli türler arasında manuel olarak bir haritalama ilişkisi kurmamızı gerektirir. Birleştirilen kök, ilişkinin manuel olarak sağlandığı yerdir. En kolay konsol uygulaması, çalıştırmak için her bir bileşen arasında iş birliği gerektirecektir. Temel bileşenlere dayanan birçok türde üst düzey bileşen vardır. Şu anda en yaygın kullanılan, yapıcı enjeksiyonudur. Uygulanabilir yapıcı enjeksiyonuna bir arayüz atamazsınız, manuel olarak yeni bir uygulama oluşturmanız gerekir. Bu işlem, soyut türü ve belirli bağımlılık türlerini ayarlamaktır.

Açık Kapalı Prensibe tekrar bakıyoruz, belirli bir fonksiyonun modifiye edilmesi gerektiğinde, orijinal uygulamayı değiştiremeyiz, ancak dekorasyon modu ile bir realizasyon sağlayabiliriz ve daha sonra kombinasyon kökünde yeni bir uygulamaya ilgili bağımlılığı ayarlayabiliriz. Sadece kodu eklemeniz ve kombinasyon kökünü değiştirmeniz yeterlidir. Yeni uygulamanın sorunları varsa, eski uygulamanın gerekli olmadığını öğrenene kadar istediğiniz zaman geri çekebilirsiniz. Bu gereksiz ilişkiyi ortadan kaldırmak için bir yeniden düzenleme adımı uygulanmaktadır. İnsanlar, özellikle çalışmalarını başkalarıyla uzlaştırdıklarında, güvenilmez olabilirler. Bu nedenle, yeniden yapılanmadan önce yeterli birim testi eklememiz ve hatta uygulama öncesi birim testleri yazmamız gerekiyor. Test Odaklı Tasarım, birim testinin önce yazılmasını gerektirir, ünite testi başarısız olursa, test başarılı olana kadar uygulama güncellenir. Ancak yazılım geliştirme burada sona eriyorsa, Test Odaklı değil, yalnızca İlk Test Tasarımı olarak adlandırılabilir. Tasarımın özü yeniden yapılanmadır ve tatmin edici bir düzeye dek ayrıklaştırmadır ve test durumu, yeniden yapılanmanın fonksiyonu bozmayacağının önemli bir garantisidir.

Bu serinin başında da belirtildiği gibi DI, aslında bir IoC uygulamasıdır, ancak IoC kavramı önerdiği bakış açısına göre daha da yönlendirilmiştir. Birçoğu Hollywood ilkesini duydu: beni arama, ben seni çağıracağım. Bu bir bağımlılık modülü olarak somut bir türdür. Ne zaman ve nasıl çağrılacaklarını önemsemelerine gerek yoktur sadece kendilerinin çağrılması için beklemeleri gerekecektir.

Son olarak SOLID'deki DIP, üst seviye modüllerin temel modüllere dayanmaması, hepsinin soyutlamaya dayanması gerektiğini gösterir. Bu açıdan DIP, soyutlamanın derecesine fazla dikkat eder. Yani, özel uygulama ve kodun şekli budur.

Ancak aşağı yukarı bu üç kavramın bir fikri ifade ettiğini, rafine edilmesi gereken bir şey varsa arayüz odaklı programlama olduğunu düşünebiliriz. Arayüzü en alta koymak için uygulama en üste yerleştirilir.

KAYNAK: https://medium.com/aelfblockchain/aelf-tech-talks-dependency-injection-part-3-2c89a6159056

💰Yorum Yap & Kazan!💰

📢 Haftalık Dapper (The Dapper Weekly) Twitter Giveaway burada!

1️⃣ Takip et
2️⃣ Retweetle & Beğen
3️⃣ Favori bölümünü yorum olarak belirt (Tüm bölümler tweet altındadır)

⭐️ Bu Giveaway'e sponsor oldukları için Aelf Blockchain'e, State Of The DApps'e ve Dapp Review'a çok teşekkür ediyoruz!

Tweet: https://twitter.com/mappopk_crypto/status/1181444710943969281

Aelf Teknik Konuşmalar: Bağımlılık Enjeksiyonu Bölüm 4

Bağımlılık Enjeksiyonunun (Dependency Injection - DI) Üç Boyutu

Bu son bölümde, her biri tamamlayıcı olan bağımlılık enjeksiyon teknolojisinin üç boyutu hakkında kısaca konuşacağız.

1) Nesne kombinasyonu

Birleştirilmiş kök, bağımlılıkları yapılandırır.

2) Yaşam Döngüsü Yönetimi

Yalnızca kombinasyon kökünün bağımlılığı belirleyen yerleşim olduğunu söyledik. Aslında bağımlılığı ayarlarken bağımlılık enjeksiyonu, ayrıca her nesnenin yaşam döngüsünün yönetilmesini gerektirir.

DI uygulanırken, bağımlılıkların birleştirilmiş kök içerisinde ayarlandığını zaten biliyoruz. Ayrıca birleşik nesnenin nesnesine veya yöntemine kompozitör olarak başvurabiliriz. Birleştirici, düzeneğin dayandığı nesneyi ifade eden birleşik bir terimdir. Veya yöntem. Genel olarak bir DI kapsayıcısı, bir birleştiricidir.

Birleştiricinin varlığından dolayı nesne, bağımlılıklarının oluşturulmasını yönetmemeye mahkumdur. Bağımlılığın tahribi nedir? Bağımlılıklar zamanında tahrip edilmezse, bellek sızıntısı riski vardır.

.NET kullanan herkes GC'nin otomatik olarak kullanılmayacak nesneleri geri kazanacağını bilir ve IDisposable arayüzünü uygularsak, nesneleri kendimiz imha edebiliriz.

DI'de, bir nesnenin yaşam döngüsü bir birleştirici tarafından yönetilir. Birleştirici, bağımlı bir nesnenin diğer farklı nesnelerle paylaşılıp paylaşılmayacağına veya nesneyi ne zaman serbest bırakacağına karar verebilir: belirli bir tüketicinin kapsamı dışında mı yoksa tüm tüketicilerin rolü ötesinde mi bırakılacağına karar verebilir.

Nesne yaşam döngüsünün yönetimi, bağımlılık enjeksiyonunda en karmaşık problemlerden biri olmalıdır. Bağımlılık enjeksiyonunun uygulanmasını desteklemek için Uzantılar adlı Microsoft’un Repo’suna göz atalım. Bu proje, tüm nesnelerin “ServiceLifetime” da tanımlanan üç yaşam tarzına sahip olduğunu belirtir. Kelimenin kendisi yaşam tarzı ya da iş tarzı anlamına gelir ve bir yaşam döngüsü türüne çevrilmiş gibi görünmektedir. Bu üç yaşam döngüsü tipi, DI kapsayıcısı perspektifinde daha iyi anlaşılabilir, ancak DI kapsayıcısı kullanılmadığında nesne yaşam döngülerini yönetme önerisi de mevcuttur. Bu üç kategori hâlâ geçerlidir:

- Singleton. Aynı soyutlama örneği, başvuru boyunca her zaman paylaşılır.

- Kapsamlı. Belirli bir rol için bir singleton kullanmak, ancak farklı kapsamlar için farklı örnekler sağlar.

- Geçici. Her istek yeni bir örnek döndürür.

3) Intercept

Teoride, kod uygulaması SOLID ilkesine uygunsa, dekoratör modunda Cephe yönelimli programlama (Aspect-oriented programming - AOP) uygulanabilir. Genel yaklaşım, önceki XXService için XXServiceDecorator adlı bir alt sınıf oluşturmak, XXService'e XXServiceDecorator'a bir yapıcı parametresi olarak enjekte etmek ve XXServiceDecorator'da genelde, doğrudan çağrı, koşullardan önce ve sonra intercept için XXService yöntemini yeniden uygulamaktır. Son olarak, birleştirilmiş kökte XXService yerine XXServiceDecorator değerini ayarlayın.

Not: AOP uygulamanın, Dinamik Interception (dinamik proxy de denir) ve Derleme Süresi Weaving (ayrıca IL Weaving olarak da bilinir) olmak üzere iki yolu vardır. Bu iki konu hakkında inceleme yapmayacağız.

# Demo

https://github.com/EanCuznaivy/DIDemo?source=post_page-----3015d4a5f7a1----------------------

KAYNAK: https://medium.com/aelfblockchain/aelf-tech-talks-dependency-injection-part-4-3015d4a5f7a1

✅ Zhuling Chen ve Aelf Singapur ekibi, Huawei Konferansına katılmak üzere davet edildi. Zhuling; Aelf Blockchain'in avantajları ve sürekli büyüyen, olası kullanım durumları ve Huawei ile olan partnerlik ile ilgili bir sunum yaptı.

Blockchain Küresel Göç için Kutsal Kâse midir?

Göç; genellikle yeni bir ülkede demokratik bir varoluşu sürdürmeyi ümit eden savaş, baskı ve ırkçılıktan kaçan vatandaşlar için son çaredir. Blockchain teknolojisi; göçmenler, teknoloji uzmanları, hükümetler, Sivil Toplum Kuruluşları (STK'lar) ve bu süreçteki diğer seçmenler için ortaya çıkan çeşitli zorlukların çözülmesine yardımcı olabilir. Bu makalede Blockchain'in göç sürecini daha adil ve ilgili tüm taraflar için daha şeffaf hale getirmesine yardımcı olabilecek bazı yöntemleri inceleyeceğiz. İlk önce ABD Başkanı Donald Trump'ın önerdiği yeni göç politikalarına değineceğiz, daha sonra Blockchain teknolojisinin yardımıyla göçün daha demokratik hale gelebileceği 4 ana yöntem üzerinde duracağız.

Son zamanlarda ABD Başkanı Donald Trump'ın ABD'deki mülteci yerleştirmesini azaltmak için yarattığı tartışmalı yürütme emrine karşı çıkan bir hareket başladı. Trump'ın önerisi, 2020 mali yılı içinde ABD'ye girmesine izin verilen mülteci sayısını 18 bine kadar azaltabilir. Geçen yıl Trump, ülkeye kabul edilen mültecilerin sayısını 30 binin altında bir rekor olarak belirledi. Bunların çoğu, başkanın Meksika ve Orta Amerika’daki çeşitli ülkelerden gelen mültecilere bakış açısından kaynaklanıyor. Trump yönetimi tarafından bu yaklaşım, dünyadaki birçok kişi için kabul edilebilir değildir ve #Blackout4Refugees küresel etiketini yaratan etkendi. ABD’ye mültecilerin kabulüne ilişkin ortalama yıllık kota 1980’den başlayarak her yıl 95 bini aştı.

Blockchain teknolojisinin benimsenmesi, dünyanın en büyük zorluklarının çoğunu çözmede kritik öneme sahiptir. Halka Açık Blockchainler’in gerçekten devrimci yapan birçok özellik aşağıda uluslararası ve tanınmış Blockchain uzmanı Andreas Antonopoulos tarafından belirtilmiştir. Andreas'ın eğitim materyallerinin çoğunda odaklandığı 5 ana Blockchain teknolojisi dayanağı vardır: 1.) Açık 2.) Genel/Halka Açık 3.) Sınırsız 4.) Nötr/Yansız 5.) Sansür Dirençli. Blockchain teknolojisini gerçek bir ezber bozucu yapan 6. kalite, değişmezliğidir. Aelf’in Blockchain ağının, küresel göç uygulamalarının daha verimli ve şeffaf bir şekilde ilerlemesini sağlayacak bazı nitelikleri vardır. Bunlar arasında birlikte çalışabilirlik, optimize edilmiş bir yönetim yapısı, uyarlanabilirlik ve hızlı, yüksek derecede ölçeklenebilir bir protokol vardır.

Blockchain teknolojisinin göçmenler, hükümetler ve göçmenleri ülkelerine kitlesel olarak kabul eden diğer ögeler için şeffaflığı artırmaya yardımcı olabileceği çeşitli yöntemler vardır:

1. Dijital Kimliklere ve Diğer Temel Belgelere Erişilebilirlik

Göçmenlerin başka bir ülkeye göç etmeyi kabul edilmeden önce Kimlik (ID) ve diğer önemli belgelerini 2 yıla kadar hükümetlere teslim etmeleri gerekmektedir. Bunun gibi durumlar genellikle aşırı derecede verimsiz hükümet uygulamalarının ve diğer faktörlerin bir sonucudur. Dijital bir kimliğe uygun erişime sahip olmak, başka bir ülkeye göç etmiş biri için de çok önemlidir. Bir kullanıcının Passport, Sürücü Belgesi veya Kimlik Numarasının dijital bir versiyonunu saklamak, bireyin kimliğini her zaman kanıtlayabileceği anlamına gelir. Bu, yetkililerin kişisel bilgileri aramalarını ve göç etme haklarını sürdüren bir kişinin güvenilirliğini kanıtlamalarını sağlar. Dijital kimlikler ayrıca her yıl çok sayıda mülteci alan ülkelere yardımcı olmaktadır. Bu, yeni ülkelerine geniş sağlık hizmetleri ve sabıka kaydı kontrolleri yoluyla bireyleri eleme imkânı veriyor. Bu sürecin, dünya çapındaki uluslardaki yerli vatandaşların güvenliğini olumlu yönde etkilediği görülmüştür. Daha fazla şeffaflık, hem göçmenler hem de onları kabul eden ülkeler için daha fazla sorumluluk anlamına gelir. Blockchain teknolojisi; Myanmar, İsrail veya Macaristan gibi belirli etnik azınlıklardan yararlanılan bölgelerde gücün kötüye kullanılmasının önlenmesine yardımcı olabilir. Örneğin bir kişinin kimliğini kanıtlama yeteneği, Rohingya Müslümanları için yaşam ile ölüm arasındaki fark anlamına gelebilir. Blockchain teknolojisi; dünyamızdaki dijital kimliğin daha şeffaf, güvenli ve değişmez bir şekilde ilerlemesini sağlar.

2. Bir Butona Tıklayarak Değer Aktarımına Anında Erişilebilirlik Verilmesi

Dünya genelinde milyonlarca göçmen işçi düzenli olarak kendi ülkelerindeki ailelerine geri para gönderiyor, böylece hayatta kalabiliyorlar. Mobil Blockchain cüzdanlarını kullanmak, birçok bölgedeki kişilerin geleneksel banka hesaplarına erişmenin genellikle mümkün olmadığı finansmana erişmesini sağlar. ELF, Ethereum, Bitcoin veya diğer tür kripto paraların transferi; değerin bir alıcıdan diğerine anında aktarılmasını sağlar. Bankalar ve finansal kurumlar yüksek düzeyde ücretler alırlar ve işlemlerin tamamlanması günler alır. Bu, binlerce kilometre uzaklıkta aileleri için geçim kaynağı sağlayan göçmenler ve göçmen işçiler için sürdürülebilir değildir. Yeni mobil ödeme altyapısı; mobil Blockchain cüzdanına sahip kullanıcıların gıda, benzin ve hayatta kalabilmek için gereken çeşitli diğer temel malzemeleri ödemesini mümkün kılıyor.

3. Şeffaflığı Sağlamak İçin Mülteci Sorunlarına Yönelik Kitle Fonlamasının ve Bağışların Takibi

Blockchain teknolojisi; kitle fonlama işleminin güvenli, erişilebilir ve şeffaf olmasının yanı sıra genel olarak doğrulanabilir olmasını sağlar. Bu; para birimini oluşturmak, dağıtmak ve değiştirmek için bir platform olarak onu mükemmel yapar. Bu süreç, özellikle dünyanın her yerindeki vatandaşların, yeni ülkelerde yerleşen mültecilerin ve göçmenlerin refahına maddi olarak katkıda bulunmalarına yardımcı olmak için etkilidir. Bağışları ve kitle fonlama katkılarını daha güvenli ve dürüst bir şekilde takip edebilme yeteneği, hırsızlığı neredeyse imkânsız kılarken fonların maksimum etkisini de sağlar. İhtiyacı olanlara yardım etmek için bu modeli kullanan çeşitli Blockchain projeleri vardır. Blockchain teknolojisini kullanan kitle fonlaması platformlarının başarı oranları genellikle kullanmayanlardan daha yüksektir. Geleneksel işletme finansmanı genellikle elde etmek çok zordur, çünkü genellikle kendi kendini finanse etme, banka finansmanı veya risk sermayesi şirketleri tarafından gerçekleştirilir. Çoğu insan için kendi kendini fonlama son derece sınırlıdır, banka finansmanı ise güçlü gelir ve nakit akışı olan mevcut bir işi gerektirir. Girişim sermayesi, genellikle güçlü bir talebe sahip olan bir ürünü veya hizmeti ve piyasaya sürülmeye yakın bir işi gerektirir. Aelf'in Blockchain teknolojisi, ileriye dönük zor durumlarla karşı karşıya kalan göçmenler için kitle fonlaması sürecini geliştirmek için kullanılabilir.

4. Hükümetler ve Sivil Toplum Kuruluşları Tarafından Sahte/Hileli Göçmen Politikaları Olasılığını Azaltma

Göçmenler ve mülteciler, Blockchain teknolojisini yalnızca faydaları için kullanamazlar. Bu süreç; hükümetler, STK’lar ve diğer seçmenler tarafından haksız yere istismar edilen göçmen haklarının korunmasına yardımcı olur. Bu kuruluşlar, sıkı göç politikalarını dürüst ve güvenilir bir şekilde kullanarak sorumlu tutulmalıdır. Dünyadaki birçok ülkede, mültecilere ve göçmenlere yönelik şiddet içeren şiddetli suistimaller yaygın hale gelmiştir. Bu kesinlikle Macaristan'da açıkça görülüyor ve birçok durumda meydana geldi. Avrupa'nın önde gelen insan hakları ajansı, Avrupa Konseyi, kıtadaki vatandaşların haklarını korumaya çalışıyor. Mültecilere yardım etmeye çalışan sivil toplum kuruluşları taciz edildi ve sansürlendi. Ek olarak, Macaristan'da göçmenlerin haklarının korunmasına yardımcı olmak amacıyla mahkemeler Macar hükümeti tarafından büyük bir baskı altına alınmıştır.

Aelf'in birlikte çalışabilirlik yetenekleri (birden fazla Blockchain ile iletişim kurabilme), Chainlink'in oracle tabanlı teknolojisi ile birleştirildi (Chainlink’in merkezi olmayan Oracle ağı, tek bir başarısızlık noktasına açık olmayan akıllı sözleşmelere benzer şekilde oldukça sağlam bir güvenlik sağlar), verilerin herkes tarafından erişilebilen tek bir yerde bulunurken birden fazla taraf arasında paylaşılmasını sağlar. Doğru göç ve göç uygulamalarını belirlemek için önemli bilgiler güvenli ve doğrulanabilir bir şekilde bulunmalıdır. Aelf’in halka açık/özel Blockchain ekosistemi, ayrıca belirli verilerin potansiyel olarak kötü niyetli oyunculara karşı özel kalmasını sağlamanın yanı sıra önemli verilerin doğru taraflarca erişilebilir olmasını da sağlar.

Birçok yönden Aelf’in Blockchain projesine yaklaşımı, blok zincir teknolojisinin küresel olarak göç ve göç politikalarıyla ilgili sorunların çözümünde yardımcı olabileceği sorunların çoğunu yansıtmaktadır. Aelf’in güçlü yönetişim yapısı, Aelf Blockchain kullanıcılarına büyük bir şeffaflık hissi veriyor çünkü Aelf token sahipleri projenin ilerlemesine büyük katkıda bulunur. Bu; blockchain teknolojisinin, problemin göçmenlerinin, hükümetlerin ve STK'ların yüzeyine düzenli olarak çözülmesine yardımcı olarak dünyaya nasıl daha fazla şeffaflık sağladığına benzerdir. Aelf gibi çözümlerle, gün geçtikçe daha da belirginleşiyor ve dünyanın en büyük zorluklarının çoğunu çözmek için Blockchain teknolojisinden yararlanılabilir.

KAYNAK: https://medium.com/aelfblockchain/is-blockchain-the-holy-grail-for-global-immigration-77432927f8a2