1. 引言
中共十九届四中全会上提出“重视发挥第三次分配作用，发展慈善等社会公益事业” [1]，这为中国慈善事业高质量发展指明了方向。目前，随着互联网技术不断发展，各种筹款捐助活动由传统的现金筹款转变为线上筹款。但线上筹款其不良事件也时有发生，存在的主要问题概括为以下三点：1) 信息披露不透明不规范，在现行的慈善系统中，由于人力物力等原因，每个慈善组织的信息披露和慈善项目的申请、审核标准不一，甚至产生不法分子诈捐，影响公众的捐款热情；2) 捐款流向不透明，大部分系统为中心化系统，捐款人对于捐款流向往往不清楚，容易产生内部人员挪用善款、篡改数据，造成恶劣的社会影响；3) 追责难，平台日志不规范，难以日常审计和突发事件的回溯 [2]。因此，建立一套以国家监管部门及核心组织配合为主，行业自我约束为辅的慈善平台，创造有利于公益慈善健康发展的社会环境。
区块链上具有去中心化、可追溯不可篡改等特性 [3] [4]，并可以通过智能合约 [5] 自动执行合同条款，天然适用于社会公益事业业务场景 [6]。捐赠流程中的慈善项目发起、捐款流向、执行结果反馈都可以通过区块链技术进行信息上链 [7] [8]，在发起项目审核通过后，将项目信息进行上链，用户可以对链上项目进行捐款，系统对非匿名用户捐款进行公开公示，方便社会公众对捐款流向进行监督，有利于慈善事业的健康发展。
2. 系统模型
为了业务完整性和数据安全，系统至少包括以下模块：身份和账户管理模块(IAM)、信息发布模块(CISM)、进展管理模块(CIPM)、慈善币管理模块(CCM)。在基于区块链的可监管慈善系统中，IAM提供用户注册、登录、行为管理和其他功能，慈善组织和受益人使用CISM向区块链模块投放慈善信息，CIPM用于记录和监管项目进展，CCM用于用户和公益组织兑换慈善币。基于区块链的可监管慈善系统的区块链模块使用开源区块链框架Hyperledger Fabric [9] 实现，构建了慈善信息链和慈善币链。
2.1. 系统框架和需求
如图1所示，基于区块链的可监管慈善系统主要包括业务层和区块链层，业务层包括用户注册、发起慈善项目、项目进展管理、链上查询、慈善币管理。区块链层包括合约层、网络层、数据层，其中合约层通过共识机制和智能合约将慈善系统的业务逻辑转化为可编程合约，通过节点的共识完成慈善信息的上链存储，基于区块链的可监管慈善系统设计必须满足以下原则：
1) 个人用户和公益组织都可以发起慈善项目，但为了便于后续的监管和追责，个人用户发起慈善项目时必须先选择公益组织，公益组织先对用户发起慈善项目进行审核，项目审核通过后公益组织设计出项目执行策略，完成后其慈善信息存储在数据存储服务器中，如云存储服务IPFS网络 [10]，签名上链后通过背书节点确认，链上记录慈善项目信息；
2) 本系统设计一种与人民币等值的加密货币CC (Charity Coin) [11]，以便于慈善资金的监管，该货币价格不会因为市场价值进行波动，捐赠者通过人民币汇兑慈善币，不征收任何汇兑费和税，捐赠者可以向受益人捐赠准确的金额而不扣除任何费用，有效地跟踪善款流向，同时系统后续将考虑使用数字人民币DCEP (Digital Currency Electronic Payment) [12] 作为慈善系统数字货币；
3) 必须验证慈善币的交易，交易双方的钱包地址都必须有足够的慈善币，交易记录了慈善币从一个钱包到另一个钱包的过程，每次捐赠都需要通过区块链共识机制进行验证，公益组织可以通过收据、图像证据来证明慈善过程，用户可以直接向公益组织捐款并对这笔捐款流向进行跟踪。
2.2. 系统算法的使用
部署基于区块链的可监管慈善系统时，可按如下方式运行：
1) 用户通过IAM模块进行个人用户和公益组织的认证注册，个人用户可以即时提交即时通过注册，公益组织包括基金会、社会团体、民办非企业，注册的审核时间约为两个工作日，完成注册后即可获得自己的钱包地址，并可以通过CISM模块发起慈善项目，提交慈善项目申请后，公益组织在五个工作日内返回项目的审核结果，组织审核通过的项目信息写入区块链；
2) 项目信息上链后进入项目筹款阶段。筹款期间，个人用户和公益组织通过CCM模块进行项目捐款，系统将相关捐款信息上链并实时更新项目筹款进度。筹款完成后，项目进入执行阶段，执行方按照项目发起时提交的执行计划执行，系统根据执行计划将捐款拨给项目执行方，执行方执行过程中通过CIPM模块更新项目进展。慈善项目执行结束后，受益人、执行方和公益组织三方共同提供项目成果报告，进行项目成果信息上链。
3. 可监管的慈善系统设计
基于区块链的可监管慈善系统由四个模块组成，包括身份和账户管理模块(IAM)、信息发布模块(CISM)、项目进展模块(CIPM)、慈善币管理模块(CCM)。如图2所示，收益人、公益组织和捐赠人是系统的三个主要用户，捐赠者、组织和受益人可以通过基于web和移动的应用程序，使用区块链网络与捐赠管理系统连接。除此之外，具有不同授权级别和管理控制的多个管理员用户也是系统的一种用户类型。
3.1. 区块链实现
如图2所示，基于区块链的可监管慈善系统基于Hyperledger Fabric (HLF)的多通道特性 [13] 设计了慈善信息链(CI-chain)和慈善币链(CC-chain)。HLF是一个联盟许可链，所有用户都需要经过证书颁发机构(CA)的认证才能加入区块链网络，HLF包含成员服务提供商模块、智能合约模块、分布式账本模块、交易模块。并且HLF在版本1.4中已经实现了令牌机制，使用UTXO模型 [14]。在本系统中，其中一条链是慈善信息链，用于存储慈善项目的发起、筹集、执行、结项等慈善项目相关信息，另一条链是慈善币链系统设计了一种新的加密货币CC。总共将有100亿个慈善币，每个CC价值1人民币，用户根据自己的意愿进行捐助。例如，如果用户捐赠10人民币，那么他将获得10 CC的余额。
3.2. IAM模块
在本模块中，个人用户必须向CA提供注册帐户所需的信息，如姓名、身份证、地址、手机号。我国公益组织可登记为社会团体、基金会、民办非企业(慈善法出台后改称社会服务机构)，公益组织通过提供公司信息，如组织名称、法人信息、统一社会信用代码等来完成注册。注册成功后用户将获得一个钱包地址，该地址打包在x.509证书中，同时作为慈善币链的账户信息，个人用户和组织都可以对CC币进行兑换。算法1说明了用户如何注册帐户。如果信息合法，将生成任何类型的用户。如果他们的信息有拼写错误或帐户已在系统中冻结，则注册将失败。
考虑到我们系统的安全性，本模块将定期检查现有账户，发现并冻结恶意账户。如果发现非法信息，相关用户的帐户将被列入失信筹款人黑名单，慈善组织将被线下追查。
3.3. CISM模块
CISM模块通过智能合约实现发起慈善项目。用户在进行慈善项目发起前，需填写包括受益者信息、目标金额、申请事由、联系方式、地址，背书组织等信息，在申请审核时系统初始化项目已筹金额为“0”，筹款状态为“未完成”。系统后续将考虑引入变色龙哈希函数使慈善信息是可修改的，但每个修改的记录都可追溯，以确保用户能够根据后续实际情况完善项目信息。算法2说明了用户发起慈善项目的智能合约。如果信息合法，将生成组织对该慈善项目的电子签名信息上链。如果信息非法或帐户已在系统中冻结，则发起慈善项目将失败。
3.4. CIPM发布
慈善项目信息上链后显示在系统页面中，捐赠者和公益组织都可以进行捐款，并实时更新筹款进度，完成筹款目标后，筹款状态更新为“已完成”，项目进入执行阶段，执行方按照项目发起时提交的执行计划执行，执行方执行过程中通过CIPM模块更新项目进展。算法3说明了慈善进展信息上链的智能合约，如果信息合法，将生成组织对该慈善项目的进展信息上链，如果信息非法或者账户已在系统中冻结，则项目进展更新失败。
3.5. CCM模块
本文设计的加密货币是基于Hyperledger Fabric，采用UTXO模式，用户只能使用未使用的交易输出。慈善币管理模块第一个智能合约是针对CC的IEO (Initial Exchange Offerings)，智能合约初始化了系统发行货币的总数，并且规定了人民币和慈善币的汇率是1，并设计了CC购买与出售的功能。算法4说明了CC的发行和CC的兑换功能。算法5说明了捐赠信息上链功能，慈善币链与慈善信息链的交互最终实现有效地善款流向可监管，防止善款滥用。
4. 实验分析
本节的第一部分介绍系统的环境配置，第二部分介绍系统主要功能实现，第三部分是对系统性能的测试与分析。
4.1. 环境设置
本系统实现在三台虚拟机VMware Workstation Pro中完成，操作系统为Ubuntu18.04。虚拟机内存2 GB，处理器核心数为2个，硬盘为25 GB。其中Hyperledger Fabric的版本为2.3，Golang版本为1.17.5，Node.js版本为12.9.1，Docker版本为19.03.2，Docker-compose版本为1.25.0，系统搭建的节点使用Docker容器封装。
4.2. 系统主要功能测试
针对本系统的慈善项目发起、项目信息展示、用户捐款记录等重要功能进行了实验测试，部分重要功能实验结果如图3~5所示，图3显示了慈善项目发起和项目信息界面，图4显示了发起慈善项目后系统的后台记录，图5显示了用户的捐款记录。
4.3. 实验结果
本系统性能测试使用Hyperledger Caliper性能测试工具 [15] 进行测试，对区块链网络中交易成功率、交易延迟、吞吐量(TPS)等指标进行测试。测试模拟三个组织各有两个节点的Fabric网络中发送交易请求，测试用例包括慈善项目发起合约createCI，查询合约queryCI等，分别测试区块链的读写性能。测试在搭建在虚拟机中Fabric网络节点上，系统配置为处理器核心数为2，内存为4 GB，硬盘为25 GB，网络带宽为100 Mbit/s，启用CouchDB作为状态数据库。
Figure 3. Project initiation function verification
图3. 项目发起功能验证
Figure 4. Background record of project initiation
图4. 项目发起后台记录
压力测试分为12轮进行，前6轮测试内容为慈善信息信息上链智能合约createCI测试，每轮测试交易量为1000笔，目的是测试账本写入性能。为了精准测试出区块链网络承载能力峰值，吞吐量发送速率梯度设定为50 tps、100 tps、150 tps、200 tps、250 tps、300 tps。后6轮测试内容为查询链上签约信息智能合约queryCI测试，每轮测试交易量为1000笔，目的是测试账本读取性能。吞吐量发送速率梯度设定为100 tps、200 tps、300 tps、400 tps、500 tps、600 tps。
在测试量为1000次的条件下，createCI智能合约的吞吐量与平均延迟的关系如图6所示，网络的交易吞吐量约为230 TPS左右。当发送速率达到第四轮200 TPS，交易的平均延迟开始急剧升高，吞吐量保持在230 TPS左右不变，平均延迟在3 s左右。当发送速率更高时，交易超出链上负载，进入排队队列等待，导致延迟不断增大。
queryCI智能合约的吞吐量与平均延迟的关系如图6所示，在前四轮中，因为queryCI智能合约的操作不需要写入链上数据，网络节点不进行共识，随着发送速率的增大，系统查询吞吐量随之增大，延迟一直稳定在0.01 s左右。当发送速率达到第四轮400 TPS，交易的平均延迟开始急剧升高，吞吐量保持在350 TPS左右不变，平均延迟在0.1 s左右。当发送速率更高时，交易超出链上负载，进入排队队列等待。
Figure 6. Blockchain reading and writing performance (left: write performance of blockchain transactions, right: read performance of blockchain transactions)
图6. 区块链读写性能表现(左：区块链写性能，右：区块链读性能)
5. 结语
相对于传统慈善平台来说，本文通过慈善过程信息上链，并设计了一种数字货币进行善款追踪，使用智能合约和数字钱包有效解决了传统慈善平台的信任问题。本文还对该系统进行了性能测试，实验表明，该系统性能可以满足业务需要。在未来的研究工作中，将考虑引入变色哈希龙函数实现根据实际情况变更项目信息、删除风险项目等功能，优化算法提高系统效率，并与相关企业合作推广本平台。