蚂蚁区块链投票案例(二)---投票合约设计开发

摘要

计划用三篇文章，一个月左右的时间来实现一个蚂蚁开放联盟链上的区块链投票案例，本文是系列第二篇。

1. 蚂蚁区块链投票案例(一)—蚂蚁链简介
2. 蚂蚁区块链投票案例(二)—投票合约设计开发
3. 蚂蚁区块链投票案例(三)—Java调用部分实现（整理中）

---

背景

本文将结合具体的投票案例，设计一组区块链投票合约，并将合约部署到蚂蚁开放联盟链进行测试。重点在于结合工具展示蚂蚁链solidity合约的开发、升级、调用的过程，业务流程尽量简单，不会涉及投票的匿名性、抗胁迫性等指标。

---

案例场景

本案例虚构了一个业主投票的场景，小区议事过程中，一般需要有业主提出议案事项，如“小区是否允许外卖小哥进入？”，议案交到业主大会，由业主大会整理并发起业主投票，计票规则一般是一户一票，权重按照房屋面积计算，如果超过一半面积的业主同意，议案则获得通过。因为投票的前后组织工作非常复杂繁重，可能需要线下扫楼等，所以一般一次投票不会只针对一个议案。每个议案下通常固定有三个选项，“同意”、“不同意”、“弃权”。因为是演示项目，流程和业务逻辑都尽量简单，例如我们在计票时不回采用面积权重的方法，只是简单的超过半数即可，不同意、弃权、未参与投票几种情况也不会做特殊处理（实际投票中，未参与投票可能会被记入同意）。

---

用例分析

通过案例场景分析，系统中存在系统管理员、业主两种角色，每种角色又对应不同操作，本案例演示重点在合约的设计开发，所以不会区分系统的管理端和业主端，也不会做对应的鉴权等操作，统一配置一个swagger方便测试。一个完备的系统中应该将信息同时写到数据库中和数据合约中，但简单起见，本案例只向合约中写入数据，不涉及到Mysql等DB操作。下图为本案例中涉及到的用例。

接下来逐个分析：

系统管理员注册

系统管理员承担了系统基础信息的维护工作，其所进行的操作需要上到区块链留痕，这里的注册我们简化为系统账户与蚂蚁链的链上账户地址绑定。

添加小区、添加房屋

系统管理员通过该功能向系统中添加小区和房屋信息，准备投票的基本信息。

编辑房屋

主要用来演示如何对合约中数据进行编辑。

发起投票

系统管理员组织并发起一次投票。需要初始化的内容包括投票起止时间、议案、可投票房屋地址等。

统计投票

在投票结束后，调用合约对投票进行计票。

业主注册

任何一个新业主账号在系统注册时，都会生成一个唯一业主数据合约与其对应。在系列上一篇中讲过，国内区块链应用实际是中介化，具体到这个用例，业主并不能用他的链上钱包地址直接对链上合约进行操作，总是要通过投票系统这个“中介”，所以业主也没必要具备自己的钱包地址，要完成数据上链，只要存到业主数据合约就可以了。

业主实名认证

业主信息注册后需要业主进行人脸识别或者提交身份证正反面信息进行实名认证。业主合约这里做的主要是认证信息固化存证，可包括身份证号、照片哈希等。

客房关系认证

业主实名认证后可像自己名下添加房屋，同样客房关系的证明，如房产证照片Hash等可以上链存证。

投票

业主对管理员发起的议案进行投票。这里需要对业主身份进行判断，对重复投票进行检测等。

---

合约设计

设计原则

开始合约设计前，我们先明确下合约的设计原则。

智能合约的生命周期主要有设计、开发、部署、运行、升级、销毁。其中的设计和升级阶段是核心，相对于非区块链项目，区块链多了一个不可篡改的特性，升级时合约需要做到向下兼容。从业务视角来看，智能合约只需要做两件事，其一是如何定义数据的结构和读写方式，其二是如何处理数据并对外提供服务接口。这两件事有点类似于MVC中M和C的关系。

为了更好的做模型抽象和合约分层，也方便合约升级、回滚、兼容，将业务控制和数据从合约代码层面就做好分离，这样的处理在复杂业务逻辑场景中经过实践是当前被认为最佳的模式。这个模式简称为CD（Controller-Data）模式，将合约分为两类：控制器合约（Controller Contract）与数据合约（Data Contract）。

控制器合约通过入参和访问数据合约获得数据，并对数据做逻辑处理，然后写回数据合约。它专注于对数据的逻辑处理和对外提供服务。根据处理逻辑的不同，常见的有命名空间控制器合约、代理控制器合约、业务控制器合约、工厂控制器合约等。一般情况下，控制器合约不需要存储任何数据，它完全依赖外部的输入来决定对数据合约的访问。特殊情况下，控制器合约可以存储某个固定的数据合约的地址或者命名空间（通过命名空间在运行时获得合约地址）。

数据合约专注于数据结构定义与所存储数据的读写裸接口。为了达到数据统一访问管理和数据访问权限控制的目的，最好是将数据读写接口只暴露给对应的控制器合约。禁止其他方式的读写访问。

基于这个模式，遵循从上至下的分析方式，从对外提供的服务接口开始设计各类控制器合约，再逐步过渡到服务接口所需要的数据模型和存储方式，进而设计各类数据合约，可以较为快速的完成合约架构的设计。

下图是一个最基础的控制合约和数据合约示意图。合约的部署和升级过程会在后文实际操作中演示。

合约设计

根据以上案例场景和用例的分析，我们可以抽象出以下几个对象：管理员、小区、房屋、业主、投票、议案。其中管理员被简化为一个线上账户，投票和议案简化为投票，我们可以得到4个合约对象：小区、房屋、业主、投票。按照CD模式，可拆分为四组共8个合约。如下图。

图中列出了各个合约的字段和方法。可以看到除了4组合约外还多出来一个代理控制合约，这里主要是方便对合约进行统一管理，方便升级和回滚。

补充说明：
代理设计模式在区块链中，一般