I-DELTA İşlevsel Görünüm

T2 Yazılım ve I-DELTA Konsorsiyumu

Bu yazı I-Delta yazı serisinin 4. bölümüdür. Tüm yazı serisi için; 1.bölüm, 2. bölüm , 3.bölüm, 4.bölüm, 5.bölüm, 6. bölüm, 7. bölüm, 8. bölüm. 
‍Click here for the English version.

I-DELTA, farklı defterlerin iletişim kurmak için kullanacağı bir pub-sub mesaj otobüsünün üzerine inşa edilmiş çok katmanlı bir çözüm kullanacaktır. Bu, atomik takasları, olay yayılımını vb. destekleyen ölçeklenebilir bir sistem olacaktır. Ayrıca, ana odak noktalarından biri veri gizliliği ve gizliliği olacaktır. Mevcut durumla karşılaştırıldığında, tasarım mantığımız, dağıtık defterler için mümkün olduğunca genel, daha esnek ve sorunsuz bir bilirkte çalışabilirlik çözümüne sahip olmaktır. İnovasyonların ayrıntıları bu bölümde daha sonra verilecektir. Aşağıda, I-DELTA'nın teknolojik inovasyonunun ana noktalarını özetliyoruz:

· Bugüne kadar, çoğu uygulama kendi dağıtık defterlerinde çalışır; potansiyel bir bilirkte çalışabilirlik çözümü, bu uygulamaların tasarımını değiştirmeye gerek kalmadan tümünü entegre etmelidir. Hatta en çok kullanılan zincirler olan Bitcoin ve Ethereum'un bile farklı sonlulukları, konsensüs mekanizmaları, desteklenen işlem sayıları, işlevsellikleri vb. vardır. İkili bilirkte çalışabilirlik çözümü, birlikte çalışmak isteyen her uygulama çifti için ayrı ayrı optimize edilmiş bir köprü/kanal gerektirecektir. Ayrıca, köprülerin, uç noktadaki zincirlerden biri çatal oluşturduğunda veya başka bir şekilde değiştiğinde güncellenebilir olması gerekir.

· Diğer yandan, tek bir mesaj otobüsüne sahip pub-sub tabanlı bir çözüm, çoklu uygulama ve kullanım durumlarının farklı alt kanallar üzerinden sorunsuz bir şekilde iletişim kurmasını sağlayacaktır. Bu kanallar kamusal veya özel olabilir; böylece bir kanal kurulurken defterler için abonelik izinlerini kontrol edebilirsiniz. Örneğin, tüm bankaların defterleri, bir sadakat sistemi için kurulan bir kanala abone olabilir. Veya, iki farklı şirket tarafından yönetilen iki defter, yalnızca aboneler olabilir.

· Yukarıda belirtildiği gibi, gizlilik ve gizlilik, I-DELTA'nın ticari benimsemeyi daha da artırmak için iki ana direk olacaktır. Önerilen Gizlilik Katmanı ile gizli abonelikler etkinleştirilecek ve defterler, ZKP'ler sayesinde doğrulanabilen gizli işlemlerle aralarında sorunsuz bir şekilde iletişim kurabilir. Bildiğimiz kadarıyla, bu ileri düzey kriptografik teknikleri kullanan bir bilirkte çalışabilirlik çözümü yoktur.

· Yapay zeka ile birlikte, dağıtık defterler yakın gelecekte gerçekleşecek olan en önemli iki kesici teknoloji olarak kabul edilmektedir. Gerçekten de, AI, I-DELTA'nın ana endişesi değildir ve tek bir zincir için yararlı görünmemektedir. İzinli veri/model paylaşımı ve bunun üzerine bir finansal ekosistem oluşturarak AI'yi etkinleştiren blockchain tabanlı çözümlerden haberdarız. Ancak, diğer kullanım yönü, bildiğimiz herhangi bir kullanım durumunda görünmüyor. Çok zincirli, uyumlu dağıtık defter teknolojileri için şu önemli ve ilginç araştırma ve geliştirme yönlendirmelerini öngörüyoruz;

o AI'yi bilirkte çalışabilirlik performansını optimize etmek için kullanma: Makine öğrenimi ve AI tabanlı modeller, iletişim kanallarının ve mesaj otobüsünün performansını optimize etmek için kullanılabilir. Örneğin, beklenen mesaj hacmine ve işlem başına bayt, zincir sayısı, aktif zincir sayısı gibi diğer özelliklere dayalı olarak, kanallar I-DELTA üzerinde farklı bir düzeyde ve ölçekte yerleştirilebilir, önceliklendirilebilir veya optimize edilebilir. Bunu, daha düşük işletme maliyetleri ve daha iyi, daha hızlı ve daha etkili bir bilirkte çalışabilirlik çözümü sağlayacağına inanıyoruz.

o I-DELTA'nın yaygın olarak kabul gören bir çözüm olacağı ve Web 3.0 için büyük bir adım olacağı dikkate alındığında, yönetim modülünü optimize etmek için modeli eğitmek (önceki maddeye atıfta bulunarak) sistem için bir yük olacaktır; işlenecek veriler büyük ölçekte olacaktır. SotA'da belirtildiği gibi, PoW, mevcut haliyle etkili bir konsensüs mekanizması değildir ve Casper, Avalanche ve Algorand gibi çeşitli çözümler araştırılmakta ve geliştirilmektedir. I-DELTA süresince, en son mekanizmaları potansiyel geliştirmeler olarak düşüneceğiz. Ancak, I-DELTA konsensüsü için olası bir yol, PoI'dir; eğitilecek AI modeli, I-DELTA ekosistemi tarafından oluşturulacak ve I-DELTA ekosistemi için kullanılacak. Yani, PoI, önceki maddeye model oluşturma için tüm hesaplamalı maliyeti konsensüse yönlendirebilir. Bu, I-DELTA'da PoI kullanımına olan ilgimizin nedenlerinden biridir.

Bilirkte Çalışabilirlik:

Bazı kurumsal ağlar, bir grup banka veya hükümet kurumu gibi, kendi blockchain ağlarını oluşturabilir. Bu ağlar ayrıca kendi kurallarını, politikalarını ve ilgili akıllı sözleşmelerini oluşturur. Ancak, bu ağlar arasındaki işbirliği yeni kullanım durumları yaratır ve çok etkili hale gelir. Örnek olarak, bazı bankalar birbirleri arasında bir ödeme sistemi oluşturabilir ve hükümet kurumu, ödeme ağı aracılığıyla vergi toplamak için ağa katılmak isteyebilir. Hükümet vergi dairesi için uygulanamayan birçok diğer kural ve politika olduğu için, hükümet kurumunu mevcut banka ağına üye yapmak zorlaşır. Bilirkte Çalışabilirlik, bu durum için bir çözüm olacaktır. İki farklı DLT için geçerli olan bazı kullanım durumları, bilirkte çalışabilirlik protokolleri kullanılarak sağlanabilir. Bu projede, konsorsiyumumuz mesaj tabanlı bir bilirkte çalışabilirlik platformu sağlayacaktır.

Daha önce belirtildiği gibi, bilirkte çalışabilirlik, DLT'ler için iyi çözülmüş bir sorun değildir. Defterler arası bilirkte çalışabilirlik, şu teknik zorluklara sahiptir:

· Akıllı sözleşmeler, farklı DLT'lerde aynı anda çalıştırılamaz.

· Farklı DLT'ler için konsensüs politikaları farklı olabilir.

· Gerçek veriler, farklı DLT'ler için farklı olabilir.

‍

Yukarıda belirtilen zorluklara göre, DLT'ler arasındaki bilirkte çalışabilirlik mesaj veya hizmet tabanlı olmalıdır. Interledger (interledger.org), mesaj tabanlı olan ve para transferi mesajlarının defterler arasında yönlendirildiği bir örnektir. Mevcut durumda, bilirkte çalışabilirlik şu ana kadar bazı özel kullanım durumları üzerinde kurulmuştur. I-DELTA'da, genel bir yaklaşım izleyen ve aşağıdaki sistemleri sağlayan bir bilirkte çalışabilirlik katmanı sunacağız:

· Defterlere ve referans mimariye özgü mesajları işleyen bir hizmet katmanı

· Defterler arasında mesajları yönlendiren dağıtık bir mesaj otobüsü

· Mesaj transferleri için kullanılan ve kullanım durumlarına uyacak şekilde genişletilebilir bir protokol

Bu sistemleri kullanarak, I-DELTA daha genel bir bilirkte çalışabilirlik katmanı sağlayacak ve defterlerin uyumluluğu için standartları tanımlayacaktır. İşte bilirkte çalışabilirlik sistem bölümlerinin daha ayrıntılı tanımları.

Bilirkte Çalışabilirlik Katmanları:

Hizmet Katmanı: Her defterin farklı olduğu ve kendi platformlarına, akıllı sözleşme dillerine ve politikalarına sahip olduğu için, her defter için ortak bir arayüz gereklidir. Bu hizmet katmanı, her defter için ortak arayüzü sağlayacaktır. Şu işlerden sorumlu olacaktır:

· Diğer defterlerden yeni mesajları dinleme

· Mesajları diğer defterlere iletim

· Diğer defter hizmetlerinin veya mesaj otobüsünün kimlik doğrulaması

· Mesajların ve mesaj türlerinin yetkilendirilmesi

· Mesaj otobüsü ve defter düzenleme hizmetleri arasındaki mesajların sıralanması

· Deftere teslim edilen mesajların izlenmesi ve denetlenmesi

· Mesaj otobüsüne geri bildirim sağlayacak bir ACK veya NACK mekanizması

· Gönderilecek mesajların olası birleştirilmesi

Her defterin farklı sistem parçaları ve uygulama detayları olduğu için, bu hizmet katmanı her DLT platformu için uygulanacaktır. I-DELTA'da, bir kamu ve bir özel defter için en az iki Hizmet Katmanı örneği sağlayacağız. Platformlar için tüm referans belgeleri ve mimariyi sağlayacağız, böylece diğer platformlar ve ortaklar diğer gerekli Hizmet Katmanlarını uygulayabilir.

Hizmet katmanı için de bir zorluk olacak, çünkü DLT sistemleri dağıtılmıştır ve her DLT için bir hizmet katmanı uygulamak kolay değildir. İzinli defterler için, örneğin Hyperledger Fabric, bu, Orderer Hizmeti gibi başka bir defter hizmeti olabilir ve sistemde Tek Başarısızlık Noktası durumlarını önlemek için bir AMQP (örneğin: Kafka) tarafından desteklenip çoğaltılabilir. Diğer yandan, Ethereum için bir hizmet katmanı uygulamak çok daha zor olacaktır. Hizmet katmanı, dağıtılmış bir sistem olarak tasarlanmalıdır, böylece ağdaki bazı eşler, adanmış bir sunucuya ihtiyaç duymadan çalışmasını sağlayabilir. I-DELTA'da, dağıtılmış bir hizmet katmanının örnek uygulamasını da sağlayacağız.

Dağıtılmış Mesaj Otobüsü: DLT sistemleri dağıtılmış olduğundan, bu sistemler arasındaki mesajları iletecek olan bilirkte çalışabilirlik katmanı da dağıtılmış olmalıdır. Dağıtılmış Mesaj Otobüsü şu işlevleri sağlayacaktır:

· DLT'lerin Hizmet Katmanları için bir Adlandırma ve kayıt hizmeti

· DLT'lerin kimlik doğrulaması

· DLT mesajlarının yetkilendirilmesi

· DLT'ler arasında mesajların iletilmesi

· Mesaj otobüsü düğümlerinin yönetimi

· Hizmet Katmanları için ACK ve NACK sağlama

· Mesajların çoğaltılması

· Mesajların tekrarının önlenmesi

· Yayın ve çok noktaya yayın iletim seçenekleri

· İzleme ve denetleme araçları

· Dağıtılmış bir Dosya Sistemi veya Dağıtılmış bir Dosya Sistemi kullanacak (örneğin IPFS)

· Mesaj Otobüsünün kullanımı için Değerlendirme ve Tahsilat sistemi

Dağıtılmış Mesaj Otobüsü, herhangi bir DLT'den bağımsız olarak çalışacaktır. DLT'ler için küresel bir mesaj otobüsü olarak çalışacak veya özel defterler için bir mesaj otobüsü olarak kullanılacak bir test ağı oluşturmak için kullanılabilir. Mesaj otobüsü, Bilirkte Çalışabilirlik Katmanının çekirdek bölümü olacaktır. Dağıtılmış olduğu için, çözeceğimiz ve bunlardan bazıları olan birçok zorluk olacaktır:

· Mesajların iletilmesi için Güvenilirlik KPI'ları

· Dağıtılmış bir mesaj otobüsü aracılığıyla iletilen mesajların optimum fazlalığının oluşturulması ve hesaplanması. Bu optimum sayı, düğüm sayısına, DLT sayısına ve mesaj otobüsünün hedef verimine göre yeniden hesaplanacaktır. Sistemdeki tüm düğümlere yayınlanacak ve konsensüs ile tanımlanması gerekmektedir.

· Mesaj otobüsünün küçültülmesi ve ölçeklendirilmesi. Mesajların çoğaltılması ve optimum fazlalık sayısına göre mesajların tekrarının önlenmesi.

· Belirli aktivite diyagramlarına sahip mesajların akışının yönetimi.

· Mesajların optimum zaman penceresi için sıralanması. QoS kısıtlamalarını karşılamak için çok optimize edilmiş olması gerekmektedir.

Bilirkte Çalışabilirlik: Mesaj Protokolü: Mesaj protokolü, en az şu özellikleri tanımlar; (1) Sürüm, (2) Kaynak DLT, (3) Hedef DLT, (4) Kimlik Doğrulama Tokeni, (5) Mesaj Türü, (6) Mesaj Yükü.

Mesaj Protokolü, hem Mesaj Otobüsü hem de bir DLT'nin Hizmet Katmanı tarafından uygulanacaktır. Protokolü daha güvenilir hale getirecek diğer alanları içerebilir. Protokol, ilk testin istatistiksel analizine göre yeniden deneme ve fazlalık özelliklerini tanımlayacaktır. Diğer yandan, daha geniş bir DLT platformları ve teknolojileri yelpazesi için gerçek birlikte çalışabilirlikten bahsetmek adına, ortak senaryolar için bazı mesaj türlerinin tanımlanması gerekmektedir. Bu nedenle, I-DELTA'da şu senaryolar için mesaj türleri ve aktivite diyagramları sağlayacağız; (1) Dijital Kimlik, (2) Ödeme Sistemleri, (3) Tedarik Zinciri Geçmişi.

‍

‍