CN113935058B - 一种面向泛在资源的拉模式可信预言机的软件定义方法 - Google Patents

Abstract

本申请实施例提供一种面向泛在资源的拉模式可信预言机的软件定义方法，涉及区块链技术领域，所述方法包括：执行环境、审计机制分别计算主密钥的前半部分、后半部分；审计机制将后半部分的一部份发送给执行环境，使执行环境生成部分的TLS Key，执行环境依据部分TLS Key接收合约节点发送的资源，将接收数据的信息摘要发送至审计机制；审计机制收到信息摘要后使执行环境拥有完整的TLS Key来解密资源，以进行部署生成执行进程；审计机制重新接收资源以进行审计，审计完成后，执行环境返回执行进程的调用ID和审计结果。本申请的方法主动将资源发送到预言机中生成调用接口，一次调用就能实现链下资源的软件定义化，还能为执行提供真实性证明。

Description

一种面向泛在资源的拉模式可信预言机的软件定义方法

技术领域

本申请实施例涉及区块链技术领域，具体而言，涉及一种面向泛在资源的拉模式可信预言机的软件定义方法。

背景技术

区块链技术经过多年的发展，在许多领域已经得到了广泛的应用，当前区块链智能合约已经具备了图灵完备性，但是必须基于账本上的数据进行计算，这种计算方式具有一定的局限性。与此同时，数据量与算法数量也在高速地增长——全网数据量每年以指数级别增长；以深度学习为代表的人工智能算法也发展迅猛，在许多领域取得了突破性的进展，这些数据和算法可视为海量异构的泛在资源。

区块链技术保证了数据的透明性与可追溯性；而海量异构的数据结合深度学习技术等人工智能算法可以用于相对复杂的数据处理场景；将泛在资源与区块链技术结合，对于解决用户对软件技术的焦虑、提升用户对软件技术的信任具有十分积极的意义。

当前，将泛在资源与区块链结合存在的主要问题是区块链上的计算资源与泛在资源执行环境需求不匹配，而预言机是解决这个问题的一种有效途径。它的主要作用是为智能合约赋予获取链下数据的能力。为了使链下的泛在资源抽象，使得其可以在区块链中获取并编程，通常会通过软件定义方法对预言机进行定义。

对于传统的区块链预言机，其是一种将链下数据“推”到链上的模式，这种“推”模式的预言机往往需要至少两次链上交易：第一次交易是某个合约调用，由该调用触发将对预言机的调用需求记录在区块链上；第二次交易是链下的预言机通过监测链上区块数据，当检测到链上有预言机调用需求后，发起调用，并将结果以另一个智能合约调用的形式记录到区块链上。且典型的区块链预言机只适用于智能合约被动地等待链下预言机发送数据，合约不能主动地将需要的算法与数据发送到预言机中并获得计算结果。

发明内容

本申请实施例提供一种面向泛在资源的拉模式可信预言机的软件定义方法，旨在解决传统预言机调用次数较多、且链上智能合约只能被动接收数据的问题。

本申请实施例第一方面提供一种面向泛在资源的拉模式可信预言机的软件定义方法，所述可信预言机包括执行环境和审计机制，所述方法包括：

所述执行环境接收到合约节点的握手请求后，所述执行环境计算主密钥的前半部分、所述审计机制计算主密钥的前后半部分；

所述审计机制将所述主密钥的后半部分拆分为第一部份和第二部份，并将所述第一部份发送给所述执行环境，以使所述执行环境生成部分的TLS Key；

所述执行环境依据所述部分的TLS Key接收所述合约节点发送的泛在资源，并在完成所述泛在资源的接收后，将所述泛在资源的信息摘要发送至所述审计机制；

所述审计机制收到所述信息摘要后发送所述第二部份至所述执行环境，以使得所述执行环境拥有完整的TLS Key；

所述执行环境依据所述完整的TLS Key解密所述泛在资源，将解密后的数据进行部署，以生成执行进程；

所述执行环境将所述合约节点的链接发送给所述审计机制；

所述审计机制重构所述执行环境的ssl 字节，使用所述ssl字节、所述链接与所述合约节点进行通信，重新收取所述泛在资源；

所述审计机制验证重新收取的泛在资源与所述执行环境提交的所述信息摘要是否吻合；

当所述审计机制的验证结果为吻合时，所述审计机制将所述重新收取的泛在资源和所述链接作为证据保存；

所述执行环境获取所述审计机制的验证结果，将所述验证结果与所述执行进程的调用ID返回所述合约节点。

可选地，所述执行环境计算主密钥的前半部分、所述审计机制计算主密钥的前后半部分，包括：

所述执行环境生成一个24字节的被审计人随机数，并通知所述审计机制开始准备审计；

所述审计机制生成24字节的审计人随机数，并通知所述执行环境审计开始；

所述执行环境与所述审计机制交换随机数的信息，分别生成所述主密钥的前半部分和所述主密钥的后半部分。

可选地，所述执行环境与所述审计机制交换随机数信息，分别生成所述主密钥的前半部分和所述主密钥的后半部分，包括：

所述执行环境采用P_MD5算法对所述被审计人随机数进行计算，生成48字节的第二被审计人随机数，并将所述第二被审计人随机数均分为两部分；

所述审计机制采用P_SHA1扩展算法对所述审计人随机数进行计算，生成48字节的第二审计人随机数，并将所述第二审计人随机数均分为两部分；

所述执行环境将所述第二被审计人随机数的后半部分发送至所述审计机制，所述审计机制将所述第二审计人随机数的前半部分发送至所述执行环境；

所述执行环境依据所述第二被审计人随机数的前半部分与所述第二审计人随机数的前半部分计算得到所述主密钥的前半部分，所述审计机制依据所述第二审计人随机数的后半部分与所述第二被审计人随机数的后半部分计算得到所述主密钥的后半部分。

可选地，所述审计机制将所述主密钥的后半部拆分为第一部分和第二部分，将所述第一部分发送给所述执行环境，以使所述执行环境生成部分TLS Key，包括：

所述审计机制采用P_SHA1算法对所述主密钥的后半部分进行计算，得到审计机制密钥数据；

所述审计机制将第一预设长度的审计机制密钥数据发送至所述执行环境；

所述执行环境采用P_MD5 算法对所述主密钥的前半部分进行计算，得到执行环境密钥数据；

所述执行环境依据所述执行环境密钥数据与所述第一预设长度的审计机制密钥数据计算得到client_write_MAC_key、client_write_key和 server_write_key三个TLSKey。

可选地，所述执行环境依据所述完整的TLS Key解密所述泛在资源，将解密后的数据进行部署，以生成执行进程，包括：

获取所述解密后的数据中的执行参数，判断所述解密后的数据的执行类型；

当所述解密后的数据的执行类型为计算型时；

调用所述计算型对应的执行方法，以进行执行；

当所述解密后的数据的执行类型为服务型时；

调用所述服务型对应的执行方法进行部署，以生成执行进程。

可选地，所述调用所述计算型对应的执行方法，以进行执行，包括：

获取所述解密后的数据的执行主类参数，依据所述执行主类参数设置定时器；

执行所述解密后的数据，并且在执行过程中使用所述定时器判断执行是否超时；

当执行并未超时时，返回执行的结果。

可选地，所述调用所述服务型对应的执行方法进行部署，以生成执行进程，包括：

部署所述解密后的数据，生成所述执行进程，并保存字典对象；

所述方法还包括：

接收所述合约节点传入所述调用ID和新的处理数据；

依据所述调用ID在字典对象中查找对应的执行进程，以执行所述新的处理数据。

可选地，所述预言机采用Nginx-uWSGI-flask服务框架的通信架构。

采用本申请提供的面向泛在资源的拉模式可信预言机软件的定义方法，主动将需要处理的数据发送到预言机中进行部署生成执行进程，以供调用，即本申请将链下的预言机上部署的执行资源以编程接口的方式提供给链上使用者如智能合约等，完成链下资源的软件定义化，链上的智能合约可以通过该接口主动拉取数据。

相比于经典的预言机的机制需要在账本上产生两笔交易，本申请的方法可直接从预言机中拉取处理的结果，减少了调用数据的调用次数，只需进行一次交易，即可实现链下资源的软件定义化，本申请的方法还避免了以往只能使用事先固定在预言机内的算法的缺点。

并且，本申请的方法中预言机能够提供证据表明来自外部的数据是真实的，并且未被篡改，为预言机的执行提供可信的真实性证明。

附图说明

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

图1是本申请一实施例提出的预言机、区块链与现实世界数据的关系的流程图示意图；

图2是本申请一实施例提出的预言机工作方式的示意图；

图3是本申请一实施例提出的面向泛在资源的拉模式可信预言机的软件定义方法的流程图。

具体实施方式

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

预言机是将区块链与泛在资源结合的有效途径之一，预言机、区块链与现实世界数据的关系如图1所示。在使用预言机将二者结合的过程中还存在着许多挑战：

（1）传统的预言机是区块链数据的提供者，数据是通过预言机主动向区块链节点推送的，合约节点只能被动的接受数据，即“推”模式的预言机。这种情况下，假设智能合约发起计算任务<算法a，输入b>此时需要合约开发者从链上取出b输入到链下预言机的算法a里，得到处理结果c，再由预言机将结果c返回到链上，触发后续逻辑。这种方式需要至少两次调用，并且只能使用事先固定在预言机内的算法。

（2）在实现区块链深度学习预言机的过程中，真实性证明是本申请首先需要考虑的内容。真实性证明关注的内容是预言者能够提供证据表明来自外部数据源的内容并未被自己或其他人篡改。

参考图2，图2是本申请一实施例提出一种面向范在资源的可信预言机的工作方式的示意图。

针对现有“推”模式的预言机的缺点，本申请的可信预言机采用“拉”模式。在“拉”模式的预言机系统中，节点可以主动将需要处理的范在资源发送到预言机中，然后从直接预言机中拉取数据处理的结果。在本申请节点发送的泛在资源指所有数据、代码、算法等，例如人工智能的算法、模型或者用于处理的数据等等。

在本申请所设计的“拉”预言机中，可以让部署有智能合约的节点（以下简称合约节点）主动将需要执行的泛在资源部署到预言机中，然后直接拉取计算结果，并且还可以通过形成服务的方式，将泛在资源实时加载入内存，形成可调用的服务，以供其他合约节点调用。

如图2所示，对于本申请的拉模式的预言机而言，其仅仅只需从区块链网络中接收业务代码、分析模型与数据。

优选的，本文的预言机采用了与Provable类似的架构，而根据过往的实验总结，本类预言机的可靠率可以达到98%以上，是几种预言机实现过程中相对可靠的一类。

如图2所示，可信预言机内包括执行环境与审计机制两部分。对于预言机真实性证明的问题，在本申请的可信预言机中，真实性证明即是预言机能够提供证据，表明来自智能合约的深度学习代码以及模型文件是真实的，并且未被自己或其他人篡改，对此，本申请在合约节点与执行环境之间增加了一个审计者，该审计者能够通过：承诺——验证——保存证据的方式为预言机提供真实性证明。

本申请的审计方加入于TLS协议中，审计方的加入可以证明于预言机用于执行的深度学习算法并未被篡改，并为之提供证明。具体的，审计方审计从合约节点发送的深度学习算法流量，能够为“拉”模式的预言机提供真实性证明。为便于表述，对于本申请加入审计方的TLS协议，以下简称为TLS-审计协议。

应当注意的是在，TLS-审计协议中，合约节点与预言机交互逻辑中，合约节点应该能够进行普通的TLS通信，相对于预言机，合约节点在TLS-审计协议中是服务器的角色，即合约节点在需要时会通知预言机发起TLS-审计通信，而自己仅需要执行普通的TLS协议。在TLS协议通信完成之后合约节点能够将深度学习算法与数据集等传输到预言机内执行。合约节点需要预言机对代码的忠实执行过程进行监督。因为从根本而言，无论是合约开发者编写的代码还是通过合约IDE上传的模型、数据等，这些本质上都是链下资源，不是智能合约链上的内容。链下的资源需要在预言机中审计机制的监督下执行，之后才能返回将其写入链上。

参考图3，图3是本申请一实施例提出面向泛在资源的拉模式可信预言机的软件定义方法的流程图，所述可信预言机包括执行环境和审计机制。如图3所示，该方法包括以下步骤：

步骤S300、所述执行环境接收到合约节点的握手请求后，所述执行环境计算主密钥的前半部分、所述审计机制计算主密钥的前后半部分。

合约节点是指区块链中部署有智能合约的节点，合约节点需要使用预言机执行链下的代码内容，因此合约节点向执行环境进行TLS协议握手并生成对应的TLS密钥，以进行资源的传输。因为本申请的TLS-审计协议中合约节点进行的是标准的TLS握手流程，其执行流程是TLS客户端的标准执行流程，即，第一步是合约节点调用startHandShake()通知预言机准备进行TLS-审计握手协议。

执行环境接收握手请求后，会计算生成主密钥Master Secret的前半部分，执行环境接生成前半部分主密钥后，通知审计机制，审计机制生成主密钥的后半部分。

该步骤中，执行环境在收到请求后还会实例化一个TLSNSession会话实例，TLSNSession是预言机中保存的TLS-Notary会话类，该类会在执行环境作出承诺之后被完善。握手的结果会逐渐为TLSNSession实例填充参数，参数填写完毕即表示连接建立成功，而每一个TLSNSession实例表示一段连接，预言机使用这个TLSNSession实例维持与合约节点和审计机制的通信。这个TLSNSession中保存了握手协议中所有的信息，多次与节点和审计机制握手的目的是完善这个Session实例，并保存在其预言机系统中，以便后续审计。

实例化TLSNSession会话后，才计算主密钥的前半部分，将该部分premastersecret经散列函数处理后写入TLSNSession。并且，审计机制掌握的主密钥的后半部分也需要经散列函数处理后写入TLSNSession。

步骤S310、所述审计机制将所述主密钥的后半部分拆分为第一部份和第二部份，并将所述第一部份发送给所述执行环境，以使所述执行环境生成部分的TLS Key。

审计机制计算的Master Secret后半部分，将其的前一部分字节的内容（即第一部）发送给执行环境，自己保留后后一部分字节的内容。

在现有的TLS协议中，客户端与服务端之间采用Master Secret进行通信。其中，Master Secret会以商量好的方式生成下表所示的四个用于会话的对称密钥：

表1 MasterSecret推导出的会话密钥及其用途

会话密钥	用途
		client_write_MAC_key	客户端的身份验证和消息校验
server_write_MAC_key	服务器的身份验证和消息校验
		client_write_key	客户端的消息加密
server_write_key	服务器的消息加密

在本申请的TLS-审计协议中，审计方（Auditor）与被审计方（Auditee）共同协商生成Master Secret，但是审计方（Auditor）会保留一部分TLS协议的秘密数据，使得被审计方（Auditee）在作出承诺之前只拥有上述四个会话密钥（client_write_MAC_key、server_write_MAC_key、client_write_key和 server_write_key）中的三个，其中被审计方缺少的是server_write_MAC_key。这样被审计方就会因为缺少server_write_MAC_key，而无法伪造收到的消息验证码。

通信完成之后，被审计方从服务器收到的加密内容中提交承诺，即从服务器收到流量的散列值。在收到承诺之后，审计方就可以将保留的内容发送给被审计方，使被审计方维持了完整TLS安全模型的同时无法伪造从服务器收到的数据内容。

或者说，所述审计机制将所述主密钥的后半部分为第一部分和第二部分，第一部分能够用于与所述主密钥的前半部分生成部分TLS Key，所述TLS Key只包括client_write_MAC_key、server_write_MAC_key、client_write_key和 server_write_key，目的是保留server_write_MAC_key，防止执行环境伪造收到的流量。

执行环境依据所接收的第一部分和自身的主密钥的前半部分生成client_write_MAC_key、server_write_MAC_key、client_write_key和 server_write_key，三个TLS Key。

步骤S320、所述执行环境依据所述部分的TLS Key接收所述合约节点发送的泛在资源，并在完成所述泛在资源的接收后，将所述泛在资源的信息摘要发送至所述审计机制；

执行环境依据client_write_MAC_key、server_write_MAC_key、client_write_key和 server_write_key与合约节点进行通信，接收合约节点发送的泛在资源，所述泛在资源指所有数据、代码、算法等，如人工智能的算法、模型、代码等。

执行环境接收完合约节点发送的资源后，向审计机制提交真实性承诺，真实性承诺的实现是：执行环境将其与合约节点进行的加密通信流量通过信息摘要算法（如sha256算法）计算信息摘要，将计算得到的信息摘要作为承诺提交给审计机制，因为执行环境本身并不掌握server_write_mac_key，所以无法伪造从合约节点收到的流量内容。

步骤S330、所述审计机制收到所述信息摘要后发送所述第二部份至所述执行环境，以使得所述执行环境拥有完整的TLS Key。

审计机制收到真实性承诺后发送其拥有的主密钥的后半部分的剩余部分（即第二部分）发送至执行环境，执行环境依据第二部分与自身的主密钥的前半部分生成server_write_MAC_key，其拥有了完整的TLS Key。

步骤S340、所述执行环境依据所述完整的TLS Key解密所述泛在资源，将解密后的数据进行部署，以生成执行进程。

软件定义是指将传统的各类资源以可编程的方式使用。本申请中的面向泛在资源的预言机，支持将链下各类资源以编程接口的方式提供给链上的智能合约使用，即完成链下资源的软件定义化。

本申请中颠覆传统的“推”模式，通过扩展智能合约的执行模型，在保持同等信任程度的情况下，智能合约可以直接调用预言机上的接口进行执行，拉取得到执行结果，从而缩短链下数据上链的链路，提升区块链智能合约链上链下交互的效率。

执行环境依据在步骤330中取得的完整的TLS Key，对步骤S320中得到的泛在资源进行解密，对于解密后的数据，进行执行，生成一个进程。

值得注意的是，本步骤中的部署并非是指狭义的部署，而是广义的，带有执行含义的。

也就是说，对于需要多次调用的数据，生成进程/服务，并对该进程进行保留，以实现部署。在机器学习中将模型加载入内存生成服务的过程至少需要两次执行，一次是生成服务进程，第二次是执行调用。因而，本申请中对于需多次调用的泛在资源的处理逻辑为:合约节点将算法传输到预言机之后，执行环境解密收到的资源，将其部署在内存当中，以供后续合约开发者调用。

对于单次使用的数据，“部署”一词的含义则侧重于执行，执行环境将解密后的数据，直接进行执行，生成一个服务，获得执行结果。

步骤S350、所述执行环境将所述合约节点的链接发送给所述审计机制。

执行环境将发送所述泛在资源的合约节点的连接发送至审计机制，以供审计机制重新接收数据来验证执行环境提交的真实性承诺。

步骤S360、所述审计机制重构所述执行环境的ssl 字节，使用所述ssl字节、所述链接与所述合约节点进行通信，重新收取所述泛在资源。

由于审计机制与执行环境通过共同填写TLSNSession的内容完成密钥协商，填写的内容是各个TLSsercret的散列值，共同构建的与合约节点通信的mastersecret。

由于TLSNSession中保存了握手协议中所有的信息，因而审计机制可以重构执行环境的ssl session，审计机制可使用该session和链接与合约节点进行通信，重新收取原始的泛在资源。

本申请中，结果验证分为两个阶段，第一个阶段主要是为了验证执行环境提交的承诺是否为真，此时审计机制会通过执行环境传递给自己的链接结合TLSNSession与合约节点进行正常的TLS通信，请求下载相同的内容，并且使用相同的方法计算hash值，如果hash值不匹配，那么就说明承诺为假，抛出异常。

步骤S370、所述审计机制验证重新收取的泛在资源与所述执行环境提交的所述信息摘要是否吻合。

步骤S380、当所述审计机制的验证结果为吻合时，所述审计机制将所述重新收取的泛在资源和所述链接作为证据保存。

审计机制验证自己所接收的该原始数据是否与执行环境提交的承诺吻合，如果承诺验证通过，审计机制会将从合约节点收到的原始数据、节点的公钥、原始数据的收取链接一并作为证据保存。

结果验证第二阶段主要是为了留存证据，审计机制通过自己的掌握的secret解密完整的信息，并将其与合约节点的公钥一并写入文件中，作为证据留存。具体的，审计机制会在通信完毕之后重建完整的master secret，用于将执行环境写入的未解密内容解密，并将合约节点的public key与解密后的内容一并写入磁盘，最后通知执行环境验证成功或者是失败。

步骤S390、所述执行环境获取所述审计机制的验证结果，将所述验证结果与所述执行进程的调用ID返回所述合约节点。

执行环境执行从合约节点处接收的资源，并向合约节点返回部署形成的执行进程的调用ID与审计信息，优选的，无论部署成功与否，执行环境都会将其运行的结果返回给调用者以便调试。

验证结果就是审计机制对执行环境所接收内容的审计结果，合约节点可依据验证结果来判断预言机是否完整、如实的接收了发送的内容，也就是说，该验证结果为预言机提供了可信证明，使得外部节点能够信任该预言机。

对验证结果进行判断后，合约节点可以通过调用ID来调用部署在预言机上的资源，进行运算等操作。

在本申请一个可选实施例中，以上步骤310中所述执行环境计算主密钥的前半部分、所述审计机制计算主密钥的前后半部分，采用以下方法：

1、所述执行环境生成一个24字节的被审计人随机数，并通知所述审计机制开始准备审计；

预言机收到startHandShake()信息，随机生成一个24字节的被审计人随机数（S₁），创建TLSNSession对象，通知审计机制开始准备审计。

2、所述审计机制生成24字节的审计人随机数，并通知所述执行环境审计开始；

审计机制随机一个生成24字节的审计人随机数(S₂)，并通知执行环境审计开始。

3、所述执行环境与所述审计机制交换随机数的信息，分别生成所述主密钥的前半部分和所述主密钥的后半部分。

执行环境将自身的被审计人随机数的一部分信息（被审计人随机数前半部分）发送至审计机制，审计机制将自身的审计人随机数信息（审计人随机数后半部分）发送给执行环境。

执行环境依据所接收的审计人随机数的部分信息与被审计人随机数一同生成主密钥的前半部分，审计机制依据所接收的被审计人随机数的部分信息与审计人随机数一同生成主密钥的后半部分。

优选的，所述执行环境与所述审计机制交换随机数信息，分别生成所述主密钥的前半部分和所述主密钥的后半部分，包括：

A、所述执行环境采用P_MD5算法对所述被审计人随机数进行计算，生成48字节的第二被审计人随机数，并将所述第二被审计人随机数均分为两部分。

被审计方（执行环境）计算P_MD5(S1)，得到48字节H1 = H₁₁||H₁₂。

B、所述审计机制采用P_SHA1扩展算法对所述审计人随机数进行计算，生成48字节的第二审计人随机数，并将所述第二审计人随机数均分为两部分。

审计方计算P_SHA1(S2)，得到48字节，H₂=H₂₁||H₂₂。

C、所述执行环境将所述第二被审计人随机数的后半部分发送至所述审计机制，所述审计机制将所述第二审计人随机数的前半部分发送至所述执行环境。

审计方向被审计方发送H₂₁，被审计方向审计方发送H₁₂。

D、所述执行环境依据所述第二被审计人随机数的前半部分与所述第二审计人随机数的前半部分计算得到所述主密钥的前半部分，所述审计机制依据所述第二审计人随机数的后半部分与所述第二被审计人随机数的后半部分计算得到所述主密钥的后半部分。

审计方计算MasterSecret的后一半M₂=H₁₂⊕H₂₂，被审计方计算MasterSecret的前一半M₁=H₂₁⊕H₁₁。

在本申请一个可选实施例中，上述步骤S320中的所述审计机制将所述主密钥的后半部拆分为第一部分和第二部分，将所述第一部分发送给所述执行环境，以使所述执行环境生成部分TLS Key，包括：

所述审计机制采用P_SHA1算法对所述主密钥的后半部分进行计算，得到审计机制密钥数据。

所述审计机制将第一预设长度的审计机制密钥数据发送至所述执行环境。

所述执行环境采用P_MD5 算法对所述主密钥的前半部分进行计算，得到执行环境密钥数据。

所述执行环境依据所述执行环境密钥数据与所述第一预设长度的审计机制密钥数据计算得到client_write_MAC_key、client_write_key和 server_write_key三个TLSKey。

审计方计算140字节的Y=P_SHA1(M₂)，并且审计方给被审计方Y中内容的120字节。被审计方计算140字节的X=P_MD5(M₁)，被审计方的X与120字节的Y联合计算，让被审计方可以计算出TLS协议中的client_write_MAC_key、client_write_key和 server_write_key三个需要的密钥，但是缺少server_write_MAC_key。此时被审计方可以与服务器通信，但是无法验证服务。

现有技术中，拆包之后的代码通过python语言来执行外部程序的技术执行。现有技术中有使用os.system()函数、使用os.popen()函数、使用subprocess.call()函数、使用subprocess.Popen()函数等方式执行。以上现有方法存在一定的缺点，如而对于复杂程序，subprocess.Popen()生成进程之后如果频繁对其进行写入调用会导致子进程管道被关闭；同时Popen对象的communicate()方法会调用wait()等待进程结束，而对服务类进程调用wait()方法会导致死锁。

在本申请一个可选实施例中，上述步骤S360中的执行环境依据所述完整的TLSKey解密所述泛在资源，将解密后的数据进行部署，以生成执行进程，还包括：

获取所述解密后的数据中的执行参数，判断所述解密后的数据的执行类型；

当所述解密后的数据的执行类型为计算型时；

调用所述计算型对应的执行方法，以进行执行；

当所述解密后的数据的执行类型为服务型时；

调用所述服务型对应的执行方法进行部署，以生成执行进程。

获取所述解密后的数据中的执行参数，判断所述解密后的数据的执行类型。

本申请中，将代码执行根据执行参数分为两种类型，一种是计算型；一种是服务型。在解密执行内容之后，执行环境会获取拆包之后的代码中的执行参数，判断代码是计算型还是服务型。判断得到类型后，下一步执行环境才会根据依据类型的不同采用不同的方法。

对于两种类型的执行方式应该分别处理。判断得到代码的执行类型后，依据其的类型调用不同方法来执行。

当所述解密后的数据的执行类型为计算型时，可以调用计算型对应的执行方法，直接进行执行，无需将其部署于预言机中。

优选的，当执行类型为计算型，其对应的执行方法，包括：

获取所述解密后的数据的执行主类参数，依据所述执行主类参数设置定时器；

执行所述解密后的数据，并且在执行过程中使用所述定时器判断执行是否超时；

当执行并未超时时，返回执行的结果。

本申请认为计算型即执行一次代码，执行完毕之后即返回结果，因此对于计算型任务，设置了一个定时器，当时间耗尽时执行环境中将主动停止计算强制返回结果，以防合约开发者编写了有缺陷的代码导致执行过程中的死循环。如果未超时，则回计算结果。

优选的，在计算型函数的执行中，使用了subprocess的PIPE管道输出处理结果，包含标准输出与标准错误，如果代码执行出错，则会向合约引擎返回错误的具体信息；同时，在子程序运行时，设置了一个计时器，时间为10秒，执行时间超过这个时间，该计算进程会被结束，并返回超时信息。而如果需要将预言机用于模型训练，则可以去掉计时器，使得模型训练完毕之后再向合约节点返回结果。

当所述解密后的数据的执行类型为服务型时，则需要将其进行部署，以生成执行进程。

优选的，当执行类型为服务型时，部署的方法为：

部署所述解密后的数据，生成所述执行进程，并保存字典对象；

所述方法还包括：

接收所述合约节点传入所述调用ID和新的处理数据；

依据所述调用ID在字典对象中查找对应的执行进程，以执行所述新的处理数据。

由于服务型需要进行部署，因此本申请服务型的执行方式相较于计算型有很大的不同。首先，通过services参数指定部署模型，将模型加载入内存，采用python库Popen的执行命令（或者也可以采用其他执行命令）进行部署生成子进程，主进程为该开启的服务子进程保留Popen对象，成功后得到得到进程ID（本申请也将其作为调用ID），其次，等待合约节点的调用，提供服务。

在生成了子进程之后，必然后续会涉及到调用时合约进程如何通信的问题以形成服务的问题。在合约开发者多次调用服务类计算之后会形成类似于多叉树状的父子进程结构，它们通过无名管道PIPE相互通信，并且父进程不会阻塞。

示例的，识别图片为例，合约开发者通过services参数指定部署模型，成功后得到返回进程ID，其后合约开发者只需要在代理合约中调用callServices，并将返回的ID与需要识别的图片通过参数的方式传入，然后执行环境会根据保存的字典找到该服务的Popen对象，使用communicate()方法即可通过管道将该图片输入到进程中，并得到返回结果。

需要注意的是，如果采用Popen类执行需要修改部分内容，因为原python标准库Popen类的communicate()调用一次之后会关闭子进程输入的管道并调用wait()等待子进程结束，所以需要修改原python库中的communicate()函数与关闭管道、等待子进程有关的内容，改为完成第一次通信之后不关闭管道，并且不调用wait()等待。服务调用不能直接使用stdin、stdout与stderr进行读写，因为对于服务类进程而言，这会导致父进程一直等待服务进程完成而形成死锁。

在本申请一个可选实施例中，所述预言机采用Nginx-uWSGI-flask服务框架的通信架构。

Nginx是一个支持高并发的异步框架的网页服务器，具有高并发、占用内存少、模块化程度高等特点。

在本申请中，Nginx服务框架是通信模块的一部分，相对于其他server，Nginx可以解决TLS-审计协议只认证response而不认证request的问题。同时，不同合约开发者使用的深度学习框架版本可能会不同，就需要将代码和模型发送到不同的环境当中运行，而Nginx可以实现通过参数配置，将不同的代码发送到不同的环境中运行。并且Nginx可以实现高可用、负载均衡等功能，对于预言机未来功能的扩充也是至关重要的。

Flask是用Python语言基于Werkzeug工具箱编写的轻量级Web开发框架。

在本申请中，借助flask程序构筑了执行代码与返回结果的中间件。同时借由Flask的路由与应用功能，实现接收网络请求、解析网络请求、解压文件、执行文件等操作并且可以通过Flask指定将合约节点指定的不同执行方式的代码分别以服务型和计算型的方式执行。

Web服务器网关接口（Web Server Gateway Interface，WSGI）是为Python定义的Web服务器和Web应用程序或框架之间的一种简单而通用的接口。

在本申请中，预言机系统是构建在Flask应用之上的Python自动执行环境，但是flask.run()不适用于长时间的生产环境，所以需要使用WSGI进行中间件代理，应用服务器会实现WSGI的服务端、进程管理以及对application的调用，同时记录下系统日志。

本申请通过通信架构能够以RPC的方式实现了一种合约与预言机进行交互的机制。通信架构中Nginx能够提供高性能的网络代理，同时，它的反向代理功能可以用于识别不同的代码版本，将其发送到不同版本的执行环境当中，使用Nginx可以提高整体系统的性能和可扩展性；而uWSGI是在通信模块中是一个介于Nginx服务器和Flask应用的中间件，它规范了Nginx和flask应用程序之间的通信，对于Nginx服务器来说，只要支持WSGI规范，就可以保证所有兼容uWSGI的Python程序能运行；对于Python程序而言，只要兼容WSGI，就可以保证能在所有支持uWSGI的服务器上运行。

并且，预言机实现了执行服务型的执行机制，该通信架构使得合约节点能够对自己部署的深度学习算法进行调用：首先，主进程需要为开启的服务子进程保留对象的过程，可由flask执行，其次，父进程与子进程之间的无名管道PIPE基于通信架构的IPC的管道通信方式进行实现。

基于同一发明构思，本申请另一实施例提供一种可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现如本申请上述任一实施例所述的面向泛在资源的拉模式可信预言机的软件定义方法。

基于同一发明构思，本申请另一实施例提供一种电子设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行时实现本申请上述任一实施例所述的面向泛在资源的拉模式可信预言机的软件定义方法。

对于装置实施例而言，由于其与方法实施例基本相似，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

本说明书中的各个实施例均采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似的部分互相参见即可。

本领域内的技术人员应明白，本申请实施例的实施例可提供为方法、装置、或计算机程序产品。因此，本申请实施例可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请实施例可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本申请实施例是参照根据本申请实施例的方法、终端设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理终端设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理终端设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理终端设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理终端设备上，使得在计算机或其他可编程终端设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程终端设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

尽管已描述了本申请实施例的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例做出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本申请实施例范围的所有变更和修改。

最后，还需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者终端设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者终端设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者终端设备中还存在另外的相同要素。

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

Claims (8)

1.一种面向泛在资源的拉模式可信预言机的软件定义方法，其特征在于，所述可信预言机包括执行环境和审计机制，所述方法包括：

所述执行环境接收到合约节点的握手请求后，所述执行环境计算主密钥的前半部分、所述审计机制计算主密钥的前后半部分；

所述审计机制将所述主密钥的后半部分拆分为第一部分和第二部分，并将所述第一部分发送给所述执行环境，以使所述执行环境生成部分的TLS Key；

所述执行环境依据所述部分的TLS Key接收所述合约节点发送的泛在资源，并在完成所述泛在资源的接收后，将所述泛在资源的信息摘要发送至所述审计机制；

所述审计机制收到所述信息摘要后发送所述第二部分至所述执行环境，以使得所述执行环境拥有完整的TLS Key；

所述执行环境依据所述完整的TLS Key解密所述泛在资源，将解密后的数据进行部署，以生成执行进程；

所述执行环境将所述合约节点的链接发送给所述审计机制；

所述审计机制重构所述执行环境的ssl 字节，使用所述ssl字节、所述链接与所述合约节点进行通信，重新收取所述泛在资源；

所述审计机制验证重新收取的泛在资源与所述执行环境提交的所述信息摘要是否吻合；

当所述审计机制的验证结果为吻合时，所述审计机制将所述重新收取的泛在资源和所述链接作为证据保存；

所述执行环境获取所述审计机制的验证结果，将所述验证结果与所述执行进程的调用ID返回所述合约节点。

2.根据权利要求1所述方法，其特征在于，所述执行环境计算主密钥的前半部分、所述审计机制计算主密钥的前后半部分，包括：

所述执行环境生成一个24字节的被审计人随机数，并通知所述审计机制开始准备审计；

所述审计机制生成24字节的审计人随机数，并通知所述执行环境审计开始；

所述执行环境与所述审计机制交换随机数的信息，分别生成所述主密钥的前半部分和所述主密钥的后半部分。

3.根据权利要求2所述方法，其特征在于，所述执行环境与所述审计机制交换随机数信息，分别生成所述主密钥的前半部分和所述主密钥的后半部分，包括：

所述执行环境采用P_MD5算法对所述被审计人随机数进行计算，生成48字节的第二被审计人随机数，并将所述第二被审计人随机数均分为两部分；

所述审计机制采用P_SHA1扩展算法对所述审计人随机数进行计算，生成48字节的第二审计人随机数，并将所述第二审计人随机数均分为两部分；

所述执行环境将所述第二被审计人随机数的后半部分发送至所述审计机制，所述审计机制将所述第二审计人随机数的前半部分发送至所述执行环境；

所述执行环境依据所述第二被审计人随机数的前半部分与所述第二审计人随机数的前半部分计算得到所述主密钥的前半部分，所述审计机制依据所述第二审计人随机数的后半部分与所述第二被审计人随机数的后半部分计算得到所述主密钥的后半部分。

4.根据权利要求1所述方法，其特征在于，所述审计机制将所述主密钥的后半部拆分为第一部分和第二部分，将所述第一部分发送给所述执行环境，以使所述执行环境生成部分TLS Key，包括：

所述审计机制采用P_SHA1算法对所述主密钥的后半部分进行计算，得到审计机制密钥数据；

所述审计机制将第一预设长度的审计机制密钥数据发送至所述执行环境；

所述执行环境采用P_MD5 算法对所述主密钥的前半部分进行计算，得到执行环境密钥数据；

所述执行环境依据所述执行环境密钥数据与所述第一预设长度的审计机制密钥数据计算得到client_write_MAC_key、client_write_key和 server_write_key三个TLS Key。

5.根据权利要求1所述方法，其特征在于，所述执行环境依据所述完整的TLS Key解密所述泛在资源，将解密后的数据进行部署，以生成执行进程，包括：

获取所述解密后的数据中的执行参数，判断所述解密后的数据的执行类型；

当所述解密后的数据的执行类型为计算型时；

调用所述计算型对应的执行方法，以进行执行；

当所述解密后的数据的执行类型为服务型时；

调用所述服务型对应的执行方法进行部署，以生成执行进程。

6.根据权利要求5所述方法，其特征在于，所述调用所述计算型对应的执行方法，以进行执行，包括：

获取所述解密后的数据的执行主类参数，依据所述执行主类参数设置定时器；

执行所述解密后的数据，并且在执行过程中使用所述定时器判断执行是否超时；

当执行并未超时时，返回执行的结果。

7.根据权利要求5所述方法，其特征在于，所述调用所述服务型对应的执行方法进行部署，以生成执行进程，包括：

部署所述解密后的数据，生成所述执行进程，并保存字典对象；

所述方法还包括：

接收所述合约节点传入所述调用ID和新的处理数据；

依据所述调用ID在字典对象中查找对应的执行进程，以执行所述新的处理数据。

8.根据权利要求1所述方法，其特征在于，所述预言机采用Nginx-uWSGI-flask服务框架的通信架构。

Images