公眾號對話方塊回覆【UCOB】下載完整方案
在近期眾多大賽中，社羣湧現出許多優質的區塊鏈應用方案，這些方案讓大家看到技術本身的蓬勃活力，也折射了區塊鏈助力產業發展的無限潛力。
應社羣開發者要求，社群每週四《超話區塊鏈》直播課推出了“對話區塊鏈應用先行者”系列，與大家分享、展示這些獲獎團隊的技術應用方案，希望可以給大家日常開發提供一些啟迪。
本期邀請區塊鏈資深開發者朱立派分享他在BSN第二次開發者大賽上的獲獎作品：《United Corporation On Blockchain》（區塊鏈上的聯合公司），探討多企業間如何實現 “鏈上協同與治理”。
為什麼選擇企業間多方協同治理場景？
很多朋友可能會好奇，為什麼會有“區塊鏈上的聯合公司”這樣看起來天馬行空的想法？
首先，區塊鏈技術很適用於“多方協同治理”場景。多中心化自治組織開放式治理能力體現在任何人只要有相應的憑證，就可以公開行使治理。受此啟發，我想基於聯盟鏈實現類似功能：聯盟各方都具備事先約定的治理能力，透過區塊鏈技術保證治理過程的公平、公正、公開、可追溯和不可抵賴。
其次，公司實際業務往來之間對“多方協同治理”存在真實場景需求。
比如一般公司間的業務往來常涉及專案、資金兩大類，如果多家公司需要聯合管理某個專案，且有資金往來，就可以考慮使用區塊鏈技術實現“鏈上協同與治理”。大家可保持對專案進展的全域性視野一致，同時，任何簽字確認的流程都由對應私鑰簽名後觸發，更容易實現責任到人。
鏈上協同與治理實現思路
各家公司在區塊鏈上以單獨的“公司合約”形式存在，只要實現了“公司合約介面”便可自定義公司內部業務邏輯與內部組織關係。
公司想要加入聯合公司時，首先提出申請，部署自己的“公司合約”；然後由已在聯合公司中的成員以新部署的“公司合約地址”作為引數發起提案；在得到聯合公司中大多數成員投票透過後，便可以正式成為聯合公司中的一員。
各家公司參與的專案將單獨以“聯合專案合約”的形式存在，聯合公司內任一家成員公司都可以發起聯合專案。
首先依據“專案合約介面”開發“聯合專案合約”，部署到區塊鏈上；並以“聯合專案合約的地址”作為提案中的引數，發起提案；聯合公司中每一家公司可以根據提案中的合約地址檢視合約，決定是否投票該提案；當得到聯合公司中大多數成員公司投票透過後，即成為“聯合專案合約”。
區塊鏈智慧合約設計思路與關鍵邏輯
合約設計思路
在合約設計上，參考了 FISCO BCOS開源社羣《智慧合約編寫之Solidity的程式設計攻略》文章裡的思路，採用“資料、管理、控制”分層的設計方法。
本智慧合約方案主要有三大模組：聯合治理模組、公司模組、專案模組，合約互動主要發生在這三大模組的合約之間。
聯合治理模組：提案與投票系統，聯合公司成員管理系統，聯合公司間資金流轉系統；
公司模組：單個公司管理系統，單個公司內部資金流轉系統；
專案模組：多個公司的聯合專案管理，單個公司的內部專案管理。
其中，“聯盟管理模組”集中管理“公司模組”合約和“專案模組”合約，管理機制主要為“投票-註冊”；公司合約、專案合約在實現對應介面合約方法的基礎上自定義業務邏輯，並以單獨合約的形式上鍊。
合約功能上，主要有以下幾點：
投票註冊功能，只有投票數超過一定比率，新公司才能成為聯合公司一員，新專案才能認定為聯合專案；
專案管理功能，如專案管理員的設定；
基於角色的許可權控制，自定義角色和許可權；
資金流轉，包括公司之間的資金流轉（涉及跨合約呼叫）和公司內部的資金流轉；
資金髮行功能，依據投票決定是否發行資金。
關鍵邏輯的合約程式碼實現
這裡介紹專案中一些關鍵邏輯的合約程式碼實現，以“儲存類智慧合約”的所有權轉移為例。
本專案採取了“儲存、邏輯、控制”分層設計的思路，部署者在部署“儲存類智慧合約”後必須轉移合約所有權關係給控制器類智慧合約，儲存類合約方法如下：
function transferOwnership(address newOwner) public onlyOwner {require(newOwner != address(0), "Ownable: new owner is the zero address");emit OwnershipTransferred(_owner, newOwner);_owner = newOwner;}上述“newOwner”引數必須為對應的“控制器合約”地址。這樣，“儲存類智慧合約”透過修飾器“modifier onlyOwner()”保證了只有對應的“控制器智慧合約”才可以修改“儲存類智慧合約”的資料。
部署完成後在“控制器合約”中透過如下方法可驗證是否已具備“儲存類合約”的所有權。
function checkUCOBNodeStorageSafety() public view returns (bool) {return ucobNodeStorage.owner()==address(this);}控制器類智慧合約的程式碼邏輯可以升級，透過投票來決定是否升級。
function changeUCOBNodeStorageOwner(bytes32 proposalId) public {require(proposalPassed(proposalId,...));...ucobNodeStorage.transferOwnership(UCOBNodeControllerAddress);...}當投票透過後，“儲存類智慧合約”的所有權關係會轉移到新的“控制器合約”地址上，資料不變，但是業務邏輯“升級”了。
更多專案中的關鍵邏輯合約程式碼實現，可以透過社羣公眾號後臺回覆【UCOB】獲取完整程式碼及說明。更多行業設計方案請關注社群每週四直播的《超話區塊鏈》，公眾號對話方塊回覆【小助手】入群。
嘉賓Q&A
Q：您能分享下作品準備過程中，遇到哪些技術問題？又是如何解決的？
A：給我比較深印象的有兩個問題，一個是遇到某些合約方法無法直接使用WeBASE網頁端或透過控制檯訪問的情況。
比如代理呼叫的方法，首先嚐試“sendRawTransaction”介面請求節點服務來呼叫這個方法，把交易資料編碼並簽名後，直接傳送RLP編碼給節點，但是節點日誌提示解析錯誤。
後來在FISCO BCOS官方群裡尋求幫助，發現是我的編碼方法不對，調整之後，呼叫就成功了。
還有一個和測試有關，因為專案部署時，有幾個合約會依賴其他合約部署後的地址，所以如果測試時發現合約程式碼不對，就要全部重新部署一遍再測試。我解決的方法是首先在Remix IDE上測試，程式碼不對就重新部署，還比較快速。全部的邏輯都測試透過沒問題了，再放到FISCO BCOS上測，這個時候就是測試SDK與合約的互動了。
Q：在做底層技術選型時，您考慮哪些因素？
A：我主要考慮這幾個方面：節點部署簡單快速，生態元件豐富易用，社羣支援及時有效，再一個就是對初學者而言容易上手。
因為我之前也有研究過國外的某個開源底層平臺，我是透過英文文件開始研究的。如果是本身就不瞭解區塊鏈的人，從英文文件開始，學習成本就很高了。一方面要理解英文，另一方面還要理解英文所表述的專業詞彙。像FISCO BCOS這樣的國產開源區塊鏈平臺，提供完善的中文文件，對一個初學者而言只需要理解專業詞彙就好了，沒有語言的成本，比較容易上手。
Q：對於國內開源的發展，您怎麼看？
A：我看到FISCO BCOS開源社羣經常講“把程式碼丟出去，把信任建起來”，很讓人欽佩。開源社羣不僅僅包括社羣發起者和運營維護者，更重要的是有廣大開發者，“眾人拾柴火焰高”，在國內開源社羣建設中，能調動開源社羣廣大開發者力量是很關鍵的。
