實現(xiàn)許可的區(qū)塊鏈解決方案既有趣又具有挑戰(zhàn)性。每天，主流媒體上都有新文章聲稱，區(qū)塊鏈技術將如何改變行業(yè)，但現(xiàn)實并沒有那么迷人。區(qū)塊鏈給已經(jīng)建立的企業(yè)業(yè)務流程帶來了巨大的價值，但是大多數(shù)被許可的區(qū)塊鏈實現(xiàn)都沒有通過試點階段。在最初的興奮之后，大多數(shù)團隊意識到，要將新的Web3技術集成到現(xiàn)有的企業(yè)堆棧中，大規(guī)模實現(xiàn)許可的區(qū)塊鏈應用程序需要大量的技術技能和基礎設施構建。

在過去的一年里，Invector Labs的團隊已經(jīng)接觸到了高度復雜的區(qū)塊鏈場景，每個場景都有自己的一組基礎設施挑戰(zhàn)。在與經(jīng)歷過幾次軟件革命的技術人員分享我們的經(jīng)驗時，他們中的許多人將web應用程序的實現(xiàn)與Netscape早期的web應用程序或Oracle以及IBM DB2早期的數(shù)據(jù)庫系統(tǒng)的實現(xiàn)相提并論。在這些實例中，這些技術的真實應用程序的用例比相應的基礎設施發(fā)展得更快。這種動態(tài)與云計算或移動計算等最近的轉型技術運動形成了鮮明對比，在這些技術運動中，基礎設施從一開始就非常穩(wěn)固。

獲得許可的區(qū)塊鏈解決方案的真正挑戰(zhàn)是什么？從標識、數(shù)據(jù)存儲、集成或消息傳遞等核心基礎設施領域，到部署和管理智能合約的流程;獲得許可的區(qū)塊鏈應用程序要求開發(fā)人員在適當?shù)奈恢迷O置正確的構建塊，以提高效率。在Invector Labs，我們很幸運地試驗了許多新的區(qū)塊鏈協(xié)議或工具，我們經(jīng)常使用這些協(xié)議或工具來解決許可的區(qū)塊鏈實現(xiàn)所面臨的挑戰(zhàn)。不幸的是，根據(jù)底層的區(qū)塊鏈堆棧，這些工具和技術看起來完全不同。

通往任何獲得許可的區(qū)塊鏈應用程序的道路都要從兩個基本決定開始：

第一個問題的答案將決定區(qū)塊鏈應用程序的核心開發(fā)堆棧。目前，像Hyperledger Fabric、Quorum或Parity這樣的以太坊變體是區(qū)塊鏈解決方案的主要選擇，此外還有像R3 Corda或Hyperledger Sawtooth也有一定的吸引力。至少在紙面上，像Dfinity或Hashgraph這樣的即將出現(xiàn)的堆棧似乎非常適合獲得許可的區(qū)塊鏈解決方案，但它們在實踐中尚未得到證明。

第二個問題的答案將決定許可的區(qū)塊鏈應用程序的核心基礎結構。提供和維護內(nèi)部區(qū)塊鏈網(wǎng)絡遠非一件容易的事情，而且最受許可的區(qū)塊鏈堆棧也不能很好地與Docker或Kubernetes等平臺集成。區(qū)塊鏈即服務 （BaaS）平臺，如azure BaaS、Kaleido或最近AWS提供的服務，可以真正地簡化區(qū)塊鏈網(wǎng)絡的供應和管理，允許開發(fā)人員專注于構建dApp，而不是基礎設施。

下圖說明了上述兩個問題的決策過程。

獲得許可的區(qū)塊鏈應用程序的真正挑戰(zhàn)

選擇一個區(qū)塊鏈平臺和相應的運行時只是旅程的開始。任何經(jīng)過許可的區(qū)塊鏈解決方案，只要比經(jīng)過美化的數(shù)據(jù)庫更復雜，就會遇到底層平臺無法直接解決的大量基礎設施挑戰(zhàn)。讓我們來探索其中的一些。

集成

如果您在許可的區(qū)塊鏈應用程序中使用智能合約，那么您可能會面臨與API的脫鏈系統(tǒng)通信的挑戰(zhàn)。Oracle是處理外部通信的區(qū)塊鏈架構的組件。然而，實施Oracle是一項高度發(fā)展的工作。我們發(fā)現(xiàn)有幾個技術在這方面很有幫助：

·Chainlink： Chainlink提供了一個簡單的編程模型，可以將比特幣或以太坊智能合約與外部輸入連接起來。該框架還避免了依賴“集中的Oracle”作為單一故障點。

·Rhombus： Rhombus是Oracle競賽的最新參與者，它為以太坊智能合約與外部數(shù)據(jù)系統(tǒng)的連接提供了一個非常優(yōu)雅的模型。Rhombus支持基于激活模式（如計劃或按需）以及推或拉數(shù)據(jù)訪問模式的不同Oracle架構。

·Oraclize： Oraclize專注于將API和數(shù)據(jù)系統(tǒng)連接到不同的區(qū)塊鏈，如Ethereum、EOS、Hyperledger Fabric或BlockApps。Oraclize的編程模型并不像其他替代方案那樣豐富，但它通過對不同區(qū)塊鏈的強大支持來彌補這一點。

數(shù)據(jù)訪問

被許可的區(qū)塊鏈對信息的書寫很有幫助，但對信息的閱讀卻沒什么幫助。大多數(shù)經(jīng)過許可的區(qū)塊鏈解決方案都需要與區(qū)塊鏈中記錄的數(shù)據(jù)交互，但是這些數(shù)據(jù)很難訪問，而且非常難以理解。以下是一些幫助應對這一挑戰(zhàn)的協(xié)議：

·圖表： 圖表提供了一種機制，用于將Ethereum智能契合約處理的數(shù)據(jù)公開為GraphQL端點。這允許外部應用程序使用熟悉的GraphQL syntaxs查詢區(qū)塊鏈數(shù)據(jù)。

數(shù)據(jù)隱私

許多獲得許可的區(qū)塊鏈場景在受監(jiān)管的行業(yè)中運行，這些行業(yè)具有很強的數(shù)據(jù)隱私約束。因此，保護和加強對鏈上數(shù)據(jù)的訪問控制是獲得許可的區(qū)塊鏈解決方案的關鍵要求。下面，我列出了一些我們發(fā)現(xiàn)在這方面有幫助的技術：

· Quorum： Quorum區(qū)塊鏈使用零知識證明的形式為私有事務提供本地支持。

· Aztec：最近宣布的Aztec協(xié)議在以太坊智能合約中提供了零知識隱私的可靠實現(xiàn)。

數(shù)據(jù)存儲

區(qū)塊鏈并不是存儲大量數(shù)據(jù)的最佳工具。獲得許可的區(qū)塊鏈解決方案通常需要外部數(shù)據(jù)存儲。不幸的是，許多適合公共區(qū)塊鏈的分散化存儲解決方案并不適用于許可的區(qū)塊鏈場景。以下是這方面的一些解決方案：

·BigchainDB： BigchainDB為事務的存儲和查詢提供了一個經(jīng)過優(yōu)化的分散式數(shù)據(jù)庫模型?？梢允褂肕ongoDB查詢語言來查詢BigchainDB中的數(shù)據(jù)，MongoDB查詢語言支持豐富的數(shù)據(jù)訪問交互。

·IPFS專用網(wǎng)： IPFS是區(qū)塊鏈應用最流行的存儲系統(tǒng)，但通常被視為區(qū)塊鏈的公共解決方案。但是，IPFS支持將通信限制到一組已知節(jié)點的私有網(wǎng)絡的配置。

·AWS量子賬本： 我們對即將發(fā)布的AWS量子賬本數(shù)據(jù)庫非常感興趣。在許多獲得許可的區(qū)塊鏈場景中，沒有共識的不變性概念當然是切實可行的，如果沒有ese，量子賬本也可以成為私有分散式應用程序的補充存儲模型。

身份

在許可的區(qū)塊鏈解決方案網(wǎng)絡中參與者的身份相對來說是眾所周知的。因此，許多復雜的協(xié)商共識計算協(xié)議在這些場景中是多余的。此外，大多數(shù)企業(yè)已經(jīng)擁有了它們希望在許可的區(qū)塊鏈解決方案中利用的用戶目錄。下面列出的技術有助于處理許可的區(qū)塊鏈解決方案中的標識：

·uPort： uPort一直在穩(wěn)步構建一系列用于管理分散式應用中的身份協(xié)議和解決方案。當前堆棧與以太坊智能合約兼容，可以在許可的區(qū)塊鏈應用程序中使用

·Azure BaaS： Azure團隊出色地擴展了不同區(qū)塊鏈的核心協(xié)議，以利用Azure Active Directory身份。最近的一個例子是在以太坊應用程序中實現(xiàn)了權威驗證協(xié)商共識協(xié)議。

在消息傳遞、測試、版本控制和許多其他領域，區(qū)塊鏈應用程序的許可還面臨著更多的挑戰(zhàn)。本文中列出的協(xié)議和工具是我們在現(xiàn)實世界實現(xiàn)中發(fā)現(xiàn)的最有效解決方案，但是在不久的將來，可能會有大量即將出現(xiàn)的技術堆棧。