如何利用現(xiàn)有的區(qū)塊鏈資源

時間：2020-06-08 11:45:01

關鍵字：以太坊區(qū)塊鏈區(qū)塊鏈智能合約

手機看文章

掃描二維碼
隨時隨地手機看文章

[導讀] IRIS網(wǎng)絡是以希臘女神Iris的名字命名的，她是彩虹的化身，是在天堂和人類之間忠誠傳遞消息的信使。契約關系是人類社會的基本組成部分，區(qū)塊鏈技術的重要性在于提供一種非常有效和低成本的方

IRIS網(wǎng)絡是以希臘女神Iris的名字命名的，她是彩虹的化身，是在天堂和人類之間忠誠傳遞消息的信使。

契約關系是人類社會的基本組成部分，區(qū)塊鏈技術的重要性在于提供一種非常有效和低成本的方式來實現(xiàn)可靠的契約關系：第一次出現(xiàn)了多方參與復雜的業(yè)務交互時不再需要（本來非常昂貴的）信任。也就是說區(qū)塊鏈技術為分布式商業(yè)提供了最重要的元素：以極低的交易成本提升網(wǎng)絡效益。越來越多的人認識到區(qū)塊鏈作為新的價值互聯(lián)網(wǎng)的影響力，并將逐步把當前的商業(yè)模式轉變?yōu)楦咝У姆植际骄W(wǎng)絡。特別是內(nèi)置于大多數(shù)現(xiàn)代區(qū)塊鏈中的通證機制，強調每個網(wǎng)絡參與者的權利，并將革新商業(yè)的現(xiàn)有模式。

不過，區(qū)塊鏈技術仍處于早期階段。與其它新技術一樣也存在缺點，包括有限的性能和還沒有發(fā)展起來的治理機制。目前，這些缺點使區(qū)塊鏈難以支持真實的分布式商業(yè)協(xié)作。諸如Hyperledger Fabric和R3 Corda，以及以太坊企業(yè)聯(lián)盟（Ethereum Enterprise Alliance）等組織都在試圖通過聯(lián)盟鏈（consortium chains）解決這些性能和治理的問題，使區(qū)塊鏈技術更適用于企業(yè)。然而，如今的聯(lián)盟鏈由大型企業(yè)公司主導的，他們封閉式的鏈上鏈下治理模式非常低效。聯(lián)盟鏈可能因為缺乏公有鏈的通證經(jīng)濟模型及其開放性和激勵性而缺乏活力。

我們希望發(fā)展當前的區(qū)塊鏈技術，讓成千上萬的中小企業(yè)（Small Medium Businesses，SMBs），甚至是個體自由職業(yè)者，可以在一個開放的網(wǎng)絡中提供他們的服務并享受回報。為了實現(xiàn)這一目標，我們確定了以下挑戰(zhàn)以及隨之而來的技術創(chuàng)新機會：

并非所有的運算都可以或應該以諸如智能合約這樣的形式在區(qū)塊鏈上實現(xiàn)

以太坊提供了圖靈完備的虛擬機運行智能合約，帶給人們開發(fā)分布式應用的諸多希望。然而，智能合約只能處理確定性邏輯（因此每個節(jié)點在處理完同一交易和塊后都能達到相同的狀態(tài)），而大量現(xiàn)存的業(yè)務邏輯是不確定的，在不同時間和不同環(huán)境參數(shù)下可能會發(fā)生變化。特別是現(xiàn)在，業(yè)務系統(tǒng)越來越依賴于計算機的算法進行決策優(yōu)化，包括自然語言處理（Natural Language Processing，NLP），機器學習和操作研究算法。我們經(jīng)常會故意在這些算法中添加一些隨機性，以使決策不僅僅是局部最優(yōu)狀態(tài)，同時試圖找到一個更好的次優(yōu)結果。

另一方面，一些真實世界的業(yè)務邏輯應該在鏈下運行，不應該作為諸如可重復運算的智能合約這種類型來執(zhí)行。利用分布式賬本集成和協(xié)同鏈下的服務和資源，是進一步推動區(qū)塊鏈技術在更多真實場景中應用的關鍵。

使用一個公有鏈來處理所有用例是不可行的。每天都有不同的區(qū)塊鏈上線，各自專注于解決問題的一個方面，比如分布式存儲、資產(chǎn)所有權或市場預測等。據(jù)coinmarketcap.com顯示，目前有超過1000種加密貨幣在不同的交易平臺上活躍。

構建業(yè)務應用程序時涉及處理存儲以及不同數(shù)據(jù)源的來源，我們的另一個工作動機是如何通過重用一些現(xiàn)有的工作，比如存儲（IPFS， SIA， Storj.io等等）、數(shù)據(jù)發(fā)送（Augur，Gnosis，Oraclize等）和物聯(lián)網(wǎng)（IOTA等）提供的這些專用的區(qū)塊鏈，而不是“重新發(fā)明輪子”。

此外，有很多（近）實時業(yè)務交易確實需要更密切的聯(lián)盟鏈/許可鏈/私有鏈來處理性能問題、安全問題和業(yè)務治理要求。因此，我們對分布式商業(yè)基礎設施的愿景是要具備在多種異構鏈，包括公共鏈/聯(lián)盟鏈/許可鏈/私有鏈之間具備互操作的能力。

跨鏈技術是滿足這一需求非常自然的解決方案。然而目前為止，現(xiàn)有的跨鏈技術主要是為了在已有區(qū)塊鏈中提供互操作性，并專注于通證的價值轉移。如何使用不同區(qū)塊鏈提供的資源，這一問題仍然沒有答案。

比較現(xiàn)有的跨鏈技術如Cosmos 和 Polkadot，提出的跨鏈技術，我們發(fā)現(xiàn)Cosmos為互操作性和可擴展性提供了更成熟的基礎。尤其我們發(fā)現(xiàn)Cosmos的多樞紐多分區(qū)（ “many hubs and many zones” ）和每個分區(qū)都是獨立的區(qū)塊鏈，擁有獨立的治理模型（ “each zones are independent blockchains having independent governance models” 的設計，提供了一種非常合適的體系架構，可以用SOC（SeperaTIon of Concern，SOC）的方式對現(xiàn)實世界的復雜性進行建模。為了最好地重用現(xiàn)有框架，我們提出了IRIS網(wǎng)絡（IRIS Network），它是由一個樞紐和眾多分區(qū)構成的去中心化的跨鏈網(wǎng)絡，基于Cosmos/Tendermint實現(xiàn)，具有更為完善的通證使用。

鑒于IRIS網(wǎng)絡是基于Cosmos/Tendermint設計的，我們將首先討論Cosmos/Tendermint，總結我們從Cosmos/Tendermint繼承的特性和獨特的創(chuàng)新。

Cosmos 和 Tendermint

Cosmos想要建立“區(qū)塊鏈的互聯(lián)網(wǎng)”。這是由許多被稱為分區(qū)“Zone”的獨立區(qū)塊鏈構成的互聯(lián)網(wǎng)絡，每個分區(qū)都由經(jīng)典的拜占庭容錯（ByzanTIne fault-tolerant，BFT）共識協(xié)議（如Tendermint）提供支持。

Tendermint提供了一個高性能、一致的、安全的BFT共識引擎，嚴格的分叉問責保證能夠控制作惡者的行為。Tendermint非常適合用于擴展異構區(qū)塊鏈，包括公有鏈以及注重的性能的許可鏈/聯(lián)盟鏈，像Ethermint 就是一次對Ethereum以太坊POS機制的快速實現(xiàn)。使用Tendermint在許可/聯(lián)盟鏈域中的成功案例包括Oracle ，CITA ［8］和Hyperledger Burrow 。

Tendermint作為共識協(xié)議用于在Cosmos Hub上構建第一個分區(qū)。Cosmos Hub可以連接到許多不同類型的分區(qū)，并且通過一種相當于區(qū)塊鏈之間的虛擬UDP或TCP的IBC協(xié)議（ Inter-blockchain CommunicaTIon，IBC）實現(xiàn)跨鏈通信。通證可以安全地通過Cosmos Hub從一個分區(qū)轉移到另一個分區(qū)，而不需要在分區(qū)之間的交易所或受信任的第三方。

為了使用Cosmos Hub開發(fā)強大的可互操作區(qū)塊鏈和區(qū)塊鏈應用，Cosmos SDK提供了區(qū)塊鏈常用模塊的開發(fā)“入門套件”，而不是限制可實現(xiàn)的用戶故事，從而為應用定制提供了最大的靈活性。

IRIS 技術創(chuàng)新

IRIS網(wǎng)絡的目標是為構建分布式商業(yè)應用提供技術基礎設施，它超越了主要用于數(shù)字資產(chǎn)的現(xiàn)有區(qū)塊鏈系統(tǒng)。

我們打算通過IRIS網(wǎng)絡解決的關鍵挑戰(zhàn)在于兩個方面：

· 利用分布式賬本支持鏈下運算資源的集成和協(xié)同

· 服務跨異構區(qū)塊鏈的互操作性

我們通過將面向服務的基礎架構融入Cosmos / Tendermint來應對這些挑戰(zhàn)。

我們的設計繼承了多年來面向服務架構（Service-oriented Architecture，SOA）實踐的思維模式。 SOA是一種架構方法，用于創(chuàng)建由自治服務構建的系統(tǒng)，這些系統(tǒng)具有明確的邊界、共享模式和契約［13］。早期的SOA實踐側重于實施企業(yè)服務總線（Enterprise Service Bus，ESB），通過服務提供者和服務消費者之間的各種點對點連接組成公用總線，實現(xiàn)服務間的通信。但是，通過ESB集中管理服務可能會觸發(fā)單點故障，也會增加服務部署的依賴性。最近大量的微服務架構可以看作是SOA的發(fā)展，不再關注ESB而是使用輕量級的消息隊列進行服務間通信。在IRIS網(wǎng)絡中，服務之間的通信旨在通過實施區(qū)塊鏈作為信任機器來協(xié)同實現(xiàn)商業(yè)協(xié)作，使它在服務提供者和服務消費者之間很難建立信任的前提下也能運行。

IRIS網(wǎng)絡使用Tendermint協(xié)議作為高性能的共識引擎。利用Tendermint的區(qū)塊鏈應用接口（ApplicaTIon BlockChain Interface，ABCI）提供的靈活性，我們定義了一組服務的基礎交易類型，包括：服務提供，服務消費和服務治理。如前所述，大多數(shù)業(yè)務邏輯不適合作為區(qū)塊鏈上確定的智能合約來實施，我們正在使用這個服務層將業(yè)務應用的特定邏輯和事務處理移出區(qū)塊鏈，僅使用區(qū)塊鏈對這些服務產(chǎn)生的結果達成共識。這一想法也受到區(qū)塊鏈社區(qū)已有成果的啟發(fā)，將一些復雜計算從主鏈上移除以解決性能問題，例如Lightning Network的離線狀態(tài)通道以及Plasma的防欺詐側鏈。盡管我們沒有實施側鏈，但是我們將傳統(tǒng)業(yè)務邏輯計算從區(qū)塊鏈中剝離出來，并將其用作復雜業(yè)務協(xié)作的可信中介總線。

對于跨鏈通信，Cosmos IBC 定義了一個協(xié)議用于將價值從一條鏈上的某個帳戶轉移到另一條鏈上的某個帳戶的協(xié)議。而IRIS網(wǎng)絡設計了新的語義，以允許利用IBC調用跨鏈計算資源。我們認為這種能力在構建可擴展的業(yè)務應用程序時非常重要。更詳細的潛在用例將會在后面描述。

IRIS網(wǎng)絡旨在提供服務基礎設施，以處理和協(xié)同鏈上的交易處理與鏈下的數(shù)據(jù)處理和業(yè)務邏輯執(zhí)行。必要時，擴展的IBC功能允許那些鏈下的處理被跨鏈調用。按目前的設想，IRIS網(wǎng)絡還將包含客戶端工具，一個支持跨鏈多資產(chǎn)存儲的智能錢包以及服務消費方和提供方使用的iServices。我們計劃提供SDK以輕松構建iServices。例如，對于特定的服務定義，客戶端Client SDK將生成服務提供方的框架以及服務消費方的模塊。

IRIS 網(wǎng)絡設計

如上圖所示，IRIS網(wǎng)絡在設計上與Cosmos網(wǎng)絡具有相同的拓撲結構。我們計劃將IRIS Hub作為Cosmos眾多分區(qū)和區(qū)域型Hub之一與Cosmos Hub連接起來。IRIS SDK本身就是計劃對Cosmos SDK的擴展，由IRIS SDK開發(fā)的IRIS全節(jié)點旨在提供一個服務的基礎設施，并在內(nèi)部集成了分布式文件系統(tǒng)IPFS（InterPlanetary File System，IPFS）。

IRIS Services（又名“iServices”）旨在對鏈下服務從定義、綁定（服務提供方注冊）、調用到治理（分析和爭端解決）的全生命周期傳遞，來跨越區(qū)塊鏈世界和傳統(tǒng)業(yè)務應用世界之間的鴻溝。 IRIS SDK通過增強的IBC處理邏輯來支持服務語義，以允許分布式商業(yè)服務在區(qū)塊鏈互聯(lián)網(wǎng)上可用。

盡管IRIS網(wǎng)絡專注于為分布式業(yè)務應用提供創(chuàng)新解決方案，但它仍是Cosmos網(wǎng)絡的一部分。連接到IRIS Hub的所有分區(qū)都可以通過標準IBC協(xié)議與Cosmos網(wǎng)絡中的任何其他分區(qū)進行交互。此外，我們相信通過引入服務語義層可以實現(xiàn)全新的業(yè)務場景，創(chuàng)新的IRIS網(wǎng)絡將增加Cosmos網(wǎng)絡的規(guī)模和多樣性。

網(wǎng)絡參與者

1. 服務消費者服務消費者是通過向網(wǎng)絡發(fā)送請求并接收響應來使用鏈下服務的用戶。

2. 服務提供者服務提供者是那些可能提供一個或多個iService定義的用戶，并且通常是其它公有鏈和聯(lián)盟鏈甚至傳統(tǒng)企業(yè)應用系統(tǒng)中鏈下服務和資源之間的適配器。服務提供者監(jiān)聽和處理傳入的請求，并將結果發(fā)送回網(wǎng)絡。一個服務提供者可以向其它服務提供者發(fā)送請求而同時成為服務消費者。服務提供者可以按計劃為他們提供的任何服務收取費用，默認情況下服務費使用IRIS網(wǎng)絡的原生費用通證“IRIS”定價；也可以在適當?shù)臅r候考慮使用Cosmos白名單中的其他費用通證對服務定價。

3. 分析員分析員是一種特殊用戶，代表了發(fā)起建立IRIS網(wǎng)絡的IRIS基金會有限公司（IRIS Foundation Limited），這是一家注冊在香港的股份有限公司。分析員是在分析模式中調用iServices的唯一授權用戶，旨在幫助創(chuàng)建和維護服務提供者的概要文件，通過這些客觀的概要文件服務消費者可以選擇合適的服務提供者。

IRIS 服務

在本節(jié)中，我們列出了在IRIS網(wǎng)絡上部署iService時預計使用的技術參數(shù)。

服務定義

Method包括：

· ID （int）： iService中該方法的唯一標識

· Name （string）： iService中該方法的唯一名稱

· Description （string）：對該方法的描述

· Input （string）：對輸入?yún)?shù)的結構化定義

· Output （string）：對輸出結果的機構化定義

· Error （string）：對可能出現(xiàn)的錯誤條件的結構化定義

· OutputPrivacy （enum）：設置此方法是非隱私的還是公鑰加密的，可選值NoPrivacy/PubKeyEncryption

ServiceDefinition包括：

· Name （string）：該iService服務的名稱

· Description （string）：對此iService服務的描述

· Tags （string）：此iService服務以逗號分隔的關鍵字

· Creator （string）：對此iService服務創(chuàng)建者的描述。可選

· ChainID （string）：最初定義此iService服務的區(qū)塊鏈標識

· Messaging （enum）：設置此服務消息是單播還是多播，可選值Unicast/Multicast

· Methods （［］Method）：定義此iService服務中可用的方法

CreateServiceDefinitionTx 交易包括：

· Definition （ServiceDefinition）：創(chuàng)建的服務定義

服務綁定：

CreateServiceBindingTx 交易包括：

· DefinitionHash （［］byte）：服務定義的哈希值，由服務提供者綁定

· ChainID （string）：服務提供者所接入的區(qū)塊鏈標識

· ProviderAddress （［］byte）：服務提供者的區(qū)塊鏈地址

· BindingType （enum）：對服務是本地還是全局的設置，可選值Local/Global；其中Global選項將綁定暴露到全局，反之則使用Local

· ProviderDeposit （int64）：服務提供者的保證金。服務提供者必須提供大于系統(tǒng)參數(shù)MinProviderDeposit所設（以IRIS通證計數(shù)）的保證金，才能創(chuàng)建有效的綁定，押金越高意味著更值得信任

· ServicePricing （string）：服務定價?；诿總€方法對服務價格模型的結構化定義，包括每次的調用成本、批量折扣、促銷條款等；服務費默認使用IRIS通證也可以是白名單列出的其它費用通證

· ServiceLevel （string）：服務水平。對服務提供者自己認可所綁定服務水平的結構化定義，包括響應時間、可用性等。

· BindingExpiration （int64）：此綁定過期的區(qū)塊高度，采用負數(shù)即表示“永不過期”

UpdateServiceBindingTx 交易包括：

· DefinitionHash （［］byte）：服務定義的哈希值，由服務提供者綁定

· ChainID （string）：服務提供者接入?yún)^(qū)塊鏈標識

· ProviderAddress （［］byte）：服務提供者的區(qū)塊鏈地址

· ChangeSet （string）：更改集，由前面三個字段確定的現(xiàn)有綁定所需更改內(nèi)容的結構化定義

服務提供者可以在任何時間更新ServicePricing，ServiceLevel和BindingExpiration，但他們的少量保證金將隨后續(xù)（分別由ServiceLevelUpdateSlash和 BindingExpirationUpdateSlash規(guī)定的）兩種情況減少。當BindingExpiration設置的高度低于當前區(qū)塊高度，將立即被解釋為無效的綁定。

更新 ProviderDeposit將始終被視為adding to，即增加當前保證金余額。當保證金低于MinProviderDeposit時，綁定將失效，直到服務提供者增加余額高于閾值方可恢復。綁定過期或者失效的時候，保證金余額將自動返還給服務提供者。

BindingType可用從Local更改為Global，但反之不行。要把一個綁定從Global 降到 Local，服務提供者只能先使綁定的問題失效，然后重新創(chuàng)建一個 Local型的綁定。

如果服務提供者出于某種原因需要將綁定移到一個新地址，是不允許直接更新ProviderAddress的；必須先使當前綁定失效，再使用所需的 ProviderAddress創(chuàng)建另一個綁定。

一個 ServiceBinding 的對象將在應用程序成功的執(zhí)行這兩個交易時（例如，在IRIS SDK種的iService業(yè)務邏輯）被創(chuàng)建或更新。

ServiceBinding包括：

· DefinitionHash （［］byte）

· ChainID （string）

· ProviderAddress （［］byte）

· ServiceLevel （string）

· ServicePricing （string）

· BindingExpiration （int64）

· IsValid （enum）：可選項True/False

服務調用

服務消費者和服務提供者被建議通過端點（endpoints）交互。有兩種服務端點 —— 請求表（request table）和響應表（response table）（見上圖）。服務請求被添加到請求表，感興趣的服務提供者監(jiān)控這些請求表并接收和處理發(fā)送給他們的請求; 服務結果（或錯誤）被返回由相應的服務消費者反過來監(jiān)控的響應表中。

Multicast多播服務的所有綁定共享一個請求表;而Unicast單播服務為每個綁定創(chuàng)建和維護單獨的請求表。至于另一個方向（的服務）將為每個服務消費者創(chuàng)建和管理專用的響應表。

ServiceRequest交易包括：

· ChainID （string）：服務消費者所接入的區(qū)塊鏈標識ID

· ConsumerAddress （［］byte）：服務消費者所的區(qū)塊鏈地址

· DefinitionHash （［］byte）：服務定義的哈希值

· MethodID （int）：被調用的方法ID

· InputValue （string）：輸入值的結構化表示

· BindingHash （［］byte）：在‘Unicast’單播服務情況下目標綁定的哈希值。可選

· MaxServiceFee （int64）：服務消費者愿意為一個‘Multicast’多播請求支付的最大服務費金額 ?？蛇x

· Timeout （int）：服務消費者愿意等待響應返回的最大區(qū)塊數(shù)

PostServiceRequestTx 交易包括：

· Requests （［］ServiceRequest）：被發(fā)送的服務請求

· RequestDeposits （［］int64）：服務消費者必須為每個請求者（使用IRIS計數(shù)）支付大于MinRequestDeposit的押金。此押金目的是為了激勵消費者及時確認收到的服務響應（參考 ConfirmServiceResponseTx）。

應用程序將驗證用戶與‘ChainID’和‘ConsumerAddress’一致的每一個請求、目標綁定的有效性、請求押金充足，服務消費者帳戶余額足夠支付請求押金和服務費用，并且請求的總數(shù)小于MaxRequestPostBatch。

當一個已驗證請求被追加到請求表中時，相關服務費用（對‘Multicast’多播方式是‘MaxServiceFee’）將從服務消費者的賬戶中扣除并鎖定到第三方托管。

GetServiceRequest 查詢包括：

· DefinitionHash （［］byte）：服務定義的哈希值

· BindingHash （［］byte）：服務提供者對此問題綁定服務的哈希值; 應用程序將驗證綁定有效，并且調用者具有匹配綁定的區(qū)塊鏈標識ChainID和服務提供者地址ProviderAddress

· BeginHeight （uint64）：應用程序應當從此區(qū)塊高度開始檢索對服務提供者的請求，一般是最大請求數(shù)‘BatchSize’和‘MaxRequestGetBatch’中較小的一個

· BatchSize （int）：返回的最大請求數(shù)

ServiceResponse 查詢包括：

· RequestHash （［］byte）：所匹配請求的哈希值

· BindingHash （［］byte）：服務提供者綁定服務的哈希值

· OutputValue （［］byte）：輸出結果的結構化（可能加密）表示。可選

· ErrorMsg （string）：錯誤信息的結構化表示?？蛇x

PostServiceResponseTx 交易包含：

· Responses （［］ServiceResponse）：服務回復內(nèi)容

應用程序將驗證服務提供者的每個響應是否帶有匹配的區(qū)塊鏈標識ChainID和地址ProviderAddress，并且該交易中的響應數(shù)少于MaxResponsePostBatch。經(jīng)過驗證的請求將附加到目標消費者的響應表中。

GetServiceResponse 查詢包括：

· RequestHash （［］byte）：原始請求的哈希值，應用程序將校驗調用者是否有匹配的區(qū)塊鏈標識‘ChainID’和服務消費者地址‘ConsumerAddress’

· BeginHeight （uint64）：應用程序應當從此區(qū)塊高度開始檢索服務提供者的響應，一般是最大響應數(shù)BatchSize和MaxResponseGetBatch中的較小的一個

· BatchSize （int）：返回的最大響應數(shù)

ConfirmServiceResponseTx 交易包含：

· ResponseHash （［］［］byte）：待確認響應的哈希值

應用程序將驗證每個待確認響應是否確實是由調用者發(fā)起的請求，并且此交易中的響應數(shù)量小于MaxResponseConfirmBatch。

從Timeout超時窗口中退出的響應（對于‘Multicast’多播服務，當MaxServiceFee隨響應返回增加而消耗光時）將不會被應用程序接受。服務消費者一收到‘Unicast’單播響應就立即開始處理。然而，對于Multicast多播響應，必須等待Timeout超時窗口結束，然后才開始處理可能收到的全部響應。

當一個Unicast單播響應被用戶確認，相關服務費用將從托管賬戶中釋放到匹配的服務提供者賬戶 ——其中扣除少量（由‘ServiceFeeTaxRate’定義的）稅金并添加到系統(tǒng)準備金（system reserve）中; 同時，相關請求的押金也將退還給服務消費者。

在Multicast多播請求的情況有點復雜：每個響應確認時，只有部分請求押金被退還給服務消費者，即此響應相關服務費用占MaxServiceFee的比例; 在所有的響應被確認之后，此請求剩余的托管余額將會退還給服務消費者。

如果請求超時而沒有看到任何響應，則應用程序將托管中的相關余額以及請求押金全額退還給用戶。但是，如果用戶沒有（在ResponseConfirmTimeout+響應區(qū)塊數(shù)的高度之前）及時確認回復，請求押金將被執(zhí)行一個（由ResponseConfirmDelayPenaltyRate定義的）小懲罰再退還給消費者，與此同時，相關服務費將照常釋放給服務提供者。

爭議解決

在任何情況下如果服務消費者對服務響應不滿意，就應該存在一種機制允許服務消費者發(fā)出投訴，從而獲得可接受的解決方案，而不必求助于諸如法律系統(tǒng)等集中的權威。同時，這種機制應避免引入可能會被任一方濫用的主觀評價。

解決出現(xiàn)在IRIS網(wǎng)絡上的爭議，其過程類似于服務調用，不僅服務消費者向服務提供者發(fā)送Complaint（服務），而且服務提供者以一個Resolution（服務）進行響應。這些交互是通過一對稱為投訴表（complaint table）和解決方案表（resolution table）的全局端點來實現(xiàn)的。

在IRIS網(wǎng)絡目前的設計中，提交投訴時需要一份消費押金。如果服務消費者不及時確認某個解決方案，將從該押金中扣除罰款。同樣地，如果服務提供者不及時響應投訴，他的保證金將被部分削減。

Complaint 包含：

· ResponseHash （［］byte）：對爭議響應的哈希

· Problem （string）：對服務響應的問題描述

· PreferredDisposal （enum）：可以是Refund或Redo選項

Resolution包括：

· ComplaintHash （［］byte）：對所匹配投訴的哈希

· Disposal （enum）：可以是Refund或Redo選項

· Refund （uint64）：服務費退款。可選

· OutputValue （［］byte）：輸出結果的結構化（可能加密）表示。可選

如上所述，我們預期的爭議解決流程可能不具有法律約束力。盡管如此，我們認為這將為解決IRIS網(wǎng)絡上的常見爭議提供有效手段。

服務分析

引入iService生態(tài)系統(tǒng)帶來一些挑戰(zhàn)。一個主要的挑戰(zhàn)是找到一種方法，讓服務消費者更容易發(fā)現(xiàn)合適的服務提供者——服務消費者需要性能指標來評估和選擇服務提供商，但如果沒有服務消費者的使用，性能指標也就不可用。

為了試圖解決這個循環(huán)問題，我們計劃引入一種分析機制，在這個機制中，一個享有特權的系統(tǒng)用戶即分析員，在常規(guī)的調度下調用所有活動的服務。這將使網(wǎng)絡中的客觀性能數(shù)據(jù)（例如響應時間、可用性、投訴處理等）對實際消費者有用。

服務分析調用將免除服務費用和消費押金，但會產(chǎn)生網(wǎng)絡交易費用。這些調用來自那些被應用程序識別和認可的保留地址。

對于新服務，分析活動將保持相對穩(wěn)定的水平，隨著它們開始吸引真正的服務消費者調用并預計生成更多的性能數(shù)據(jù)，分析活動將逐漸減少單個服務的使用。

分析過程中發(fā)生的交易費用默認情況下從系統(tǒng)準備金（system reserve）中支付，必要時基金會準備金（Foundation reserve）將會介入。

查詢

上述所有與服務生命周期相關的對象都可以使用ABCI ‘Query’接口［［3］］查詢到。這些查詢將通過‘Query’連接執(zhí)行，并不參與共識過程。我們已經(jīng)看到了如何得到的GetServiceRequest和得到GetServiceResponse查詢作為服務調用過程的一部分。上面描述的所有與服務相關的生命周期對象都可以使用ABCI查詢接口3來查詢。

以下是我們目前計劃的查詢的一個非詳盡的摘要：

服務對象

性能指標

IBC 改進

在Cosmos上建立自己的服務基礎架構有一個獨特優(yōu)勢：服務可以部署一次，并通過區(qū)塊鏈互聯(lián)網(wǎng)隨時隨地進行調用。具體來說，我們的計劃是完成以下內(nèi)容：

1. 服務定義廣播到IRIS網(wǎng)絡中的每個分區(qū)；

2. 全局服務綁定廣播到IRIS網(wǎng)絡中的每個分區(qū)；

3. 針對遠程提供者的服務請求或投訴被路由到提供者所連接的區(qū)塊鏈；

4. 針對遠程消費者的服務響應或決議被路由回消費者所連接的區(qū)塊鏈。

在處理一個CreateServiceDefinitionTx交易時，應用程序被設計為首先在本地驗證和存儲ServiceDefinition對象，然后創(chuàng)建一個包含了對每個相鄰鏈定義的IBCPacket。

每個相鄰鏈最終從相應的中繼過程中接收包含該數(shù)據(jù)包的IBCPacketTx；如果此定義在接收鏈中尚不存在，則后者將通過為他的每個相鄰鏈（除了最初接收數(shù)據(jù)包的源鏈之外）創(chuàng)建一個IBCPacket來傳遞此定義；如果該定義已經(jīng)存在，接收鏈將停止傳遞此定義。

同樣，當ServiceBinding創(chuàng)建或更新它的BindingType集合或更新為Global時，將為每個相鄰鏈創(chuàng)建一個包含綁定的IBCPacket數(shù)據(jù)包，并在整個IRIS網(wǎng)絡中進行廣播。

上述IBCPacket由以下部分組成：

· Header （IBCPacketHeader）：數(shù)據(jù)包的頭部

· Payload（ServiceDefinition或ServiceBinding）：服務定義或綁定的字節(jié)數(shù)

前面提到的IBCPacketHeader由以下部分組成：

· SrcChainID（string）：創(chuàng)建此數(shù)據(jù)包的區(qū)塊鏈標識ID

· DstChainID（string）：此數(shù)據(jù)包將派往的相鄰區(qū)塊鏈標識ID

· Number（int）：數(shù)據(jù)包對應的唯一編號

· Status（enum）：‘NoAck’

· Type （string）：“iris-service-definition”或者是“iris-service-binding”

現(xiàn)在讓我們來看看如何通過IBC發(fā)生跨鏈服務調用。當請求一個Unicast單播服務時，應用程序檢查目標綁定是否是Local本地的，如果是Local則將ServiceRequest追加到相應的請求表中，如2.2所述；否則，將會創(chuàng)建一個包含ServiceRequest的IBCPacket。

包含一個‘ServiceRequest’的IBCPacket由以下部分組成：

· Header（IBCPacketHeader）：數(shù)據(jù)包的頭部

· Payload（ServiceRequest）：服務請求的字節(jié)數(shù)

前面提到的IBCPacketHeader由以下部分組成：

· SrcChainID（string）：創(chuàng)建此數(shù)據(jù)包的區(qū)塊鏈標識ID

· DstChainID（string）：遠程服務提供者所在的區(qū)塊鏈標識ID，例如‘ServiceRequest’、‘ServiceBinding’、‘ChainID’

· Number（int）：數(shù)據(jù)包對應的唯一編號

· Status（enum）：‘AckPending’

· Type（string）：“iris-service-request”

· MaxHeight（int）：當前高度加上‘ServiceRequest.Timeout’

當遠程請求最終到達目標鏈時，應用程序將其追加到相應的端點（請求表）中，以便進行目標綁定。對此遠程請求的響應將被包裝在一個收據(jù)IBCPacket中，該收據(jù)被一直路由回到源鏈，并將其追加到原始消費者的遠程端點（響應表）中。

對遠程的Multicast多播服務的請求以相同的方式處理，只不過可以在源鏈中生成多個IBCPacket。

遠程投訴和解決的工作方式與請求和響應的方式相同，因此在此不做詳細闡述。

下面是應用程序依賴IBCPacket類型的完整列表：

用例

在本節(jié)中，我們?yōu)镮RIS網(wǎng)絡列出了一些可能的用例。

分布式人工智能用于隱私保護下的數(shù)據(jù)分析

這個用例的服務基礎架構已由位于上海的科技創(chuàng)業(yè)公司邊界智能進行了原型設計，并將其應用到聯(lián)盟鏈產(chǎn)品BEAN （BlockchainEdge Analytics Network）中，用于解決長期已來為運行分析模型獲取數(shù)據(jù)的挑戰(zhàn)。盡管同態(tài)加密是允許通過加密數(shù)據(jù)實現(xiàn)計算的關鍵方法之一，但由于性能低下，實際上無法解決現(xiàn)實世界的機器學習問題。因此，BEAN的創(chuàng)建提供了另一種解決方案--利用傳統(tǒng)的分布式人工智能研究［14］中的模型并行性和SOA設計模式，作為區(qū)塊鏈的附加層開發(fā)分布式分析服務。

為了保護數(shù)據(jù)存取，運行在數(shù)據(jù)端的（部分）模型需要開放給客戶端，并在服務定義中說明。由于只有部分模型開放給客戶端，模型開發(fā)人員不必擔心有人竊取他們的想法；同樣，數(shù)據(jù)擁有者永遠不需要擔心失去對其數(shù)據(jù)使用的控制，因為數(shù)據(jù)不會離開他們的數(shù)據(jù)源。

其他潛在的好處可能包括以下幾點：

1. 僅在鏈上交換少量參數(shù)數(shù)據(jù)，這可以幫助提高性能。

2. 一種更實用的數(shù)據(jù)使用審計方法，這在醫(yī)療保健領域經(jīng)常被用到。

醫(yī)療健康數(shù)據(jù)隱私度高，涉及眾多安全需求。這就為醫(yī)療健康數(shù)據(jù)用于跨組織協(xié)作的目的提出了挑戰(zhàn)（例如用于輔助診斷的跨醫(yī)院會診記錄搜索，新藥臨床試驗的患者身份，健康保險自動理賠等）。最小化可行產(chǎn)品（Minimum Viable Product，MVP）服務層的實現(xiàn)是建立在Ethermint的基礎之上，試圖連接眾多醫(yī)院、保險公司和分析服務提供者，以提供具有隱私保護的醫(yī)療健康數(shù)據(jù)分析能力。

支持鏈上服務注冊和調用的智能合約已經(jīng)實現(xiàn)。鏈下數(shù)據(jù)處理的一個例子是支持相關診斷組（Diagnosis Related Group，DRG）的分組分析服務。更具體地說，當一個醫(yī)院用戶調用DRG服務時，原始醫(yī)療記錄將在鏈下進行處理，使用服務提供者提供的客戶端NLP（由SQL和Python實現(xiàn)）代碼存根來提取通過區(qū)塊鏈接收DRGS服務傳來的結構化數(shù)據(jù)，而不傳遞高度機密的原始醫(yī)療記錄。

BEAN場景闡述了一個更復雜的服務使用案例，包括實現(xiàn)分布式分析、連接服務提供者和服務消費者、利用區(qū)塊鏈提供可審計交易平臺以及可信任的分布式計算基礎。

數(shù)據(jù)和分析電子市場

通過對幾個AI+區(qū)塊鏈項目的研究，發(fā)現(xiàn)似乎大部分項目都旨在提供數(shù)據(jù)交換市場和分析API市場。在建議的IRIS基礎架構中，通過使用IRIS服務提供者SDK來發(fā)布數(shù)據(jù)作為數(shù)據(jù)服務和包裝分析API作為分析服務，從而輕松地構建這些網(wǎng)絡。

分布式電子商務

將建議的IRIS基礎架構與傳統(tǒng)系統(tǒng)（例如ERP）集成以獲取庫存信息，或對可信數(shù)據(jù)源進行鏈間查詢以獲取交通和天氣數(shù)據(jù)等信息，此方法與許多企業(yè)應用程序開發(fā)人員已經(jīng)熟悉的方法非常相似。通過集成這些服務來支持分布式電子商務應用程序，就有可能提供與中心化系統(tǒng)（例如Amazon亞馬遜或Alibaba阿里巴巴）相近的用戶體驗。

公有鏈和聯(lián)盟鏈的結合

對于許多業(yè)務場景而言，采用混合了公有鏈和聯(lián)盟鏈優(yōu)良特性的混合架構，從而可以提供有益的結果，特別是在性能、安全性和經(jīng)濟激勵方面。

例如，醫(yī)院和保險公司可以組成聯(lián)盟鏈以支持高性能的醫(yī)療保險交易，同時識別其他信息，例如關于某些疾病的全球服務的統(tǒng)計數(shù)據(jù)，這些信息可以從其他公有鏈中調用。從公有鏈接收到的通證可以返回給聯(lián)盟鏈中的信息提供者，從而激勵系統(tǒng)參與者改善和提高服務質量。利用IRIS提供的這種基礎架構，可以在滿足嚴格的性能和安全要求的前提下實現(xiàn)大規(guī)模的自發(fā)協(xié)作。

IRIS服務基礎架構可以支持許多用例，例如更高效的基于資產(chǎn)的安全系統(tǒng)、分布式監(jiān)管技術（如嚴格評估，互助市場等）。IRIS項目計劃之一還包括與此類應用程序項目團隊展開密切合作，以支持并使他們能夠擁有所需的區(qū)塊鏈基礎架構，讓他們專注于更高效地交付預期的業(yè)務價值。

通證經(jīng)濟

與Cosmos網(wǎng)絡相似，IRIS網(wǎng)絡也被設計為支持多通證模型。這些通證被不同的分區(qū)所擁有，同時可以通過IRIS樞紐從一個分區(qū)轉移到另一個分區(qū)。我們構建了兩種通證類型來支持IRIS網(wǎng)絡上的操作：

· 權益通證

· 費用通證

權益通證

與Cosmos網(wǎng)絡 15采用同樣的權益機制設計，IRIS樞紐也擁有自己特殊的原生通證來表示權益。通證命名為IRIS。關于IRIS通證，我們設計了一些具體功能，其包括：

· 通過驗證人和代理人系統(tǒng)，將IRIS通證整合到IRIS網(wǎng)絡的共識引擎驗證人中;

· 代表投票權，參與IRIS網(wǎng)絡的治理

費用通證

在IRIS網(wǎng)絡中有兩種費用通證：

· 網(wǎng)絡費用用來進行垃圾請求防范和支付驗證人進行賬本維護的報酬;

· 服務費用用來支付部署iServices的服務提供者的報酬。默認支付服務的通證為IRIS通證

IRIS網(wǎng)絡旨在支持所有來自Cosmos網(wǎng)絡白名單中的費用通證，例如 Photon光子，以及IRIS通證。

支持各種白名單的中的費用通證是我們計劃從Cosmos中采用的一個特性。它可以為網(wǎng)絡的參與者提供增強的體驗。在Cosmos中，對于網(wǎng)絡費用通證network fee token，每一個驗證人都擁有配置文件來定義他自己對每一個費用通證的價值評估。驗證人可以運行一個獨立的定時器，根據(jù)實時市場數(shù)據(jù)更新配置信息，或者使用默認的配置數(shù)據(jù)。

對于服務費用通證service fee token的設計，同樣支持多通證模型。因此，在IRIS網(wǎng)絡上的服務提供者，可以自由選擇白名單中出現(xiàn)的通證為其服務收費。

為了幫助IRIS網(wǎng)絡的參與者降低通證價格的波動性，基金會希望發(fā)展全球性的iService以從不同的交易所、或者從oracle預言機的潛在信息中獲取市場價格數(shù)據(jù)。

權益通證和費用通證都會進一步細化以確保符合法律和監(jiān)管規(guī)定的義務。

初始通證分配

最開始，系統(tǒng)預計發(fā)放2000000000個IRIS通證。IRIS通證的分布計劃如下：

· 私募： 25%

· 邊界智能： 15% （自IRIS Hub主網(wǎng)上線起的4年成熟期，每月釋放1/48。）

· Tendermint： 10% （自IRIS Hub主網(wǎng)上線起的2年成熟期，每月釋放1/24。）

· IRIS 基金會： 15% （保留用作基金會的日常建設和運營）

· 生態(tài)建設： 30% （在鏈接到IRIS Hub的分區(qū)中進行通證交換；激勵潛在用戶；獎勵的合作伙伴;潛在未來募資）

· 對Cosmos生態(tài)ATOM持有者的空投： 5%

如果IRIS網(wǎng)絡完全開發(fā)完畢，IRIS通證每年的通脹速率會根據(jù)網(wǎng)絡質押情況通過社區(qū)治理進行調整，以期很大一部分流通中的IRIS通證能被參與者作為權益證明主動投入到網(wǎng)絡驗證中。