多企业间如何实现 “链上协同与治理”

公众号对话框回复【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开源社区经常讲“把代码丢出去，把信任建起来”，很让人钦佩。开源社区不仅仅包括社区发起者和运营维护者，更重要的是有广大开发者，“众人拾柴火焰高”，在国内开源社区建设中，能调动开源社区广大开发者力量是很关键的。

本文来源：陀螺财经
原文标题：多企业间如何实现 “链上协同与治理”

—-

编译者/作者：陀螺财经

玩币族申明：玩币族作为开放的资讯翻译/分享平台，所提供的所有资讯仅代表作者个人观点，与玩币族平台立场无关，且不构成任何投资理财建议。文章版权归原作者所有。