如何利用現有的區塊鏈資源

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

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

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

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

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

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

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

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

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

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

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

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

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

Cosmos 和 Tendermint

Cosmos想要建立“區塊鏈的互聯網”。這是由許多被稱為分區“Zone”的獨立區塊鏈構成的互聯網絡，每個分區都由經典的拜占庭容錯（Byzantine fault-tolerant，BFT）共識協議（如Tendermint）提供支持。

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

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

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

IRIS 技術創新

IRIS網絡的目標是為構建分布式商業應用提供技術基礎設施，它超越了主要用于數字資產的現有區塊鏈系統。

我們打算通過IRIS網絡解決的關鍵挑戰在于兩個方面：

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

· 服務跨異構區塊鏈的互操作性

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

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

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

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

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

IRIS 網絡設計

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

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

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

網絡參與者

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

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

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

IRIS 服務

在本節中，我們列出了在IRIS網絡上部署iService時預計使用的技術參數。

服務定義

Method包括：

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

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

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

· Input （string）：對輸入參數的結構化定義

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

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

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

ServiceDefinition包括：

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

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

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

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

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

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

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

CreateServiceDefinitionTx 交易包括：

· Definition （ServiceDefinition）：創建的服務定義

服務綁定：

CreateServiceBindingTx 交易包括：

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

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

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

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

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

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

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

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

UpdateServiceBindingTx 交易包括：

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

· ChainID （string）：服務提供者接入區塊鏈標識

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

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

如何利用現有的區塊鏈資源

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

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

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

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

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

ServiceBinding包括：

· DefinitionHash （［］byte）

· ChainID （string）

· ProviderAddress （［］byte）

· ServiceLevel （string）

· ServicePricing （string）

· BindingExpiration （int64）

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

服務調用

如何利用現有的區塊鏈資源

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

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

ServiceRequest交易包括：

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

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

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

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

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

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

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

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

PostServiceRequestTx 交易包括：

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

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

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

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

GetServiceRequest 查詢包括：

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

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

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

· BatchSize （int）：返回的最大請求數

ServiceResponse 查詢包括：

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

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

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

· ErrorMsg （string）：錯誤信息的結構化表示。可選

PostServiceResponseTx 交易包含：

· Responses （［］ServiceResponse）：服務回復內容

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

GetServiceResponse 查詢包括：

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

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

· BatchSize （int）：返回的最大響應數

ConfirmServiceResponseTx 交易包含：

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

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

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

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

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

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

爭議解決

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

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

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

Complaint 包含：

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

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

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

Resolution包括：

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

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

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

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

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

服務分析

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

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

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

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

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

查詢

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

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

服務對象

性能指標

IBC 改進

在Cosmos上建立自己的服務基礎架構有一個獨特優勢：服務可以部署一次，并通過區塊鏈互聯網隨時隨地進行調用。具體來說，我們的計劃是完成以下內容：

1. 服務定義廣播到IRIS網絡中的每個分區；

2. 全局服務綁定廣播到IRIS網絡中的每個分區；

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

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

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

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

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

上述IBCPacket由以下部分組成：

· Header （IBCPacketHeader）：數據包的頭部

· Payload（ServiceDefinition或ServiceBinding）：服務定義或綁定的字節數

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

· SrcChainID（string）：創建此數據包的區塊鏈標識ID

· DstChainID（string）：此數據包將派往的相鄰區塊鏈標識ID

· Number（int）：數據包對應的唯一編號

· Status（enum）：‘NoAck’

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

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

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

· Header（IBCPacketHeader）：數據包的頭部

· Payload（ServiceRequest）：服務請求的字節數

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

· SrcChainID（string）：創建此數據包的區塊鏈標識ID

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

· Number（int）：數據包對應的唯一編號

· Status（enum）：‘AckPending’

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

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

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

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

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

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

用例

在本節中，我們為IRIS網絡列出了一些可能的用例。

分布式人工智能用于隱私保護下的數據分析

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

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

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

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

2. 一種更實用的數據使用審計方法，這在醫療保健領域經常被用到。

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

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

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

數據和分析電子市場

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

分布式電子商務

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

公有鏈和聯盟鏈的結合

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

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

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

通證經濟

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

· 權益通證

· 費用通證

權益通證

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

· 通過驗證人和代理人系統，將IRIS通證整合到IRIS網絡的共識引擎驗證人中;

· 代表投票權，參與IRIS網絡的治理

費用通證

在IRIS網絡中有兩種費用通證：

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

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

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

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

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

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

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

初始通證分配

最開始，系統預計發放2000000000個IRIS通證。IRIS通證的分布計劃如下：

· 私募： 25%

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

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

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

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

· 對Cosmos生態ATOM持有者的空投： 5%

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