paint-brush
PIECHAIN Demosu: Pratik Bir Blockchain Birlikte Çalışabilirlik Çerçevesini Keşfetmekile@interoperability
326 okumalar
326 okumalar

PIECHAIN Demosu: Pratik Bir Blockchain Birlikte Çalışabilirlik Çerçevesini Keşfetmek

Çok uzun; Okumak

PIECHAIN, Ethereum, Hyperledger Fabric ve Quorum blok zincirlerini destekleyen, atomik zincirler arası işlemleri sağlayan ve zincirler arası açık artırmalar gibi pratik uygulamaları mümkün kılan, blockchain birlikte çalışabilirliği için Kafka tabanlı bir çerçeve sunar.
featured image - PIECHAIN Demosu: Pratik Bir Blockchain Birlikte Çalışabilirlik Çerçevesini Keşfetmek
Interoperability in Software Publication HackerNoon profile picture
0-item

Yazarlar:

(1) Daniel Reijsbergen, Nanyang Teknoloji Üniversitesi, Singapur, Singapur;

(2) Aung Maw, Singapur Teknoloji ve Tasarım Üniversitesi, Singapur, Singapur;

(3) Jingchi Zhang, Nanyang Teknoloji Üniversitesi, Singapur, Singapur;

(4) Tien Tuan Anh Dinh, Deakin Üniversitesi, Melbourne, Avustralya;

(5) Anwitaman Datta, Nanyang Teknoloji Üniversitesi, Singapur, Singapur.

İçeriğe Genel Bakış

Özet ve Giriş

PIEChain'e Genel Bakış

PIEChain'in Uygulanması

Gösteri Planı

Uzantılar

Referanslar


Soyut

Son yıllarda çok sayıda farklı blockchain platformu ortaya çıktı, ancak bunların çoğu silolar halinde çalışıyor. Bu nedenle, blok zincirinin birlikte çalışabilirliğini sağlamak için güvenilir zincirler arası iletişime ihtiyaç vardır. Blockchain'in birlikte çalışabilirliği zorludur çünkü işlemler genellikle geri alınamaz; bu nedenle, eğer bir işlem taahhüt edilirse, protokolün ilgili tüm işlemlerin de taahhüt edilmesini sağlaması gerekir. Cosmos ve Polkadot gibi mevcut birlikte çalışabilirlik yaklaşımları, yalnızca kendi alt zincirleri arasındaki birlikte çalışabilirliği desteklemeleri veya mevcut blok zincirlerinde müdahaleci değişiklikler gerektirmeleri açısından sınırlıdır. Bu sınırlamanın üstesinden gelmek için genel, Kafka tabanlı zincirler arası iletişim çerçevesi olan PIECHAIN'i öneriyoruz. PIECHAIN'i pratik bir vaka çalışması için kullanıyoruz: birden fazla zincirde token bulunduran kullanıcıların başka bir zincirde satılan bir bilet için teklif verdiği zincirler arası bir müzayede. PIECHAIN, zincirler arası iletişim için genel bir çerçevenin halka açık ilk pratik uygulamasıdır.


I.GİRİŞ

Blockchain, düşmanca ortamlar için tasarlanmış, çoğaltılmış, kurcalanmaya açık bir veritabanıdır. Bazıları kötü amaçlı olabilecek ve yalnızca eklenen bir defteri tutan bir dizi düğümden oluşur. Defter, bazı küresel durumları değiştiren işlemleri saklar. Kanonik örnekte, yani kripto para birimlerinde [7], küresel durumlar kullanıcı hesapları ve yerel (değiştirilebilir) tokenlardır ve defter, tokenleri bir hesaptan diğerine aktaran işlemleri içerir. Ortaya çıkan başka bir uygulamada, blok zincirler, örneğin dijital sanat eserleri veya konser biletleri gibi varlıkları benzersiz bir şekilde temsil eden, değiştirilemez tokenleri (NFT'ler) saklar. Birçok blockchain, kullanıcıların kendi durumlarını ve durumları değiştiren kodları tanımlamasına olanak tanıyan akıllı sözleşmeleri de destekler. Akıllı sözleşmeler defterde saklanır ve tüm blockchain düğümleri tarafından kopyalanır ve tutarlı tutulur. Son yıllarda birçok bağımsız blockchain platformu ortaya çıktı ve bunun sonucunda uzun kuyruklu bir ekosistem ortaya çıktı. Bir tarafta Ethereum ve Hyperledger gibi az sayıda oldukça popüler, genel amaçlı blockchain platformları var. Öte yandan, belirli uygulamalar için tasarlanmış binlerce küçük blok zinciri vardır ve bunların çoğu henüz geliştirme aşamasındadır. Bu, sağlık hizmetleri, kimlik yönetimi ve IoT'ye yönelik blok zincirlerin yanı sıra 2023'ün başlarından itibaren 10.000'den fazla kripto para birimini [3] içermektedir. Genel olarak bu blok zincirleri birlikte çalışmaz, yani silolar halinde bulunurlar. Bu nedenle, blok zincirinin birlikte çalışabilirliği, yani kullanıcıların farklı blok zincirleri üzerinde bilgi veya varlık alışverişi yapma yeteneği, araştırma topluluğunun artan ilgisini çeken bir konudur [6], [10], [4], [1], [ 11].


Şekil 1. PIECHAIN mimarisi: zincirler arası hizmetler (CC-SVC'ler), Kafka ağından/ağına olayları okur/yazar ve temeldeki farklı blok zincirleriyle (BC'ler) etkileşime girer.


Güvenli bir blockchain birlikte çalışabilirlik çerçevesi tasarlamanın ana zorluklarından biri atomikliği, yani üzerinde anlaşmaya varılan bir dizi işlemdeki tüm adımların başarılı bir şekilde sona ermesini veya hiçbirinin sona ermemesini garanti etmektir. Blockchain işlemleri (prensipte) geri döndürülemez olduğundan, bu durum blockchainlerde geleneksel veritabanlarına göre daha karmaşıktır. Örneğin, A Zincirindeki bir NFT için ödeme zaten B Zincirinde yapılmışsa atomite, B Zincirindeki işlem geri alınamayacağından A Zincirindeki işlemin devam etmesini gerektirir. Atomikliği garanti altına almak için yaygın bir yaklaşım, anlaşmaya dahil olan tüm tokenleri akıllı sözleşmelere emanet etmek ve bunları yalnızca tüm taraflarca imzalanan bir taahhüt mesajı yoluyla serbest bırakmaktır [6]. Blockchain'in birlikte çalışabilirliğindeki bir diğer önemli zorluk, emanet edilen tokenlerin sonsuza kadar dondurulamaması için canlılığın garanti edilmesidir. Canlılığı sağlamak için, düğümlerin tüm tarafların varlıklarını emanetten çekmesine olanak tanıyan bir iptal mesajı göndermesi mümkün olmalıdır.


Hem atomikliği hem de canlılığı garanti etmek için, birlikte çalışabilirlik çerçevesinin, bir blok zincirine taahhüt mesajı ve diğerine iptal mesajı gönderen rakip düğümleri tolere edebilmesi gerekir. Asenkron ağlar için (yani mesaj gecikmelerinde herhangi bir sınırın olmadığı) bunun güvenilir bir üçüncü taraf (TTP) olmadan başarılmasının imkansız olduğu bilinmektedir [10]. Bu zorluğun üstesinden gelmek için iki ana yaklaşım vardır [6]. İlk yaklaşım, senkronizasyon varsayımını iptaller için bir soğuma süresi ile birleştirmektir; yani, bir taahhüt oyu oluşturulduktan sonra, iptaller için herhangi bir bekleme süresinin bitiminden önce etkilenen tüm blok zincirlerine eklenebileceğini varsayarız. Bu yaklaşım örneğin karma zaman kilitli sözleşmelerde benimsenmiştir [5]. İkinci yaklaşım, geçerli bir taahhüt veya iptal mesajının oluşturulabilmesini sağlamak için TTP'yi başka bir blok zinciriyle değiştirmek, ancak her ikisinin birden oluşturulamamasıdır [6], [9].


Her ne kadar her iki türden yaklaşım da bilimsel literatürde önerilmiş olsa da, ya kamuya açık bir uygulamaya sahip değiller [5], [6], [9] ya da uygulama kapsamları sınırlı, örneğin başka bir blok zincirinde destekli varlıklar oluşturmak gibi. [11] veya jeton takasları [8]. Ayrı bir gelişmede, varsayılan olarak birlikte çalışabilirliği mümkün kılan Cosmos ve Polkadot gibi çeşitli blockchain platformları ortaya çıktı. Ancak bu platformlar yalnızca kendi alt zincirleri arasındaki birlikte çalışabilirliği destekler veya mevcut blok zincirlerinde müdahaleci değişiklikler yapılmasını gerektirir. Bu, mevcut blockchain platformlarına, onları değiştirmeden arayüzlenebilecek genel ve pratik bir birlikte çalışabilirlik çerçevesine olan ihtiyacı motive etmektedir. Amacımız böyle bir çerçeve sağlamak.


Katkılar ve Yenilik : Bu hedefe ulaşmak için PIECHAIN'i sunuyoruz. Pratikte senkronizasyonun varsayılması zor olduğundan PIECHAIN, TTP'nin yerine zincirler arası hizmetleri kullanır. Zincirler arası hizmetler, verimlilik için Apache'nin Kafka protokolünü kullanan bir olay günlüğü kullanarak iletişim kurar. PIECHAIN'in pratik ilgisini göstermek amacıyla gerçekçi bir örnek olay çalışması için zincirler arası bir hizmet uyguladık: zincirler arası açık artırma. PIECHAIN'i akıllı sözleşmeleri destekleyen en popüler blockchain platformlarından bazılarıyla arayüzledik: Ethereum, Hyperledger Fabric ve Quorum. Son olarak vaka çalışmamız için bir GUI geliştirdik. Açık artırma vaka çalışması, kodu GitHub'daki PIEChain kod deposunda bulunabilen üç vaka çalışmasından biridir (iki açık artırma ve bir flaş kredi [6]).



II. PIECHAIN'E GENEL BAKIŞ

A. Kuruluşlar

PIECHAIN'deki ana varlıklar aşağıdaki gibidir (ayrıca bkz. Şekil 1):


Kullanıcılar tarafından tutulan varlıkları (örneğin jetonlar, anahtarlar) saklayan blok zincirler. Bir kullanıcı varlıkları birden fazla blok zincirde tutabilir. Her blok zincirinin kimin okuma ve yazma erişimine sahip olduğunu belirlemek için kendi protokolü vardır - blok zincirler genellikle ya izinlidir, yani sabit bir düğüm kümesi okuma ve yazma erişimine sahiptir ya da izinsizdir, yani herkes okuma erişimine sahiptir ve işlemler ve düğümler oluşturabilir Yeterli güce sahip olan (örn. işlem hızı) blok zincirine işlemler ekleyebilir. Kullanıcıların farklı blok zincirlerde varlık alışverişi yapmasına olanak tanıyan çapraz zincir hizmetleri (CC-SVC'ler). Her CC-SVC, zincirler arası iletişimi kolaylaştırmak için kullanıcı istemcileriyle etkileşime giren bir sunucudan oluşur. Uygulamada CC-SVC, kullanıcılardan katılım karşılığında ücret alır ve herhangi bir sayıda blok zinciriyle etkileşime girebilir. Aşağıda her CC-SVC, bir sunucu tarafından Kafka defterine gönderilen atomik varlık alışverişinde yer alan bir dizi olaya karşılık gelir. Uygulamada tek bir sunucu birçok CC-SVC'yi çalıştırabilir.


CC-SVC'ler tarafından oluşturulan olayların yalnızca eklenen bir günlüğü olarak hizmet veren Kafka ağı. Olaylar, temel blockchainlerde yapılan işlemlere karşılık gelir. Kafka ağı, olayları yüklemek için CCSVC'lerden ücret alan sabit bir düğüm kümesi tarafından işletilir.


PIECHAIN'de, CC-SVC'lerin yarı güvenilir olduğunu ve ticari dış kaynak hizmet sağlayıcılarına benzer şekilde, korunacak bir itibara sahip olarak dürüst davranmaya motive olduklarını varsayıyoruz. Kafka ağ operatörleri güvenilmezdir ancak temeldeki blok zincirlerle etkileşime girmedikleri için kötü davranmaya teşvikleri yoktur. Bu, verimliliği güvenlikten önce önceliklendiren bir protokol (Kafka) çalıştırmamıza olanak tanır. Alternatif bir tasarım, CC-SVC'leri güvenilmez ve Kafka ağını güvenilir hale getirmektir. Bu durumda, her Kafka düğümü, işlemlerin bu zincirlere dahil edildiğini doğrulamak için temeldeki blok zincirlerin her biri için bir (hafif) istemci çalıştırır. Bu durumda olay günlüğünün PBFT [2] gibi daha güvenli bir protokol kullanması gerekecektir. Gelecekteki çalışmalar olarak böyle bir tasarım bırakıyoruz.


B. Süreç Akışı

Bölüm II-A'nın varlıkları göz önüne alındığında, PIECHAIN'deki süreç akışı, Herlihy ve diğerleri tarafından önerilen zincirler arası anlaşmalarla aynı yapıya sahiptir. [6]. Çapraz zincir anlaşmaları, birden fazla kullanıcının farklı blok zincirlerindeki varlıkları takas etmek için yaptığı anlaşmalardır ve beş aşamadan oluşur (ayrıca bkz. Şekil 2):


  1. Takas aşaması: CC-SVC, anlaşmaya dahil olan varlıkları emanet etmek ve aktarmak için kullanılan farklı blok zincirleri üzerinde akıllı sözleşmeler oluşturur.


  2. Escrow aşaması: Kullanıcılar, giden varlıklarını akıllı sözleşmelere aktararak emanet ederler.


  3. Transfer aşaması: Varlıklar geçici olarak değiştirilir, yani akıllı sözleşmelerin uygulama mantığı belirlenir.


  4. Doğrulama aşaması: Her kullanıcı, yürütme mantığının sonucunun kendilerini tatmin edecek düzeyde olup olmadığını kontrol eder.


  5. Taahhüt aşaması: Anlaşma, tüm tarafların memnun olması durumunda taahhüt yoluyla, aksi takdirde kürtaj yoluyla sonuçlandırılır. Taahhüt, akıllı sözleşmelerdeki yürütme mantığının yürütüldüğü ve varlıkların anlaşmada belirtildiği şekilde değiştirildiği anlamına gelir. Kürtaj, her akıllı sözleşmedeki varlıkların orijinal sahiplerine iade edilmesi anlamına gelir.


Taahhüt etmek için kullanıcılar etkileşimli olarak CC-SVC tarafından Kafka defterine gönderilen bir taahhüt oyu oluştururlar. İptal etmek için tek bir kullanıcı CC-SVC'ye bir iptal mesajı gönderir. Her CC-SVC için Kafka defterine bir taahhüt veya iptal mesajı eklenebilir, ancak her ikisi birden eklenemez. Kafka defterindeki bir taahhüt oyunun dahil edilme kanıtı, farklı blok zincirlerindeki tüm akıllı sözleşmeler tarafından kabul edilir; bu, bir taahhüt oyu oluşturulduktan sonra ya tüm varlık transferlerinin gerçekleştirilebileceğini ya da hiçbirinin gerçekleştirilemeyeceğini garanti eder.


Şekil 2. Bir CC-SVC (üst), iki kullanıcı (orta) ve iki blok zincirinin (altta) olduğu bir ortamda Bölüm II-B'nin beş adımının gösterimi. Kafka ağı gösterilmiyor.



III. PIECHAIN'İN UYGULANMASI

PIECHAIN'in pratik uygulanabilirliğini göstermek için, onu yaygın olarak kullanılan çeşitli blockchain platformlarına arayüzledik ve bunu bilimsel literatürden [6] bir uygulamayı uygulamak için kullandık: dijital bir varlık için zincirler arası açık artırma. Blockchain desteği, Bölüm V'te tartıştığımız gibi diğer örnek olay incelemelerini de kapsamaktadır.


A. Blockchain Desteği

Temel bir blockchain ile PIECHAIN arasında arayüz oluşturmak için CC-SVC'lerin bu zincirlerdeki işlemleri doğrulayabilmesi gerekir. Uygulamamız şu blockchain platformlarını desteklemektedir: Ethereum (özel Ethereum'un hem Proof-of-Work hem de Proof-ofAuthority versiyonları), Hyperledger Fabric ve Quorum. Son ikisi izinli blok zincirlerini desteklerken, Ethereum izinsiz bir ana zincire sahiptir ancak aynı işlevselliğe sahip özel zincirleri de destekler.


B. Açık Artırma

Vaka çalışmamızda, bir müzayedeci bir blok zincirindeki bir varlığı satıyor ve başka bir blok zincirindeki varlıklar şeklinde ödeme alıyor. [6]'da olduğu gibi, bir bilet satıcısı örneğini kullanıyoruz. Bilet, özel bir blok zincirindeki bir NFT'dir, diğer blok zinciri ise daha yaygın olarak kullanılan takas edilebilir tokenleri (örneğin, Ether) destekler. İlk blok zincirine bilet blok zinciri, ikincisine ise madeni para blok zinciri adı verilir. Bu, birden fazla kripto para blok zincirinin bulunduğu ayarlara kolaylıkla genelleştirilebilir. Aşağıda ilk fiyat açık artırmasını ele alacağız (yani en yüksek teklifi veren teklif sahibi teklifini öder ve varlığı alır). Protokolün beş aşaması şu şekildedir:


  1. Açık artırmayı düzenleyen kişi, bilet blok zinciri ve madeni para blok zincirleri üzerinde akıllı sözleşmeler oluşturan bir CC-SVC'ye kaydolur.


  2. Açık artırmacı, varlığını (biletin NFT'sini) bilet sözleşmesine aktarır ve teklif sahipleri, tekliflerini kendi para blok zincirindeki sözleşmeye aktarır.


  3. Uygulama mantığı belirlenir: Müzayedeci, bileti hangi tarafın alacağını ve hangi teklifin müzayedeciye aktarılacağını belirterek her bir bilet ve madeni para sözleşmesini günceller. (Bu mantığın bilet sözleşmesinde önceden belirlenemeyeceğini unutmayın çünkü bilet zincirindeki sözleşme, madeni para blok zincirlerinden veri okuyamaz.)


  4. Her kullanıcı (yani açık artırmayı düzenleyen ve teklif verenler), transfer protokolünün sonucunun kendileri için uygun olup olmadığını, yani biletin gerçekten doğru tarafa aktarılıp aktarılmadığını belirler.


  5. Tüm kullanıcılar bir taahhüt oyu oluşturur; bu oluşturulduktan sonra, transfer aşamasında belirtilen transferleri gerçekleştirmek için her sözleşmeye gönderilir.


PIECHAIN'de açık artırma iki (mantıksal) türde CC-SVC gerektirir: aktaran ve imzalayan. Aktarıcı, madeni para zincirlerindeki olayları (teklifleri) dinler ve bunları bilet blok zincirine aktarır. İmzalayan, taahhüt oylamasının oluşturulmasına yardımcı olur.


IV. GÖSTERİM PLANI

Gösterimimiz için, zincirler arası açık artırmayı göstermek amacıyla React çerçevesini kullanan bir grafik kullanıcı arayüzü (GUI) geliştirdik. GUI üç ana sayfadan oluşur: Şekil 3'te gösterildiği gibi bilinen açık artırmaların listesini görüntüleyen bir kontrol paneli sayfası, Şekil 5'te gösterildiği gibi bireysel açık artırmaların ayrıntılı görünümü ve yeni açık artırmaların oluşturulması için bir sayfa (görüntülenmemektedir). Açık arttırmacının görüşü teklif vereninkiyle aynıdır. Kontrol paneli görünümünde, potansiyel müzayedeciler bir müzayede başlatmak için "Yeni Açık Artırma Oluştur" düğmesini tıklayabilirler; açık artırmayı düzenleyen kişi bir CC-SVC'yi, açık artırmaya çıkarılacak varlığı, diğer hangi blockchain'lerden teklif kabul edileceğini, farklı bloklar arasındaki tokenların döviz kurunu seçer. blok zincirleri (önceden sabitlenmesi gerekir) ve açık artırmanın sonuçlanma zamanı. Daha sonra, CC-SVC rölesi ilgili sözleşmeleri oluşturur ve varlık zincirindeki sözleşmenin adresini açık artırmacıya gönderir. Açık artırmacı daha sonra sözleşme adresini ekleyip "Mevcut Açık Artırmayı Ekle" düğmesini tıklayarak açık artırmayı kontrol paneline ekleyebilir. Bu arada, sözleşme adresini potansiyel teklif sahiplerine duyurur.


Teklif sahipleri varlık sözleşmesi adresini öğrendiklerinde bunu gösterge tablolarına da ekleyebilirler. Teklif sahibi, ihaleyi ekledikten sonra, ihale panelinde yer alan “Görüntüle” butonuna basarak ihaleyi daha detaylı görüntüleyebilir ve bu sayede detaylı görünüm sayfasına yönlendirilir. Bu sayfada teklif veren, açık artırmanın oluşturulma ve sonuçlanma zamanları ve teklif listesi gibi önemli bilgileri görebilir. En yüksek teklif yıldız işaretiyle işaretlenmiştir. Açık artırma hala devam ediyorsa teklif veren, blockchain'i belirterek teklif ekleyebilir.



Şekil 4. Bir blockchain istemcisinin konsol çıktısını gösteren pencere.



teklifin yapıldığı yer ve teklif edilecek jeton miktarı. Daha sonra ilgili coin sözleşmesine işlem yapılır ve bilgi CC-SVC aktarıcısına gönderilir. Kullanıcı ayrıca CC-SVC aracılığıyla vermiş olduğu teklifleri iptal edebilir.


Açık artırma sonuçlandıktan sonra, CC-SVC rölesi tüm katılımcıları bilgilendirir ve akıllı sözleşmelerde malların geçici transferini belirtir. CC-SVC daha sonra tüm katılımcıların müşterilerinden bir taahhüt oyu oluşturmaya katılmalarını ister. (Katılmama cezasıyla sonuçlanmalıdır [4].) Taahhüt oyu oluşturulduğunda, varlıkların nihai transferini başlatmak için tüm sözleşmelere gönderilir. Bu noktada GUI açık artırmanın sonuçlandığını gösterecektir.


Demonun tam akışı şu şekilde olacaktır:


  1. Bir kullanıcı (açık artırmacı) web tarayıcısı tabanlı bir GUI açar ve bunu seçilen bir varlık için bir açık artırma başlatmak için kullanır. Bu süreçte açık artırma oluşturma sayfasındaki tüm özellikler gösterilir. Varlık, Hyperledger Fabric'te çalışan özel bir bilet zincirinde bulunur. Sözleşmeler, ilgili tüm blok zincirlerde oluşturulur (Şekil 2'nin 1. adımı).


  2. Farklı makinelerde tarayıcı pencereleri kullanan en az iki kullanıcı, yeni oluşturulan açık artırmanın ayrıntı sayfasına gider ve varlığa ilişkin bireysel tekliflerini gönderir (Şekil 2'nin 2. adımı). Teklif verenlerden en az biri (özel) Ethereum kullanıyor, diğeri ise Quorum kullanıyor.


  3. Bir süre sonra açık artırma sonuçlandırılır ve kazanan teklif belirlenir (Şekil 2'nin 3. adımı). Bu, açık artırmacı tarafından CCSVC aktarıcısına bir "açık artırma sonu" olayının gönderilmesine neden olacaktır. Bu tür bir olayı dinleyen imzacılar, olayı fark edecek ve bir taahhüt oyu oluşturacaktır (Şekil 2'nin 4. adımı). Taahhüt oyu daha sonra Kafka'ya gönderilir ve aktarma düğümü tarafından açık artırma sözleşmesine ve madeni para zinciri sözleşmelerine iletilir. Bu noktada varlık kazanan teklif sahibine, kazanan teklif ise müzayedeciye devredilir (Şekil 2'nin 5. adımı).


Demo boyunca, Şekil 4'te gösterildiği gibi, her adımdan sonra temel blok zincirlerinin durumlarını sorgulamak için bir terminal penceresi kullanacağız. Bu, izleyicinin arka planda meydana gelen değişiklikleri gözlemlemesine ve akışın akışıyla etkileşime girmesine olanak tanıyacaktır. gösteri: örneğin, arka plan durumlarının nasıl değiştiğini görmek için yeni eylemler isteyerek.


Demonun akışını göstermek için, geçici demo slaytlarını ve müzayedeci ile teklif sahiplerinin eylemlerini tek bir bilgisayar kullanarak gerçekleştirecekleri ekranı gösteren bir video çevrimiçi olarak bulunabilir 2. (Bu PIECHAIN'in bir sınırlaması değildir ancak video kaydetmeyi kolaylaştırır.)


Şekil 5. Aktif bir müzayedenin detaylı görünümü.


V. UZATMALAR

CC-SVC çerçevesi ve desteklenen blok zincirlerine yönelik arayüz, PIECHAIN'i diğer kullanım durumlarına kolayca genişletmek için kullanılabilir. Bunlardan biri [6]'da açıklandığı gibi zincirler arası flaş kredidir. Flaş krediler için bir GUI'nin, arbitraj fırsatları genellikle hızlı bir şekilde çözüldüğü için sınırlı pratik ilgisi olacaktır, dolayısıyla CC-SVC ile etkileşimler normalde ticaret botları tarafından yapılacaktır. Ancak zaman kalırsa, flaş kredideki adımların ilgili çeşitli sözleşmelerin durumları üzerindeki etkisine ilişkin bir görselleştirme göstereceğiz.


REFERANSLAR

[1] Rafael Belchior, Andre Vasconcelos, S' ergio Guerreiro ve Miguel ' Correia. Blockchain'in birlikte çalışabilirliği üzerine bir araştırma: Geçmiş, şimdiki ve gelecekteki eğilimler. ACM Bilgi İşlem Araştırmaları (CSUR), 2021.


[2] Miguel Castro ve Barbara Liskov. Pratik Bizans hata toleransı. OsDI, cilt 99, sayfa 173–186, 1999'da.


[3] CoinLore. https://www.coinlore.com/all paralar, 2023.


[4] Daniel Engel, Maurice Herlihy ve Yingjie Xue. Başarısızlık (kelimenin tam anlamıyla) bir seçenektir: Merkezi olmayan finansta atomik taahhüt ve isteğe bağlılık. SSS 2021, 2021'de.


[5] Maurice Herlihy. Atomik zincirler arası takaslar. ACM PODC'de, sayfa 245–254, 2018.


[6] Maurice Herlihy, Barbara Liskov ve Liuba Shrira. Zincirler arası anlaşmalar ve çekişmeli ticaret. VLDB Dergisi, 2021.


[7] Satoshi Nakamoto. Bitcoin: Eşler arası bir elektronik nakit sistemi, 2008.


[8] Sri Aravinda Krishnan Thyagarajan, Giulio Malavolta ve Pedro Moreno-Sanchez. Evrensel atomik takaslar: Tüm blok zincirlerde güvenli para alışverişi. IEEE S&P, 2022'de.


[9] Victor Zakhary, Divyakant Agrawal ve Amr El Abbadi. Blok zincirleri arasında atomik bağlılık. VLDB Vakfı Tutanakları, 13(9), 2021.


[10] Alexei Zamyatin, Mustafa Al-Bassam, Dionysis Zindros, Eleftherios Kokoris-Kogias, Pedro Moreno-Sanchez, Aggelos Kiayias ve William J Knottenbelt. SoK: Dağıtılmış defterler arasında iletişim. Finansal Kripto'da, 2021.


[11] Alexei Zamyatin, Dominik Harz, Joshua Lind, Panayiotis Panayiotou, Arthur Gervais ve William Knottenbelt. Xclaim: Güvenilmez, birlikte çalışılabilen, kripto para birimi destekli varlıklar. IEEE S&P, 2019'da.