在第一期智能合约库有奖征码活动中，我基于共享经济场景开发了通用化功能合约模板，并贡献到区块链应用开发组件WeBankBlockchain-SmartDev中。
根据这次开发，我总结了一些个人心得，与社区开发者分享，希望对行业从业者，以及刚刚接触区块链技术并迫切想要了解如何将区块链跟实际生产环境对接，设计一些场景化交互的小伙伴带来启发与借鉴。
本次分享我将从三个维度来进行：第一，共享经济场景跟区块链结合的需求解析；第二，重点介绍通用化智能合约的规划与设计；第三，通用化合约的要点归纳与总结。
共享经济场景与区块链结合的需求解析
共享经济场景随处可见。共享单车、共享充电宝、共享打印机，这些产品早已融入人们生活之中。从不同的应用场景中，我们可以看出共享经济的共性：数据多方流转、身份鉴权、存证、溯源以及自主化操作。
这些场景也折射出共享经济目前所存在的痛点：
- 由于缺少人为的监管把控，场景容易出现业务上的漏洞；
- 在一些商业化应用场景中可能会有数据伪造、身份造假的风险；
- 存在事后追溯效果差的弊端。
基于以上痛点，共享经济产品非常需要信任背书，而区块链自身具有不可篡改、分布式记账的特性，刚好满足信任背书的需求。
区块链也可以通过用户签名、设备自动化上链、区块链鉴权存证，从而达到存证的不可篡改、分布式存储、全流程可追溯的目的。
相比原来的产品，区块链技术作为一种技术加持，修补了许多漏洞，加强数据安全。
以共享充电为例，假设我是厂商，与平台运营方、合作方组成合作的业务团体，共同做共享充电的商业化运作。通过引入区块链，实现多方协作过程中数据的透明化，乃至后续数据可追溯化。
用户端、物联网设备、业务平台这三大主体是常见的物联网跟人进行交互中的三角点。用户使用手机APP对共享充电的物联网设备进行扫码后，设备端与平台进行数据交互，设备端会得到当前扫码用户的相关信息，并进入后续的业务流程。
业务平台是高度集权的，在多方参与的过程中，平台方是有权对数据进行修改调整的，这就意味着业务数据存在篡改的风险。
我们对数据的基础诉求是：业务数据从开始到结束的整个生命周期，都应该是不可篡改，保证数据的真实完整性是构建业态信任的基石；所以我们引入了区块链来实现诉求。
比如：用户扫码使用物联网设备，物联网设备不经过业务平台直接自动化打包数据构建交易进行上链，在区块链网络中针对上链操作的交易并非全盘接收，而是要对上链数据进行多方确权。
目前，区块链的一些技术瓶颈和定位，不适合做复杂计算和大量存储，比较适合账本类型的记账工作，记录结果摘要等数据。
随着未来使用场景增加，区块链延伸的功能也会越来越多样。但回归到本质，最初我们想要结合区块链是出于加强信任的意愿。
首先，像这一类型的需求通常伴随各方用户参与、权限管控、身份鉴权等；
其次，业务数据的存证也是不可缺少的环节；
最后，配套衍生功能，如积分产生、交易、核销以及各个场景额外的需求功能。
智能合约的规划与设计
在共享经济场景中，我们对场景中的共性功能进行提炼，写出通用化合约。设计通用合约的目的好比开发开源框架，将共性功能提炼并实现，减少开发工作量、提高复用率，以便我们根据具体业务进行灵活拓展。
从不同维度对通用合约进行规划与设计。我们可以先从业务体系角度做规划，将用户体系拆分成不同主体：
超级管理员是最初区块链部署时的用户。
授权管理者在业务中主要进行运营管控，如：对部分业务体系中的物联网设备进行授权、对积分核销、禁用用户等。
注册用户是经过业务平台注册认证通过的用户在区块链体系中的映射。
上图是最为核心的存证设计。我可以根据5W法则来参考，构思存证体系中的要素，将它们映射到我们实际的区块链业务产品中。
比如：who是业务主体；when是时间戳，第三方凭证机构所颁发的时间凭证；what是业务体系的数据摘要；where是设备信息；why 为何可以上链，我们需要身份鉴权。
在共享经济场景中，明确要求必须是物联网设备或者经过授权对象才可以上链交易操作。另外，在共享经济产品中有部分衍生化的功能，比如签名验证、沿用官方合约+业务改造、预留拓展功能以及工具类。
再从技术维度去考量，其中考量可以分为不同层次。
第一是规范化。我们通常不会把所有的业务代码都纳入到一个合约中，而是会做拆分，即分层设计，使得代码解耦和结构更清晰。
第二是业务功能。从业务复杂度、性能和安全风控这三个角度来选择对应的编程模式。如果业务不是特别复杂，可以采用单合约+库进行组合；如果业务复杂度比较高，则可以拆成多个合约，每个合约在实际环境中进行部署，然后对合约进行管控。
这种复杂模式的运营成本会比较高，需要我们把控好每个合约的控制权限。
第三是前瞻性的考量。更多的是未来合约拓展。比如我写了1.0的版本，之后又写了2.0版本，这便是合约的迭代。
如果我想对业务代码进行改造，一开始部署并没有预留多余参数，那么就需重新修改代码，重新部署，中间可能存在原有数据与新数据不共容的问题。
在这种情况下，我们有多种处理方式：
第一种是将业务逻辑和数据分层；
第二种是用原生合约的方式去修改合约地址，从而使得数据和新改造的合约进行无缝衔接。同时，可以采用FISCO BCOS本身提供的预编译合约--table，解决数据的可持续性问题。
经过业务到技术的维度考量后，我们可以对合约进行设计。首先，采用分层仓储化的模式进行拆分；其次，使用原生合约，采用单合约部署加多个合约类库的模型。目前，并没有将逻辑层和数据层拆分，因为在实际过程中可以预留给实际场景选择性地进行拆分。
在这一套合约的构成中，主合约主要有存证、身份鉴权、积分生成、流转等功能，辅助合约类库：包括了两个仓储合约库和三个工具合约库。
业务操作完整流程如下：
流程一
当完成合约编写后，我们会编译主合约并由区块链管理员将其部署到链上，授权多位管理者，再由这些管理者来授权对应的物联网设备。
流程二
在业务平台端，假设张三这个用户使用APP或者小程序在平台进行注册，完后业务平台端的实名认证，平台会生成对应区块链上的身份地址和公私钥给到张三。
流程三
张三首先使用APP对共享充电的机器设备进行扫码使用；
设备端在接收到扫码信息后与业务平台进行交互，从而得到用户信息。
用户进行充电服务，待服务完成后进行订单付款，此时APP会在用户付款时，提示用户授权APP对本次订单进行授权签名。
用户订单签名可以是由手机蓝牙直接发送给物联网设备，也可以是用户APP跟业务平台交互后，再推送给物联网设备端。
设备端对数据进行有效性校验，通过校验后，设备端把对应的用户订单签名、以及自身产生的充电记录、订单信息一起打包构建交易发送到区块链。
区块链针对交易上发的操作者进行身份鉴权，业务数据中的用户也需要进行身份鉴权，保证其为平台注册认证的许可用户，最后进行其他业务相关性验证，无误后，进行数据存证。
在实际业务场景中，我们还可以通过预言机等中间件将区块链信息有效地反馈到业务平台中。
通用化合约的要点归纳与总结
从业务体系来说，用户角色、权限管控、存证功能是基础，是必须要满足的。其次，通用合约的定制功能是根据实际需求和未来预留，一般会采用模块化合约库的形式去做不同业务体系拆分，其他内容可以根据业务需求，在实际中去考量。
目前，面向广大开源贡献者开展的智能合约库有奖征集代码活动仍在继续，希望大家群策群力，为后续的开发者提供安全又可靠的合约。
在开发过程中，使用开源软件能够减少开发投入，将注意力聚焦在我们更需要投入时间研究的内容上。
https://www.qq.com/video/q326...
《超话区块链》
《超话区块链》是由FISCO BCOS 开源社区推出的直播活动，每周四晚8点，社区邀请一位技术极客或应用先锋，做客直播间分享开发实践或应用心得。作为社区固定栏目，《超话区块链》已举办近百场，从技术研讨到产业应用均有触达，欢迎大家自荐或推荐朋友到直播间分享。加【小助手】入群观看直播。
