我是Ivan，一个国家队的区块链加传统业务的设计者，之后我会就不同的传统业务场景发布不同的区块链实施建议~，欢迎同行或者不同行业人员一起探讨、合作~

---

1 区块链和政务场景的结合点分析

区块链作为一项新兴技术具有不可篡改、数据永久留存等特性，在如今的信息化时代有着越来越重要的作用，区块链的一些具体描述在其他的好多文章里都有描述，这里就不多做赘述。

而区块链在政务系统中具有更加实用的应用，现有政府单位均具有多级部门，每个审批需要多个政务机构的多级部门进行审批，各级部门和决策者掌握着大量的数据和信息，各部门内部缺乏联通和整合，并且不同机构的政务系统均缺乏联通和整合。

部门间数据存在缺失和重复的现象，导致信息不具统筹应用的作用。各部门间信息传递及决策需要经过中间层传递，而信息的传递非常容易造成信息的泄露及信息的更改，已经审批后的文件容易被篡改而影响正确的决定。

因此区块链+政务的解决迫在眉睫，我们可以通过区块链解决政务系统中所有信息化的问题，保证系统中的数据准确安全，更好的服务于政务决策单位。

2 现有政务操作流程及问题点

2.1 实际业务流程

实际业务流程：政府投资项目审批流程作为示例。

按照项目阶段主要的参与部门

2.1.1 立项阶段：市发改委、市国土局、市住建委、市环保局。

2.1.2 建设用地审批阶段：市国土局、市水利局、市气象局、市消防支队、市人防办、市住建委、市发改委

2.1.3 招标阶段：市财政局、市住建委、市政务中心

2.1.4 施工许可阶段：市住建委

2.1.5 竣工验收阶段：市住建委、国土局、财政局、发改委等多部门

以下的流程我们只选用立项阶段来进行分析。

2.2.流程分析及问题分析

2.2.1原有立项流程

（1）申请方提出项目计划书，市发改委收到项目计划书后进行评审。

（2）需要中介结构、市国土局、市住建委等多方部门进行并联评估，输出多方评估报告。

（3）市国土局、市发改委、市环保局对项目进行并联审批。

（4）市发改委输出可行性研究报告审批。

（5）市发改委输出初步设计和概算审批。

2.2.2立项流程的系统数据流程

（1）申请方将申请文件提交至市发改委的中心化数据库

（2）市发改委从数据库中取出数据进行审批

（3）将审批结果保存至中心化数据库中。

（4）将原中心化数据库中的结果发送给中介结构、市住建委、市环保局等多方机构的数据库中。

（5）多方均从数据库中读出市发改委审批后的申请文件，审批后保存至数据库。

（6）各方将审批后的文件发送至发改委

（7）市发改委可以查看各方对申请文件的审批结果。

2.2.3数据流程问题分析

在传统的业务流程中，在一些线下的文件以及中心化系统中，均存在数据被篡改的可能。通过低成本的就可以将对原本的数据进行篡改，而后替换掉原来已经提交的材料,这一恶意过程没有任何记录了修改内容的痕迹。

（1）现有系统的审批环节中：

在现有系统的审批流程中，线下的审批通过物理化签章对纸质化文件进行签字盖章等方式进行的多级存在被篡改的可能。

（2）现有系统的审批结果

现有系统中审批结果有两种，签章的纸质化文件以及中心化系统中一些低安全等级的签名值。可以通过伪造签名的方式替换原有签名结果，传递一个虚假审批结果。

（3）现有系统的审批结果传递

纸质化文件通过邮寄等方式。电子化文件通过局域网或者广域网的方式来进行发送，接收方无法直接验证文件的正确性，这样导致如果发出的数据被篡改是无法验证数据的安全性的。

解决办法：

针对审批环节、审批结果、以及审批传递的均通过区块链进行，进行完全的链上审批、审批结果链上传递、审批结果链上证据固化永存。

3 改进后政务数据流程

3.1区块链政务系统的数据流程

（1）申请方通过分布式系统-申请方系统将申请文件通过节点1上链，发出申请。

（2）区块链节点1收到申请后将数据广播至节点2，3，4，5

（3）市发改委收到申请对其文件进行审批后，将审批结果通过节点2上链。

（4）经市发改委审批后的结果上链后，经过节点2的广播，将审批后的结果广播至节点1，3，4，5

（5）中介结构、市住建委、市环保局通过各自节点读取到申请文件和审批结果后，对其进行审批后通过节点5上链，上链后，节点5将数据同步给节点1、节点2、节点3、节点4。

（6）各方可直接从链上读取到数据，如有隐私方面问题，可以通过区块链上对应的技术手段设置数据的选择性可见，保证隐私及业务系统稳定。

（7）节点6为灾备节点。

3.2区块链政务特性介绍

3.2.1分布式系统

各业务系统基于各自的节点进行搭建各自的业务的业务系统，将需要多方共享或处理的数据通过各自节点上链，因为区块链数据同步的特性，将数据同步给链上全部节点，各自可以根据业务系统的业务要求将数据进行单独处理。

3.2.2不可篡改

从技术角度来讲，数据上链后，原数据不可进行任何篡改。从业务角度来讲，数据上链后如想进行修改，可以上传新数据上链，这样可以满足业务需求也可以记录所有修改项目。

3.2.3强大的灾备能力

一条区块链上有多个节点，每个节点对应一台至多台物理服务器，而每个节点上均保存着链上的全部数据，除非将所有节点全都物理化毁坏，否则数据永远保存。

我们还可以根据实际的业务需求，增加备份节点，这样当链上有节点因为某些因素毁坏后，我们可以使用备份的节点替换坏掉的节点，增加系统的服务能力。

3.2.4审批保证真实意愿

所有审批均使用公私钥算法签名进行审批，所有公私钥均保存在加密机中，只有自己可以使用，保证审批结果为真实审批意愿，不存在盗用等情况。

3.3疑难点分析解决

3.3.1数据隐私化

在正常的政务业务中，存在数据的选择性可见等问题，我们可以通过区块链上的智能合约以及加密算法来解决隐私的问题，使数据选择性可见保证隐私问题。

3.3.2公私钥保存媒介

公私钥作为用户在链上的身份证明，需要高度保密，故公私钥均保存在加密机中，只有经过高安全等级的验证后才可以进行调用，避免私钥乱用的情况。

3.3.3数据备灾

在常规业务节点外，按照业务需求需要设置至少一个备灾节点，这样当链数据出现问题后，我们可以使用备灾节点做替代

4  实际解决方案设计

4.1目标产品形态描述（案例）

4.1.1申请方式

申请方通过网页端或者手机上传文件，打开申请列表后，选择审批方提前配置好的审批流程，提交审批。

4.1.2审批方式

审批方可以通过手机应用或者网页端收到审批结果，使用手机或网页端进行审批，审批完成后将审批结果上链。

4.1.3审批提醒

审批申请或者某方的审批结果上链后，分布式系统自动通知业务系统。

4.1.4审批结果通知

当申请方的申请通过审批方配置的申请流程完成审批时，会将审批结果通知给各方。

4.2产品业务结构

为各业务方提供区块链节点，然后基于每个链节点搭建业务系统，业务逻辑通过区块链上的智能合约来实现。

系统提供数据服务模块，具有数据对比以及数据可视化的功能。

4.3产品架构设计

4.4其他任何问题请加微信详谈

我是Ivan，欢迎小伙伴们一起详谈各种区块链化的业务设计及疑难问题。

本人作为区块链加传统行业的业务研究者从事过大型国企区块链链改项目，以及大型国有区块链金融项目经验，我们有完善的链改团队，

对外提供

（1）解决方案服务

（2）解决方案+实施服务

有合作意向可以微信详谈。

（如转载请注明出处，侵权必究）