亚洲精品综合在线,高清一级片在线播放,色二区,污片网站,久草视频观看,蜜桃视频成人网站入口,日韩黄色视频大全,国产女人18毛片水真

點擊藍字

關(guān)注我們

本文由“GO開源說”第十期《BitXHub——區(qū)塊鏈跨鏈協(xié)作平臺》直播內(nèi)容修改整理而成，視頻內(nèi)容較長，本文內(nèi)容有所刪減和重構(gòu)。

當前的區(qū)塊鏈應用和底層技術(shù)平臺呈現(xiàn)出百花齊放的狀態(tài)，但主流區(qū)塊鏈應用中的每條鏈大多仍是一個獨立的、垂直的封閉體系。在業(yè)務形式日益復雜的商業(yè)應用場景下，鏈與鏈之間缺乏統(tǒng)一的互聯(lián)互通機制，這極大限制了區(qū)塊鏈上數(shù)字資產(chǎn)價值的流動性，跨鏈需求由此而來。

BitXHub平臺由中繼鏈、應用鏈以及跨鏈網(wǎng)關(guān)三種角色組成，并鏈原生集成W3C標準的DID，依據(jù)場景導向可靈活組織部署架構(gòu)，具有通用跨鏈傳輸協(xié)議、異構(gòu)交易驗證引擎、多層級路由三大核心功能特性，保證跨鏈交易過程的安全性、靈活性與可靠性。BitXHub于2020年3月份開源核心代碼組件，希望與廣大開發(fā)者攜手共建萬鏈互聯(lián)生態(tài)。

項目開源地址：GitHub: https://github.com/meshplus/bitxhub

BitXHub系統(tǒng)架構(gòu)

BitXHub的技術(shù)架構(gòu)如下圖，自下而上分為物理層、基礎(chǔ)層、跨鏈服務層、接口層四個部分。

第一層是物理層，中繼鏈的設(shè)計為了滿足不同場景下用戶物理環(huán)境需求，支持在普通物理機、云主機或者嵌入式設(shè)備上穩(wěn)定運行，兼顧多場景適用性。

第二層是基礎(chǔ)層，這一層包含了聯(lián)盟鏈本身需要具備的模塊，比如網(wǎng)絡(luò)模塊、存儲模塊、共識模塊、虛擬機、隱私安全模塊。

第三層是跨鏈相關(guān)的服務層，包括應用鏈管理模塊、執(zhí)行模塊、事務管理模塊、驗證引擎模塊和隱私保護模塊，各模塊互相協(xié)作完成中繼跨鏈流程。

第四層是接口層，中繼鏈對外提供gRPC和Restful兩種接口服務，支持不同場景下用戶的使用。

接下來為大家分享 BitXHub核心模塊的工作原理，主要包括：跨鏈交易并行執(zhí)行設(shè)計方案、如何使用GO插件機制適配多種共識算法以及BitXHub中的多模塊化實踐。

跨鏈交易并行處理

背景

在區(qū)塊鏈中，每個區(qū)塊中包含一個交易列表，但是一般都是串行執(zhí)行，因為串行執(zhí)行雖然能夠保證每個節(jié)點得到賬本保持一致。

在中繼鏈上，交易能夠分為跨鏈交易和普通交易。普通交易負責中繼鏈上原生的一些事務處理，數(shù)量較少，執(zhí)行的速度較快；另一部分是跨鏈交易，這是中繼鏈上主要的交易類型，跨鏈交易由于涉及到驗證規(guī)則的驗證，在執(zhí)行速度上是比較慢的。

為了加速中繼鏈上的交易執(zhí)行，我們想到可以對無依賴關(guān)系的交易進行并行化的處理，這些交易對于賬本的改動并不重合，可以提升中繼鏈處理交易的效率。

我們對于中繼鏈上的交易進行分類，并對鏈上的主要交易類型——跨鏈交易進行額外的加速策略。

分組策略

對于一個區(qū)塊中的交易列表：

首先區(qū)分這些交易中普通交易和跨鏈交易。

按照區(qū)塊中交易的順序，沒有被普通交易隔斷的跨鏈交易可以分為一組，碰到普通交易之后必須開始重新分組。這是因為普通交易中可能包含應用鏈管理、驗證規(guī)則管理等類型的交易，如果這些類型的交易為執(zhí)行的話，可能會影響到后續(xù)跨鏈交易的執(zhí)行。

跨鏈交易分組

對于上述的每一個跨鏈交易分組，還可以進一步細分這些跨鏈交易。因為跨鏈交易中可能是從不同的應用鏈上發(fā)送過來的，這些不同應用鏈上發(fā)出的跨鏈交易本身在中繼鏈上的處理是不會相互影響的，所以這些跨鏈交易可以被繼續(xù)細分。

交易執(zhí)行

在上述兩個步驟中，能夠得到多個分組，但是對于這些分組，并不能簡單的全部并行執(zhí)行。能夠進行并行處理的部分是跨鏈交易的部分，普通交易還是無法并行執(zhí)行。當交易列表中存在普通交易時，必須恢復到串行執(zhí)行，碰到跨鏈交易的分組，可以按照發(fā)起鏈分成的細分組來并行處理。

共識算法插件模塊

Go語言的插件系統(tǒng)基于C語言動態(tài)庫實現(xiàn)的，通過采用Go語言提供的插件模式，實現(xiàn)BitXHub對共識插件的動態(tài)鏈接加載。動態(tài)鏈接的機制可以為我們提供更多的靈活性，主程序可以在編譯后動態(tài)加載共享庫實現(xiàn)熱插拔的插件系統(tǒng)。

1. 查找插件路徑是否存在（編譯后的.so文件）；

2. 通過Go語言plugin模塊加載插件文件，plugin.Open返回結(jié)構(gòu)體中包含方法符號表；

3. 查找插件是否實現(xiàn)NewNode方法符號，直接利用了結(jié)構(gòu)體中的符號表，如果沒有對應的符號表會返回錯誤；

4. 類型斷言方法的入?yún)⒑统鰠ⅲ?/span>

5. 調(diào)用NewNode方法，這一步返回真正的共識算法模塊實例；

多模塊選擇加載

BitXHub中某些模塊有多種實現(xiàn)，比如交易執(zhí)行模塊有串行執(zhí)行器和并行執(zhí)行器，賬本模塊有帶歷史數(shù)據(jù)的賬本實現(xiàn)和不帶歷史數(shù)據(jù)的賬本實現(xiàn)。如果僅僅是這種多種實現(xiàn)的情況，直接在BitXHub代碼中進行實現(xiàn)即可，BitXHub啟動時根據(jù)配置文件進行選擇。但是我們碰到了一個特別的需求，某些特性（比如并行執(zhí)行器）僅在商業(yè)版BitXHub中提供，并不開放源代碼。因此直接在開源的BitXHub中實現(xiàn)代碼是不可能的；同時，商業(yè)版和開源版的大部分代碼是一樣的，在內(nèi)部再維護一份商業(yè)版本的BitXHub也是不太現(xiàn)實的。因此，我們選擇僅僅把商業(yè)版本特性閉源，利用go語言的特性將開源的BitXHub和閉源的商業(yè)版本模塊結(jié)合，即可編譯出商業(yè)版本的BitXHub二進制文件。

以串行執(zhí)行器和并行執(zhí)行器為例，并行執(zhí)行器模塊如何編譯到BitXHub中呢？BitXHub代碼中存在一個.template文件專門import用于閉源的模塊，如果編譯商業(yè)版本，Makefile便會根據(jù)該文件生成.go文件將這兩個模塊的包引入（這種go語言中帶下劃線的import方式可以顯式的調(diào)用包的init方法）；同時，BitXHub中存在一個goent.diff，里面記錄了那些閉源的特性模塊使用的具體版本，編譯商業(yè)版本時會根據(jù)該文件修改go.mod。這樣閉源特性相關(guān)模塊就編譯進BitXHub了。

另外，我們開發(fā)了一個單獨的Agency模塊，該模塊有register和get方法，register方法用于注冊不同類型的執(zhí)行器的構(gòu)造方法，get方法根據(jù)傳入的類型得到對應的執(zhí)行器的構(gòu)造方法。

串行執(zhí)行器和并行執(zhí)行器都在init方法中調(diào)用agency中的register方法進行各自類型和構(gòu)造方法的注冊。當BitXHub啟動時，所有包的init方法會先于main方法運行，這樣兩個執(zhí)行器的類型和構(gòu)造方法就被注冊進agency模塊了，當main函數(shù)運行時，BitXHub根據(jù)配置文件得到需要加載的執(zhí)行器類型，并從agency模塊中得到對應的構(gòu)造函數(shù)，就可以構(gòu)造出對應的執(zhí)行器進行使用了。