53％的回應組織正在將區(qū)塊鏈列為未來兩年的最高戰(zhàn)略重點

區(qū)塊鏈具有很大的發(fā)展前景，但企業(yè)對采用這種技術(shù)創(chuàng)新猶豫不決。 其中一個主要原因是供應商鎖定的風險，即企業(yè)大量投資于公司的技術(shù)，如果公司希望轉(zhuǎn)換，公司在合作的同時，不希望數(shù)據(jù)轉(zhuǎn)移提供給其他供應商。Insolar正在創(chuàng)建一個可與其他主要分布式分類帳技術(shù)（DLT）互操作的平臺，以促進該技術(shù)的更廣泛采用。

根據(jù)德勤2019年全球區(qū)塊鏈調(diào)查，53％的回應組織將區(qū)塊鏈列為未來兩年的最高戰(zhàn)略重點。 雖然這在2018年增長了10％，但區(qū)塊鏈的采用仍然是謹慎的，并不普遍。 這種猶豫和等待觀察方法的部分原因在于缺乏區(qū)塊鏈平臺的互操作性。在將不同的DLT和傳統(tǒng)系統(tǒng)結(jié)合使用，創(chuàng)建混合架構(gòu)方面，行業(yè)需要自由選擇。 選擇可以分為三類：

不同DLT之間的通信

目前阻礙采用區(qū)塊鏈和分布式賬本技術(shù)的一個方面是缺乏不同DLT之間互操作性的標準。 這是一種雞與蛋的因果關(guān)系，因為只有當大部分市場采用特定技術(shù)時，公認的標準才能成為現(xiàn)實標準。 在此之前，我們不能有任何標準集。 然而，像Insolar這樣的平臺可以使他們的技術(shù)與其他DLT平臺集成。 因此，Insolar區(qū)塊鏈平臺的創(chuàng)建可與區(qū)塊鏈領域的其他幾個主要平臺互操作。

與傳統(tǒng)技術(shù)的互操作性

區(qū)塊鏈平臺和傳統(tǒng)系統(tǒng)之間的數(shù)據(jù)共享是希望大規(guī)模采用的任何平臺的必要舉措。 這是因為幾乎所有數(shù)據(jù)目前都保存在這樣的系統(tǒng)上。 如果我們考慮將紙質(zhì)文檔數(shù)字化（即掃描并以數(shù)字方式保存）的艱巨任務，這種復制會占用時間和空間。 因此，這里的想法是使傳統(tǒng)系統(tǒng)與區(qū)塊鏈可互操作，使得所述區(qū)塊鏈系統(tǒng)能夠訪問保存到前幾代數(shù)字技術(shù)的數(shù)據(jù)。 如果發(fā)生這種情況，可以分三個階段設想從遺留系統(tǒng)到區(qū)塊鏈的遷移：

1）集成區(qū)塊鏈，使其記錄與傳統(tǒng)系統(tǒng)相同的信息。

2）逐步切換到僅在區(qū)塊鏈上記錄信息，接口能夠訪問傳統(tǒng)和基于區(qū)塊鏈的數(shù)據(jù)庫以檢索數(shù)據(jù)。

3）所有數(shù)據(jù)存儲在區(qū)塊鏈上并減少傳統(tǒng)技術(shù)使用，可能通過將所有數(shù)據(jù)切換到基于區(qū)塊鏈的管理。

DLT平臺內(nèi)的交互

DLT平臺可以由多個網(wǎng)絡組成，并且這些網(wǎng)絡不一定必須互連。 如果不是，那么它們甚至可能無法彼此互操作，即使它們是使用單一技術(shù)構(gòu)建的。 屬于一個平臺提供商的公共和專用網(wǎng)絡無法彼此共享數(shù)據(jù)就屬于這種情況。 混合區(qū)塊鏈網(wǎng)絡的創(chuàng)建允許開放和封閉網(wǎng)絡之間的互操作性和數(shù)據(jù)共享。 在Insolar區(qū)塊鏈平臺上，可以有許多不同的云運行私有或公共網(wǎng)絡。 但是，它們能夠通過內(nèi)部協(xié)議相互通信，同步不同云之間的Merkle樣張（見下文）。

Merkle Tree Hashes的互操作性

Merkle trees是區(qū)塊鏈的核心特征。 它們將數(shù)據(jù)壓縮為更易于管理的格式，同時它們還使數(shù)據(jù)事務更易于驗證并檢查它們是否已被篡改。Merkle Tree是通過加密散列（將數(shù)據(jù)轉(zhuǎn)換為唯一文本）多個事務來創(chuàng)建的，以提供值（散列），然后成對散列生成的散列（唯一文本）以形成頂級散列成為根的層次結(jié)構(gòu) 它下面的哈希值的總和。 如果任何事務被篡改，它會導致從它創(chuàng)建的哈希值發(fā)生變化，因此很容易返回并查看某些內(nèi)容已被更改。

因此，通過在網(wǎng)絡中的對象狀態(tài)上提供可獨立驗證的加密證明（Merkle散列）來確定真相是什么。

在區(qū)塊鏈中，互操作性的范例意味著如何引用塊的特定版本，依賴項或哈希碼。 在Insolar中，對事務的Merkle根的引用提供了不同Insolar云之間的互操作性的基礎，并且計劃在連接到其他DLT時使用。 因此，合同可以接收呼叫并驗證證據(jù)，而無需直接訪問分類帳。

DLT與Insolar的互操作性

在Insolar上，將有兩種方法可以在平臺和其他DLT云之間建立通信。 第一種是通過遠程調(diào)用高級API，類似于與傳統(tǒng)系統(tǒng)的通信。 具體來說，對于Hyperledger Fabric，這將是唯一的選擇。 但是，此選項不提供任何跨DLT驗證：Insolar和DLT將基本上通過oracles相互交談。 第二種選擇是將包含在Insolar域中的不同DLT的代碼并行運行，從而創(chuàng)建所謂的“parachain”配置。 它基本上像緩沖區(qū)一樣使用Insolar代碼和來自兩個平臺的數(shù)據(jù)。Insolar和其他DLT之間的Merkle樣張將通過這個特殊的Insolar域進行驗證。

還有可能在Insolar上運行原生合同。 最初的計劃是運行Hyperledger Fabric鏈代碼，但Insolar也能夠在其虛擬機中運行Go或基于Java的合同。

需要互操作平臺的互操作，為業(yè)界提供構(gòu)建異構(gòu)架構(gòu)的廣泛選擇。 因此，我們避免供應商鎖定，這反過來將導致更多的DLT采用，因為使用相同的數(shù)據(jù)更容易嘗試不同的平臺。Insolar已經(jīng)確定，在技術(shù)開發(fā)的這個相對早期階段，從其他平臺執(zhí)行本地合同是區(qū)塊鏈采用的關(guān)鍵。