一种区块链智能合约更新方法、装置及设备与流程

文档序号:15979921发布日期:2018-11-17 00:12阅读:147来源:国知局

本申请涉及计算机技术领域,尤其涉及一种区块链智能合约更新方法、装置及设备。

背景技术

智能合约是一种旨在以信息化方式传播、验证或执行合同的计算机协议,允许在没有第三方的情况下进行可信交易,这些交易可追踪且不可逆转。其实际上是由开发人员将协议明确的权利和义务以代码的形式呈现,基于此,一旦某个事件触发合约中的条款,代码即自动执行。

区块链技术是一种去中心化的分布式数据库技术。区块链中的每笔数据,都会广播至全网的区块链节点,每个节点都会保存全量的、一致的数据。区块链技术要求每个节点的状态保持一致,包括数据库的状态等。

区块链智能合约是指将智能合约以数字化的形式写入区块链中,不仅可以发挥智能合约在成本效率方面的优势、避免恶意行为对合约正常执行的干扰;还可以基于区块链技术的特性,保障存储、读取、执行整个过程透明可跟踪、不可篡改;还可以基于区块链自带的共识算法构建出一套状态机系统,使智能合约能够高效地运行。

而随着区块链和智能合约底层技术的不断成熟,区块链上将会迸发大规模的智能合约的应用,因此,需要为智能合约的开发迭代和部署提供一种灵活的更新机制。



技术实现要素:

本说明书实施例提供一种区块链智能合约更新方法、装置及设备,用于为智能合约的开发迭代和部署提供一种灵活的更新机制。

本说明书实施例提供一种区块链智能合约更新方法,包括:

接收第一交易节点发起的第一交易请求,所述第一交易请求用于请求将智能合约的更新信息提交上链,所述第一交易节点为所述智能合约的所有方对应的节点;

确定所述智能合约的安全级别,并基于所述安全级别对所述第一交易请求进行共识验证;

根据共识验证的结果响应或拒绝响应所述第一交易请求。

可选的,在接收第一交易节点发起的第一交易请求之前,还包括:

接收所述第一交易节点发起的第二交易请求,所述第二交易请求用于请求将所述智能合约提交上链,所述第二交易请求中包括所述安全级别;

对所述第二交易请求进行共识验证,并在共识验证的结果为通过时响应所述第二交易请求。

可选的,所述基于所述安全级别对所述第一交易请求进行共识验证包括:

基于所述安全级别,以及安全级别和更新规则之间预配置的对应关系,确定所述智能合约的更新规则;

基于所述更新规则对所述第一交易请求进行共识验证。

可选的,基于所述更新规则对所述第一交易请求进行共识验证包括:

当所述更新规则为第一类更新规则时,对所述更新信息上带有的签名进行共识验证;

若所述更新信息上带有所述第一交易节点的签名,则确定共识验证的结果为通过。

可选的,基于所述更新规则对所述第一交易请求进行共识验证包括:

当所述更新规则为第二类更新规则时,对所述更新信息上带有的签名进行共识验证;

若所述更新信息上带有目标交易节点的签名,则确定共识验证的结果为通过;

其中,所述目标交易节点包括:所述智能合约的参与方中的部分或全部对应的节点、以及所述第一交易节点。

可选的,基于所述更新规则对所述第一交易请求进行共识验证包括:

当所述更新规则为第三类更新规则时,确定所述共识验证的结果为未通过。

可选的,根据共识验证的结果响应或拒绝响应所述第一交易请求包括:

当共识验证的结果为通过时,响应所述第一交易请求;

当所述共识验证的结果为未通过时,拒绝响应所述第一交易请求。

可选的,所述第一交易请求包括存储节点的地址信息,所述存储节点中存储有所述智能合约;

其中,响应所述第一交易请求包括:

基于所述存储节点的地址信息,获取所述智能合约;

基于所述更新信息,对所述智能合约进行更新。

本说明书实施例还提供一种区块链智能合约更新装置,包括:

第一接收模块,用于接收第一交易节点发起的第一交易请求,所述第一交易请求用于请求将智能合约的更新信息提交上链,所述第一交易节点为所述智能合约的所有方对应的节点;

第一共识验证模块,用于确定所述智能合约的安全级别,并基于所述安全级别对所述第一交易请求进行共识验证;

第一响应模块,用于根据共识验证的结果响应或拒绝响应所述第一交易请求。

本说明书实施例还提供一种电子设备,包括:

处理器;以及

被安排成存储计算机可执行指令的存储器,所述可执行指令在被执行时使所述处理器执行以下操作:

接收第一交易节点发起的第一交易请求,所述第一交易请求用于请求将智能合约的更新信息提交上链,所述第一交易节点为所述智能合约的所有方对应的节点;

确定所述智能合约的安全级别,并基于所述安全级别对所述第一交易请求进行共识验证;

根据共识验证的结果响应或拒绝响应所述第一交易请求。

本说明书实施例还提供一种计算机可读存储介质,所述计算机可读存储介质存储一个或多个程序,所述一个或多个程序当被包括多个应用程序的电子设备执行时,使得所述电子设备执行以下操作:

接收第一交易节点发起的第一交易请求,所述第一交易请求用于请求将智能合约的更新信息提交上链,所述第一交易节点为所述智能合约的所有方对应的节点;

确定所述智能合约的安全级别,并基于所述安全级别对所述第一交易请求进行共识验证;

根据共识验证的结果响应或拒绝响应所述第一交易请求。

本说明书实施例采用的上述至少一个技术方案能够达到以下有益效果:

基于应用场景的不同需求,对智能合约的安全级别进行划分,得到多个不同特性的安全级别,例如:所有方无条件更新升级合约的级别、所有方有条件更新升级的级别、不可更新升级合约的级别等等。为各安全级别的智能合约配置合适的更新机制,以区别性地对不同安全级别的智能合约进行更新升级,与现有技术相比,能在不影响可信机制的基础上,有效提高智能合约的开发迭代和部署的灵活性。

附图说明

此处所说明的附图用来提供对本申请的进一步理解,构成本申请的一部分,本申请的示意性实施例及其说明用于解释本申请,并不构成对本申请的不当限定。在附图中:

图1为本说明书提供的一种应用场景的示意图;

图2为本说明书一实施例提供的一种区块链智能合约更新方法的流程示意图;

图3为本说明书一实施例提供的一种智能合约上链方法的流程示意图;

图4a和图4b为本说明书另一实施例提供的一种智能合约更新方法的示意图;

图5为本说明书一实施例提供的一种区块链智能合约更新装置的结构示意图;

图6为本说明书一实施例提供的一种电子设备的结构示意图。

具体实施方式

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

正如背景技术部分陈述的,现有技术中的区块链上可能会并发大规模的智能合约的应用,但现有的区块链上的智能合约的特性单一,无法满足不同应用场景的需求。例如:有些智能合约的“合约”属性很强,在合约建立之后任何一方均无权修改、撤回,即信奉“codeislaw”-代码就是法律;而若合约参与方后续想要更新升级该合约,则会出现无法更新升级的问题;还有些智能合约更像是传统意义上的构建在区块链这个分布式操作系统上的应用,合约所有方可随便对智能合约进行更新升级,但会出现可信机制被破坏的问题,例如:合约所有方能将参与方的合约金私自挪动。

由此可见,随着区块链上智能合约规模的不断增加,单一特性的智能合约显然越来越难以满足多应用场景的需求。

基于此,本发明提供一种区块链智能合约更新方法,通过对智能合约的安全级别进行划分,得到多个不同特性的安全级别,以与区块链上的不同应用场景的需求相适应,与现有技术相比,能在不影响可信机制的基础上,有效提高智能合约的开发迭代和部署的灵活性。

下面参见附图对本发明的应用场景进行示例性说明。

参见图1,其一种应用场景可以为:

区块链中包括节点1、节点2…节点6等等。其中,各节点上均配置有更新管理模块,该更新管理模块用于确定提交至本区块链上的智能合约的安全级别,以为后续更新升级智能合约提供基础。可选的,此处并不限定区块链上的节点的具体个数。

以节点1为第一智能合约的所有方(账号)对应的节点为例,在所有方需要对第一智能合约进行更新升级时,由节点1以交易请求的形式将更新信息请求提交上链。然后,区块链上的共识节点确定第一智能合约的安全级别,进而可基于该安全级别对应的合约特性对该交易请求进行共识验证,若通过共识验证,则允许更新信息上链,以对第一智能合约进行更新升级。

其中,共识验证是指通过特殊节点的投票,在很短的时间内完成对交易的验证和确认。

以下结合附图,详细说明本申请各实施例提供的技术方案。

图2为本说明书一实施例提供的一种区块链智能合约更新方法的流程示意图,参见图2,该方法具体可以包括如下步骤:

步骤22、接收第一交易节点发起的第一交易请求,所述第一交易请求用于请求将智能合约的更新信息提交上链,所述第一交易节点为所述智能合约的所有方对应的节点;

其中,该智能合约为已上链的智能合约;更新信息为对智能合约中的权利、义务、触发条款的条件等进行修改的信息,用于添加条款、删除条款等更新操作;所有方为具有该智能合约权限的账号,可以是合约参与方,也可以是合约参与方托管的第三方。

需要说明的是,在步骤22之前,还包括:智能合约上链步骤,结合图3,该步骤具体包括如下步骤:

步骤32、接收所述第一交易节点发起的第二交易请求,所述第二交易请求用于请求将所述智能合约提交上链;

其中,所述第二交易请求中包括所述智能合约的安全级别,所述安全级别为预配置的、用于表示所述智能合约对应的交易的风险程度大小的参数,安全级别越大则表明交易的风险越大,反之则表明当次交易的风险越小;所述智能合约上带有所述第一交易节点的签名。

需要说明的是,预配置安全级别步骤的第一种实现方式可以为:

在合约参与方制定或上传智能合同时,对应节点为合同参与方提供一安全级别选择框,安全级别选择框用于展示至少一个安全级别,由合约参与方协商从中选出一个安全级别作为该智能合约的安全级别。

预配置安全级别步骤的第二种实现方式可以为:

由对应节点为智能合约配置一默认的安全级别。具体可以示例如下:

示例1、对应节点扫描智能合约中的关键词,基于关键词评估合约所需的安全级别;具体地:

对应节点扫描智能合约确定其中的涉及金额、参与方类型(公司、单位、高校、个人等)、条款数量等等关键词;基于关键词对智能合约进行评估,确定其可能所需的安全级别,评估规则可以为:金额越多,所需安全级别越高;条款越多,所需安全级别越高;参与方类型所需的安全级别一般为公司>单位>高校>个人;

示例2、对应节点确定智能合约的合约种类,基于合约种类评估合约所需的安全级别;具体地:

对应节点扫描智能合约标头或扫描智能合约的内容,确定智能合约的合约种类;从经验值/专家建议等为各种合约种类配置的安全级别中选出该智能合约对应的安全级别。其中,各种合约种类配置的安全级别可以举例为:商务合约配置最高的安全等级;生活中常见的合约(例如:供用电、水、气、热力合约等)配置较低的安全等级。

其中,对应节点可以为合约参与方对应的节点,也可以为合约所有方对应的节点。

步骤34、对所述第二交易请求进行共识验;

需要说明的是,步骤34的一种实现方式可以为:

验证该智能合约上是否带有指定用户的签名且签名是否合法,若是,则确定共识验证结果为通过;若否,则确定共识验证结果为未通过;

其中,指定用户取决于智能合约的类别、制定时参与方的要求。

步骤36、在共识验证的结果为通过时响应所述第二交易请求。

即,在共识验证的结果为通过时,响应第二交易请求允许智能合约上链,以将该智能合约存入存储节点中;

可见,本实施例通过在上链智能合约之前,基于其应用场景的需求,预先为智能合约配置一合适的安全级别,进而可确定其更新机制,为后续合约的更新提供基础。

步骤24、确定所述智能合约的安全级别,并基于所述安全级别对所述第一交易请求进行共识验证;

即,本步骤基于不同类别的智能合约的特性,区别性地对智能合约进行共识验证,其一种实现方式可以为:

步骤s1、基于所述安全级别,以及安全级别和更新规则之间预配置的对应关系,确定所述智能合约的更新规则;

步骤s2、基于所述更新规则对所述所述第一交易请求进行共识验证。

对于步骤s1,需要说明的是,由于不同应用场景所需的智能合约的特性是不同的,例如:有些应用场景要求智能合约不可修改,有些应用场景要求智能合约可多方协作来修改。因此,本实施例中的安全级别和更新规则之间预配置的对应关系可以示例为包括:

第一安全级别(较低),其适用于弱合约强服务的应用场景,对应于第一类更新规则,即合约所有方可任意升级合约代码;

例如:在医疗机构部署合约,以维护用户个人健康数据的应用场景中,由于该合约并不会影响用户的自身利益,因此,一般情况下用户授权医疗机构后,医疗机构可任意升级合约。

第二安全级别(较高),其适用于多方协作的应用场景,对应于第二类更新规则,即合约所有方在得到全部或部分指定用户的签名后方可升级合约;

例如:在甲乙双方签约,并将合约托管给丙方的应用场景中,丙方作为合约所有方,在更新升级合约时,需要得到甲乙双方或至少一方的签名方方可有权进行合约更新升级。

第三安全级别(最高),其适用于区块链上大部分的应用场景,对应于第三类更新规则,即合约一经部署成功,无论是合约所有方还是其他用户均无法对其进行更新升级。可选的,可将第三安全级别作为区块链默认的安全级别。

另外,虽然此处仅示例了三种安全级别,但不难理解的是,安全级别是可灵活划分的,对应的更新规则也是可灵活配置的。因此,其他安全级别及其更新规则的划分也处于本实施例的保护范围之内。

基于步骤s1示例的安全级别和更新规则之间的对应关系,步骤s2中的共识验证步骤的第一种实现方式可以为:

若所述智能合约是第一安全级别的,则确定其更新规则为第一类更新规;进一步地,可基于所述第一类更新规则,对所述更新信息上带有的签名进行共识验证;若所述更新信息上带有所述第一交易节点的签名,则确定共识验证的结果为通过。

即,只要有合约所有方的签名即可通过验证,由此,可达到合约所有方在同一地址任意升级合约代码的目的。

共识验证步骤的第二种实现方式可以为:

若所述智能合约是第二安全级别的,则确定其更新规则为第二类更新规;进一步地,可基于所述第二类更新规则,对所述更新信息上带有的签名进行共识验证;若所述更新信息上带有目标交易节点的签名,则确定共识验证的结果为通过;其中,所述目标交易节点包括:所述第一交易节点和所述智能合约的参与方对应的节点。参与方可以是全部参与方,也可以是部分参与方;具体由所有参与方在制定智能合约时的更新要求而定。

共识验证步骤的第三种实现方式可以为:

若所述智能合约是第三安全级别的,则确定其更新规则为第三类更新规;进一步地,可基于所述第三类更新规则,确定所述共识验证的结果为未通过。

即,在共识节点确定该智能合约为不可更新的第三安全级别时,无需验证签名等信息直接确定验证不通过。

步骤26、根据共识验证的结果响应或拒绝响应所述第一交易请求。

不难理解的是,当共识验证的结果为未通过时,则拒绝响应该第一交易请求,不允许对该智能合约进行更新升级;

当共识验证的结果为通过时,则响应该第一交易请求,允许对该智能合约进行更新升级;

其中,更新升级智能合约的一种实现方式可以为:

获取所述第一交易请求中包括的存储节点的地址信息,所述存储节点中存储有所述智能合约;在共识验证结果为通过时,基于存储节点的地址信息,获取智能合约;基于所述更新信息,对所述智能合约进行更新。

其中,存储节点的作用是:存储交易节点之间交易时所用的智能合约,该存储节点可以为合约参与节点,也可以是其他节点。

可见,本实施例基于应用场景的不同需求,对智能合约的安全级别进行划分,得到多个不同特性的安全级别,例如:所有方无条件更新升级合约的级别、所有方有条件更新升级的级别、不可更新升级合约的级别等等。为各安全级别的智能合约配置合适的更新机制,以区别性地对不同安全级别的智能合约进行更新升级,与现有技术相比,能在不影响可信机制的基础上,有效提高智能合约的开发迭代和部署的灵活性。

图4a和图4b为本说明书另一实施例提供的一种智能合约更新方法的示意图,下面结合图4a和图4b对本方法进行示例性说明:

参见图4a,一种示例具体可以包括如下步骤:

步骤①、假设节点2和节点3之间发生交易,双方通过线下交互,以制定需要遵守的智能合约及其安全级别,并在智能合约上签名;

其中,智能合约可以举例为:

当第二天的最高温度大于38°时,节点2上的账户2向节点3上的账户3支付100元;

当第二天的最高温度小于等于38°时,节点3上的账户3向节点2上的账户2支付100元;

为便于后续更改,双方为智能合约配置的安全级别为第二安全级别。

步骤②、节点2或节点3将智能合约托管给节点1;

即,节点2和节点3共同委托可信的节点1为智能合约所有方。

步骤③、由节点1发起将该智能合约提交上链的交易请求;

由共识节点对该交易请求进行共识验证,若共识验证的结果为通过,则允许该智能合约上链,并将其存入存储节点;

其中,共识验证包括:验证智能合约上带有的节点1、节点2和节点3的签名是否合法;

步骤④、节点2和节点3通过线下交互,对合约的更新信息达成共识,在更新信息上签名;

例如:节点2和节点3对应的用户双方可能都觉得合约中的38°不合理,同意将38°改为35°,则由其中任一方构建合约更新信息(将38°改为35°),并签名;然后,向另一方发起更新合约的请求,另一方在验证更新信息无误且对方签名合法后,也签名;

步骤⑤、由节点2或节点3向节点1发起更新请求;

相应地,节点1首先查看该智能合约的安全级别及其对应的更新规则;然后,验证更新请求是否符合更新规则的要求;若是,则签名,并执行步骤⑥;

步骤⑥、发起将更新信息提交上链的交易请求;

由共识节点对该交易请求进行共识验证,若共识验证的结果为通过,则允许该更新信息上链,以基于存储节点的地址信息,查找到该智能合约,进而将合约中的38°修改为35°。

参见图4b,与图4a示出的示出的例子的不同之处在,本示例中步骤①④可以为在线上进行的。假设节点2为交易发起方,步骤①的实现方式可以简要说明如下:

节点2基于双方的权利和义务制定合约,并在签名后,向区块链发起第一交易请求,第一交易请求中携带节点3的身份信息;

节点3对节点2的签名和智能合约的内容进行验证,若验证通过,则在签名后,向区块链发起第二交易请求,第二交易请求中携带节点2的身份信息;

节点2对节点3的签名进行验证,若验证通过,则将带有节点2和节点3签名的智能合约托管给节点1,由节点1验证后提交上链。

步骤④的实现方式可以简要说明如下:

节点2基于需要修改的内容,制定智能合约的更新信息,并在签名后,向区块链发起第三交易请求,第三交易请求中携带节点3的身份信息;

节点3对节点2的签名和更新信息的内容进行验证,若验证通过,则在签名后,向区块链发起第四交易请求,第四交易请求中携带节点2的身份信息;

节点2对节点3的签名进行验证,若验证通过,则将带有节点2和节点3签名的更新信息托管给节点1,由节点1验证后提交上链。

可见,本实施例在上链智能合约之前为其配置一安全级别,由此,区块链可确定其对应的更新规则;进而,在后续更新该智能合约时,可基于其对应的更新规则进行共识验证,以达到对于不同安全级别的智能合约,采用其对应的更新规则进行更新升级。与现有技术相比,能在不影响可信机制的基础上,有效提高智能合约的开发迭代和部署的灵活性。

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

图5为本说明书一实施例提供的一种区块链智能合约更新装置的结构示意图,参见图5,该装置具体可以包括:第一接收模块51、第一共识验证模块52和第一响应模块53,其中:

第一接收模块51,用于接收第一交易节点发起的第一交易请求,所述第一交易请求用于请求将智能合约的更新信息提交上链,所述第一交易节点为所述智能合约的所有方对应的节点;

第一共识验证模块52,用于确定所述智能合约的安全级别,并基于所述安全级别对所述第一交易请求进行共识验证;

第一响应模块53,用于根据共识验证的结果响应或拒绝响应所述第一交易请求。

可选的,装置还包括:

第二接收模块,用于接收所述第一交易节点发起的第二交易请求,所述第二交易请求用于请求将所述智能合约提交上链,所述第二交易请求中包括所述安全级别;

第二共识验证模块,用于对所述第二交易请求进行共识验证;

第二响应模块,用于在共识验证的结果为通过时响应所述第二交易请求。

可选的,第一共识验证模块52,具体用于基于所述安全级别,以及安全级别和更新规则之间预配置的对应关系,确定所述智能合约的更新规则;基于所述更新规则对所述第一交易请求进行共识验证。

可选的,第一共识验证模块52,具体用于当所述更新规则为第一类更新规则时,对所述更新信息上带有的签名进行共识验证;若所述更新信息上带有所述第一交易节点的签名,则确定共识验证的结果为通过。

可选的,第一共识验证模块52,具体用于当所述更新规则为第二类更新规则时,对所述更新信息上带有的签名进行共识验证;若所述更新信息上带有目标交易节点的签名,则确定共识验证的结果为通过;

其中,所述目标交易节点包括:所述智能合约的参与方中的部分或全部对应的节点、以及所述第一交易节点。

可选的,第一共识验证模块52,具体用于当所述更新规则为第三类更新规则时,确定所述共识验证的结果为未通过。

可选的,第一响应模块53,具体用于当共识验证的结果为通过时,响应所述第一交易请求;当所述共识验证的结果为未通过时,拒绝响应所述第一交易请求。

可选的,所述第一交易请求包括存储节点的地址信息,所述存储节点中存储有所述智能合约;

相应地,第一响应模块53,具体用于当共识验证的结果为通过时,基于所述存储节点的地址信息,获取所述智能合约;基于所述更新信息,对所述智能合约进行更新。

可见,本实施例基于应用场景的不同需求,对智能合约的安全级别进行划分,得到多个不同特性的安全级别,例如:所有方无条件更新升级合约的级别、所有方有条件更新升级的级别、不可更新升级合约的级别等等。为各安全级别的智能合约配置合适的更新机制,以区别性地对不同安全级别的智能合约进行更新升级,与现有技术相比,能在不影响可信机制的基础上,有效提高智能合约的开发迭代和部署的灵活性。

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

应当注意的是,在本发明的装置的各个部件中,根据其要实现的功能而对其中的部件进行了逻辑划分,但是,本发明不受限于此,可以根据需要对各个部件进行重新划分或者组合。

图6为本说明书一实施例提供的一种电子设备的结构示意图,参见图6,该电子设备包括处理器、内部总线、网络接口、内存以及非易失性存储器,当然还可能包括其他业务所需要的硬件。处理器从非易失性存储器中读取对应的计算机程序到内存中然后运行,在逻辑层面上形成区块链智能合约更新装置。当然,除了软件实现方式之外,本申请并不排除其他实现方式,比如逻辑器件抑或软硬件结合的方式等等,也就是说以下处理流程的执行主体并不限定于各个逻辑单元,也可以是硬件或逻辑器件。

网络接口、处理器和存储器可以通过总线系统相互连接。总线可以是isa(industrystandardarchitecture,工业标准体系结构)总线、pci(peripheralcomponentinterconnect,外设部件互连标准)总线或eisa(extendedindustrystandardarchitecture,扩展工业标准结构)总线等。所述总线可以分为地址总线、数据总线、控制总线等。为便于表示,图6中仅用一个双向箭头表示,但并不表示仅有一根总线或一种类型的总线。

存储器用于存放程序。具体地,程序可以包括程序代码,所述程序代码包括计算机操作指令。存储器可以包括只读存储器和随机存取存储器,并向处理器提供指令和数据。存储器可能包含高速随机存取存储器(random-accessmemory,ram),也可能还包括非易失性存储器(non-volatilememory),例如至少1个磁盘存储器。

处理器,用于执行所述存储器存放的程序,并具体执行:

接收第一交易节点发起的第一交易请求,所述第一交易请求用于请求将智能合约的更新信息提交上链,所述第一交易节点为所述智能合约的所有方对应的节点;

确定所述智能合约的安全级别,并基于所述安全级别对所述第一交易请求进行共识验证;

根据共识验证的结果响应或拒绝响应所述第一交易请求。

上述如本申请图5所示实施例揭示的区块链智能合约更新装置或管理者(master)节点执行的方法可以应用于处理器中,或者由处理器实现。处理器可能是一种集成电路芯片,具有信号的处理能力。在实现过程中,上述方法的各步骤可以通过处理器中的硬件的集成逻辑电路或者软件形式的指令完成。上述的处理器可以是通用处理器,包括中央处理器(centralprocessingunit,cpu)、网络处理器(networkprocessor,np)等;还可以是数字信号处理器(digitalsignalprocessor,dsp)、专用集成电路(applicationspecificintegratedcircuit,asic)、现场可编程门阵列(field-programmablegatearray,fpga)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。可以实现或者执行本申请实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合本申请实施例所公开的方法的步骤可以直接体现为硬件译码处理器执行完成,或者用译码处理器中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器,闪存、只读存储器,可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器,处理器读取存储器中的信息,结合其硬件完成上述方法的步骤。

区块链智能合约更新装置还可执行图2-3的方法,并实现管理者节点执行的方法。

基于相同的发明创造,本申请实施例还提供了一种计算机可读存储介质,所述计算机可读存储介质存储一个或多个程序,所述一个或多个程序当被包括多个应用程序的电子设备执行时,使得所述电子设备执行图2-3对应的实施例提供的区块链智能合约更新方法。

本说明书中的各个实施例均采用递进的方式描述,各个实施例之间相同相似的部分互相参见即可,每个实施例重点说明的都是与其他实施例的不同之处。尤其,对于系统实施例而言,由于其基本相似于方法实施例,所以描述的比较简单,相关之处参见方法实施例的部分说明即可。

上述对本说明书特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下,在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外,在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中,多任务处理和并行处理也是可以的或者可能是有利的。

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

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

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

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

在一个典型的配置中,计算设备包括一个或多个处理器(cpu)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器,随机存取存储器(ram)和/或非易失性内存等形式,如只读存储器(rom)或闪存(flashram)。内存是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括,但不限于相变内存(pram)、静态随机存取存储器(sram)、动态随机存取存储器(dram)、其他类型的随机存取存储器(ram)、只读存储器(rom)、电可擦除可编程只读存储器(eeprom)、快闪记忆体或其他内存技术、只读光盘只读存储器(cd-rom)、数字多功能光盘(dvd)或其他光学存储、磁盒式磁带,磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质,可用于存储可以被计算设备访问的信息。按照本文中的界定,计算机可读介质不包括暂存电脑可读媒体(transitorymedia),如调制的数据信号和载波。

还需要说明的是,术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含,从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素,而且还包括没有明确列出的其他要素,或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下,由语句“包括一个……”限定的要素,并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。

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

以上所述仅为本申请的实施例而已,并不用于限制本申请。对于本领域技术人员来说,本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等,均应包含在本申请的权利要求范围之内。

当前第1页1 2 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1