鑑於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通證能被參與者作為權益證明主動投入到網路驗證中。
首要說明的是，私募的IRIS通證將用於開發IRIS網路。這部分通證的使用計劃如下：
· 運營: 10% (包括服務提供者和承建商的費用，例如，審計、顧問、法律和其他第三方費用，以及其它管理費）)
· 軟體開發: 50% (包括直接用於開發上線所需的成本、費用和開支)
· 開發者支援: 10% (包括駭客馬拉松、志願者獎勵和培訓專案)
· 研發贊助: 10% (包括會議、研究專案和大學合作)
· 市場拓展: 20% (包括業務發展，社羣發展和推廣，以及出差、交流、出版、發行和其他費用等)
關於更多IRIS網路資訊：https://www.irisnet.org/
更多區塊鏈專案介紹：http://www.qukuaiwang.com.cn/news/xiangmu
風險提示：區塊鏈投資具有極大的風險，專案披露可能不完整或有欺騙。請在嘗試投資前確定自己承受以上風險的能力。本網站只做專案介紹，專案真假和價值並未做任何稽覈。
