一种数据处理方法及相关产品与流程

本申请涉及区块链技术领域，具体涉及一种数据处理方法及相关产品。

背景技术：

随着网络的迅速发展，网络慈善捐款越来越普及，越来越多的人可以通过网络平台进行募捐和捐款，使得越来越多的人从中得到帮助。

然而，传统模式的网络募捐平台存在诸多问题。其一，网络平台上的募捐信息一般由受捐人或其亲属填写，存在虚假信息的可能。其二，针对募捐所得捐款无法确保全部能用于治疗。

技术实现要素：

本申请实施例提供了一种数据处理方法及相关产品，实施本申请实施例，有利于防止募捐人作假和确保捐款的正确使用。

第一方面，本申请实施例提供了一种数据处理方法，应用于服务器，所述方法包括：

接收捐款客户端发送的捐款请求，所述捐款请求包括捐款；

根据预先制定的智能合约转移所述捐款；

根据所述智能合约按照预设规则处理所述捐款。

可选地，所述根据所述智能合约按照预设规则处理所述捐款包括：

根据所述捐款确定捐款总金额；

按照所述捐款总金额的第一预设比例确定第一放款，并将所述第一放款转账至募捐人指定的数字钱包；

接收募捐客户端发送的第一请款请求，所述第一请款请求包括所述第一放款使用的凭证信息；

根据所述第一请款请求向所述捐款客户端发送第一投票请求；

若所述第一投票请求的投票结果为撤销余下捐款，则将所述余下捐款以捐款比例按照捐款来源原路退还；

若所述第一投票请求的投票结果为同意放款，则按照所述捐款总金额的第二预设比例确定第二放款，并将所述第二放款转账至所述募捐人指定的数字钱包。

可选地，若所述第一投票请求的投票结果为不同意放款，所述根据所述智能合约按照预设规则处理所述捐款还包括：

接收所述募捐客户端发送的第二请款请求，所述第二请款请求包括所述第一放款使用的补充凭证信息；

根据所述第二请款请求向所述捐款客户端发送第二投票请求；

根据所述第二投票请求的投票结果处理所述捐款。

可选地，在将所述第二放款转账至所述募捐人指定的数字钱包之后，所述根据所述智能合约按照预设规则处理所述捐款还包括：

接收所述募捐客户端发送的第三请款请求，所述第三请款请求包括所述第二放款使用的凭证信息；

根据所述第三请款请求向所诉捐款客户端发送第三投票请求；

根据所述第三投票请求的投票结果处理所述捐款。

可选地，所述方法还包括：

判断转移至所述智能合约的捐款金额是否达到预设募捐总金额；

若转移至所述智能合约的捐款金额达到所述预设募捐总金额，则停止向所述智能合约转移捐款。

可选地，所述方法还包括：

接收募捐客户端发送的募捐请求，所述募捐请求包括募捐信息；

向区块链广播所述募捐信息。

可选地，所述募捐信息包括预算医疗金额和/或募捐人或受捐人银行账户余额的证明信息，所述向区块链广播所述募捐信息包括：

判断所述预算医疗金额和/或募捐人或受捐人银行账户余额与所述预设募捐总金额的差值是否小于预设阈值；

若所述预算医疗金额和/或募捐人或受捐人银行账户余额与所述预设募捐总金额的差值小于预设阈值，则向区块链广播所述募捐信息。

第二方面，本申请实施例提供了一种数据处理装置，应用于服务器，所述数据处理装置包括：

接收模块，用于接收捐款客户端发送的捐款请求，所述捐款请求包括捐款；

转移模块，用于根据预先制定的智能合约转移所述接收到的捐款；

处理模块，用于根据所述智能合约按照预设规则处理所述捐款。

第三方面，本申请实施例提供了一种服务器，包括处理器、存储器、通信接口，以及一个或多个程序，所述一个或多个程序被存储在所述存储器中，并且被配置由所述处理器执行，所述程序包括用于执行第一方面所述的方法中的步骤所对应的指令。

第四方面，本申请实施例提供了一种计算机可读存储介质，其中，上述计算机可读存储介质存储用于电子数据交换的计算机程序，其中，上述计算机程序使得计算机执行如本申请实施例第一方面所述的方法中所描述的部分或全部步骤。

第五方面，本申请实施例提供了一种计算机程序产品，其中，上述计算机程序产品包括存储了计算机程序的非瞬时性计算机可读存储介质，上述计算机程序可操作来使计算机执行如本申请实施例第一方面的方法中所描述的部分或全部步骤。该计算机程序产品可以为一个软件安装包。

可以看出，本申请实施例提供的技术方案中，接收捐款客户端发送的捐款请求，所述捐款请求包括捐款；根据预先制定的智能合约转移所述捐款；根据所述智能合约按照预设规则处理所述捐款。可见，实施本申请实施例，有利于防止募捐人作假和确保捐款的正确使用，杜绝利用爱心进行虚假捐款，将社会善款真正应用于社会上最需要帮助的人。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1是本申请实施例提供的一种数据处理方法的流程示意图；

图2是本申请实施例提供的另一种数据处理方法的流程示意图；

图3是本申请实施例提供的另一种数据处理方法的流程示意图；

图4是本申请实施例提供的另一种数据处理方法的流程示意图；

图5是本申请实施例提供的一种数据处理装置的功能模块组成框图；

图6是本申请实施例提供的一种服务器的物理架构示意图。

具体实施方式

为了使本技术领域的人员更好地理解本申请方案，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”、“第三”等是用于区别不同对象，而不是用于描述特定顺序。此外，术语“包括”和“具有”以及它们任何变形，意图在于覆盖不排他的包含。例如包含了一系列步骤或模块的过程、方法、系统、产品或设备没有限定于已列出的步骤或模块，而是可选地还包括没有列出的步骤或模块，或可选地还包括对于这些过程、方法、产品或设备固有的其他步骤或模块。

在本文中提及“实施例”意味着，结合实施例描述的特定特征、结构或特性可以包含在本申请的至少一个实施例中。在说明书中的各个位置出现该短语并不一定均是指相同的实施例，也不是与其它实施例互斥的独立的或备选的实施例。本领域技术人员显式地和隐式地理解的是，本文所描述的实施例可以与其它实施例相结合。

区块链是一种按照时间顺序将数据区块相连的一种链式数据结构，并以密码学方式保证的不可篡改和不可伪造的分布式账本。

区块链的特性有开放、共识、去中心、去信任、透明、双方匿名、不可篡改以及可追溯等。其中，开放与透明意为任何人都可以参与到区块链网络，每一台设备都能作为一个节点，每个节点都允许获得一份完整的数据库拷贝。节点基于一套共识机制，通过竞争计算共同维护整个区块链。任一节点失效，其余节点仍能正常工作。其中，去中心化与去信任意为区块链由众多节点共同组成一个端到端的网络，不存在中心化的设备和管理机构。节点之间数据交换通过数字签名技术进行验证，无需互相信任，只要按照系统既定的规则进行，节点之间不能也无法欺骗其他节点。其中，透明与双方匿名意为区块链的运行规则是公开的，所有的数据信息也是公开的，因此每一笔交易都对所有节点可见。由于节点与节点之间是去信任的，因此节点之间无需公开身份，每个参与的节点都是匿名的。其中，不可篡改和可追溯意为每个甚至多个节点对数据库的修改无法影响其他节点的数据库，除非能控制整个网络中超过51％的节点同时修改，这是几乎不可能发生的。区块链中的，每一笔交易都通过密码学方法与相邻两个区块串联，因此可以追溯到任何一笔交易记录。

具体的，区块链可以利用块链式数据结构来验证与存储数据、利用分布式节点共识算法来生成和更新数据、利用密码学的方式保证数据传输和访问的安全、利用由自动化脚本代码组成的智能合约来编程和操作数据的一种全新的分布式基础架构与计算方式。因此，区块链技术不可篡改的特性从根本上改变了中心化的信用创建方式，有效提高了数据的不可更改性以及安全性。其中，由于智能合约使得所有的条款编写为程序，这些条款可在区块链上自动执行，保证了当存在触发智能合约的条件时，区块链能强制根据智能合约中的内容执行，且不受任何外力阻挡，从而保证了合约的有效性和执行力，不仅能够大大降低成本，也能提高效率。区块链上的各个节点都有相同的账本，能够确保账本记录过程是公开透明的。区块链技术可以实现了一种点对点的、公开透明的直接交互，使得高效率、大规模、无中心化代理的信息交互方式成为了现实。

本申请实施例主要应用于服务器，服务器例如可以包括区块链节点服务器、传统服务器、大型存储系统、台式电脑、笔记本电脑、平板电脑、掌上电脑、智能手机、便携式数字播放器、智能手表以及智能手环等等。其中，区块链节点服务器例如可以包括传统服务器、大型存储系统、台式电脑、笔记本电脑、平板电脑、掌上电脑、智能手机、便携式数字播放器、智能手表以及智能手环等等，区块链节点服务器为根据共识机制确定的区块链网络中的其中一个服务器。应理解，由于区块链是一个去中心化的分布式数据库，所以每次处理数据都需要选出区块链网络中的其中一个服务器作为执行者来处理数据。而每次选取服务器的规则便是共识机制，本申请实施例中共识机制可以是工作量证明机制(proofofwork，pow)、股权证明机制(proofofstake，pos)、瑞波共识机制(rippleconsensus)以及授权股权证明机制(delegatedproofofstake，dpos)等，在此不作限定。本申请实施例中，客户端包括但不限于带通讯功能的设备、智能手机、平板电脑、笔记本电脑、台式电脑、便携式数字播放器、智能手环以及智能手表等。

本申请实施例中，包含有一个区块链公有链平台，平台为每个用户分配一个数字钱包和数字身份。另外，还包含一种应用于移动终端的数字钱包应用，所述数字钱包可以用来发送和接收数字化法币，并且具有提现功能，即将金额从个人的数字钱包转账至支付宝、微信等第三方平台或银行卡。

请参阅图1，图1是本申请实施例提供的一种数据处理方法的流程示意图，如图1所示，所述方法应用于服务器，所述方法包括：

s101、服务器接收捐款客户端发送的捐款请求，所述捐款请求包括捐款。

其中，可以理解的是，用户在募捐平台(也即区块链公有链平台)上浏览到相关的募捐信息是，其可以通过自己的手机、电脑等捐款客户端进行捐款，其所捐的款会被服务器接收。

其中，所述方法还包括：服务器接收募捐客户端发送的募捐请求，所述募捐请求包括募捐信息；所述服务器向区块链广播所述募捐信息。

其中，可以理解是，募捐人可以通过募捐客户端向服务器发送募捐请求，募捐人可以是受捐人或者其家属、亲朋好友等，所述募捐请求包括募捐理由、相关证明材料、募捐金额即金额使用预算等信息；服务器可以接收募捐人通过募捐客户端提出的募捐请求。

服务器将所述募捐信息广播至区块链，也即向区块链公有链平台发起募捐，之后募捐平台上每一个用户都可以浏览链上公开的被捐赠人的募捐信息，用户如果希望捐赠，可以直接通过自己的数字钱包充值，然后转账完成捐赠。

其中，可以理解是，在接收到募捐人的募捐请求之后，服务器需要审核相关信息，确保募捐请求的真实性，审核通过后向区块链公有链平台发起募捐。其中，审核相关信息可以是人工审核，也可以是募捐平台智能审核。

其中，可以理解的是，所述募捐信息包括预算医疗金额和/或募捐人或受捐人银行账户余额的证明信息，所述服务器向区块链广播所述募捐信息包括：所述服务器判断所述预算医疗金额和/或募捐人或受捐人银行账户余额与所述预设募捐总金额的差值是否小于预设阈值；若所述预算医疗金额和/或募捐人或受捐人银行账户余额与所述预设募捐总金额的差值小于预设阈值，则所述服务器向区块链广播所述募捐信息。

举例来说，在募捐请求的相关证明材料中包含医疗收费证明或者医院开出的预算医疗金额的证明材料，服务器自动的提取相关信息，然后用募捐金额减去医疗收费或者预算医疗金额得到一个差额，判断计算得到的差额是否小于预设值，若是，则审核通过。或者是，在募捐请求的相关证明材料中包含募捐人或者病人的银行账户流水证明材料，用募捐金额减去该银行账户余额得到一个差额，判断计算得到的差额是否小于预设值，若是，则审核通过。

s102、服务器根据预先制定的智能合约转移所述捐款。

其中，所述智能合约是预先制定的，是一种旨在以信息化方式传播、验证或执行合同的计算机协议，从用户角度来讲，智能合约可以包含一个自动担保账户，例如，当特定的条件满足时，程序就会释放和转移资金；智能合约也可以是沟通服务器或网络中各个节点(包括各个用户、账户、地址等)的智能化计算机协议，例如，当特定的条件满足时，智能合约程序就会沟通各个关联的节点释放和转移资金。从技术角度来讲，智能合约被认为是网络服务器，只是这些服务器并不是使用ip地址架设在互联网上，而是架设在区块链上，从而可以在其上面运行特定的合约程序。

其中，所述方法还可以包括：服务器判断转移至所述智能合约的捐款金额是否达到预设募捐总金额；若转移至所述智能合约的捐款金额达到所述预设募捐总金额，则停止向所述智能合约转移捐款。

其中，可以理解的是，所有捐款人的捐款将转移到所述智能合约中。所述智能合约中设置了募捐总金额，一旦转入所述智能合约的金额达到所述募捐总金额，则所述智能合约触发执行，并不再接受捐款。

s103、服务器根据所述智能合约按照预设规则处理所述捐款。

其中，可以理解的是，由于智能合约是是预先制定的，其制定时预设了处理转移至所述智能合约中的捐款。

其中，服务器根据所述智能合约按照预设规则处理所述捐款可以包括通过捐款人投票方式逐级释放捐款，首先向募捐人转账一定比例的捐款，然后等待募捐人的请款请求，根据请款请求中的捐款使用的相关证明信息生成投票请求，所有的捐款人可以投票决定是否再次向募捐人转账捐款。

可以看出，本申请实施例提供的技术方案中，接收捐款客户端发送的捐款请求，所述捐款请求包括捐款；根据预先制定的智能合约转移所述捐款；根据所述智能合约按照预设规则处理所述捐款。可见，实施本申请实施例，有利于防止募捐人作假和确保捐款的正确使用，杜绝利用爱心进行虚假捐款，将社会善款真正应用于社会上最需要帮助的人。

请参阅图2，图2是本申请实施例提供的另一种数据处理方法的流程示意图，如图2所示，所述方法应用于服务器，所述方法包括：

s201、服务器接收捐款客户端发送的捐款请求，所述捐款请求包括捐款。

其中，可以理解的是，用户在募捐平台(也即区块链公有链平台)上浏览到相关的募捐信息是，其可以通过自己的手机、电脑等捐款客户端进行捐款，其所捐的款会被服务器接收。

s202、所述服务器根据预先制定的智能合约转移所述捐款。

s203、所述服务器根据所述捐款确定捐款总金额。

s204、所述服务器根据智能合约按照所述捐款总金额的第一预设比例确定第一放款，并将所述第一放款转账至募捐人指定的数字钱包。

其中，需要指出的是，所述第一预设比例可以在智能合约执行之前进行调整。

举例来说，作为智能合约执行释放捐款的第一步，智能合约可以将把总捐款额的30％直接转账至募捐人指定的数字钱包，或者在执行释放捐款的第一步前，平台自动的或者依募捐人的申请调整比例至40％。比如，受捐病人的病情突然加重，近期所需医疗费用增多，募捐人可以根据情况向募捐平台发出申请调整第一次放款的比例。

其中，募捐人指定的数字钱包可以是受捐病人的数字钱包，也可以是募捐人的数字钱包，其可以对已转账至自己数字钱包的金额进行提现，获得现金，用于治疗开销。

s205、所述服务器接收募捐客户端发送的第一请款请求；所述第一请款请求包括所述第一放款使用的凭证信息。

其中，可以理解的是，当需要再次用款时，募捐人可以通过募捐客户端发送的第一请款请求，请求再次放款用于治疗开销。

其中，所述第一请款请求中包含针对第一放款资金的使用情况，受捐人在将第一放款资金使用后提交医院的发票等使用凭证至平台予以公示，所述第一请款请求触发智能合约执行释放捐款的第二步。

另外，需要说明的是，所述第一放款请求中还包括第二放款的比例。例如，所述其一请款请求第二次释放总捐款额的40％。

s206、所述服务器根据所述第一请款请求向捐款客户端发送第一投票请求。

其中，在根据所述第一请款请求向捐款客户端发送第一投票请求可以包括：判断所述第一凭证信息是否满足预置条件，若满足，则根据所述第一请款请求向捐款客户端发送第一投票请求。

举例来说，服务器自动提取出所诉第一凭证中第一放款资金的使用情况，判断第一放款资金中已使用的金额是否达到所述第一放款资金总额的80％，若是，则根据所述第一请款请求向捐款客户端发送第一投票请求。

其中，服务器接收到募捐人通过募捐客户端发送的第一请款请求后，根据其中第一放款使用的凭证信息确定投票的内容。所述投票内容包括：第一放款请求中募捐人请求释放的第二放款的比例、服务器根据第一放款使用的凭证信息自动评估的第二放款的比例、不同意释放捐款、撤销余下捐款等。

举例来说，所述投票内容可以为：

a、同意释放40％

b、不予释放

c、同意释放20％

d、撤销余下捐款

其中的“a、同意释放40％”是募捐人请求释放的第二放款比例，其中的“c、同意释放20％”是服务器根据第一放款使用的凭证信息自动评估的第二放款的比例。

服务器确定投票内容后，向捐款客户端发送投票请求，也即向每一个捐款人发送投票请求。其中，可以理解是，所述投票请求要求捐款人在规定时间内对捐款释放进行投票，做出其决策。若捐款人未在规定时间内进行投票，则视作弃权；规定时间到达后，智能合约将根据投票结果自动执行。

其中，可以理解的是，所述投票时间可以视情况是否紧急而规定投票的时间长度，当情况紧急，受捐病人急需用钱治疗，投票时间可以短一些；当情况不是很紧急，为了使更多捐款人可以参与投票，投票时间可以长一些。

s207、若所述第一投票请求的投票结果为撤销余下捐款，所述服务器则根据智能合约将所述余下捐款以捐款比例按照捐款来源原路退还。

其中，可以理解的是，若投票结果为撤销余下捐款，也即说明捐款人认为募捐存在虚假信息或者募捐所得捐款未用于治疗等不符合募捐本意的情况，因此不予向募捐人再放款。

其中，在将所述余下捐款以捐款比例按照捐款来源原路退还之后，所述方法还包括：将所述募捐人以及所述受捐人列入黑名单；冻结所述募捐人的数字钱包；并将所述虚假募捐信息在区块链上进行广播，提示用户予以监督。

另外，本申请实施例的相关术语或解释可参考上述实施例描述的内容。

可以看出，本申请实施例提供的技术方案中，通过捐款人投票的方式逐级释放捐款，当发现募捐存在虚假信息或者发放的第一放款未用于治疗时，可以根据投票结果撤销余下捐款，从而有利于防止募捐人作假继续骗取捐款，杜绝爱心捐款被无情滥用。

请参阅图3，图3是本申请实施例提供的另一种数据处理测方法的流程示意图，如图3所示，所述方法应用于服务器，所述方法包括：

s301、服务器接收募捐客户端发送的募捐请求；所述募捐请求包括募捐信息。

其中，可以理解是，募捐人可以通过募捐客户端向服务器发送募捐请求，募捐人可以是受捐人或者其家属、亲朋好友等，所述募捐请求包括募捐理由、相关证明材料、募捐金额即金额使用预算等信息；服务器可以接收募捐人通过募捐客户端提出的募捐请求。

s302、所述服务器向区块链广播所述募捐信息。

其中，可以理解是，服务器在接收到募捐人的募捐请求之后，需要审核相关信息，确保募捐请求的真实性，审核通过后向区块链广播，发起募捐。其中，审核相关信息可以是人工审核，也可以是募捐平台智能审核。

s303、所述服务器接收捐款客户端发送的捐款请求，所述捐款请求包括捐款。

其中，可以理解的是，用户在募捐平台(也即区块链公有链平台)上浏览到相关的募捐信息是，其可以通过自己的手机、电脑等捐款客户端进行捐款，其所捐的款会被服务器接收。

s304、所述服务器根据预先制定的智能合约转移所述捐款。

s305、所述服务器判断转移至所述智能合约的捐款金额是否达到预设募捐总金额。

其中，所述预设募捐总金额可以是募捐人发起的募捐金额，也可以是服务器根据所述募捐请求自动评估的募捐金额。

s306、所述服务器若转移至所述智能合约的捐款金额达到所述预设募捐总金额，则停止向所述智能合约转移捐款。

s307、所述服务器根据智能合约按照所述预设募捐总金额的第一预设比例确定第一放款，并将所述第一放款转账至募捐人指定的数字钱包。

s308、所述服务器接收所述募捐客户端发送的第一请款请求；所述第一请款请求包括所述第一放款使用的凭证信息。

其中，所述第一放款使用的凭证信息可以包括医院的发票等使用凭证、受捐病人的康复情况。

s309、所述服务器根据所述第一请款请求向捐款客户端发送第一投票请求。

其中，可以理解是，所述投票请求要求捐款人在规定时间内对捐款释放进行投票，做出其决策。若捐款人未在规定时间内进行投票，则视作弃权；规定时间到达后，智能合约将根据投票结果自动执行。

s310、若所述第一投票请求的投票结果为不同意放款，所述服务器等待接收捐款客户端发送的第二请款请求。

其中，可以理解的是，所述投票结果为不同意放款，可能是因为募捐人提供的医疗凭证信息表明实际医疗开销还远远未达到第一放款的金额，捐款人认为需要等第一捐款金额使用完后或者接近使用完后再释放第二放款。亦或者是，所述第一凭证信息中包括受捐病人的康复情况，当捐款人认为受捐病人的康复情况良好，后期可能不需要大量的医疗费时，暂时决定先不予放款，等待受捐病人需要时再次请求放款时，通过再一次投票决定放款。

s311、所述服务器接收所述募捐客户端发送的第二请款请求；所述第二请款请求包括所述第一放款使用的补充凭证信息。

其中，所述第一放款使用的补充凭证信息可以包括医院的发票等使用凭证、受捐病人的康复情况。

s312、所述服务器根据所述第二请款请求向捐款客户端发送第二投票请求。

其中，可以理解的是，所述第二投票请求的内容和所述第一投票请求的内容可以是一样的，也可以是根据第一放款使用的补充凭证信息重新设定的，本申请在此不作限定。

s313、所述服务器根据所述第二投票请求的投票结果处理捐款，直至所述捐款全部释放。

另外，本申请实施例的相关术语或解释可参考上述实施例描述的内容。

可以看出，本申请实施例提供的技术方案中，通过捐款人投票的方式逐级释放捐款，可以要求募捐人补充更多凭证来确定是否继续放款，从而有利于防止募捐人在实际医疗费用远低于放款金额的情况下继续骗取捐款，杜绝爱心捐款被无情滥用。

请参阅图4，图4是本申请实施例提供的另一种数据处理方法的流程示意图，如图4所示，所述方法应用于服务器，所述方法包括：

s401、服务器接收捐款客户端发送的捐款请求，所述捐款请求包括捐款。

s402、所述服务器根据预先制定的智能合约转移所述捐款。

s403、所述服务器根据所述捐款确定捐款总金额。

s404、所述服务器根据智能合约按照所述捐款总金额的第一预设比例确定第一放款，并将所述第一放款转账至募捐人指定的数字钱包。

s405、所述服务器接收募捐客户端发送的第一请款请求；所述第一请款请求包括所述第一放款使用的凭证信息。

s406、所述服务器根据所述第一请款请求向捐款客户端发送第一投票请求。

s407、若所述第一投票请求的投票结果为同意放款，所述服务器则按照所述捐款总金额的第二预设比例确实第二放款金额，并将所述第二放款转账至所述募捐人指定的数字钱包。

其中，可以理解的是，若所述第一投票请求的投票结果为同意放款，则说明捐款人认为受捐病人的情况属实，需要捐款用于治疗。

其中，需要指出的是，所述第二预设比例可以在合约执行第二放款之前进行调整。

s408、所述服务器接收所述募捐客户端发送的第三请款请求；所述第三请款请求包括所述第二放款使用的凭证信息。

s409、所述服务器根据所述第三请款请求向捐款客户端发送第三投票请求。

s410、所述服务器根据所述第三投票请求的投票结果处理捐款，直至所述捐款全部释放。

另外，本申请实施例的相关术语或解释可参考上述实施例描述的内容。

可以看出，本申请实施例提供的技术方案中，通过捐款人投票方式逐级释放捐款，有利于防止募捐人作假和确保捐款的正确使用，杜绝利用爱心进行虚假捐款，将社会善款真正应用于社会上最需要帮助的人。

上述主要从方法侧执行过程的角度对本申请实施例的方案进行了介绍。可以理解的是，服务器为了实现上述功能，其包含了执行各个功能相应的硬件结构和/或软件模块。本领域技术人员应该很容易意识到，结合本文中所提供的实施例描述的各示例的模块及算法步骤，本申请能够以硬件或硬件和计算机软件的结合形式来实现。某个功能究竟以硬件还是计算机软件驱动硬件的方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。

本申请实施例可以根据上述方法示例对服务器进行功能模块的划分，例如，可以对应各个功能划分各个功能模块，也可以将两个或两个以上的功能集成在一个处理模块中。上述集成的模块既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。需要说明的是，本申请实施例中对模块的划分是示意性的，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式。

图5是本申请实施例中所涉及的一种数据处理装置的功能模块组成框图。所述数据处理装置应用于服务器，且所述数据处理装置500包括以下逻辑模块：

接收模块501，用于接收捐款客户端发送的捐款请求，所述捐款请求包括捐款；

转移模块502，用于根据预先制定的智能合约转移所述接收到的捐款；

处理模块503，用于根据所述智能合约按照预设规则处理所述捐款。

可选地，处理模块503包括：

确定子模块，用于根据所述捐款确定捐款总金额；

处理子模块，用于按照所述捐款总金额的第一预设比例确定第一放款，并将所述第一放款转账至募捐人指定的数字钱包；

接收子模块，用于接收募捐客户端发送的第一请款请求，所述第一请款请求包括所述第一放款使用的凭证信息；

发送子模块，用于根据所述第一请款请求向所述捐款客户端发送第一投票请求；

所述处理子模块，还用于若所述第一投票请求的投票结果为撤销余下捐款，则将所述余下捐款以捐款比例按照捐款来源原路退还；

所述处理子模块，还用于若所述第一投票请求的投票结果为同意放款，则按照所述捐款总金额的第二预设比例确定第二放款，并将所述第二放款转账至所述募捐人指定的数字钱包。

可选地，若所述第一投票请求的投票结果为不同意放款，所述接收子模块，还用于接收所述募捐客户端发送的第二请款请求，所述第二请款请求包括所述第一放款使用的补充凭证信息；所述发送子模块，还用于根据所述第二请款请求向所述捐款客户端发送第二投票请求；所述处理子模块，还用于根据所述第二投票请求的投票结果处理所述捐款。

可选地，在将所述第二放款转账至所述募捐人指定的数字钱包之后，所述接收子模块，还用于接收所述募捐客户端发送的第三请款请求，所述第三请款请求包括所述第二放款使用的凭证信息；所述发送子模块，还用于根据所述第三请款请求向所诉捐款客户端发送第三投票请求；所述处理子模块，还用于根据所述第三投票请求的投票结果处理所述捐款。

可选地，所述数据处理装置500还包括：

判断模块，用于判断转移至所述智能合约的捐款金额是否达到预设募捐总金额；

停止模块，用于若转移至所述智能合约的捐款金额达到所述预设募捐总金额，则停止向所述智能合约转移捐款。

可选地，所述数据处理装置500还包括：

所述接收模块，还用于接收募捐客户端发送的募捐请求，所述募捐请求包括募捐信息；

广播模块，用于向区块链广播所述募捐信息。

可选地，所述募捐信息包括预算医疗金额和/或募捐人或受捐人银行账户余额的证明信息，所述广播模块包括：

判断子模块，用于判断所述预算医疗金额和/或募捐人或受捐人银行账户余额与所述预设募捐总金额的差值是否小于预设阈值；

广播子模块，用于若所述预算医疗金额和/或募捐人或受捐人银行账户余额与所述预设募捐总金额的差值小于预设阈值，则向区块链广播所述募捐信息。

其中，需要指出的是，本实施例所述的上述逻辑单元可执行方法实施例中所述的方法。

可以看出，本申请实施例提供的服务器，接收捐款客户端发送的捐款请求，所述捐款请求包括捐款；根据预先制定的智能合约转移所述捐款；根据所述智能合约按照预设规则处理所述捐款。可见，实施本申请实施例，有利于防止募捐人作假和确保捐款的正确使用，杜绝利用爱心进行虚假捐款，将社会善款真正应用于社会上最需要帮助的人。

与上述图5所示的实施例一致的，请参阅图6，图6是本申请实施例提供的一种服务器600的结构示意图，如图所示，所述服务器600包括应用处理器610、存储器620、通信接口630以及一个或多个程序621，其中，所述一个或多个程序621被存储在上述存储器620中，并且被配置由上述应用处理器610执行，当所述一个或多个程序621被运行时，所述处理器610执行以下操作：接收捐款客户端发送的捐款请求，所述捐款请求包括捐款；根据预先制定的智能合约转移所述捐款；根据所述智能合约按照预设规则处理所述捐款。

可选地，所述处理器610还执行以下操作：根据所述捐款确定捐款总金额；按照所述捐款总金额的第一预设比例确定第一放款，并将所述第一放款转账至募捐人指定的数字钱包；接收募捐客户端发送的第一请款请求，所述第一请款请求包括所述第一放款使用的凭证信息；根据所述第一请款请求向所述捐款客户端发送第一投票请求；若所述第一投票请求的投票结果为撤销余下捐款，则将所述余下捐款以捐款比例按照捐款来源原路退还；若所述第一投票请求的投票结果为同意放款，则按照所述捐款总金额的第二预设比例确定第二放款，并将所述第二放款转账至所述募捐人指定的数字钱包。

可选地，若所述第一投票请求的投票结果为不同意放款，所述处理器610还执行以下操作：接收所述募捐客户端发送的第二请款请求，所述第二请款请求包括所述第一放款使用的补充凭证信息；根据所述第二请款请求向所述捐款客户端发送第二投票请求；根据所述第二投票请求的投票结果处理所述捐款。

可选地，在将所述第二放款转账至所述募捐人指定的数字钱包之后，所述处理器610还执行以下操作：接收所述募捐客户端发送的第三请款请求，所述第三请款请求包括所述第二放款使用的凭证信息；根据所述第三请款请求向所诉捐款客户端发送第三投票请求；根据所述第三投票请求的投票结果处理所述捐款。

可选地，所述处理器610还执行以下操作：判断转移至所述智能合约的捐款金额是否达到预设募捐总金额；若转移至所述智能合约的捐款金额达到所述预设募捐总金额，则停止向所述智能合约转移捐款。

可选地，所述处理器610还执行以下操作：接收募捐客户端发送的募捐请求，所述募捐请求包括募捐信息；向区块链广播所述募捐信息。

可选地，所述募捐信息包括预算医疗金额和/或募捐人或受捐人银行账户余额的证明信息，所述处理器610还执行以下操作：判断所述预算医疗金额和/或募捐人或受捐人银行账户余额与所述预设募捐总金额的差值是否小于预设阈值；若所述预算医疗金额和/或募捐人或受捐人银行账户余额与所述预设募捐总金额的差值小于预设阈值，则向区块链广播所述募捐信息。

可以看出，本申请实施例提供的服务器，接收捐款客户端发送的捐款请求，所述捐款请求包括捐款；根据预先制定的智能合约转移所述捐款；根据所述智能合约按照预设规则处理所述捐款。可见，实施本申请实施例，有利于防止募捐人作假和确保捐款的正确使用，杜绝利用爱心进行虚假捐款，将社会善款真正应用于社会上最需要帮助的人。

本申请实施例还提供一种计算机存储介质，其中，该计算机存储介质存储用于电子数据交换的计算机程序，该计算机程序使得计算机执行如上述方法实施例中记载的任一方法的部分或全部步骤，上述计算机包括电子设备。

本申请实施例还提供一种计算机程序产品，上述计算机程序产品包括存储了计算机程序的非瞬时性计算机可读存储介质，上述计算机程序可操作来使计算机执行如上述方法实施例中记载的任一方法的部分或全部步骤。该计算机程序产品可以为一个软件安装包，上述计算机包括电子设备。

需要说明的是，对于前述的各方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本申请并不受所描述的动作顺序的限制，因为依据本申请，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作和模块并不一定是本申请所必须的。

在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其他实施例的相关描述。

在本申请所提供的几个实施例中，应该理解到，所揭露的装置，可通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如上述模块的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个模块或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或模块的间接耦合或通信连接，可以是电性或其它的形式。

上述作为分离部件说明的模块可以是或者也可以不是物理上分开的，作为模块显示的部件可以是或者也可以不是物理模块，即可以位于一个地方，或者也可以分布到多个网络模块上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。

另外，在本申请各个实施例中的各功能模块可以集成在一个处理模块中，也可以是各个模块单独物理存在，也可以两个或两个以上模块集成在一个模块中。上述集成的模块既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。

上述集成的模块如果以软件功能模块的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储器中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储器中，包括若干指令用以使得一台计算机设备(可为个人计算机、服务器或者网络设备等)执行本申请各个实施例上述方法的全部或部分步骤。而前述的存储器包括：u盘、只读存储器(rom，reap-onlymemory)、随机存取存储器(ram，ranpomaccessmemory)、移动硬盘、磁碟或者光盘等各种可以存储程序代码的介质。

本领域普通技术人员可以理解上述实施例的各种方法中的全部或部分步骤是可以通过程序来指令相关的硬件来完成，该程序可以存储于一计算机可读存储器中，存储器可以包括：闪存盘、只读存储器(英文：reap-onlymemory，简称：rom)、随机存取器(英文：ranpomaccessmemory，简称：ram)、磁盘或光盘等。

以上对本申请实施例进行了详细介绍，本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的一般技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本申请的限制。