一种基于区块链的可信打赏业务处理方法、装置及设备与流程

1.本说明书涉及区块链技术领域，尤其涉及一种基于区块链的可信打赏业务处理方法、装置及设备。


背景技术：

2.现实生活中，违规收送礼品礼金进行不法利益输送的形式不断翻新，并且隐蔽性越来越好。从收送实体物品逐渐转向通过打赏平台的方式实现利益输送。在通过打赏平台进行利益输送方式中，各参与方甚至并不需要见面，只需要在打赏平台进行正常的打赏，具有极强的隐蔽性。
3.现有技术中，很多打赏平台的服务器内容不公开且易于篡改，无法对打赏平台中的打赏事件进行有效监测，由此，在打赏的过程中很难发现含有不法利益输送性质的可疑打赏事件。


技术实现要素：

4.本说明书一个或多个实施例提供了一种基于区块链的可信打赏业务处理方法、装置及设备，用于解决如下技术问题：
5.很多打赏平台的服务器内容不公开且易于篡改，无法对打赏平台中的打赏事件进行有效监测，由此，在打赏的过程中很难发现含有不法利益输送性质的可疑打赏事件。
6.本说明书一个或多个实施例采用下述技术方案：
7.本说明书一个或多个实施例提供一种基于区块链的可信打赏业务处理方法，应用于区块链服务器，所述方法包括：
8.从打赏平台的打赏服务器获取用户的实人认证信息并上链；
9.在所述打赏平台上有打赏事件发生后，从所述打赏服务器获取所述打赏事件的记录信息并上链，所述记录信息指示了对应的打赏用户、被打赏用户；
10.运行异常打赏监测模型，根据已上链的信息，对所述打赏平台上的一个或者多个打赏事件进行巡检，以判定是否存在可疑打赏事件；
11.若是，则将所述可疑打赏事件上报至监管端进行异常确认。
12.本说明书一个或多个实施例提供一种基于区块链的可信打赏业务处理装置，应用于区块链服务器，所述装置包括：
13.第一获取单元，从打赏平台的打赏服务器获取用户的实人认证信息并上链；
14.第二获取单元，在所述打赏平台上有打赏事件发生后，从所述打赏服务器获取所述打赏事件的记录信息并上链，所述记录信息指示了对应的打赏用户、被打赏用户；
15.巡检单元，运行异常打赏监测模型，根据已上链的信息，对所述打赏平台上的一个或者多个打赏事件进行巡检，以判定是否存在可疑打赏事件；
16.上报单元，若是，则将所述可疑打赏事件上报至监管端进行异常确认。
17.本说明书一个或多个实施例提供一种基于区块链的可信打赏业务处理设备，应用
于区块链服务器，包括：
18.至少一个处理器；以及，
19.与所述至少一个处理器通信连接的存储器；其中，
20.所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够：
21.从打赏平台的打赏服务器获取用户的实人认证信息并上链；
22.在所述打赏平台上有打赏事件发生后，从所述打赏服务器获取所述打赏事件的记录信息并上链，所述记录信息指示了对应的打赏用户、被打赏用户；
23.运行异常打赏监测模型，根据已上链的信息，对所述打赏平台上的一个或者多个打赏事件进行巡检，以判定是否存在可疑打赏事件；
24.若是，则将所述可疑打赏事件上报至监管端进行异常确认。
25.本说明书一个或多个实施例提供的一种非易失性计算机存储介质，存储有计算机可执行指令，所述计算机可执行指令设置为：
26.从打赏平台的打赏服务器获取用户的实人认证信息并上链；
27.在所述打赏平台上有打赏事件发生后，从所述打赏服务器获取所述打赏事件的记录信息并上链，所述记录信息指示了对应的打赏用户、被打赏用户；
28.运行异常打赏监测模型，根据已上链的信息，对所述打赏平台上的一个或者多个打赏事件进行巡检，以判定是否存在可疑打赏事件；
29.若是，则将所述可疑打赏事件上报至监管端进行异常确认。
30.本说明书实施例采用的上述至少一个技术方案能够达到以下有益效果：本说明书实施例通过将获取的用户的实人认证信息与打赏事件的记录信息上链，由于上链的信息具备不可篡改的特性，后续根据上链的信息对打赏平台的打赏事件进行巡检时，使得巡检的结果具备更精准可靠。同时，本说明书实施例通过运行异常打赏监测模型判定打赏事件是否可疑，可以更及时有效地对打赏平台的打赏事件进行全面监测。此外，本说明书实施例在判断存在可以打赏事件时，可以快速的将可疑打赏事件上报至监管端，尽可能地加快可疑打赏事件处理速度。
附图说明
31.为了更清楚地说明本说明书实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本说明书中记载的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。在附图中：
32.图1为本说明书一个或多个实施例提供的一种基于区块链的可信打赏业务处理方法的流程示意图；
33.图2为本说明书一个或多个实施例提供的一种基于区块链的可信打赏方法的流程示意图；
34.图3为本说明书一个或多个实施例提供的一种基于区块链的可信打赏业务处理装置的结构示意图；
35.图4为本说明书一个或多个实施例提供的一种基于区块链的可信打赏业务处理设
备的结构示意图。
具体实施方式
36.本说明书实施例提供一种基于区块链的可信打赏业务处理方法、装置及设备。
37.现实生活中，违规收送礼品礼金进行不法利益输送的形式不断翻新，并且隐蔽性越来越好。从收送实体物品逐渐转向通过打赏平台的方式实现利益输送。在通过打赏平台进行利益输送方式中，各参与方甚至并不需要见面，只需要在打赏平台进行正常的打赏，具有极强的隐蔽性。若无法对打赏事件进行有效监控，将很难在打赏的过程中发现含有不法利益输送性质的可疑打赏事件。
38.利益输送行为包括行贿受贿与违法利益合法化转换等违法行为，犯罪分子借由打赏平台，使得打赏用户和被打赏用户之间产生利益输送关系，进而完成相应的违法行为。其中，行贿受贿是指为了谋取不正当利益，通过打赏平台实施给予国家工作人员、集体经济组织工作人员或者其他从事公务的人员以财物的行为，违法利益合法化转换是指将犯罪或其他非法违法行为所获得的违法收入，通过打赏平台打赏虚拟礼物，使其在形式上合法化的行为。
39.为了更好的说明本说明书实施例的方案，下面主要以打赏平台进行行贿受贿的角度进行详细说明：
40.通过打赏平台进行行贿受贿，是极有可能发生在现实生活中的，比如，用户a身兼要职，并在打赏平台a的直播间进行直播活动，开发商b在该打赏平台的直播间观看直播，并向用户a打赏大量的虚拟礼物，此过程极大可能是开发商b行贿于用户a。a在直播完成后，可以将收到虚拟礼物通过打赏平台获取现金，进而完成此次的行贿受贿过程。由此可以看出，打赏平台是可以成行贿受贿工具的，这期间并不需要过于复杂的操作，即可完成一次瞒过监管部门的行贿受贿过程。
41.上述过程中，相关的监管部门无法对打赏平台的每个直播间进行实时的监控，也就很难对于上述的行贿受贿行为有效察觉。更多情况下，监管部门只是被动的接收举报，再根据举报对打赏平台的行贿受贿行为进行检测，如此可以看出，打赏平台可能已经成为不法分子进行行贿受贿的优选方向，若不能采取更好的措施进行阻止，很可能发生更多起行贿受贿案件。
42.同样的，通过打赏平台进行行贿受贿行为也不利于打赏平台的口碑，打赏平台无法及时监管到发生的行贿受贿行为，并对所发生的行贿受贿行为进行上报，打赏平台也可能会承担相应的责任。
43.由此可以看出，不管是为了维护社会风气，还是为了保护打赏平台自身口碑，都需要加强打赏平台对于打赏事件的监管工作，避免打赏平台出现行贿受贿的打赏事件，坚决抵制行贿受贿这种不良的社会风气。
44.为了使本技术领域的人员更好地理解本说明书中的技术方案，下面将结合本说明书实施例中的附图，对本说明书实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本说明书一部分实施例，而不是全部的实施例。基于本说明书实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都应当属于本说明书保护的范围。
45.图1为本说明书一个或多个实施例提供的一种基于区块链的可信打赏业务处理方法的流程示意图，该方法流程可以应用于打赏公链服务器，打赏公链服务器可以与各类打赏平台的直播软件相结合，以便用于防止用户通过直播软件中直播间打赏的方式进行行贿受贿行为，维护打赏平台的良好风气。流程中的某些输入参数或者中间结果允许人工干预调节，以帮助提高准确性。
46.需要说明的是，打赏公链服务器可以为一种具备区块链性质的服务器，上传到打赏公链服务器的数据无法进行篡改。
47.本说明书实施例的方法流程步骤如下：
48.s102：从打赏平台的打赏服务器获取用户的实人认证信息并上链。
49.本说明书实施例中的用户可以包括直播间的观众与直播间的主播，直播间的观众可以对主播执行打赏事件。用户需要在指定的打赏客户端输入该用户的实人认证信息，此时所提及的打赏客户端为需要获得认证的直播软件，后续打赏客户端所发生的打赏事件才可以上链，并被监管端监管。其中，此时提到的打赏客户端从属于打赏平台，该打赏客户端被用户下载安装后由主播进行直播或由观众观看主播的表演。
50.用户在打赏客户端执行打赏事件前，是需要进行身份认证的。在不法分子通过打赏实现行贿受贿时，相关的身份信息可以追查实施打赏者与接收打赏者的真实身份。
51.在现实生活中，大都采用实名认证的方式对用户进行身份认证，而实名认证是对用户资料真实性进行的一种验证审核，有助于建立完善可靠的互联网信用基础。但近年来，出现了很多不法分子，通过身份黑市交易，将个人的网络身份绑定到一个完全不属于本人的现实身份上，所以，实名认证已经不能准确的识别用户的真实身份。这就需要安全性和精准度更好的认证方式。基于此，本说明书实施例可以通过实人认证的方式对用户进行身份认证。
52.其中，实人认证在对用户进行身份认证时，可以依托证件光学字符识别(optical character recognition，ocr)识别技术、活体检测、人脸比对等生物识别技术，对用户身份信息真实性进行核验的服务，可以更好的验证用户为真人且为本人。
53.将用户的实人认证信息上链，是指通过打赏服务器将用户的实人认证信息上传至打赏公链服务器，打赏公链服务器用于记录所有用户的实人认证信息，方便后续针对打赏事件识别出行贿受贿行为。
54.s104：在打赏平台上有打赏事件发生后，从打赏服务器获取打赏事件的记录信息并上链，记录信息指示了对应的打赏用户与被打赏用户。
55.打赏用户可以为用户中发生打赏事件的观众，被打赏用户可以为打赏平台中直播间的被打赏主播。在打赏平台上的直播间内有观众向主播发起打赏事件后，从打赏服务器获取该打赏事件的记录信息，并将该打赏事件的记录信息上传至打赏公链服务器，该打赏事件的记录信息具有不可篡改的特性，方便后续的查询验证。
56.若需要查询某个打赏事件，打赏公链服务器可以接收发自证据采集端的携带用户标识的查询请求，此处的证据采集端可以为查询端，通过监管部门所执行触发的查询请求。然后，根据用户标识，在打赏公链服务器上查询对应于是否存在对应的打赏事件的记录信息，此处的用户可以为打赏用户和/或被打赏用户。最后，打赏公链服务器向证据采集端返回查询结果，以作为证据。
57.进一步的，由于借助打赏平台实施行贿受贿的行为，大都存在较强的隐蔽性，监管部门无法实时监测到每个打赏平台的直播间，若想避免不法分子借助打赏平台实施行贿受贿的行为，可以通过预先训练异常打赏监测模型，实时对各个打赏平台中的直播间进行监控，以此来解决不易实时监控打赏平台的难题。下面可以通过执行下述的s106来完成相应的操作。
58.s106：运行异常打赏监测模型，根据已上链的信息，对打赏平台上的一个或者多个打赏事件进行巡检，以判定是否存在可疑打赏事件。
59.打赏公链服务器运行的打赏监测模型可以是基于神经网络训练的监测模型，该模型是通过大量有关打赏事件的数据训练得到，可以准确的对打赏事件进行巡检。
60.此时提到的已上链信息可以为用户的实人认证信息，本说明书实施例可以通过打赏用户与被打赏用户的关系，对打赏平台上的打赏事件进行巡检，下面对于不同的情况进行举例说明：
61.例如，打赏用户与被打赏用户之间存在业务往来，此时打赏用户可能通过打赏事件向被打赏者行贿，从而获取被打赏者的帮助，以便在业务上达到某种目的，异常打赏监测模型可以将此种情况暂定为可疑打赏事件，之后上报给监管部门，由监管部门进一步进行甄别。
62.再例如，打赏用户与被打赏用户存在上下级关系，此时打赏用户可能通过打赏事件向被打赏者行贿，从而获取被打赏者的帮助，以达到升职加薪的目的，异常打赏监测模型可以将此种情况暂定为可疑打赏事件，之后上报给监管部门，由监管部门进一步进行甄别。或者，打赏用户的亲属与被打赏者存在上下级，此时打赏用户可能通过打赏事件向被打赏者行贿，从而获取被打赏者的帮助，以达到帮助亲属升职加薪的目的，异常打赏监测模型也可以将此种情况暂定为可疑打赏事件。
63.在说明书实施例可以通过智能合约，每当满足设定条件时运行异常打赏监测模型，这里的设定条件即为上面的提到的各种情况，即已上链信息为用户的实人认证信息，然后通过异常打赏监测模型的运行，对已上链的一个或者多个打赏事件的记录信息进行遍历和检测。对已上链的一个或者多个打赏事件的记录信息进行遍历，可以是通过异常打赏监测模型在所有的打赏事件的记录信息中找出查找出可疑的一个或多个打赏事件的记录信息。
64.此外，已上链信息还可以为，已经认定含有行贿受贿性质的打赏事件，后续可以通过异常打赏监测模型提取行贿受贿打赏事件的特征，并基于行贿受贿打赏事件的特征对打赏平台的打赏事件进行巡检，即可以对打赏平台的打赏事件进行特征分析，若含有行贿受贿打赏事件的特征，就可以认定此次打赏事件可能存在行贿受贿。
65.在本说明书实施例中，打赏事件的记录信息还可以指示对应的打赏事件的时间和打赏礼物，对已上链的一个或者多个打赏事件的记录信息进行检测时，具体可以为，根据打赏事件的记录信息，判定同一打赏用户或者同一被打赏用户对应的多个打赏事件是否发生过于密集和/或打赏礼物价值过高，以此判定是否存在可疑打赏事件。比如，在某个打赏平台的某个直播间内，打赏用户a向被打赏用户b一次或多次打赏了大量的虚拟礼物，即可以认定该直播间可能存在行贿受贿行为，另外，若同一个直播间内多个打赏用户在短时间内向被打赏用户打赏大量的虚拟礼物也可以认定该直播间可能存在行贿受贿行为。在认定该
直播间可能存在行贿受贿行为后，可以将该直播间暂定为可疑直播间，并上报给监管部门，由监管部门进一步进行判定。
66.本说明书实施例在判定同一打赏用户或者同一被打赏用户对应的多个打赏事件是否发生过于密集和/或打赏礼物价值过高之前，还可以根据设定的风险数量阈值，确定所要检测的打赏事件所属的直播场次的观众用户数量过少，若观众用户数量过少，还发生了过于密集和/或打赏礼物价值过高，存在行贿受贿行为的几率更高，风险数量阈值可以设定为10人。比如，在某个打赏平台的某个直播间内，只有3个观众，而这3个观众都发起了大量的礼物打赏，或者，其中1个观众发起了大量的礼物打赏，这几种情况都是可能存在行贿受贿行为的，可以将该直播间暂定为可疑直播间，并上报给监管部门，由监管部门进一步进行判定。
67.此外，本说明书实施例在判定同一打赏用户或者同一被打赏用户对应的多个打赏事件是否发生过于密集和/或打赏礼物价值过高之前，还可以识别直播间内主播的直播的内容，确定该主播的直播内容是否为正常的直播内容，若该主播的直播内容并非正常的直播内容，还发生了过于密集和/或打赏礼物价值过高，存在行贿受贿行为的几率比较高，是否为正常的直播内容可以根据大多数正常主播的直播内容进行鉴别，若是存在行贿受贿，大都不会进行正常的直播，只是开个直播间，接收打赏，由于只是为了进行行贿受贿，该主播开放直播的时间也可能比较短。比如，在某个打赏平台的某个直播间内，主播并未进行任何的直播内容，并且在该直播间的打赏事件发生过于密集和/或打赏礼物价值过高，即可以认定该直播间可能存在行贿受贿行为。
68.进一步的，除了上述的巡检方式外，还应该注意打赏礼物的多次流向问题，即直播间发生行贿受贿行为时，首次发生的礼物打赏是正常的，后续过程中，接受打赏的主播对该笔打赏进行转移，转移时可以分批次进行。针对上述问题，本说明书实施例可以通过下述方案对行贿受贿行为进行检测：
69.确定打赏事件的被打赏用户与打赏礼物，将该被打赏用户作为第一被打赏用户，然后获取该打赏礼物在由第一被打赏用户获得之后的二次流向信息并上链，以此将该打赏礼物的二次流向信息进行记录，方便后续的追查。
70.对已上链的一个或者多个打赏事件的记录信息进行检测时，可以先确定二次流向信息指示了打赏礼物从第一被打赏用户流向了第二被打赏用户，之后，分别确定第一被打赏用户和第二被打赏用户在打赏平台上的人气度，然后判定是否第一被打赏用户的人气度大于第二被打赏用户，且两者之间的差距程度大于设定程度，若是，可以判定打赏事件存在异常。
71.在上述过程，第一被打赏用户的人气度大于第二被打赏用户，可以说明第一被打赏用户是一个人气度较高的主播，该主播在收到大量打赏时，是属于正常的打赏事件。如果第一被打赏用户将接受的打赏转发给人气度较低的第二被打赏用户时，该行为就存在一定的可疑，这时，若第一被打赏用户与第二被打赏用户的人气度差距程度较大时，可以说明第二被打赏用户的人气度比较低，第一被打赏用户向第二被打赏用户转发打赏礼物的行为非常可疑，可以判定该打赏事件存在异常。同时，也可以单独判定第二被打赏用户的人气度，若第二被打赏用户的人气度低于预设程度时，可以说明第二被打赏用户并非有人气的主播，也不太可能是打赏平台需要扶持的主播，而此时，第一被打赏用户又向第二被打赏用户
转发大量礼物，可以判定该打赏事件存在异常。
72.进一步的，对已上链的一个或者多个打赏事件的记录信息进行检测时，可以根据打赏事件的记录信息，确定对应的打赏事件的打赏用户和被打赏用户，其中，上链的实人认证信息可以包括对应的用户的工作信息。之后，可以根据实人认证信息中用户的工作信息，以及预先构建的工作关系模型，预测打赏用户和被打赏用户之间的工作是否存在利益输送风险关系。该利益输送风险关系对应行贿受贿关系与违法利益合法化转换关系等涉及打赏平台的违法关系。
73.本说明书实施例的工作关系模型可以确定出各用户之间的各种工作关系，比如，打赏用户工作于公司a，被打赏用户工作于公司a，工作关系模型可以确定出打赏用户与被打赏用户处于同一个公司；再比如，打赏用户工作于公司a，被打赏用户工作于公司a下面的子公司b，工作关系模型也可以确定出打赏用户与被打赏用户处于同一个公司，处于同一个公司是可能存在行贿受贿的。再比如，打赏用户工作于公司a，被打赏用户工作于与公司a存在合作关系的公司b，工作关系模型也可以确定出打赏用户与被打赏用户所处的公司存在关联，而存在关联的公司也是可能存在行贿受贿的。
74.s108：若是，则将可疑打赏事件上报至监管端进行异常确认。
75.本说明书实施例在对已上链的一个或者多个打赏事件的记录信息进行遍历和检测之前，可以先获取监管部门提供的风险用户的信息，再根据该风险用户的信息，查询出对应于该风险用户的一个或者多个打赏事件的记录信息，用于后续对已上链的一个或者多个打赏事件的记录信息进行遍历和检测。之后若判定遍历和检测的打赏事件中存在可疑打赏事件，则确定可疑打赏事件所属的直播间的同场观众用户，并根据该直播间的同场观众用户，确定包括风险用户的在内的风险用户关系网。最后，可以将风险用户关系网与可以打赏事件一同上报至监管端进行异常确认。
76.需要说明的是，若直播间存在行贿受贿的情况，很大可能是整个直播间的用户都参与了该次行贿受贿，即使有些用户没有给主播打赏礼物，也可能是整个行贿受贿的参与者。确定包括风险用户在内的风险用户关系网，后续可以对参与行贿受贿活动的所有人员进行调查，不遗漏任何一个违法犯罪的人员。
77.若判定遍历和检测的打赏事件中不存在可疑打赏事件，本说明书实施例继续对后续的打赏事件进行巡检，以更好的维护整个打赏平台的合法运作，杜绝打赏平台中的不合法打赏事件。
78.利益输送的违法行为指违法利益合法化转换时，本说明书实施例为了防止不法分子通过打赏平台实现违法利益合法化转换，比如，用户a通过非法手段获利大量不合法财产，并且，用户a是无法将这些钱财正常使用的，用户a计划与某个打赏平台的主播合作，通过向该主播打赏虚拟礼物，然后该主播再将收获的礼物从打赏平台换取报酬，此时得到的报酬为通过直播收获的正常财产，这样就完成了将不合法财产的转化。本说明书实施例可以针对此种情况，采用上面提到的方案进行巡检，以判定是否存在可疑打赏事件。若是，则将该可疑打赏事件上报至监管端进行异常确认。
79.本说明书实施例主要针对利用打赏平台实现利益输送的违法行为，并不局限于行贿受贿与违法利益合法化转换，还可以包括资产转移，比如，公司c存在大量的贷款并未归还，同时，公司c在打赏平台c的直播间c内，向该直播间的主播d打赏大量的虚拟礼物，以致
公司c的资金短缺，被迫清空结算，而未归还的贷款也无力偿还，在这个过程中，公司c将大量资产转移到了主播d，该主播很有可能是在帮助公司c实现资产的恶意转移，最终非法获利。本说明书实施例可以针对此种情况，同样采用上面提到的方案进行巡检，以判定是否存在可疑打赏事件。若是，则将该可疑打赏事件上报至监管端进行异常确认。
80.现有大多数的打赏平台，存在演变成行贿受贿工具的趋势。若不法分子借助直播的方式，行贿者通过向被行贿者打赏或者刷礼物，完成行贿受贿的整个过程。从目前的打赏机制上很难查，因为各直播的服务器内容不公开，而且，现在打赏平台中的打赏内容也容易被篡改。所以，需要对打赏平台进行调整，实现可信打赏，让直播打赏做到透明可信，杜绝行贿受贿和违法利益合法化转换。
81.本说明书实施例提供了一种基于区块链的可信打赏方法，具体流程示意图可以参见图2，本方法分为4个部分：打赏客户端、打赏服务器、打赏公链服务器与查询端(比如，证据监控端、采集端等)。其中：
82.打赏客户端用于负责主播接收打赏和观众打赏主播；打赏服务器为用户记录打赏者身份、金额、时间和设备信息；打赏公链服务器用于把打赏的记录都上链，并且开始巡检，并自动发现可以打赏；查询端用于通过平台用户名(id)或身份证查询到这个人的打赏记录，是为了留作警方查证
83.1：打赏客户端向打赏服务器发送观众和主播实人认证；1.1：打赏服务器将用户实人认证信息和id发送至打赏公链服务器，完成上链操作；2：打赏客户端的观众给指定主播打赏时，将对应的打赏记录发送至打赏服务器；2.1：打赏服务器将打赏人、被打赏人、打赏的金额、打赏时间和打赏的位置发送至打赏公链服务器，完成上链操作；3：若发生可以打赏，查询端用打赏人或被打赏人身份证或者名字向打赏公链服务器发起查询；3.1：打赏服务器遍历被查询的打赏和被打赏记录；3.2：打赏服务器向查询端返回结果，留作证据。
84.在打赏公链服务器还可以进行自动巡检，具体为：3.3：根据公安提供的线索和研发发现存在的规则，发布巡检定制的模型，模型规则包括：1.短时间大量。2.单人或少数人大量打赏等；3.4：定时通过智能合约，加载发布的监测模型，然后遍历交易，因为是在区块链上，所以任何节点数据遍历都可以；3.5：根据配置的模型自动查询可疑打赏，然后上报，方便监督或者警察确认。
85.本说明书实施例提供的上述方案中，具有以下特征：
86.1、可以主动识别出该打赏是否是行贿受贿和违法利益合法化转换，还是真的基于直播内容的打赏；
87.2、可以对打赏人或者被打赏人随时查出可信打赏记录；
88.3、可以从警方提供的线索找出这两个人是否有过打赏行贿的记录；
89.4、如果有不法打赏，可以从打赏和被打赏的路径分析出风险用户关系网。
90.5、打赏事件的记录信息不可篡改。
91.图3为本说明书一个或多个实施例提供的一种基于区块链的可信打赏业务处理装置的结构示意图，装置包括：第一获取单元302、第二获取单元304、巡检单元306与上报单元308。
92.第一获取单元302从打赏平台的打赏服务器获取用户的实人认证信息并上链；
93.第二获取单元306在打赏平台上有打赏事件发生后，从打赏服务器获取打赏事件
的记录信息并上链，记录信息指示了对应的打赏用户、被打赏用户；
94.巡检单元306运行异常打赏监测模型，根据已上链的信息，对打赏平台上的一个或者多个打赏事件进行巡检，以判定是否存在可疑打赏事件；
95.上报单元308若是，则将可疑打赏事件上报至监管端进行异常确认。
96.进一步的，装置还包括：
97.接收单元，接收发自证据采集端的携带用户标识的查询请求；
98.第一查询单元，根据用户标识，在链上查询对应于是否存在对应的打赏事件的记录信息；
99.证据单元，向证据采集端返回查询结果，以作为证据。
100.进一步的，巡检单元306执行运行异常打赏监测模型，根据已上链的信息，对打赏平台上的多个打赏事件进行巡检时，具体包括：
101.通过智能合约，每当满足设定条件时运行异常打赏监测模型；
102.通过异常打赏监测模型的运行，对已上链的一个或者多个打赏事件的记录信息进行遍历和检测。
103.进一步的，巡检单元306执行对已上链的一个或者多个打赏事件的记录信息进行遍历和检测之前，装置还包括：
104.第三获取单元，获取监管部门提供的风险用户的信息；
105.第二查询单元，根据风险用户的信息，查询出对应于风险用户的一个或者多个打赏事件的记录信息，用于遍历和检测；
106.巡检单元306执行判定是否存在可疑打赏事件之后，装置还包括：
107.用户确定单元，若判定结果为是，则确定可疑打赏事件所属的直播间的同场观众用户；
108.关系网确定单元，根据同场观众用户，确定包括风险用户的在内的风险用户关系网。
109.进一步的，记录信息还指示了对应的打赏事件的时间和打赏礼物，巡检单元306执行检测具体包括：
110.根据记录信息，判定同一打赏用户或者同一被打赏用户对应的多个打赏事件是否发生过于密集和/或打赏礼物价值过高。
111.进一步的，巡检单元306执行判定同一打赏用户或者同一被打赏用户对应的多个打赏事件是否发生过于密集和/或打赏礼物价值过高之前，装置还包括：
112.数量确定单元，根据设定的风险数量阈值，确定所要检测的打赏事件所属的直播场次的观众用户数量过少。
113.进一步的，装置还包括：
114.确定单元，确定打赏事件的被打赏用户，作为第一被打赏用户；
115.第四获取单元，获取打赏礼物在由第一被打赏用户获得之后的二次流向信息并上链；
116.巡检单元306执行检测还包括：
117.确定二次流向信息指示了打赏礼物从第一被打赏用户流向了第二被打赏用户；
118.分别确定第一被打赏用户和第二被打赏用户在打赏平台上的人气度；
119.判定是否第一被打赏用户的人气度大于第二被打赏用户，且两者之间的差距程度大于设定程度。
120.进一步的，上链的实人认证信息包括对应的用户的工作信息，巡检单元306执行检测具体包括：
121.根据记录信息，确定对应的打赏事件的打赏用户和被打赏用户；
122.根据实人认证信息，以及预先构建的工作关系模型，预测打赏用户和被打赏用户之间的工作是否存在利益输送风险关系。
123.进一步的，利益输送风险关系包括：行贿受贿关系、违法利益合法化转换关系。
124.图4为本说明书一个或多个实施例提供的一种基于区块链的可信打赏业务处理设备的结构示意图，应用于区块链服务器，包括：
125.至少一个处理器；以及，
126.与至少一个处理器通信连接的存储器；其中，
127.存储器存储有可被至少一个处理器执行的指令，指令被至少一个处理器执行，以使至少一个处理器能够：
128.从打赏平台的打赏服务器获取用户的实人认证信息并上链；
129.在打赏平台上有打赏事件发生后，从打赏服务器获取打赏事件的记录信息并上链，记录信息指示了对应的打赏用户、被打赏用户；
130.运行异常打赏监测模型，根据已上链的信息，对打赏平台上的一个或者多个打赏事件进行巡检，以判定是否存在可疑打赏事件；
131.若是，则将可疑打赏事件上报至监管端进行异常确认。
132.本说明书一个或多个实施例提供的一种非易失性计算机存储介质，存储有计算机可执行指令，计算机可执行指令设置为：
133.从打赏平台的打赏服务器获取用户的实人认证信息并上链；
134.在打赏平台上有打赏事件发生后，从打赏服务器获取打赏事件的记录信息并上链，记录信息指示了对应的打赏用户、被打赏用户；
135.运行异常打赏监测模型，根据已上链的信息，对打赏平台上的一个或者多个打赏事件进行巡检，以判定是否存在可疑打赏事件；
136.若是，则将可疑打赏事件上报至监管端进行异常确认。
137.在20世纪90年代，对于一个技术的改进可以很明显地区分是硬件上的改进(例如，对二极管、晶体管、开关等电路结构的改进)还是软件上的改进(对于方法流程的改进)。然而，随着技术的发展，当今的很多方法流程的改进已经可以视为硬件电路结构的直接改进。设计人员几乎都通过将改进的方法流程编程到硬件电路中来得到相应的硬件电路结构。因此，不能说一个方法流程的改进就不能用硬件实体模块来实现。例如，可编程逻辑器件(programmable logic device,pld)(例如现场可编程门阵列(field programmable gate array，fpga))就是这样一种集成电路，其逻辑功能由用户对器件编程来确定。由设计人员自行编程来把一个数字系统“集成”在一片pld上，而不需要请芯片制造厂商来设计和制作专用的集成电路芯片。而且，如今，取代手工地制作集成电路芯片，这种编程也多半改用“逻辑编译器(logic compiler)”软件来实现，它与程序开发撰写时所用的软件编译器相类似，而要编译之前的原始代码也得用特定的编程语言来撰写，此称之为硬件描述语言
(hardware description language，hdl)，而hdl也并非仅有一种，而是有许多种，如abel(advanced boolean expression language)、ahdl(altera hardware description language)、confluence、cupl(cornell university programming language)、hdcal、jhdl(java hardware description language)、lava、lola、myhdl、palasm、rhdl(ruby hardware description language)等，目前最普遍使用的是vhdl(very-high-speed integrated circuit hardware description language)与verilog。本领域技术人员也应该清楚，只需要将方法流程用上述几种硬件描述语言稍作逻辑编程并编程到集成电路中，就可以很容易得到实现该逻辑方法流程的硬件电路。
138.控制器可以按任何适当的方式实现，例如，控制器可以采取例如微处理器或处理器以及存储可由该(微)处理器执行的计算机可读程序代码(例如软件或固件)的计算机可读介质、逻辑门、开关、专用集成电路(application specific integrated circuit，asic)、可编程逻辑控制器和嵌入微控制器的形式，控制器的例子包括但不限于以下微控制器：arc625d、atmel at91sam、microchip pic18f26k20以及silicone labs c8051f320，存储器控制器还可以被实现为存储器的控制逻辑的一部分。本领域技术人员也知道，除了以纯计算机可读程序代码方式实现控制器以外，完全可以通过将方法步骤进行逻辑编程来使得控制器以逻辑门、开关、专用集成电路、可编程逻辑控制器和嵌入微控制器等的形式来实现相同功能。因此这种控制器可以被认为是一种硬件部件，而对其内包括的用于实现各种功能的装置也可以视为硬件部件内的结构。或者甚至，可以将用于实现各种功能的装置视为既可以是实现方法的软件模块又可以是硬件部件内的结构。
139.上述实施例阐明的系统、装置、模块或单元，具体可以由计算机芯片或实体实现，或者由具有某种功能的产品来实现。一种典型的实现设备为计算机。具体的，计算机例如可以为个人计算机、膝上型计算机、蜂窝电话、相机电话、智能电话、个人数字助理、媒体播放器、导航设备、电子邮件设备、游戏控制台、平板计算机、可穿戴设备或者这些设备中的任何设备的组合。
140.为了描述的方便，描述以上装置时以功能分为各种单元分别描述。当然，在实施本说明书时可以把各单元的功能在同一个或多个软件和/或硬件中实现。
141.本领域内的技术人员应明白，本说明书实施例可提供为方法、系统、或计算机程序产品。因此，本说明书实施例可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本说明书实施例可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、cd-rom、光学存储器等)上实施的计算机程序产品的形式。
142.本说明书是参照根据本说明书实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
143.这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特
定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
144.这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
145.在一个典型的配置中，计算设备包括一个或多个处理器(cpu)、输入/输出接口、网络接口和内存。
146.内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(ram)和/或非易失性内存等形式，如只读存储器(rom)或闪存(flash ram)。内存是计算机可读介质的示例。
147.计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(pram)、静态随机存取存储器(sram)、动态随机存取存储器(dram)、其他类型的随机存取存储器(ram)、只读存储器(rom)、电可擦除可编程只读存储器(eeprom)、快闪记忆体或其他内存技术、只读光盘只读存储器(cd-rom)、数字多功能光盘(dvd)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。
148.还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个
……”
限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。
149.本说明书可以在由计算机执行的计算机可执行指令的一般上下文中描述，例如程序模块。一般地，程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等等。也可以在分布式计算环境中实践本说明书，在这些分布式计算环境中，由通过通信网络而被连接的远程处理设备来执行任务。在分布式计算环境中，程序模块可以位于包括存储设备在内的本地和远程计算机存储介质中。
150.本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于装置、设备、非易失性计算机存储介质实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。
151.上述对本说明书特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。
152.以上所述仅为本说明书的一个或多个实施例而已，并不用于限制本说明书。对于本领域技术人员来说，本说明书的一个或多个实施例可以有各种更改和变化。凡在本说明书的一个或多个实施例的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本说明书的权利要求范围之内。