一、项目主要内容

据新华社2020年10月25日晚消息，中共中央政治局2020年10月24日下午就区块链技术发展现状和趋势进行第十八次集体学习。中共中央总书记习近平在主持学习时强调，区块链技术的集成应用在新的技术革新和产业变革中起着重要作用。

随后“什么是区块链”、“区块链有什么用”、“怎么掌握区块链”这几个问题响不绝耳。这里尽量用通俗易懂的语句回答这些问题，期望即使是从没接触过区块链的人也能搞懂这项已经成为国家级现象的神奇技术。

什么是区块链？

专业解释里，一般都会带上“分布式网络”、“密码学”、“共识算法”、“智能合约”这些有点晦涩的术语，这里打算举一个例子。

要理解区块链，首先要接受一个设定：有个账本，要记录的是一群人之间的公共账目（比如班费、物业费、公益捐款的收支），这个账本由大家一起来记账。选一个人，在账本的某一页，一行一行的记录明细，当一页记满后，大家都去核对账目，正确的话，大家签字认可这一页的所有账目。记满一页后，再选另一个人开始记接下来的一页。现在有意思的事情来了，新的一页首先要把上一页的一些摘要特征（比如页码、余额、人数、条数什么的…）抄写下来放在页首以供对照，免得前一页被改了或丢了还无据可查。然后，再一条条记账，记满一页后，核对、签名确认…依次反复。这样，账本的一页和一页之间就形成了“证据链”。

更重要的是，账本上已经签名确认的每一页，所有人都会一字不漏地复制一份，放到自己家里，以免少数人篡改、污损、丢失账目。这样，账本的每一页是一个“区块(Block)”，一页一页之间形成前后连贯的证据链，每个人之间构成了多点的网络，这就是“区块链”的概要原型了。这里面的关键点在于，这个账本一定是一群人的账，并不是一个人的账。如果是一个人的账，自己拿个小本本记就好了，为什么要整这么麻烦。就是因为这一群人互相之间并不完全信任，记账过程可能出纰漏，所以必须用这么繁琐的步骤，让大家平等参与，一起保证账目的准确和公允性，产生的结果大家保存，永远不会丢也不会错。

上面的举例看起来步骤繁琐，还要求每个人都一字不差地复刻和保存，那么就需要技术手段来帮助大家记账。这又回到技术环节，随着计算机科技的发展，无论是网络、密码学、数据结构、分布式算法等技术都趋于成熟，区块链领域把这些技术组合在一起，一揽子完成了从记账到分发到验证到保存的整个过程。运用技术服务整个群体，这就是神奇的区块链技术。

区块链有巨大的发展潜力，本身蕴含着极密集的技术含量，对技术有足够研究和把控，才能使自身发展不受外界影响和制约。区块链技术将会被用到与国计民生有关的广泛场景里，牵涉到许多人的财务和个人信息，甚至是金融行业、政务民生等关键领域的重要信息，重视技术和运作的安全可控，才能保护财务安全、信息安全，乃至社会安全。所以，当下国家给我们提出了明确的要求：“注意区块链技术发展现状和趋势，提高运用和管理区块链技术能力”，这样才能更好地建设网络强国、发展数字经济、助力经济社会发展。

我国产业界在区块链领域投入很早、力度很大，诸多大型金融企业、互联网公司、科技公司都在进行区块链研究，在过去几年中，已经逐步解决或接近解决了区块链领域的一系列核心问题，如性能、安全、易用性、合规等，在这个过程中也积累了大量的知识产权和专利。

我们重点发展的区块链领域是“联盟链”，联盟链和匿名的、有虚拟代币的“公有链”（诸如比特币、以太坊等）有极大不同，联盟链不发币不挖矿，摈弃了野蛮运作的弊端，能更规范、合法的运作，可有效服务于实体经济。

由微众银行、深圳市金融科技协会等国内机构共同发起成立的区块链联盟——金链盟，掌握多项核心技术，于2017年开源发布了以FISCO BCOS为代表的区块链底层平台和系列解决方案。这一系列开源项目都安全可控、性能优异、免费且易用，致力于服务实体经济，在大量关系国计民生的产业中已广泛落地，技术和模式得到了大量实际案例的验证。

另外值得一提的是，FISCO BCOS采用技术开源的路径加速行业发展，孵化拓展了国内最大和最活跃的行业生态社区，在推进中重视人才培养，在高校、社会、产业机构中培养了大量的区块链专业人才，帮助区块链技术和产业发展加速人才方面的突破。

区块链已经触达当下，更将影响未来，和一个具备无限潜力的趋势共同成长，现在，就是最好的时节。

区块链原理

说到原理,需要解释以下几个概念:区块,哈希算法,公钥与私钥,时间戳,Merkle树。

首先,区块作为区块链的基本结构单元,由包含元数据的区块头和包含交易数据的区块主体构成。
区块头含三组数据,第一组用于链接前面的区块,索引来自父区块的哈希值数据。第二组与挖矿难度;用于工作量证明(PoW)的计数器,其名为Nonce;最后一组是Merkle数根数据,用来快速归纳校验区块中所有交易数据。

其二,哈希算法。这源于一个密码学的数学函数—-哈希函数。输入值为任意大小的字符串,输出值为固定大小的数,一般是十六进制的。长度为N的字符串,其复杂度为N的高阶无穷小。加密根据特定的字典(即哈希表)。而这里主要得力于加密的哈希函数,作为比特币交易的哈希函数一般要求以下三点:碰撞阻力(collision resistance),隐秘性(hiding),谜题友好(puzzle friendliness)。接着,大体地介绍这三个概念:

碰撞阻力:有哈希函数H,如果无法找到两个值x和y(即不存在两个值x,y),且x与y不等,使得H(x)=H(y),则称哈希函数H具有碰撞阻力。

隐秘性:已知哈希函数H(x)的输出值y,不可通过严密的逆推得到输入值x,这种特性称为隐秘性。这种加密也称不对称加密。

谜题友好:哈希函数H,其任意输入值x的位数记为n,假定k选自高阶最小熵分布,如果无法找到一个可行的方法,在比2^n小很多时间内找到x,保证(k||x)=y成立,那么称哈希函数H为谜题友好。

最后一点,(the last but not the least)Merk构。这个树结构以发明者拉尔夫 (Ralph Merkle)的名字命名。以下是这个树结构的示例图:

如图所示,假设我们有很多这些数据区块两两分组,然后为每一组建立一个有两个哈希指针的数据结构,每个指针对应一个区块,这些数据结构就成了树的下一个层次。我们轮流将这些区块组成两两分组,为每一组建立一个包含每个区块组哈希指针的新的数据结构。以此类推,直到我们得到一个单一区块,即树根节点。最前面的哈希指针指向的值即为私钥,用户必须切记。

一些区块有关的问题：

这些问题,一部分是中本聪在创立区块链之前就注意到并且加以解决的,还有的是后人发现的。

(1)两类军问题

也被称为两军悖论,或者协同攻击问题。两个军队分隔很远,传递消息的信差可能在途中阵亡,或因军队距离不能在得到消息后及时回复,发送方也无法确认消息确实丢失的情形,导致不可能达到一致性。在分布式算法上,试图在异步系统和不可靠的通道上达成一致情形是可能的。因此对一致性的研究一般假设信道是可靠的,或非异步系统上系统上同步。总而言之,它是用来阐述在一个不可靠的通信链路上试图通过通信以达成一致是存在缺陷的和困难的悖论。

(2）拜占庭将军问题

问题的起源是这样的,拜占庭罗马帝国国土辽阔,为了防御敌人每个军队分隔很远,将军与将军之间只能靠信差传递消息。但军队中的叛徒和谋反者会影响信息传递,如何在不受叛徒影响下传递信息的问题就是拜占庭将军问题。举例, A为发布消息的总司令,B,C,D则为三个将军,其中有叛变者。

如图:

可以将数据列表,如下:

可以看出,B就是叛徒

(3)女巫攻击

大规模的p2p系统面临着有问题的和敌对的节点的威胁，为了应付这种威胁，很多系统采用了冗余。然而，如果一个有恶意的实体模仿了多个身份，他就可以控制系统的很大一部分，破坏了系统的冗余策略。我们把这种模仿多个身份的攻击定义为女巫攻击。

验证技术可用于防止Sybil攻击和消除伪装敌方实体。本地实体可以基于中央权威来接受远程身份，其确保身份和实体之间的一对一对应，并且甚至可以提供反向查找。身份可以直接或间接地验证。在直接验证中，本地实体查询中央授权机构以验证远程标识。在间接验证中，本地实体依赖于已经接受的身份，继而保证所讨论的远程身份的有效性。

基于身份的验证技术通常以匿名为代价提供问责制，这可能是一个不可取的折衷，特别是在希望允许无检查的信息交换和公开讨论敏感话题的在线论坛。验证机构可以通过拒绝执行反向查找来尝试保持用户的匿名性，但是这种方法使验证机构成为攻击的主要目标。或者，权威机构可以使用除了用户的真实身份的知识之外的一些机制 - 诸如验证未识别的人在特定地点和时间的物理存在 - 来实施在线身份和真实世界用户之间的一一对应。

去中心化的经济革命与区块链的前景：

经济去中心化

经济革命,它的核心就是去中心化。而区块链的发展前景必然联系与经济。

什么是去中心化?在一个分布有众多节点的系统中,每个节点都具有高度自治的特征。节点之间彼此可以自由连接,形成新的连接单元。任何一个节点都有可能成为阶段性的中心,但不具备强制性的控制功能节点与节点之间的影响,会通过网络形成非线性因果关系。这种开放式,扁平化,平等性的系统现象或结构,称之为去中心化。

中心化的意义在于控制,尤其是工业时代,人们将生产和工作都集中在一起,从而达到完全控制的目的。中心能够控制所有过程,保证准确无误。与此同时,也是它的致命缺点。

决断的权威,权力的垄断,必然导致腐败的滋生,小小的错误决断也会因此被放大,产生不可预计的结果。去中心化使得权威存在的必要越来越弱,正如中本聪所言”每个人都是中本聪”。

赋予机器思考的力量

2018年GTC上所展现的人工智能的应用也许在不久的将来就会完全实现(因为其中不少已经实现了)。

“AI并不是天方夜谭,它确实可以实现而许多已经呈现在我们眼前.” ———-黄仁勋。

将数据传入中心服务器有极大可能引起黑客攻击,数据窃取,和服务器瘫痪。但分布式的区块链技术可以完美解决,在拜占庭容错机制下,各个区块权力相当,黑客攻击难度大大提高,使得信息安全得到保障。

区块链前景———撕不毁的智能合约。

这样完全解决了法庭上”你认为,我认为”的争论,严格按照智能合约执行。但是智能合约的制定倒是需要各方面的专家一同讨论制定。

国内国外区块链技术研究存在的问题与未来研究方向与方式

问题:

(1)理论研究落后于实际发展

(2)大多数研究都集中在比特币环境

(3)一些重要议题尚未涉及,缺少对处理性能,拓展性,集成性等主题的研究

方向:

(1)可以拓展区块链研究的范围,尤其是空白领域如技术监管,漏洞检测,和应急反应,遭到攻击后的后果与责任负责,还有侧链,影子链,私有链等,都有待深入研究。

(2)可以加大关注在区块链技术在经济,社会生活中的应用前景。

项目基于情况

现有三家公司A、B和C,情况如下：

公司A规模大，信用良好，实力丰厚，有很大的风险承担的能力，拥有直接从银行等金融机构获得大笔融资的资格。

公司B、C规模相对较小，不能直接从银行金融机构获得大笔资金。

现有以下交易场景：

公司A向公司B订购一批货物；公司B生产这批货物，需要向公司C订购一批材料。

公司A现在资金短缺，向公司B签订一份一定数额的单据，承诺会给付公司B货款。这时，公司B可以用这份跟公司A签订的单据向银行贷款，凭借的是公司A的信用。并且，公司B有了公司A授权的信用，公司B能以同样的方式向公司C签订单据，公司C也可以凭借单据向银行贷款。

传统方法下，这样的流程需要非常复杂的授权、验证过程。

本项目基于腾讯微众银行开源的FISCOBCOS区块链平台，使用区块链技术高效地实现这样的信用传递过程，实现了基于区块链的供应链金融平台。

二、项目实施情况总结

1.项目实施情况

(1)本项目采用了链端作为后端的支持维护，容器为Ubuntu18.04 .5，区块链采用的是腾讯微众银行开源的FISCOBCOS区块链平台。此外，还用到了FISCO BCOS Python SDK，Flask 1.1和Python 3.6.3+来组成一个完善的后端，在项目的初期计划中，我们着重与理论研究，在代码实现上完成后端的搭建编写，链端逻辑算法的编写即可，在后期，采用了OC语言，实现了一个简易的iOSAPP完成前端数据的展现。

(2)实现了该区块链的供应链金融平台。控制台仲裁机构进行以下操作：

有银行bank1,受信公司A,公司B、C;

bank_1向受信公司A提供1000信用资产；

公司A向公司B转移500信用资产；

公司B用250信用资产向银行获取真实资金；

此时进行查询操作。

(3)后端API示例（使用Python SDK、Flask框架实现）:

后端每次收到请求时，都会先检查链上内容的更新，确保返回的是最新信息。

公司信息查询，根据公司名称获取相应信息：

单据查询，根据公司名称获取所有该公司参与的交易的单据：

欠款查询，根据银行名称和受信公司名称，获取该银行向该受信公司授权的信用资产数额：

2.项目研究内容及方法的创新

项目研究内容

从功能视角、系统视角、用户视角和开发视角，分别从逻辑层面、运行层面、使用层面和开发层面厘清代码架构和关键算法。

(1)功能视角

在深入一份区块链底层代码之前，首先要通过其官网、技术文档、github wiki等渠道获取项目设计文档，了解其基本功能设计。

一般每个项目都会提供核心功能列表、总体架构图、功能模块图等介绍文档，通过这些介绍可以掌握项目基本功能。即使你真的找不到也不打紧，大部分区块链底层项目在功能设计层面的差异较小，核心功能模块也大致相同。

以FISCO BCOS为例，基础层代码如下：

核心层核心代码如下：

接口层核心代码如下：

(2)系统视角

系统视角从整个区块链网络运行角度，关注区块链节点全生命周期所参与的系统行为。

关注点包括从敲下启动节点的命令开始，节点经历了哪些初始化环节，之后又是如何与其他节点建立点对点网络，以及完成分布式协作的。

由于不同区块链在部署架构上略有差异，系统运行方式也有所不同，但万变不离其宗，系统视角来看，每个区块链系统都要经历节点初始化、建立点对点网络、完成分布式交互的过程。

从系统视角看区块链，首先要关注初始化工作。以FISCO BCOS为例，区块链节点启动从main函数入口进入，通过libinitializer模块初始化并启动各模块，启动顺序如下：

通过启动顺序可以知道FISCO BCOS的一个重要特性——支持多群组账本，每个群组是一个独立的Ledger模块，每个Ledger具有独立的存储、同步、共识处理功能。

完成初始化工作同时，系统将会启动若干线程（或者进程、协程，原理类似），这些线程包括网络监听、共识、消息同步等，可以结合代码分析与系统命令查看运行节点配合确定有哪些关键线程，搞清楚关键线程的工作机制就可以基本掌握区块链系统运行机制。

以FISCO BCOS为例，节点启动之后的关键线程以及他们之间的关系如下：

初始化完成之后，网络模块的Host线程将根据配置列表，主动与其他节点建立连接，并且持续监听来自其他节点的连接；Sync线程开始相互发送区块高度，发现高度低于其他节点则开启下载逻辑；RPC与Channel线程等待客户端发送请求，将收到的交易塞入txpool；Sealer线程从txpool获取交易，Consensus线程则开始处理共识消息包。

如此，整个区块链系统有条不紊地运转，完成客户端请求与分布式协作。

(3)用户视角

用户视角关注操作接口和交易生命周期，关注访问区块链的接口和协议设计、编解码方式、核心数据结构、错误码规范等，还会关注如何发送一笔交易到链上，交易在链上又经历了哪些处理流程，直到达成全网共识。

一般区块链底层项目都会给出交互协议的说明文档，通常实现包括JsonRPC、gRPC、Restful等不同类型的交互协议。

不同项目的交互接口会有所不同，但大都会包含发送交易、部署合约、调用合约、查看区块、查看交易以及回执、查看区块链状态等接口。不同项目的数据编码也会有所不同，有些采用Json，有些采用protobuf等。

当从技术文档中了解清楚交互协议、接口、编解码和错误码等设计细节之后，接下来最重要的是通过发送交易、部署合约、调用合约这些关键接口，对代码进行抽丝剥茧，贯穿交易整个生命周期，从而搞清楚区块链底层最核心的逻辑。

以FISCO BCOS为例，通过多个模块相互协作，完成交易整个生命周期的处理：

(4)开发视角

开发视角关注的是整个代码工程，包括第三方依赖，源码模块之间的相互关系，单元测试框架和测试用例，编译和构建方式，持续集成和benchmark，以及如何参与社区源码贡献等等。

不同语言都有相应推荐的编译构建方式以及单测框架，通常在区块链项目源码目录可以快速定位到第三方依赖库，比如以cmake构建的C++项目有CmakeLists.txt文件，go项目有go.mod文件，rust项目有cargo.toml文件等。

以FISCO BCOS为例，从CmakeLists.txt可以看到依赖库包括：

项目核心源码包括fisco-bcos程序入口代码，以及libxxx的各模块代码，根据模块的名字可以快速识别其对应功能，这里也体现了一个项目源码质量的高低，高质量的代码应该是“代码即注释”。

单元测试代码在test目录，采用boost的单元测试框架，子目录unittests中单测代码与源码目录一一对应，非常容易找到源码对应的单元测试代码。

构建和持续集成工具代码在tools目录，子目录ci中维护了多个不同场景的持续集成用例，在github提交的每一个pr（pull request）都会触发这些持续集成用例，当且仅当每个用例成功通过方可允许合入pr。

具体实现方法如下:

(5)Python API的安装

由于我们使用的是ubuntu，所以需要进行依赖软件问题的解决，这里先进行软件的安装，安装命令如下所示。

1	sudo apt install -y zlib1g-dev libffi6 libffi-dev wget git

(6)API的安装

我们使用git clone https://gitee.com/FISCO-BCOS/python-sdk命令从Gitee上下载源码进行编译。

(7)进入源码并且创建虚拟环境

便于接下来用python实现调用链端并且实现交易，运行命令为

1 2	cd python-sdk && bash init_env.sh -p source ~/.bashrc && pyenv activate python-sdk && pip install --upgrade pip

激活虚拟环境成功如下图所示

(8)区块链网络搭建

在API接口部署完毕之后，我们就可以进行区块链网络的搭建，在这里我们在一个容器中部署四个节点的FISCO BCOS联盟。
首先用sudo apt install -y openssl curl命令解决ubuntu的依赖问题，便于接下来的操作。

(9)生成搭建工作

使用cd ~ && mkdir -p fisco && cd fisco进行目录创建步骤存放我们所需的源码，并使用命令下载节点的生成脚本以便于接下来的生成搭建工作，curl-#LO https://github.com/FISCO-BCOS/FISCO-BCOS/releases/download/v2.7.2/build_chain.sh && chmod u+x build_chain.sh

(10)生成FISCO链

在fisco目录下执行下面的指令，生成一条单群组4节点的FISCO链。请确保机器的30300~30303，20200~20203，8545~8548端口没有被占用。bash build_chain.sh -l 127.0.0.1:4 -p 30300,20200,8545
需要注意的是，其中-p选项指定起始端口，分别是p2p_port,channel_port,jsonrpc_port
出于安全性和易用性考虑，v2.3.0版本最新配置将listen_ip拆分成jsonrpc_listen_ip和channel_listen_ip，但仍保留对listen_ip的解析功能，为便于开发和体验，channel_listen_ip参考配置是 0.0.0.0 ，出于安全考虑，请根据实际业务网络情况，修改为安全的监听地址，如：内网IP或特定的外网IP。

(11)启动

节点部署完毕之后，可以使用bash nodes/127.0.0.1/start_all.sh启动四个节点

在终端中，出现了以下的信息，说明四个节点部署成功并且启动成功

try to start node0
try to start node1
try to start node2
try to start node3
node1 start successfully
node2 start successfully
node0 start successfully
node3 start successfully

(12)进程检查

然后执行ps -ef | grep -v grep | grep fisco-bcos进行进程检查

我们可以看到，这路是四个进程在运行，说明四个阶段各自占用了端口并且没有被占用。

(13)节点实时运行状态检查

之后执行tail -f nodes/127.0.0.1/node0/log/log* | grep connected检查日志输出，在此命令中，以node0节点为例，检查该节点实时运行状态。

在这里我们可以看到该节点的状态信息源源不断输出，并且可以看出，该节点正在和其他三个节点相连。

(14)控制台部署

接下来是进行控制台的部署工作，在控制台链接FISCO BCOS节点，实现查询区块链状态、部署调用合约等功能，能够快速获取到所需要的信息。

首先我们需要解决依赖问题，也就是JDK的安装以及环境声明，因为FISCBCOS节点启动成功需要安装JDK8以上的版本，所以在这里我们使用JDK11，首先访问Oracle官网，下载JDK11源码压缩包，然后进行解压。我们选择/opt文件夹作为JDK11的储存位置。然后使用vim在/etc/profile文件中进行Java_Home等路径环境声明。

编写完成之后，我们使用source /etc/profile进行全局声明。使java环境部署成功，然后我们使用java -version来检测环境部署是否成功。

(15)配置控制台信息

使用cp -r nodes/127.0.0.1/sdk/* console/conf/来配置控制台信息，配置完成之后，就可以启动控制台。

(16)启动控制台

使用cd ~/fisco/console && bash start.sh来启动控制台，可以看到控制台启动成功

(17)WEBASE-Front节点的搭建

然后进行WEBASE-Front节点的搭建，步骤和FISCO搭建类似，不进行过多的描述，启动成功之后如下图所示

(18)检查节点进程

使用ps -ef | grep node命令来检查节点的进程

(19)检查端口进程

使用netstat -anlp | grep 20200 来检查端口进程

(20)查看运行日志

使用grep -B 3 "main run success" log/WeBASE-Front.log来查看运行日志

(21)图形化控制台

最后我们可以通过访问http://localhost:5002/WeBASE-Front
访问这个网站之后，我们可以看到一个图形化控制台

我们可以看到这里的四个节点都正常在运行，并且随机赋予了每个节点不同的节点ID。

在合约IDE界面，我们可以编写合约的算法逻辑，来实现公司交易的算法逻辑，我们将以及编写好的Loan.sol

在上传成功之后，我们可以进行编译合约，然后进行合约的调用。

这里我们可以看到，在这里，合约调用成功，并且成功返回了一个交易回执。

(22)监控查看

此外我们可以进行数据的监控查看

(23)实现数据的交互

然后在python-sdk中，我们需要编写，调用该虚拟环境的函数，借此实现数据的交互。在此处，我们需要将Loan.sol注入到python-sdk/contracts文件夹中，以及将编写的函数注入到python-sdk函数当中，并且将生成的随机地址，写入到编写的函数当中。

在运行之后，我们可以的到合约的URL，将该URL注入到iOSAPP中，就可以在iOS中实现公司交易查询等一系列操作

获取名称为A的公司的信息

GET: {http://172.16.207.150 }:8383/get_company_inf/?cpName=A

获取所有公司A参与交易的单据

GET: {http://172.16.207.150}:8383/get_receipt/?cpName=A

获取银行bank_1向公司A提供的信用资产的数额

GET: {http://172.16.207.150}:8383/get_AmountOfCreditAsset_bank_GiveTo_TrustedCompany/?bName=bank_1&cpName=A

(24)新建用户，部署合约

值得注意的是：Solidity不支持返回变长变量，所以查询结构体时，无法看到其中的变长数组和mapping映射。
在WeBASE-Front控制台中选择私钥管理选项，点击新增用户按钮，输入新用户名创建新用户。

点击部署按钮，使用Administrator用户的私钥，输入仲裁机构的名称来初始化合约。部署成功会有弹窗反馈。

(25)添加公司

点击合约调用按钮，选择addCompany方法，用Administrator的私钥创建受信公司A。并用相同的方法创建普通公司B和C。

(26)添加银行

使用addBank方法创建银行bank_1

(27)行向受信公司授权信用资产

调用bank_giveCreditAssetTo_trustedCompany方法，令银行

bank_1授权信用资产给公司A，数值为1000；完成后查看receipts[0]，确认交易单据上链；并查看companies[0]公司A的情况，确认其信用资产已正确增加。

receipts[0]：

companies[0]：

(28)公司A向公司B转移信用资产：

调用companyA_giveCreditAssetTo_companyB方法，令公司A转移信用资产给公司B，数值为500；完成后查看receipts[1]，确认交易单据上链；并查看companies[0]公司A和companies[1]公司B的情况，确认信用资产已正确转移。

receipts[1]:

companies[0]:

companies[1]:

(29)银行给予公司真实资金

调用bank_giveRealMoneyTo_company方法，令银行给予公司B 真实资金，数值为500；完成后查看receipts[2]，确认交易单据上链；并查看companies[1]公司B的情况，确认真实资金正确转移。

receipts[2]:

companies[1]:

(30)受信公司向银行还款

调用trustedCompany_repaidTo_bank方法，令受信公司A归还款项给银行，数值为500；完成后查看receipts[3]，确认交易单据上链。

receipts[3]:

(31)受信公司向银行确认完成本次事务

调用trustedCompany_FinishWith_Bank方法，令受信公司A向银行bank_1确认完成本次事务；完成后查看companies[0]公司A，确认已正确归零，以及trustedCompanyHasFinishedWithBank值，确认已置为true。

companies[0]:

rustedCompanyHasFinishedWithBank:

方法创新

(1)存储设计

使用storage数据位置储存需要上链的变量，这样数据将永远存在于区块链上。

项目背景中所述的供应链金融平台，需要仲裁机构、金融机构(银行）和公司这几方角色，以及记录交易的单据。在智能合约中，使用结构体实现这些角色、储存每个角色的信息。下面结合代码对角色功能及需要储存的角色信息进行说明。

仲裁机构：

只有仲裁机构有权限添加银行实例和公司实例。

仲裁机构结构体包含：

字符串ArbitralName,机构名称；

address变量ArbitrallnstitutionAddres,仲裁机构的账户地址。

储存地址是为了在之后的操作中进行地址对比，判断操作者是否是仲裁机构。

银行：

银行可以向受信公司发放信用资产，接收受信公司的还款。并且公司能够消耗信用资产，从银行获得等额的真实资金。

银行结构体包含：

字符串bankName,银行名称；

无符号整型数组ReceiptIndex_loanMoneyToCompany,储存向公司提供资金的交易单据的索引值。使用该索引值可以在合约的receipts数组中访问对应单据；

无符号整型数组ReceiptIndex_authorizeCreditAssetToCompany,储存银行向受信公司授权信用资产的交易单据的索引值。使用该索引值可以在合约的receipts数组中访问对应单据；

无符号整型数组

ReceiptIndex_getRepaidMoneyFromTrustedCompany,储存受信公司向银行归还资金的交易单据的索引值。使用该索引值可以在合约的receipts数组中访问对应单据；

字符串到无符号整型的映射companyDebtAmount,储存受信公司应向银行归还的资金数额。映射形式：公司名称->资金数额

公司：

公司可以分为受信公司（布尔值isTrusted为true)和普通公司(isTrusted为false)。银行只会向受信公司授权信用资产，并且由受信公司负责向银行归还资金。信用资产可以在任何公司间流通，每个公司都可以用信用资产向银行换取真实资金。在本合约中，一次需要信用传递的交易生产过程里有且只有一个受信公司。

公司结构体包含：

字符串companyName,公司名称；

字符串companyType,公司类型；

布尔值isTrusted,是否为受信公司，true表示是受信公司；

无符号整型creditAsset,当前信用资产数额；

无符号整型数组

ReceiptIndex_getCreditAssetFromCompanyOrBank,储存其他公司或银行给予自身信用资产的交易单据的索引值。使用该索引值可以在合约的receipts数组中访问对应单据；

无符号整型数组ReceiptIndex_giveCreditAssetToCompany,储存自身给予其他公司信用资产的交易单据的索引值。使用该索引值可以在合约的receipts数组中访问对应单据；

无符号整型realMoney,当前真实资金数额；

无符号整型数组ReceiptIndex_getRealMoneyFromBank,储存银行给予自身真实资金的交易单据的索引值。使用该索引值可以在合约的receipts数组中访问对应单据；

无符号整型数组ReceiptIndex_repayRealMoneyToBank,储存自身归还银行真实资金的交易单据的索引值。使用该索引值可以在合约的receipts数组中访问对应单据；

单据：

单据可以记录所有交易和资产转移。单据的记录形式永远是实体,A向实体B提供某种资产。

单据结构体包含：

字符串Name_A,交易中实体A名称；

字符串Name_B,交易中实体B名称；

布尔值bankParticipation,此次交易是否有银行参与；

布尔值isRealMoney,此次交易是否是真实资金的转移；

无符号整型amount,交易资产的数额；

合约中其他数据结构：

仲裁机构结构体arbitrallnstitution,储存仲裁机构实例；

公司结构体数组companies,储存所有公司实例；

银行结构体数组banks,储存所有银行实例；

单据结构体数组receipts,储存所有单据实例；

布尔值trustedCompanyHasFinishedWithBank,表示受信公司是否已经向银行还清资金并确认本次事务完成，若为true表示完成。

(2)数据流图

合约涉及的主要机制：信用资产流通机制、真实资金流通机制。

这里先给出这两套机制所确定的整个系统的性质：

只有受信公司能获得银行的信用资产授权；公司的信用资产只能向银行兑换真实资金；最终由受信公司向银行还款；所有公司从银行

获得的真实资金数额不会超过银行授权给受信公司的信用资产数额。即永远不会出现信用超支的情况。

信用资产creditAsset的流通机制：

-初始时，只有受信公司A能得到银行授权，拥有信用资产

-信用资产可以在公司之间流通

-信用资产的产生和转移情况都会上链

真实资金realMoney的流通机制：

-公司向银行获取真实资金要消耗自身等额的信用资产

-由受信公司向银行还款

-真实资金的转移情况上链

(3)核心创新功能

合约初始化：

根据传入的仲裁机构名称，才合约中创建一个仲裁机构实例，并将其中储存的用户地址设为创建本合约的用户地址。

添加公司：

若当前msg.sender为仲裁机构地址，且传入的公司类型cpType不为“bank”，且传入的公司名称cpName没有与已有的任何公司和银行的名称重复，那么根据传入的公司名称cpName、公司类型cpType和是否为受信公司whetherTrusted来创建一个新的公司实例，初始信用资产和真实资金均为0,收据索引数组均为空。并将这个新创建的公司实例添加到合约的companies数组中。

添加银行：

若当前msg.sender为仲裁机构地址，且传入的银行名称bName没有与已有的任何公司和银行的名称重复，那么根据传入的bName创建一个新的银行实例，收据索引数组均为空。并将这个新创建的银行实例添加到合约的banks数组中。

创建新单据（内部方法）:

根据传入的实体A名称nameA、实体B名称B、转移资产的数量amt、是否有银行参与bankParticipates和是否是真实资金的转移realMoney,创建一个记录资产从实体A转移到实体B的单据，并将此新创建的单据添加到合约的receipts数组中。该方法会在后续的一些方法中被调用。

银行向受信公司授权信用资产：

若传入的授权信用资产数量amt为正，且传入的银行名称bName和公司名称cpName合法，且cpName对应的公司是受信公司，那么根据传入的银行名称bName、公司名称cpName和授权信用资产数量amt,调用newReceipt方法创建银行向公司授权信用资产的新单据。
新单据在receipts数组中的索引存入银行与该公司相应的单据索引储存数组中。银行中储存的该受信公司应向银行归还的资金数额增加amt。该受信公司的信用资产增加amt。

公司A向公司B转移信用资产：

若传入的信用资产转移数量amt为正，且传入的公司A名称companyName_A和公司B名称companyName_B合法，且公司A当前拥有的信用资产数值大于amt,那么根据传入的信用资产转移数量amt、公司A名称companyName_A和公司B名称companyName_B,调用newReceipt方法创建公司A向公司B转移信用资产的新单据。

新单据在receipts数组中的索引存入双方相应的单据索引储存数组中。公司A的信用资产减少amt;公司B的信用资产增加amt。

银行给予公司真实资金：

若传入的资金转移数量amt为正，且传入的银行名称bName和公司名称cpName合法，那么根据传入的银行名称bName、公司名称cpName和转移资金数量amt,调用newReceipt方法创建银行向公司转移资金的新单据。

新单据在receipts数组中的索引存入银行与该公司相应的单据索引储存数组中。该公司的信用资产减少amt,真实资金增加amt。

受信公司向银行还款：

若传入的还款数额amt为正，且传入的公司名称cpName和银行名称bName合法，且cpName对应的公司是受信公司，且还款数额amt合法，即amt小于等于银行记录的授权给该受信公司的信用资产数值减去该公司当前剩余的信用资产数值，那么根据传入的受信公司名称cpName、银行名称bName和还款数额amt,调用newReceipt方法创建受信公司向银行归还资金的新单据。

新单据在receipts数组中的索引存入银行与该公司相应的单据索引储存数组中。银行记录的授权给该受信公司的信用资产数值减少Amt。

受信公司向银行确认完成本次事务：

若传入的传入的公司名称cpName和银行名称bName合法，且cpName对应的公司是受信公司，且受信公司当前信用资产数值等于银行记录的授权给该受信公司的信用资产数值，即受信公司没有未还款项，那么可以确认完成本次事务。受信公司信用资产数值归零；银行记录的授权给该受信公司的信用资产数值归零；合约中变量trustedCompanyHasFinishedWithBank变为true。

一些查询链上信息的方法：

根据公司名称查询公司信息

根据银行名称查询银行信息

根据银行名称和受信公司名称查询受信公司应向银行归还的资金数额

获得现有公司、银行、单据实例的个数

3.项目成果的学术价值

(1)共识算法

区块链系统通过共识算法保障系统一致性。理论上，共识是对某个提案(proposal)达成一致意见的过程，分布式系统中提案的含义十分宽泛，包括事件发生顺序、谁是leader等。区块链系统中，共识是各个共识节点对交易执行结果达成一致的过程。

共识算法分类
根据是否容忍拜占庭错误，共识算法可分为容错(Crash Fault Tolerance, CFT)类算法和拜占庭容错(Byzantine Fault Tolerance, BFT)类算法：

CFT类算法：普通容错类算法，当系统出现网络、磁盘故障，服务器宕机等普通故障时，仍能针对某个提议达成共识，经典的算法包括Paxos、Raft等，这类算法性能较好、处理速度较快、可以容忍不超过一半的故障节点；

BFT类算法：拜占庭容错类算法，除了容忍系统共识过程中出现的普通故障外，还可容忍部分节点故意欺骗(如伪造交易执行结果)等拜占庭错误，经典算法包括PBFT等，这类算法性能较差，能容忍不超过三分之一的故障节点。

FISCO BCOS共识算法

FISCO BCOS基于多群组架构实现了插件化的共识算法，不同群组可运行不同的共识算法，组与组之间的共识过程互不影响，FISCO BCOS目前支持PBFT(Practical Byzantine Fault Tolerance)和Raft(Replication and Fault Tolerant)两种共识算法：

PBFT共识算法: BFT类算法，可容忍不超过三分之一的故障节点和作恶节点，可达到最终一致性；

Raft共识算法: CFT类算法, 可容忍一半故障节点，不能防止节点作恶，可达到一致性。

(2)智能合约

交易的执行是区块链节点上的一个重要的功能。交易的执行，是把交易中的智能合约二进制代码取出来，用执行器（Executor）执行。共识模块（Consensus）把交易从交易池(TxPool)中取出，打包成区块，并调用执行器去执行区块中的交易。在交易的执行过程中，会对区块链的状态（State）进行修改，形成新区块的状态储存下来（Storage）。执行器在这个过程中，类似于一个黑盒，输入是智能合约代码，输出是状态的改变。

随着技术的发展，人们开始关注执行器的性能和易用性。一方面，人们希望智能合约在区块链上能有更快的执行速度，满足大规模交易的需求。另一方面，人们希望能用更熟悉更好用的语言进行开发。进而出现了一些替代传统的执行器（EVM）的方案，如：JIT、 WASM_甚至JVM。然而，传统的EVM是耦合在节点代码中的。首先要做的，是将执行器的接口抽象出来，兼容各种虚拟机的实现。因此，EVMC被设计出来。

EVMC (Ethereum Client-VM Connector API)，是以太坊抽象出来的执行器的接口，旨在能够对接各种类型的执行器。FISCO BCOS目前采用了以太坊的智能合约语言Solidity，因此也沿用了以太坊对执行器接口的抽象。

在节点上，共识模块会调用EVMC，将打包好的交易交由执行器执行。执行器执行时，对状态进行的读写，会通过EVMC的回调反过来操作节点上的状态数据。

经过EVMC一层的抽象，FISCO BCOS能够对接今后出现的更高效、易用性更强的执行器。目前，FISCO BCOS采用的是传统的EVM根据EVMC抽象出来的执行器—Interpreter。因此能够支持基于Solidity语言的智能合约。目前其他类型的执行器发展尚未成熟，后续将持续跟进。

(3)对等网络

设计目标
FISCO BCOS P2P模块提供高效、通用和安全的网络通信基础功能，支持区块链消息的单播、组播和广播，支持区块链节点状态同步，支持多种协议。

P2P主要功能
区块链节点标识
通过区块链节点标识唯一标识一个区块链节点，在区块链网络上通过区块链节点标识对区块链节点进行寻址

管理网络连接
维持区块链网络上区块链节点间的TCP长连接，自动断开异常连接，自动发起重连

消息收发
在区块链网络的区块链节点间，进行消息的单播、组播或广播

状态同步
在区块链节点间同步状态

区块链节点标识
区块链节点标识由ECC算法的公钥生成，每个区块链节点必须有唯一的ECC密钥对，区块链节点标识在区块链网络中唯一标识一个区块链节点

通常情况下，一个节点要加入区块链网络，至少要准备三个文件：

node.key 节点密钥，ECC格式

node.crt 节点证书，由CA颁发

ca.crt CA证书，CA机构提供

区块链节点除了有唯一区块链节点标识，还能关注Topic，供寻址使用

区块链节点寻址：

区块链节点标识寻址
通过区块链节点标识，在区块链网络中定位唯一的区块链节点

Topic寻址
通过Topic，在区块链网络中定位一组关注该Topic的节点

管理网络连接
区块链节点间，会自动发起和维持TCP长连接，在系统故障、网络异常时，主动发起重连
区块链节点间建立连接时，会使用CA证书进行认证

连接建立流程

消息收发
区块链节点间消息支持单播、组播和广播

单播，单个区块链节点向单个区块链节点发送消息，通过区块链节点标识寻址
组播，单个区块链节点向一组区块链节点发送消息，通过Topic寻址
广播，单个区块链节点向所有区块链节点发送消息

单播流程

组播流程

广播流程

状态同步

每个节点会维护自身的状态，并将状态的Seq在全网定时广播，与其它节点同步

AMOP 消息转发流程
单播时序图

多播时序图

带身份验证的单播时序图

通信协议使用的数据结构:

0x37 消息类型中 content 数据结构：

{"nodeId":"2bb4562f4f4b69e2c5156510da4beddfca548403eb7cea49bd56daed46de31e4d78a44fdfa051170c64f0233dbc0fd75b5b4e8bc2df50a3c9ade833794128623","topic":"#!$TopicNeedVerify_hello","topicForCert":"#!$VerifyChannel_#!$TopicNeedVerify_hello_92be6ce4dbd311eaae5a983b8fda4e0e"}

随机数单播中的 content 数据结构：
{"randValue":"14131f50ef730219d48e1f9c441db871c","topic":"hello"}

随机数签名回包中 content 数据结构：
{"signature":"vU/Vzqn4MiP0nO1xN+M5TOk/YcyFtY/TLrgU38jFdooN66r3TzNVKEBpkNId8gCuAeNpNPCo8vmTV3dcs/Xj1AE="}

0x38 消息类型中 content 数据结构：
{"checkResult":0,"nodeId":"2bb4562f4f4b69e2c5156510da4beddfca548403eb7cea49bd56daed46de31e4d78a44fdfa051170c64f0233dbc0fd75b5b4e8bc2df50a3c9ade833794128623","topic":"#!$TopicNeedVerify_hello"}

(4)交易并行

DAG

一个无环的有向图称做有向无环图（Directed Acyclic Graph），简称DAG图。在一批交易中，可以通过一定方法识别出每笔交易需要占用的互斥资源，再根据交易在Block中的顺序及互斥资源的占用关系构造出一个交易依赖DAG图，如下图所示，凡是入度为0（无被依赖的前序任务）的交易均可以并行执行。如下图所示，基于左图的原始交易列表的顺序进行拓扑排序后，可以得到右图的交易DAG。

模块架构

其中主要流程包括：

用户直接或间接通过SDK发起交易。交易可以是能够并行执行的交易和不能并行执行的交易；

交易进入节点的交易池中，等待打包；

交易被Sealer打包为区块，经过共识后，发送至BlockVerifier进行验证；

BlockVerifier根据区块中的交易列表生成交易DAG；

BlockVerifier构造执行上下文，并行执行交易DAG；

区块验证通过后，区块上链。

DAG数据结构
方案中所用到的DAG数据结构如下：

其中：
顶点（Vertex）
inDegree用于存储顶点当前的入度;
outEdge用于保存该顶点的出边信息，具体为所有出边所连顶点的ID列表。
DAG：
vtxs是用于存储DAG中所有节点的列表；
topLevel是一个并发队列，用于存储当前入度为0的节点ID，执行时供多个线程并发访问；
totalVtxs：顶点总数
totalConsume：已经执行过的顶点总数；
void init(uint32_t _maxSize)：初始化一个最大顶点数为maxSize的DAG；
void addEdge(ID from, ID to)：在顶点from和to之间建立一条有向边；
void generate()：根据已有的边和顶点构造出一个DAG结构；
ID waitPop(bool needWait)：等待从topLevel中取出一个入度为0的节点；
void clear()：清除DAG中所有的节点与边信息。
TxDAG:
dag：DAG实例
exeCnt：已经执行过的交易计数；
totalParaTxs：并行交易总数；
txs：并行交易列表
bool hasFinished()：若整个DAG已经执行完毕，返回true，否则返回false;
void executeUnit()：取出一个没有上层依赖的交易并执行；

交易DAG构造流程

1.从打包好的区块从取出区块中的所有交易；
2.将交易数量作为最大顶点数量初始化一个DAG实例；
3.按序读出所有交易，如果一笔交易是可并行交易，则解析其冲突域，并检查是否有之前的交易与该交易冲突，如果有，则在相应交易间构造依赖边；若该交易不可并行，则认为其必须在前序的所有交易都执行完后才能执行，因此在该交易与其所有前序交易间建立一条依赖边。

DAG执行流程
流程如下：

主线程会首先根据硬件核数初始化一个相应大小的线程组，若获取硬件核数失败，则不创建其他线程；
当DAG尚未执行完毕时，线程循环等待从DAG中pop出入度为0的交易。若成功取出待执行的交易，则执行该交易，执行完后将后续的依赖任务的入度减1，若有交易入度被减至0，则将该交易加入topLevel中；若失败，则表示DAG已经执行完毕，线程退出。

4.项目成果的社会效益和经济效益，尚需深入研究的问题等

社会效益

(1)打造全场景透明管理，建信筑和联手FISCO BCOS助力建造业数字化

随着工业4.0时代持续推进，区块链逐渐挥别纯粹的技术自赏和金融标签，渗透进各类实体产业。

在传统建造场景下，行业信息不透明、管理协同性差、信息化水平不高等“痼疾”，使得建造项目的推进过程存在管理难、追责难、监管难、信任难的问题。“区块链+建造”的结合，利用区块链技术，瞄准这些行业痛点，提出了应用层面的切实解决方案。

深圳市建信筑和科技有限公司（以下简称：建信筑和）基于FISCO BCOS区块链平台开发的“伊OS透明建造解决方案”，正是区块链技术在建造行业场景化应用的典型代表。

该方案凭借全场景管理模式的领先优势，入选区块链服务网络BSN首批官方指定应用，并在工信部中国电子技术标准化研究院主办的2020年第四届中国区块链开发大赛上，斩获桂冠。

信息不对称+管理难协同，建造业痛点待破局
在传统建造业中，“信息不对称+管理难协同”是制约行业发展的重要因素。建造业上下游链条很长，如果产业链上每个环节的参与者之间信息不透明，无形中提高了工作协同的沟通、管理成本。诸如施工方和设计方对于设计方案的扯皮、各主体间款项账期的节点把控模糊等问题层出不穷，拖慢整体工程进度。同时，信息不透明也使甲方难以实现全流程式管理穿透，管理不及时、不到位为项目埋下了违规风险，进一步推高信任成本，反过来又加重了工作协同难度。

在传统行业中，建造业信息化程度一直处于较低水平，建设过程中涉及业主投资方、监管方、代建方、咨询方、设计方、施工方、监理方、运营方等众多单位，同时随着当前各类工程项目投资规模的不断扩大，项目管理和资金监管方面压力大，这些问题制约着建造业生态的健康成长。因此，传统建造业的破局路径之一，就是尽快打破现状，利用信息化手段推动建造业实现项目管理“全场景、全主体、全流程透明协同”，而区块链，则是加速技术化进程的独特手段。

在此背景下，建信筑和加入FISCO BCOS区块链开源生态，基于FISCO BCOS区块链技术打造了面向建造行业的全生命周期管理系统——“伊OS透明建造解决方案”，以推进建造行业实现“全场景透明化管理”。该解决方案运用区块链分布式存储/共享、智能合约等技术，与建造行业已有成熟的IT工具如设计软件、造价系统、智慧工地、BIM系统等进行整合，同时结合大数据和人工智能等先进技术，有效破除了行业痛点，构建了一个具有管理穿透、公开透明、信息共享、信用评价的全过程透明建设平台。

区块链技术助力，建造实现全场景穿透管理
“伊OS透明建造解决方案”采取了场景式存证、数字签名、加密算法、智能合约等区块链技术，打破了原有单线任务框架，实现了去中心化的任务协同和数据流转。将原有项目链条（产业链条）上的参与者，例如项目方、设计、施工、勘察、总包、分包、监理、班组等，置于同一任务场景中，不再具有严格的上下游流程关系，原来极易形成彼此掣肘的“物流、资金流、信息流”也能做到有机协同。

同时由于智能合约触发机制的存在，工程资金流向有了明确的监管方向，资金流转的每一步都可透明，这将进一步确保资金使用的合理、合规、合法。同时，工程资金透明也使得工程质量和安全更有保障，形成建造产业良性循环。

“伊OS透明建造解决方案”不仅能够实现单项目多标段管理，还可以实现多项目管理，目前已被广泛运用在建造行业，有效提升项目运行效率。截止2020年5月底，伊OS平台上运行项目超300个，参建单位达400多家。在某集团在建的100+个管网项目中，伊OS系统协助项目负责人全面的管理现场施工的过程、进度、质量、安全进行，通过奖惩机制成功落地执行，让项目问题解决率从60%提升到80%。

建信筑和CTO房少君表示，区块链技术遇见建造行业，不仅可以对项目全过程实施文件共享、资金监管、工程量申报、质量安全、绩效考核等全场景“俯瞰”，而且能有效点亮原先项目管理、工程结算及资金监管上的“盲区”，“事前任务分布-事中实时监督-事后责任追溯”自此形成了高效协同的有机闭环。

万字报告选定FISCO BCOS，携手重塑建造信用生态
为了有效地打造“伊OS透明建造解决方案”，建信筑和选择了FISCO BCOS。“为了甄选区块链底层平台，我们团队专门做了一份过万字的研究报告，最终选定FISCO BCOS，主要是因为它拥有不可多得的语言优势，生态组件、节点部署和技术支持等都非常丰富、易用和高效。”房少君介绍，在FISCO BCOS技术底层上，建信筑和有效地完成了五大业务场景的系统化构建：场景式存证、工程量申报、资金监管、数据交易确权和票据流转。

基于FISCO BCOS区块链技术的“伊OS透明建造解决方案”能够确保项目实施过程中物流流转和信息流转一一对应、资金流向透明监管、物流全程可追溯和资金到账的高度匹配，不仅是区块链在建造行业中的项目管理流程再造，更是新型“全场景”式管理模式下的信用生态重塑。

(2)“人民版权”存证原创新闻超200万篇 | FISCO BCOS应用案例

2019年7月，基于FISCO BCOS区块链底层技术研发的一站式版权管理平台“人民版权”正式上线。至2020年第一季度，该平台在版权原创存证、侵权监测、司法维权方面取得一系列成果：
“人民版权”已为超过200万篇新闻稿件进行版权存证；可自动识别的新闻数超过1亿条，相当于3年的新闻总量；全网监测数据量日均近300万条, 全年总监测量超过10亿条。

目前，“人民版权”已经通过国家网信办境内区块链信息服务备案。未来，平台将持续通过区块链、人工智能等创新技术与知识产权保护深度融合，对抗侵权问题，助力构建版权保护新生态。

区块链助力版权保护存证新闻报道200万篇

近年来，近六成原创媒体作者遭遇过内容侵权，原创稿件被侵权频次高达每篇作品3.64次。网络的虚拟性使得侵权行为难以被及时发现和识别；网络的即时性和裂变传播，令侵权的发展更为迅速，为版权溯源、取证维权也带来了困难。

“人民版权”利用区块链技术的完整性、可追溯性、不可篡改性等特点，综合应用基于区块链的分布式身份解决方案WeIdentity，实现了数字作品链上信息追溯和全网数据监测在内的版权保护全流程管理。

自上线以来，“人民版权”已为2,030,890篇原创新闻报道进行了版权存证保护。全网实时对比监测稿件量达日均2,871,903篇，全年总监测量超过10亿条。识别采集媒体总量达9,988,781家，覆盖了将近全部的电子报刊、网络媒体以及主流客户端。海量信息的实时监测，为快速识别侵权转载并取证上链提供了前提。

首创梯度化司法服务低成本完成侵权诉讼

“人民版权”首创“梯度化司法综合服务”。面向数字版权维权需求，“人民版权”提供了一套创新司法服务，形成了包含互联网法院、公证、司法鉴定、律师、仲裁为一体的权威司法梯度化服务体系，为版权保护在数权时代的司法维权奠定坚实基础。

此外，与传统的维权模式相比，“人民版权”采用电子证据管理、线上调解、互联网法院诉讼等新模式，以智能电子化代替传统人工模式降低成本，用传统版权服务1/2的价格便可完成确权、维权全流程，帮助用户以最小成本、最高效率维权，提升版权维权的司法效率。

今年初，“人民版权”还正式接入了北京互联网法院“天平链”电子证据平台，成为首个实现版权存证、侵权监测、线上版权交易、司法维权全链条打通的媒体版权平台。

媒体年交易额可达百万打造线上最大版权交易平台

“人民版权”平台将版权交易环节引入线上。版权交易中心利用区块链技术对内容生产传播全流程的记录，能够进一步帮助媒体实现在信息分发链条上的价值再分配。据悉，线上引入交易环节，媒体单位版权交易年均收益额预估可达七百万元，市场效益可观。

目前，“人民版权”平台已经完成北京歌华有线电视网络股份有限公司、山东数字出版传媒有限公司、微众银行等五大一级节点接入。2019年10月，“北京云·融媒体”成为第一家接入“人民版权”的省级融媒体平台。同时，人民在线/人民网舆情数据中心发起的“人民版权联盟”已有100多家党媒正在对接中。

“人民版权”运用区块链、大数据与AI 识别等创新技术，即将实现视频版权保护功能。目前，“人民版权”正在与西部国家版权交易中心、北方国家版权交易中心、中广电传媒有限公司等进行视频版权方面的合作，携手共促视频版权生态的良性发展。

经济效益
FISCO BCOS助力深圳破解网贷良性退出难题
虽然区块链技术热度方兴，而深圳已经成功应用于网贷机构良性退出工作中。记者昨日从深圳地方金融监管局获悉，今年上半年，深圳率先全国推出以区块链技术为核心的P2P网贷机构良性退出统一投票表决系统，至今已在全市20家网贷机构投入应用，导入出借人8万余人，待收本金102亿余元。

投票系统让万千出借人有了“表决权”

面对网贷机构退出的兑付方案，普通出借人如何表达自己的意见和诉求？今年上半年，在深圳市、区两级地方金融监管部门的指导和推动下，深圳率先全国推出P2P网贷机构良性退出统一投票表决系统（下称“投票系统”）。

该系统是《深圳市网络借贷信息中介机构良性退出指引》（下称《良性退出指引》）的配套技术支持平台，旨在有效解决平台良性退出过程中涉众决策难的问题，为网贷良性退出工作打响了“开山炮”。

“P2P网贷机构良性退出面临的首要难题是涉众决策难。”深圳市互联网金融协会秘书长曾光介绍，网贷机构管理的资产权属属于出借人，但出借人数量庞大，分布在全国各地，结构复杂诉求不一，平台与出借人沟通成本高、出借人对平台不信任。

为提供涉众决策统一规则，深圳市互联网金融协会率先推出《良性退出指引》，创新设置出借人监督委员会、“三分之二加双过半”的表决规则等一系列良性退出规则要求。

在《良性退出指引》基础上，再度推出“网贷机构投票系统”，使涉及出借人重大利益事项的投票表决成为可能。“在以前的出借人表决实际操作中，往往通过微信群、QQ群、社交网站的投票软件，少数代表的现场会等形式进行投票，其合法性和公正性倍受质疑，执行过程也常有反复。”曾光介绍，在此情况下，新的投票系统为出借人提供投票表决服务，致力于实现公平、公开、透明的投票表决环境。出借人监督委员会负责对相关事项进行审核监督，网贷机构授权协会提供信息披露及投票表决服务。

记者了解到，目前深圳市已经有20家网贷机构使用投票系统。曾光介绍，“使用投票系统的大部分网贷机构都按照《退出指引》要求，积极推动了第一次重大事项投票表决，确认退出流程，选举监委会成员并对清退组和监委会授权。”另外部分平台已通过投票系统完成第二轮投票表决事项，各平台的良性退出工作进展有序。

尚需深入研究的问题

在区块链系统和业务设计时，不信任什么。

先讲结论：几乎什么都不能信！建立Don’t Trust,Just Verify的理念，才是通往区块链世界的正确态度。

不信任其他节点
区块链节点和其他节点会建立P2P通信，共同组成网络，传递区块、交易、共识信令等各种信息。其他节点可能是由不同的机构、不同的人持有，持有节点的人可能是善意，也可能是恶意。即使在善意假设时，节点运行存活的健康度也会受运维水平和资源影响，比如处于一个不稳定的网络里，会偶尔挂掉，会抽风乱发消息，或者硬盘满等原因导致数据存储失败，以及出现其他可能的故障。在恶意假设时，要预设其他节点可能会骗自己或伤害自己，比如传递过来错误的协议包，或者用诡异的指令寻找漏洞进行攻击，或者发起高频垃圾请求，频繁连接然后断开，又或者海量连接占用资源等。

所以节点应该是把自己看成在黑暗丛林里孤身求生存的猎人，必须有“独立自主”、“自给自足”的态度，摆出“不相信其他任何节点”的姿势保护自己。在节点准入时，需要采用证书技术来认证节点身份；在连接控制上，拒绝有异常的连接；采用频率控制对连接次数、请求量等做限制；在协议包格式和指令正确性等方面做验证。自己发出去的信息，不应暴露自己的私有信息，也不期望其他节点一定会给出立刻和正确的响应，必须采用异步处理和校验容错的设计。

节点和客户端互相不信任
客户端，指在区块链网络外，向区块链发起请求的模块，如业务使用的java sdk、钱包客户端等。客户端和节点通过网络端口通信。如果客户端掌握在不受控的人手里，有可能会向节点发起大量的请求，或发送一堆垃圾信息，使节点疲于应对，甚至巧妙地构建漏洞攻击信息，试图越权访问，窃取信息或使节点出错。

同时，从客户端的角度看，节点有可能不响应或响应缓慢，或者返回错误的数据，包括格式错误、状态错误、表示收妥但其实不处理等，甚至别有用心的人会设置一个“假”节点和客户端通信，欺骗客户端。节点做出这些与期望不符的反应，可能使客户端运行出错，功能受损。

为提升节点和客户端的互信，可以为双方分配数字证书，必须通过证书进行双向握手，客户端经过私钥签名才能对节点发起交易类请求，节点应对客户端进行权限控制，拒绝高危的接口调用，不要轻易开放节点管理接口、系统配置接口等。双方对每次通信的数据格式、数据有效性都进行严密校验。双方在交互时也应该进行频率控制，异步处理，对每一个交互进行结果校验，不能预设对方正确处理，必须获取交易回执和处理结果进行确认。

当认为只和一个节点通信并不能保证安全时，客户端可以采用“f+1查询”的思路，尽可能多地和几个节点通信。如果当前链的共识安全模型是“3f+1”，那么，如果从f+1个节点读到的信息是一致的，结果是可以确认的。

不信任区块高度
区块高度是一个非常关键的信息，代表整个链当前的状态。向区块链发送交易、节点间进行共识、对区块和状态的校验等操作都会依赖区块高度。

某个节点在断网或处理速度缓慢时，其区块高度有可能落后于整个链，又或者某个节点恶意伪造数据时，其高度又可能超过整个链。在链出现分叉时，如某一个分叉上的区块高度被另一个分叉超越，落后的分叉就会变得毫无意义。即使在正常的情况下，节点依旧有可能间歇性地落后于整个链一到几个区块，然后在一定时间内才可能追上最新高度。

如在PBFT共识模型里，总数2/3以上节点在同一个高度时，全链就有机会达成共识继续出块。余下的1/3的节点有可能和参与共识的节点高度不同，这时意味着从这个节点读取到的数据，并不是全网最新的数据，只能代表链在该高度时的一个快照。

业务逻辑可以把区块高度做为一个参考值，基于高度做一些判定逻辑，在确定性共识（如PBFT）的链上，采用f+1查询等方法确认链的最新高度，在可能分叉的链上，需要参考“6个区块确认”的逻辑，审慎选取可信的区块高度。

不信任交易数据
交易（Transaction）代表一方向另一方发起了一个事务请求，交易可能导致资产的转移、改变帐户状态或系统配置，区块链系统通过共识后确认交易，使相关的事务生效。交易必须带上发送者的数字签名，交易里所有数据字段都必须包含在签名里，未经签名的字段存在被伪造的可能，不予采信。交易数据在网络上广播时，可以被其他人读取，如交易数据里包含隐私数据，发送者则必须对数据进行脱敏或加密保护。交易可能因为网络原因被重发，或者被其他人保存下来刻意再次发送，造成交易的“重放”，所以区块链系统必须对交易进行防重，避免出现“双花”。

不信任状态数据
区块链的状态（State）数据是由智能合约运行后生成的，理想情况下，每个节点的合约引擎一致、输入一致、规则一致，那么输出的状态就应该一致。但不同的节点可能安装了不同的软件版本，或者合约引擎的沙盒机制不够严密引入了不确定性因素，甚至被侵入、篡改，或者存在其他莫名其妙的bug，都可能导致合约运行输出结果不一致，那么一致性和事务性就无法得到保障。

状态的校验是成本很高的事情，典型的校验方法是使用MPT（Merkle Patricia Tree）树，把所有状态都塞到树里管理起来。MPT树可以把所有的状态归结为一个Merkleroot Hash，节点之间在共识过程中确认交易运行后生成的状态树Merkleroot，确保状态一致。

这棵树结构复杂，数据量大，消耗不少的计算和存储资源，很容易就成为了性能瓶颈。所以对状态的校验需要有更快、更简单，且又稳妥的方案，如结合版本验证、增量Hash验证等算法，辅以数据缓存，可减少重复计算和优化IO次数，能在保证一致性、正确性的同时，有效地提升验证效率。

不信任私钥持有者
采用私钥对交易以及其他关键操作进行签名，再使用公钥验签，是区块链上最基础的验证逻辑。只要私钥被正确使用，这个逻辑是安全的。

但私钥仅仅是一段数据，只依赖私钥则用户是匿名的。在联盟链面对的场景里，需要使用许可型的身份，首先通过KYC、尽调、权威认证等现实世界的验证方式确认身份，然后将身份和公钥绑定并公示，或者结合PKI体系的数字证书发放公私钥，这样私钥对应的身份是可知、可信、可控的。

私钥可能会因丢失、泄漏而被他人盗用，或者因被遗忘导致资产损失。所以在私钥的保存上，需要考虑采用周全的保护方案，如加密存储、TEE环境、密码卡、USBkey、软硬加密机等方案。在私钥的管理上，则需要考虑密钥丢失后如何安全的重置、找回。

加强版的私钥使用思路有几个，比如使用多签、门限签名等方式，每次交易时必须用多个私钥进行签名，私钥可以保管在不同的地方，安全性高，但技术方案和使用体验复杂。

还有一种是交易私钥和管理私钥分离。交易私钥用于管理资产，管理私钥用于管理个人资料，交易私钥可以被管理私钥重置，管理私钥本身则通过门限、分片等算法，分开存储保管，以备重置或找回。

不信任其他链
在跨链的场景里，每条链有自己的资产、共识，链之间的安全模型变得非常复杂，比如一条链上的记账者串通造假，或者链出现了分叉、区块高度回滚，这时如果链外的其他模块和链有不够严谨的交互，都会造成数据不一致或资产损失。如果不同的链采用的还是不一样的平台架构，那么在工程上会更加复杂。

跨链、侧链目前依旧是业界在研究和逐步实现的课题，主要目的是解决链和链之间的通信，进行资产锁定和资产交换，保证整个过程的全局一致性、交易事务性，以及抗欺诈。从A链往B链转移一个资产，必须要确保A链上的资产被锁定或销毁，且B链上一定能增加对应的一笔资产，在双方可能分别出现分叉、回滚的时间窗里，要有机制确保双向的资产安全。

在现有跨链的方案里，存在中继、链间HUB等方式，这些系统的设计本身也要达到高度可信可靠的标准，安全等级应不低于甚至高于所对接的链，同样也应采用多中心、群体共识的体系设计，整体复杂度可算是链的N次方了。

不信任网络层
区块链节点需要和其他节点发生通信，所以必须在网络上暴露自己的通信端口，如果通过公网通信，那么相当于在公网上暴露了自己，很容易遭到类似渗透、DDOS这样的网络攻击。节点必须在网络层保护自己，包括在网关上设置IP黑白名单、设置端口策略、进行DDOS流量防护，且对网络流量、网络状态进行监测，如果突发网络流量或连接数暴增，说不定，就是被人当肉鸡或者正在脱库进行时了。非必要端口，切忌对公网开放，如用于做管理监控的RPC端口，只能对机构内部开放，在进行网络策略设定之前，一定要慎之又慎。

不信任代码
“Code is law”确实是一句响亮的口号，但是在程序员头发掉光之前，他写的代码都可能有bug，只是看写bug快还是修bug快而已。

无论是底层的代码还是智能合约代码，都可能存在技术性或逻辑性的坑，但凡代码产生的数据和指令行为，都需要另一段代码对其进行严格地校验，代码本身也需要进行静态和动态扫描，包括采用形式化证明等技术进行全面地审核验证，以检测可能的逻辑错误、安全漏洞或是否有信息泄露。前段时间有一份公布到github上的某酒店系统的代码，居然包括了mysql的连接用户名密码，且数据库端口居然是向公网开放的，这种坑简直不可想象。

开放出去的开源代码，固然可以被人审查、反馈以提升安全性，也可能被人翻找漏洞、随意修改，甚至恶意埋雷。但总的来说，开源还是利大于弊。在开源社区中，开发者会向项目提交PR（Pull Request）。审核PR是很关键也很繁重的工作，值得安排专家并分配大量时间去做审核。有开源项目的老司机透露，其项目核心模块的PR的审核时间长达经年，否则“加了个功能引入两个bug”那真是得不偿失，更别说如果被植入漏洞埋雷了。

不信任记账者
共识的流程大致可以抽象为，选出记账者，记账者发布区块，其他节点校验和确认。公链里记账可以用“挖矿”的方式进行（如比特币），矿工用大量的算力代价为它自己的诚信背书，又或者是用大量的资产权益抵押获得记账权（Pos和DPos等共识）。在联盟链常用的PBFT/Raft等算法里，记账者列表可以是随机或轮换产生，记账者给出提案，其他投票人多步提交，收集投票。按少数服从多数的原则，一般是2/3以上共识节点同意，共识才能达成。

从系统可用性角度看，记账者有可能出错、崩溃，或者运行缓慢，影响整个链的出块。又或者记账者可以只收录手续费高的交易，抛弃一些交易，导致有些交易总是不能达成。有的记账者还可以凭借算力或暗箱运作，进行“预挖”或者“扣块攻击”，破坏博弈关系……

记账者故障或作恶，超越了共识的安全阈值的话，将直接伤害整条链的价值基础。根据不同的记账模式，记账者需要设计不同的容错、校验、抗欺诈算法，执行激励和惩罚机制，在运行过程中定期检查记账者的健康度，对于无力记账或者作恶的记账节点，全网不接受他们的记账结果，并对其进行惩戒，甚至是踢出网络。

罗列起来还有很多，包括合约、证书、同步等等，每一个模块都有自己的功用和风险点，简直罄竹难书。总之，区块链做为分布式的多方协作的体系，接入了形形色色参与者，整个体系绝不是单个开发者或运营者所能单点把控，“善意推测”在这个领域已经不尽适用，整个世界步步惊心，处处冷箭，只能通过周密的算法和繁杂的流程维系共识和安全，简而言之，没有经过验证的信息，一个字节都不能相信。

比起单一环境里的软件设计，区块链领域的设计思路确实存在颠覆性，开发者要从“做功能，只容错，不防骗”的思维模式里跳出来，带着“怀疑一切”的态度进行设计。

开发者在面向区块链领域时，不能只是思考怎么实现一个功能，而更要去思考整个流程会不会有出错，会不会被人篡改数据、发掘漏洞、攻击系统、欺诈其他参与者。要换位思考自己所实现的功能，会被别人用什么方式使用，在不同的环境会有什么表现，可能造成什么后果。任何收到的信息，任何流程输入、输出，都必须经过严格地校验才能采信，开发者能做到这一点，才算是打开了区块链新世界的大门，才能在连续剧里至少活到第二集。

分布式算法、对称非对称加密、HASH、证书、安全和隐私等技术在区块链领域大行其道，都是为了在保护信息的同时，给信息加上一层又一层的证明和可验证因子，这使得整个系统变得复杂、繁琐，但这是值得的，因为这样才能共同验证，构建“安全”和“信任”。