CN115580412B - 基于区块链管理数字遗产的系统、方法和装置 - Google Patents

Abstract

本说明书实施例提供了基于区块链管理数字遗产的系统、方法和装置。区块链节点用于响应于接收到至少一个第一交易，对于每个第一交易，对其包括的基于属性加密算法生成的属性签名进行验证；在属性签名验证通过之后，区块链节点用于在合约状态中记录与属性签名策略对应的已证明账户列表；管理设备用于从合约状态获取与属性签名策略对应的已证明账户列表，并基于从区块链的合约状态中获取的属性签名策略对应的已证明账户列表的情况，向区块链节点发送用于分配目标账户的数字遗产的第二交易，其中，第二交易包括目标账户和接收账户；区块链节点用于接收和执行第二交易，将目标账户的数字遗产转移到接收账户。

Description

基于区块链管理数字遗产的系统、方法和装置

技术领域

本说明书实施例属于区块链技术领域，尤其涉及基于区块链管理数字遗产的系统，以及基于区块链管理数字遗产的方法和装置。

背景技术

区块链（Blockchain）是分布式数据存储、点对点传输、共识机制、加密算法等计算机技术的新型应用模式。区块链系统中按照时间顺序将数据区块以顺序相连的方式组合成链式数据结构，并以密码学方式保证的不可篡改和不可伪造的分布式账本。由于区块链具有去中心化、信息不可篡改、自治性等特性，区块链也受到人们越来越多的重视和应用。

随着互联网技术的飞速发展，应运而生的虚拟财产为整个社会带来了巨大的财富，越来越多的物品被虚拟数字替代，“数字遗产”应运而生，比如，数字人民币、NFT（Non-Fungible Token，非同质化通证）、账户、图文、音视频、游戏装备等等。当一个人离世之后，其现实生活中的财产（例如，房产、车等等）可以由其亲属继承，而存在于互联网的数字遗产的继承问题也是一个需要解决的难题。

发明内容

本说明书的一个或多个实施例描述了一种基于区块链管理数字遗产的系统，以及基于区块链管理数字遗产的方法和装置。

根据第一方面，提供了一种基于区块链管理数字遗产的系统，上述系统包括管理设备和区块链，区块链节点用于响应于接收到至少一个第一交易，对于每个第一交易，对其包括的基于属性加密算法生成的属性签名进行验证，其中，上述至少一个第一交易分别由至少一个第一账户发送，每个上述第一交易还包括上述属性签名对应的属性签名策略，上述属性签名策略包括一个或多个预设亲属关系，上述属性签名用于在验证通过的情况下指示上述第一账户与上述目标账户的亲属关系满足上述属性签名策略；在属性签名验证通过之后，区块链节点用于在合约状态中记录与属性签名策略对应的已证明账户列表；上述管理设备用于从上述合约状态获取与属性签名策略对应的已证明账户列表，并基于从区块链的合约状态中获取的属性签名策略对应的已证明账户列表的情况，向区块链节点发送用于分配上述目标账户的数字遗产的第二交易，其中，上述第二交易包括上述目标账户和接收账户；区块链节点用于接收和执行上述第二交易，将上述目标账户的数字遗产转移到上述接收账户。

根据第二方面，提供了一种基于区块链管理数字遗产的方法，应用于管理设备，上述管理设备包括基于属性加密算法生成的主公钥和主私钥，上述区块链中存储有上述管理设备基于上述主公钥、上述主私钥和预分配接收账户对应的亲属关系属性列表生成的预分配接收账户的关系子私钥，上述方法包括：基于从区块链的合约状态中获取的属性签名策略对应的已证明账户列表的情况，确定数字遗产的接收账户，其中，属性签名策略对应的已证明账户列表是上述区块链基于预分配接收账户发送的第一交易生成的，第一交易包括用于证明预分配接收账户与目标账户的亲属关系的关系证明信息，上述关系证明信息包括预分配接收账户、属性签名和上述属性签名对应的属性签名策略，上述属性签名是预分配接收账户基于上述属性签名策略和其关系子私钥进行属性签名得到的，在其亲属关系属性列表与上述属性签名策略相匹配的情况中，签名成功；向上述区块链发送用于分配上述目标账户的数字遗产的第二交易，上述第二交易包括上述目标账户和接收账户，以供上述区块链将上述目标账户的数字遗产转移到上述接收账户。

根据第三方面，提供了一种基于区块链管理数字遗产的装置，设置于管理设备，上述管理设备包括基于属性加密算法生成的主公钥和主私钥，上述区块链中存储有上述管理设备基于上述主公钥、上述主私钥和预分配接收账户对应的亲属关系属性列表生成的预分配接收账户的关系子私钥，上述装置包括：确定单元，配置为基于从区块链的合约状态中获取的属性签名策略对应的已证明账户列表的情况，确定数字遗产的接收账户，其中，属性签名策略对应的已证明账户列表是上述区块链基于预分配接收账户发送的第一交易生成的，第一交易包括用于证明预分配接收账户与目标账户的亲属关系的关系证明信息，上述关系证明信息包括预分配接收账户、属性签名和上述属性签名对应的属性签名策略，上述属性签名是预分配接收账户基于上述属性签名策略和其关系子私钥进行属性签名得到的，在其亲属关系属性列表与上述属性签名策略相匹配的情况中，签名成功；分配单元，配置为向上述区块链发送用于分配上述目标账户的数字遗产的第二交易，上述第二交易包括上述目标账户和接收账户，以供上述区块链将上述目标账户的数字遗产转移到上述接收账户。

根据第四方面，提供了一种计算机可读存储介质，其上存储有计算机程序，当上述计算机程序在计算机中执行时，令计算机执行如第二方面中任一实现方式描述的方法。

根据第五方面，提供了一种计算设备，包括存储器和处理器，其特征在于，上述存储器中存储有可执行代码，上述处理器执行上述可执行代码时，实现如第二方面中任一实现方式描述的方法。

根据本说明书的一个实施例提供的基于区块链管理数字遗产的系统，区块链节点用于对第一账户发送的第一交易的属性签名进行验证，属性签名用于在验证通过的情况下指示第一账户与目标账户的亲属关系满足属性签名对应的属性签名策略。在属性签名验证通过之后，区块链节点在合约状态中记录与属性签名策略对应的已证明账户列表。管理设备从合约状态获取与属性签名策略对应的已证明账户列表，并基于获取情况，向区块链发送用于分配目标账户的数字遗产的第二交易，第二交易包括接收账户。区块链执行第二交易，将目标账户的数字遗产转移到接收账户。由此，完成了目标账户的数字遗产的分配。

附图说明

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

图1示出了一个实施例中的区块链架构图；

图2示出了本说明书实施例中的基于区块链管理数字遗产的系统可以应用于其中的一个应用场景的示意图；

图3示出了以第一用户为例创建第一用户的数字身份的一个流程的示意图；

图4示出了本说明书实施例的基于区块链管理数字遗产的系统中用户A和目标亲属用户之间建立亲属关系的一个示例的时序图；

图5示出了基于区块链管理数字遗产的系统管理目标账户的数字遗产的一个示例的时序图；

图6示出了属性签名策略policy1的一个示意图；

图7示出了属性签名策略policy2的一个示意图；

图8示出了基于区块链管理数字遗产的系统管理目标账户的数字遗产的又一个示例的时序图；

图9示出了根据一个实施例的基于区块链管理数字遗产的装置的示意性框图。

具体实施方式

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

图1示出了一实施例中的区块链架构图。在图1所示的区块链架构图中，区块链100中包括N个节点，图1中示意示出了6个节点。节点之间的连线示意性的表示P2P（Peer toPeer，点对点）连接，所述连接例如可以为TCP连接等，用于在节点之间传输数据。这些节点上可存储全量的账本，即存储全部区块和全部账户的状态。其中，区块链中的每个节点可通过执行相同的交易而产生区块链中的相同的状态，区块链中的每个节点可存储相同的状态数据库。

区块链领域中的交易可以指在区块链中执行并记录在区块链中的任务单元。交易中通常包括发送字段（From）、接收字段（To）和数据字段（Data）。其中，在交易为转账交易的情况中，From字段表示发起该交易（即发起对另一个账户的转账任务）的账户地址，To字段表示接收该交易（即接收转账）的账户地址，Data字段中包括转账金额。

区块链中可提供智能合约的功能。区块链上的智能合约是在区块链系统上可以被交易触发执行的合约。智能合约可以通过代码的形式定义。在区块链中调用智能合约，是发起一笔指向智能合约地址的交易，使得区块链中每个节点分布式地运行智能合约代码。

在部署合约的场景中，例如，Bob将一个包含创建智能合约信息（即部署合约）的交易发送到如图1所示的区块链中，该交易的data字段包括待创建的合约的代码（如字节码或者机器码），交易的to字段为空，以表示该交易用于部署合约。节点间通过共识机制达成一致后，确定合约的合约地址“0x6f8ae93…”，各个节点在状态数据库中添加与该智能合约的合约地址对应的合约账户，分配与该合约账户对应的状态存储，并存储合约代码，将合约代码的哈希值保存在该合约的状态存储中，从而合约创建成功。

在调用合约的场景中，例如，Bob将一个用于调用智能合约的交易发送到如图1所示的区块链中，该交易的from字段是交易发起方（即Bob）的账户的地址，to字段为上述“0x6f8ae93…”，即被调用的智能合约的地址，交易的data字段包括调用智能合约的方法和参数。在区块链中对该交易进行共识之后，区块链中的各个节点可分别执行该交易，从而分别执行该合约，基于该合约的执行更新状态数据库。

区块链技术区别于传统技术的去中心化特点之一，就是在各个节点上进行记账，或者称为分布式记账，而不是传统的集中式记账。区块链系统要成为一个难以攻破的、公开的、不可篡改数据记录的去中心化诚实可信系统，需要在尽可能短的时间内做到分布式数据记录的安全、明确及不可逆。不同类型的区块链网络中，为了在各个记录账本的节点中保持账本的一致，通常采用共识算法来保证，即前述提到的共识机制。例如，区块链节点之间可以实现区块粒度的共识机制，比如在节点（例如某个独特的节点）产生一个区块后，如果产生的这个区块得到其它节点的认可，其它节点记录相同的区块。再例如，区块链节点之间可以实现交易粒度的共识机制，比如在节点（例如某个独特的节点）获取一笔区块链交易后，如果这笔区块链交易得到其他节点的认可，认可该区块链交易的各个节点可以分别将该区块链交易添加至自身维护的最新区块中，并且最终能够确保各个节点产生相同的最新区块。共识机制是区块链节点就区块信息（或称区块数据）达成全网一致共识的机制，可以保证最新区块被准确添加至区块链。当前主流的共识机制包括：工作量证明（Proof ofWork，POW）、股权证明（Proof of Stake，POS）、委任权益证明（Delegated Proof of Stake，DPOS）、实用拜占庭容错（Practical Byzantine Fault Tolerance，PBFT）算法等。其中，在各种共识算法中，通常在预设数目的节点对待共识的数据（即共识提议）达成一致之后，从而确定对该共识提议的共识成功。具体是，在PBFT算法中，对于N≥3f+1个共识节点，可容忍f个恶意节点，也就是说，当N个共识节点中2f+1个节点达成一致时，可确定共识成功。

如前所述，当一个人离世之后，其存在于互联网的数字遗产的继承问题是一个需要解决的难题。为此，本说明书的一个实施例提供了一种基于区块链管理数字遗产的系统，实现了对逝者的账户内数字遗产的分配。作为示例，图2示出了本说明书实施例的基于区块链管理数字遗产的系统可以应用于其中的一个应用场景的示意图。如图2所示，在本应用场景中，系统可以包括多个第一账户分别对应的设备201、管理设备202和区块链100。这里，管理设备202可以是管理机构对应的设备。各第一账户可以通过其对应的设备201向区块链100发送第一交易，第一交易可以包括基于属性加密算法生成的属性签名和属性签名对应的属性签名策略，属性签名策略可以包括多个预设亲属关系，该属性签名可以用于在验证通过的情况下，指示第一账户与目标账户的亲属关系满足属性签名策略。这里，目标账户为逝者生前所使用的账户。对于每个第一交易，区块链节点可以对该第一交易包括的属性签名进行验证，验证通过之后，在区块链100的智能合约的合约状态中记录与属性签名策略对应的已证明账户列表。管理设备202可以从合约状态中获取与各属性签名策略对应的已证明账户列表，基于获取情况，向区块链节点发送用于分配目标账户的数字遗产的第二交易，其中，第二交易包括目标账户和至少一个接收账户。区块链节点可以接收和执行第二交易，将目标账户的数字遗产转移到至少一个接收账户的账户内。由此，完成了逝者生前所使用的目标账户内数字遗产的继承。

用户在参与物理世界的活动时，会对应一个用于描述自己的身份，身份可以包括姓名、工作、学历、婚姻状态等等。同样，用户参与网络世界的活动时，也需要使用一个数字身份。数字身份可以是指描述一个用户的一组数据，是网络世界中关于一个用户的所有信息的总和。数字身份可以由各种各样的属性汇总而成，也就是说，数字身份可以通过属性描述，比如，姓名、身份标识、出生日期、出生地、工作地、职位、学历、证书编号、婚姻状态等等，属性组成了一个完整的身份实体。

作为示例，图3示出了以第一用户为例创建第一用户的数字身份的一个流程的示意图，其他用户也可以通过相同的方式创建数字身份。在图3所示的示例中，与区块链100进行交互的第一用户设备301和管理设备202中可以设置有加密模块，举例来说，可以设置有CP-ABE（ciphertextpolicy attribute based encryption，基于密文策略的属性加密）加密模块，CP-ABE的密文对应于一个访问策略，密钥对应属性集合，当且仅当属性集合中的属性能够满足此访问策略时才可对密文进行解密。具体创建第一用户的数字身份的过程可以如下所示：

S301，管理设备202生成主公钥和主私钥。

作为一个示例，管理设备202可以通过调用CP-ABE加密模块的Setup函数来生成主公钥和主私钥，主公钥可以上传到区块链100上公开，主私钥由管理设备202保管，不能泄露。作为另一个示例，也可以采用安全多方计算的方式来生成主公钥和主私钥，主私钥由多个管理设备202共同维护，需要使用主私钥时由多个管理设备202同时参与计算。主公钥和主私钥的生成过程可以如下：

CPABE_Setup(msk, mpk)，其中，mpk可以表示主公钥，msk可以表示主私钥。

S302，管理设备202向区块链100上传主公钥。

本实施例中，管理设备202可以向区块链100的任一区块链节点发送交易Tx1，该交易Tx1可由管理设备202对应的管理机构的区块链账户A1发送，账户A1对应于账户私钥systemSK和账户公钥systemPK，本例中，还可以称为系统公钥systemPK和系统私钥systemSK。私钥systemSK可用于生成交易Tx1的数字签名，公钥systemPK可用于对该数字签名进行验证。该交易Tx1可以调用区块链中的数据管理合约C1（下文中简称为合约C1），以向区块链上传主公钥。其中，该合约可由管理设备202部署到区块链中，以进行对区块链账户对应的数字身份的管理。上述区块链节点在接收到该交易之后将该交易发送给区块链中的其他节点，从而使得区块链中的各个节点可执行该交易。区块链的各个节点通过执行该交易，将主公钥存储到合约C1的合约状态中。

实践中，账户私钥systemSK和账户公钥systemPK组成的加密认证密钥对，可以支持非对称加密算法和签名算法，例如，椭圆曲线密码学（Elliptic curve cryptography，ECC）算法密钥，支持椭圆曲线数字签名算法（Elliptic Curve Digital SignatureAlgorithm，ECDSA）和椭圆曲线综合加密方案（elliptic curve integrate encryptscheme，ECIES）加解密算法。以ECC为例，可以通过调用KeyGen生成系统公钥systemPK和系统私钥systemSK，具体计算过程如下：

systemPK, systemSK = ECC_KeyGen()。

在一种实施方式中，交易Tx1中还可以包括账户A1对应的公钥，从而区块链100中的各个节点通过执行交易Tx1还将系统公钥systemPK存储到区块链中，系统公钥systemPK除了可用于验证账户A1的数字签名之外，其他设备还可以使用系统公钥systemPK对上传到区块链的数据进行加密，从而使得该数据只允许管理设备202通过使用系统私钥systemSK进行解密而获取到该数据。可以理解，区块链中的各个节点可以通过其他方式获取系统公钥systemPK，例如，可从管理机构的官方主页中获取，或者可以从秘钥管理机构获取等，对此不作限定。

S303，第一用户设备301可以在本地生成账户公钥accountPK和账户私钥accountSK。

账户公钥accountPK和账户私钥accountSK既是链上账户发起交易的签名公私钥，也是数据传输的加解密公私钥。第一用户需要对账户私钥accountSK进行安全保管。

S304，第一用户设备301向区块链100发送注册信息。

个人或者机构在使用区块链之前，需要在区块链上注册一个账户。为此，第一用户设备301可以向区块链100发送注册信息，该注册信息可以包括第一用户设备301生成的账户公钥accountPK。

S305，区块链100生成注册信息对应的用户账户。

区块链100可以通过调用接口生成注册信息对应的用户账户，具体的，

CreactChainAccount(AccountId, accountPK)。

S306，区块链100可以向第一用户设备301发送注册后的用户账户AccountId。

S307，用户账户AccountId通过第一用户设备301向区块链100发送账户认证信息。

在本实施例中，第一用户设备301可以向区块链100发送账户认证信息，以在区块链上将用户账户AccountId与实体身份进行关联，只有链上账户认证通过后才可以正常使用。这里，账户认证信息可以包括第一用户的用户身份信息。其中，第一用户的用户身份信息可以是与第一用户的身份相关的各种信息，包括但不限于姓名、昵称、身份唯一编号、证件图片、人脸图像等等。

实践中，管理机构可以对第一用户的用户身份信息进行身份校验和认证，例如，校验用户身份信息是否真实，又例如，校验身份唯一编号在链上是否已经存在认证账号，从而保证身份唯一编号在链上有唯一账号对应。为了使用户身份信息更加安全，第一用户设备301可以使用从区块链获取的系统公钥systemPK对第一用户的用户身份信息进行加密，并将加密后的用户身份信息上传到区块链100。以ECIES为例，可以通过调用ENCRYPT进行加密，具体的，

accountInfoCipher = ECIES_ENCRYPT(systemPK，accountInfo)。

其中，accountInfo表示第一用户的用户身份信息，accountInfoCipher表示加密后的第一用户的用户身份信息，即账户认证信息。之后，第一用户设备301调用合约上传accountInfoCipher，具体的，

RegisterAccount(accountInfoCipher)。

S308，管理设备202从区块链获取第一用户的用户身份信息。

这里，管理设备202可以监听链上的RegisterAccount合约调用事件，获取账户认证信息accountInfoCipher。之后，管理设备202可以使用系统私钥systemSK对获取的账户认证信息accountInfoCipher进行解密，具体的，

accountInfo = ECIES_DECRYPT(systemSK，accountInfoCipher)。

S309，管理设备202在对用户身份信息校验通过之后，对用户账户进行认证，认证通过，生成第一用户的身份属性列表；基于身份属性列表、主公钥和主私钥生成子私钥。

在本实施例中，管理设备202在对第一用户的用户身份信息校验通过之后，对用户账户进行认证，认证通过，可以基于第一用户的用户身份信息生成第一用户对应的身份属性列表Attrilist，该属性列表Attrilist中可以包括用户账户AccountId和用户身份属性。第一用户的身份属性列表Attrilist中可以包括第一用户的多个身份属性标签，身份属性标签可以是一类特征的总和，可以是描述第一用户的一组数据。作为示例，第一用户的身份属性列表中包括的属性可以用于描述第一用户的基本身份，例如，身份属性列表中可以包括但不限于用户账户AccountId、姓名、昵称、身份唯一编号等属性。之后，管理设备202可以基于身份属性列表Attrilist、主公钥和主私钥生成第一子私钥。举例来说，管理设备202可以通过CP-ABE的KeyGen函数生成第一用户设备301对应的子私钥sk，具体的，

AttriList: {AccountId, 姓名，身份唯一编号等属性}；

sk = CPABE_KeyGen(Attrilist, msk，mpk)。

由上式可知，对函数CPABE_keygen()的输入参数包括属性列表、msk和mpk，通过基于属性加密算法生成子私钥sk，该子私钥sk可用于基于签名策略进行属性签名，得到签名，以用于证明用户账户AccountId对应的第一用户具有身份属性列表中的特定属性（即满足签名策略），而mpk可用于基于签名策略验证该签名为真，即验证用户账户AccountId对应的第一用户具有属性列表中的特定属性。

S310，管理设备202将用户账户AccountId对应的身份属性列表、子私钥和认证状态上传至区块链100。

在本实施例中，管理设备202可以使用用户账户AccountId的公钥accountPK，加密用户账户AccountId对应身份属性列表Attrilist和子私钥sk，以ECIES为例，具体的，

accountCipher = ECIES_ENCRYPT(accountPK，AttriList，sk)。

管理设备202可以调用合约接口更新用户账户AccountId的认证状态，如果认证成功，一并上传用户账户AccountId对应的身份属性列表Attrilist和子私钥sk。具体的，

CertifyAccount(AccountId, accountCipher, status, accountPK)。

其中，status可以表示账户的认证状态，举例来说，如果账户认证通过，则status可以为“Certified”，如果账户认证失败，status可以为则“Init”。

S311，区块链节点与用户账户关联地存储用户账户对应的身份属性列表、子私钥和认证状态。

作为示例，管理设备202上传的用户账户AccountId对应身份属性列表、子私钥和认证状态可以存储在合约状态中，比如，可以专门设置一个accountInfoList列表来存储用户账户AccountId的信息，该accountInfoList列表中可以包含多条数据{ AccountId，status, accountPK，accountCipher}。

S312，第一用户设备301从区块链100获取其对应的身份属性列表、子私钥和认证状态，进行存储。

作为示例，第一用户设备301可以根据用户账户AccountId和公钥accountPK，从合约状态的accountInfoList列表上获取用户账户AccountId对应的认证状态，以及身份属性列表和子私钥对应的密文accountCipher。第一用户设备301可以使用公钥accountPK对应的私钥accountSK对获取的密文accountCipher进行解密，从而获取到身份属性列表AttriList和sk子私钥，具体的：

AttriList，sk = ECIES_DECRYPT(accountSK，accountCipher)。

由此，基于图3所示的流程，可以在区块链100中创建第一用户的数字身份。基于相同的方式还可以创建其他用户的数字身份。有了多个用户的数字身份之后，还可以继续完善用户之间的亲属关系。作为示例，用户之间的亲属关系也可以是以属性的形式表示。例如，针对每个数字身份可以设置一个亲属属性列表，该列表中可以包含与该数字身份有亲属关系的账户。

请继续参见图4，图4示出了本说明书实施例的基于区块链管理数字遗产的系统中用户A和目标亲属用户之间建立亲属关系的一个示例的时序图。本例中，用户A为目标亲属用户的父亲，父亲想要申请链上亲属关系。图4的时序图包括用户A对应的用户设备401、目标亲属用户对应的用户设备402、管理设备202和区块链100。

S401，用户A的用户账户AccountId1对应的用户设备401向区块链100上传亲属关系申请信息ApplyInfo。

本例中，亲属关系申请信息ApplyInfo可以包括目标亲属账户AccountId2和亲属关系“儿子”，如，{ AccountId2，“儿子”}。作为示例，为了保证信息的安全，可以使用管理机构的系统公钥systemPK对亲属关系申请信息ApplyInfo进行加密后，具体的，

ApplyInfoCipher = ECIES_ENCRYPT(systemPK，ApplyInfo)，

之后，上传至区块链100，举例来说，可以调用接口存储到合约状态，具体的，

ApplyRelation(ApplyInfoCipher)。

S402，管理设备202从区块链100获取亲属关系申请信息。

本例中，管理设备202可以监听链上的ApplyRelation合约调用事件，从而获取用户账户AccountId1上传的亲属关系申请信息。如果亲属关系申请信息是加密的，可以使用系统私钥systemSK对获取的亲属关系申请信息进行解密，具体的，

ApplyInfo = ECIES_DECRYPT(systemSK，ApplyInfoCipher)。

S403，管理设备202获取用户账户AccountId1和目标亲属账户AccountId2对应的实体身份信息，并基于获取的实体身份信息对亲属关系申请信息进行验证；验证通过，针对用户账户AccountId1和目标亲属账户AccountId2分别生成对应的亲属关系属性标签，并更新AccountId1和目标亲属账户AccountId2对应的亲属关系属性列表；基于主公钥、主私钥和对应的亲属关系属性列表，分别生成用户账户AccountId1和目标亲属账户AccountId2对应的关系子私钥。

本例中，管理设备202可以通过多种方式获取用户账户AccountId1和目标亲属账户AccountId2对应的实体身份信息。例如，可以通过用户账户AccountId1和目标亲属账户AccountId2之前上传的账户认证信息获取，账户认证信息中包括用户的用户身份信息。之后，基于用户身份信息对亲属关系申请信息进行验证，例如，可以通过权威身份管理机构中记录的信息，验证AccountId1和AccountId2的实体身份信息对应的亲属关系是否与亲属关系申请信息一致，例如，本例中，校验AccountId1和AccountId2是否为父子关系。

验证通过后，可以为用户账户AccountId1和目标亲属账户AccountId2分别分配亲属关系属性标签，亲属关系属性标签是一类亲属关系的总和，格式可以为{“关系”：“对应链上账户”}，例如，某个账户的亲属关系属性标签可以如，{“配偶”：“AccountIdX”,“儿子”：“AccountIdY”，“女儿”：“AccountIdZ”}。

本例中，用户A为目标亲属用户的父亲，因此，可以为用户A的用户账户AccountId1分配亲属关系属性标签{“儿子”：“AccountId2”}，为目标亲属用户的目标亲属账户AccountId2分配关系属性标签{“父亲”：“AccountId1”}。

之后，根据分配的亲属关系属性标签可以分别更新用户账户AccountId1和目标亲属账户AccountId2对应的亲属关系属性列表RelationAttriList。亲属关系属性列表RelationAttriList是一个亲属关系属性的列表集合。管理设备202还可以基于主公钥、主私钥和对应的亲属关系属性列表RelationAttriList，分别生成用户账户AccountId1和目标亲属账户AccountId2对应的关系子私钥relationSK。具体的，

relationSK = CPABE_KeyGen(RelationAttriList, msk，mpk)。

S404，管理设备202将用户账户和目标亲属账户对应的亲属关系属性列表和关系子私钥上传到区块链100。

本例中，为了保护信息的安全，可以使用用户账户AccountId1对应的公钥accountPK1对用户账户AccountId1对应亲属关系属性列表RelationAttriList1和关系子私钥relationSK1进行加密。使用目标亲属账户AccountId2对应的公钥accountPK2对目标亲属账户AccountId2对应亲属关系属性列表RelationAttriList2和关系子私钥relationSK2进行加密，具体的，

accountRelationCipher1 = ECIES_ENCRYPT(accountPK1，RelationAttriList1，relationSK1)；

accountRelationCipher2 = ECIES_ENCRYPT(accountPK2，RelationAttriList2，relationSK2)。

可选的，管理设备202还可以生成RelationAttriList1和RelationAttriList2的哈希值，具体的，

RelationAttriListHash1 = HASH(RelationAttriList1)，

RelationAttriListHash2 = HASH(RelationAttriList2)。

之后，管理设备202可以调用合约接口，上传用户账户和目标亲属账户对应的亲属关系属性列表、关系子私钥和亲属关系属性列表的哈希值。具体的，

RelateAccount(AccountId1, accountRelationCipher1,RelationAttriListHash1)，

RelateAccount(AccountId2, accountRelationCipher2,RelationAttriListHash2)。

S405，区块链节点接收用户账户和目标亲属账户对应的亲属关系属性列表和关系子私钥，与用户账户关联的存储其对应的亲属关系属性列表和关系子私钥，与目标亲属账户关联的存储其对应的亲属关系属性列表和关系子私钥。

本例中，区块链可以将用户账户和目标亲属账户对应的亲属关系属性列表和关系子私钥存储在合约状态，例如，可以存储在合约状态中的accountRelationInfoList列表中，accountRelationInfoList列表中可以存储多条数据，每条包含数据{ AccountId,accountRelationCipher, RelationAttriListHash}。由此，在区块链100中与用户账户关联的存储用户账户对应的亲属关系属性列表、关系子私钥和亲属关系属性列表的哈希值，与目标亲属账户关联的存储目标亲属账户对应的亲属关系属性列表、关系子私钥和亲属关系属性列表的哈希值。

S406，用户账户从区块链100获取其对应的亲属关系属性列表和关系子私钥，并进行存储。

本例中，用户账户AccountId1可以根据AccountId和accountPK从合约状态的accountRelationInfoList列表中获取自身对应的亲属关系属性列表和关系子私钥的密文accountRelationCipher，并使用自身的账户私钥accountSK进行解密，得到对应的亲属关系属性列表和关系子私钥，进行存储。具体的，

RelationAttriList1，relationSK1 = ECIES_DECRYPT(accountSK1，accountRelationCipher1)。

S407，目标亲属账户从区块链100获取其对应的亲属关系属性列表和关系子私钥，并进行存储。

本例中，目标亲属账户AccountId2可以根据AccountId和accountPK从合约状态的accountRelationInfoList列表中获取自身对应的亲属关系属性列表和关系子私钥的密文accountRelationCipher，并使用自身的账户私钥accountSK进行解密，得到对应的亲属关系属性列表和关系子私钥，进行存储。具体的，

RelationAttriList2，relationSK2 = ECIES_DECRYPT(companySK2，accountRelationCipher2)。

由此，基于图4所示的流程，可以在区块链100中创建用户账户和目标亲属账户的亲属关系。基于相同的方式还可以创建其他账户之间的亲属关系。

基于创建的数字身份和亲属关系，可以管理逝世用户的数字遗产。如图5所示，图5示出了基于区块链管理数字遗产的系统管理目标账户的数字遗产的一个示例的时序图。在本示例中，区块链系统中未存储目标账户对应的遗产分配规则，也就是说，目标账户的对应的用户生前没有向区块链上传用于分配自己数字遗产的遗嘱。此时，需要基于区块链上的亲属关系来分配目标账户的数字遗产。作为示例，当目标账户对应的用户去世时，具体用于分配目标账户的数字遗产的过程可以如下所示：

S501，第一账户501向区块链100发送第一交易Tx1。

本例中，第一账户501可以是与目标账户有亲属关系的账户。第一交易Tx1可以包括基于属性加密算法生成的属性签名，以及与属性签名对应的属性签名策略。这里，属性签名策略可以包括一个或多个预设亲属关系，属性签名用于在验证通过的情况下指示第一账户501与目标账户的亲属关系满足第一交易所包括的属性签名策略。

属性签名可以是第一账户基于属性签名策略和第一账户的关系子私钥进行属性签名得到的。第一账户的关系子私钥可以由管理设备基于主公钥、主私钥和第一账户对应的亲属关系属性列表生成，亲属关系属性列表可以包括多项，每项可以包括第二账户，以及第二账户对应的用户与第一账户对应的用户之间的亲属关系，属性签名可以在第一账户的亲属关系属性列表和属性签名策略相匹配的情况中成功生成。

第一账户501对应的用户为了证明自己具有目标账户的数字遗产的继承资格，可以向区块链发送证明信息，该证明信息可以包括属性签名，可以使用基于属性的签名（attribute-based signature，ABS）进行属性签名。ABS是一种公钥签名验证算法，用户的密钥和签名结构取决于属性。只有当用户密钥的属性集（包括多个属性标签）与签名策略相匹配时，才能签名并验证成功。本例中，属性签名策略可以与法定继承顺序对应，根据法定继承顺序可以设置多个属性签名策略，例如，可以针对第一继承顺序设置属性签名策略policy1，针对第二继承顺序设置属性签名策略policy2。作为示例，属性签名策略policy1和属性签名策略policy2的结构可以是树状结构。继续参考图6，图6示出了属性签名策略policy1的一个示意图，policy1 = (1 of 5){配偶、儿子、女儿、父亲、母亲}，基于属性签名策略policy1得到的属性签名，只有当第一账户501对应的亲属关系属性列表中包括的亲属关系属性与policy1相匹配时，才能签名并验证成功。继续参考图7，图7示出了属性签名策略policy2的一个示意图，policy2= (1 of 8){兄、弟、姐、妹、祖父、祖母、外祖父、外祖母}，基于属性签名策略policy2得到的属性签名，只有当第一账户501对应的亲属关系属性列表中包括的亲属关系属性与policy2相匹配时，才能签名并验证成功。

第一账户501对应的用户可以根据与逝者的亲属关系选择属性签名策略policy。例如，如果是逝者的儿子或者女儿，可以选择使用第一继承顺序对应的属性签名策略policy1计算生成属性签名sign，具体的，

policy = policy1，

data = HASH(policy)，

sign = ABS_Sign(relationSK，policy，data)。

其中，relationSK可以表示第一账户对应的关系子私钥。

第一账户501可以通过发送第一交易上传证明信息，第一交易中的证明信息可以包括账户accountID、属性签名sign和生成属性签名时使用的属性签名策略policy。作为示例，第一账户501可以调用合约接口上传证明信息，具体的，

CertifyRelation(accountID，sign，policy)。

实践中，由于可能有多个用户具有继承逝者数字遗产的继承资格，因此，区块链可能会接收到多个账户发送的多个用于上传证明信息的交易。

实践中，第一账户501对应的用户在实现生活中获知目标账户对应的用户逝世后，可以在区块链上主动发送第一交易，以证明自己具有目标账户的数字遗产的继承资格。

在一些可选的实现方式中，当目标账户对应的用户逝世后，在区块链中未存储目标账户对应的遗产分配规则的情况下，管理设备202可以向区块链发送用于上传遗产预分配信息的第三交易，其中，遗产预分配信息可以包括被分配数字遗产对应的目标账户和预分配接收账户。这里，遗产预分配信息可以是管理设备202基于本地存储的目标账户对应的亲属关系属性列表生成的。例如，可以将亲属关系属性列表中的、具有继承资格的账户作为预分配接收账户。也就是说，遗产预分配信息中的预分配接收账户可以是指具有继承资格的账户，发送第一交易的第一账户可以为预分配接收账户。

之后，区块链节点可以执行第三交易，在区块链100上存储遗产预分配信息。这样，区块链中的账户可以获取到该遗产预分配信息，而遗产预分配信息中的预分配接收账户对应的用户可以获知自己具有目标账户的数字遗产的继承资格。预分配接收账户可以发送第一交易，以进一步证明自己具有目标账户的数字遗产的继承资格，同时可以证明自己的继承顺序。

实践中，管理设备可以基于本地存储的目标账户对应的亲属关系属性列表直接生成遗产预分配信息。更优的，为了保证本地存储的目标账户对应的亲属关系属性列表是准确的，未被恶意篡改过，管理设备也可以在对本地存储的目标账户对应的亲属关系属性列表进行验证后，基于验证后的目标账户对应的亲属关系属性列表生成遗产预分配信息。具体的：

1),管理设备从区块链获取预存的目标账户对应的亲属关系属性列表的哈希值，并基于该哈希值确定本地预先存储的目标账户对应的亲属关系属性列表是否正确。

举例来说，管理设备可以从区块链获取目标账户的亲属关系属性信息{AccountId, accountRelationCipher, RelationAttriListHash}，同时，管理设备也可以计算本地存储的目标账户对应的亲属关系属性列表的哈希值，并将计算得到的哈希值与从区块链获取的RelationAttriListHash进行对比，如果两者一致，则表示本地存储的目标账户对应的亲属关系属性列表正确，未被篡改过。

2），响应于确定本地存储的目标账户对应的亲属关系属性列表正确，基于目标账户对应的亲属关系属性列表和法定继承顺序生成遗产预分配信息。

由此，使用验证过的亲属关系属性列表生成遗产预分配信息，可以使生成的遗产预分配信息更加准确。

S502，对于每个第一交易，区块链节点可以对该第一交易包括的基于属性加密算法生成的属性签名进行验证，在属性签名验证通过之后，在合约状态中记录与属性签名策略对应的已证明账户列表。

可选的，区块链节点可以基于第一交易中的属性签名策略policy和预先获取的主公钥mpk对第一交易中的属性签名sign进行验证，具体的，

data = HASH(policy)，

result = ABS_Verify(mpk，policy，data，sign)。

只有result为true的情况下，验证通过，才能证明第一账户与目标账户的亲属关系满足第一交易中的属性签名策略policy。

针对每一个属性签名策略，合约状态中可以存储有该属性签名策略对应的已证明账户列表，该已证明账户列表中包括验证通过的、与目标账户的亲属关系满足该属性签名策略的账户。以第一继承顺序对应的属性签名策略policy1为例，policy1对应的已证明账户列表中可以包括验证通过的、与目标账户的亲属关系满足第一继承顺序的账户。

S503，管理设备202从合约状态获取与属性签名策略对应的已证明账户列表。

S504，管理设备202基于从区块链的合约状态中获取的属性签名策略对应的已证明账户列表的情况，向区块链100的区块链节点发送用于分配目标账户的数字遗产的第二交易Tx2，其中，第二交易Tx2可以包括目标账户和接收账户。

本例中，第二交易Tx2中可以包括多个接收账户，多个接收账户可以形成一个接收账户列表，例如，RelationList = {accountID10, accountID20, accountID30...}。管理设备202可以通过调用合约接口发送第二交易Tx2，具体的，

Distribute(accountID， RelationList)。

第二交易Tx2可以触发智能合约的遗产分配，智能合约会根据RelationList对目标账户的数字遗产进行分配。

实践中，管理设备202可以基于从合约状态中获取的属性签名策略对应的已证明账户列表的情况，确定接收账户。

在一种情况中，如果合约状态中各属性签名策略对应的已证明账户列表为空，即，没有账户证明自己具有目标账户的数字遗产的继承资格。比如，目标账户对应的逝者没有亲属，或者亲属不愿继承逝者的数字遗产。此时，管理设备202可以基于存储的目标账户对应的亲属关系属性列表和法定继承顺序，确定第二交易Tx2中的接收账户。也就是说，按照法律规定的继承顺序和继承比例，将目标账户的数字遗产分配给与目标账户具有亲属关系的账户。

在另一种情况中，如果合约状态中某一个或者多个属性签名策略对应的已证明账户列表不为空，即，有账户证明自己具有目标账户的数字遗产的继承资格。此时，管理设备202可以从区块链100获取属性签名策略对应的已证明账户列表，并根据属性签名策略对应的已证明账户列表和法定继承顺序，确定第二交易Tx2中的接收账户。举例来说，可以将法定继承顺序靠前的属性签名策略对应的已证明账户列表中的账户作为第二交易Tx2的接收账户。例如，假设第一继承顺序对应属性签名策略policy1，第二继承顺序对应属性签名策略policy2，第三继承顺序对应属性签名策略policy3。如果policy1、policy2和policy3对应的已证明账户列表都不为空，则可以将policy1对应的已证明账户列表中的账户作为第二交易Tx2的接收账户；如果policy1对应的已证明账户列表为空，policy2和policy3对应的已证明账户列表都不为空，则可以将policy2对应的已证明账户列表中的账户作为第二交易Tx2的接收账户。

S505，区块链节点接收和执行第二交易Tx2，将目标账户的数字遗产转移到接收账户。

本例中，区块链节点可以接收和执行第二交易Tx2，通过调用智能合约将目标账户的数字遗产转移到接收账户。作为示例，当有多个接收账户时，可以将目标账户的数字遗产平均分配给多个接收账户。可选的，在转移数字遗产之后，还可以向接收账户发送资产转移信息，以通知接收账户对应的用户查看账户接收遗产的情况。

回顾以上过程，在本说明书的上述实施例中，区块链节点用于对第一账户发送的第一交易的属性签名进行验证，属性签名用于在验证通过的情况下指示第一账户与目标账户的亲属关系满足属性签名对应的属性签名策略。在属性签名验证通过之后，区块链节点在合约状态中记录与属性签名策略对应的已证明账户列表。管理设备从合约状态获取与属性签名策略对应的已证明账户列表，并基于获取情况，向区块链发送用于分配目标账户的数字遗产的第二交易，第二交易包括接收账户。区块链执行第二交易，将目标账户的数字遗产转移到接收账户。由此，在逝者生前未上传遗产分配规则的情况下，实现了目标账户的数字遗产的分配。

继续参见图8，如图8所示，图8示出了基于区块链管理数字遗产的系统管理目标账户的数字遗产的又一个示例的时序图。在图8所示的示例中，目标账户对应的用户生前向区块链存储了用于分配自己数字遗产的遗产分配规则。此时，可以根据目标账户对应的遗产分配规则来分配目标账户的数字遗产。具体用于分配目标账户的数字遗产的过程可以如下所示：

S801，目标账户801向区块链上传遗产分配规则。

本例中，在符合法律要求的情况下，目标账户801对应的用户可以按照个人意愿设置遗产分配规则，用于分配自己的数字遗产。举例来说，遗产分配规则中可以约定：资产类型、接收账户、分配比例等信息。例如，一个用户可以约定遗产分配规则DistributionRule为：

{

链上全部资产

[

Account1: 50%，

Account2: 30%，

Account3: 20%，

]

}。

实践中，如果用户的遗产分配规则填写不规范，用于上传该遗产分配规则的链上交易会直接报错，不更新链上信息。遗产分配规则可以直接发送到区块链上进行存储，例如，存储到合约状态。举例来说，合约状态中可以设置有一个DistributionRuleList列表，专门用来存储用户的遗产分配规则。DistributionRuleList列表中可以包含数据{accountID，DistributionRule}。如果用户的账户已经存在历史遗产分配规则，则使用最新的遗产分配规则覆盖更新历史遗产分配规则。

S802，在区块链100中存储有目标账户对应的遗产分配规则的情况下，管理设备202发送用于分配目标账户的数字遗产的第四交易。

本例中，如果目标账户对应的用户在生前已往区块链存储了遗产分配规则，那么在目标账户对应的用户逝世后，管理设备202可以向区块链发送第四交易，以触发链上对目标账户的数字遗产的分配。举例来说，管理设备202可以通过调用合约接口发送第四交易，具体的，

Distribute(accountID)。

S803，区块链节点执行第四交易，基于目标账户的遗产分配规则中的接收账户和分配比例对目标账户的数字遗产进行转移。

可选的，在转移数字遗产之后，还可以向接收账户发送资产转移信息，以通知接收账户对应的用户查看账户接收遗产的情况。

回顾以上过程，在本说明书的上述实施例中，区块链节点基于区块链中存储的目标账户的遗产分配规则对目标账户的数字遗产进行转移。由此，在目标账户对应的用户生前上传了遗产分配规则的情况下，完成了目标账户的数字遗产的分配。

本说明书示出了一个实施例的基于区块链管理数字遗产的方法，该方法可以应用于管理设备。其中，管理设备可以通过任何具有计算、处理能力的装置、设备、平台、设备集群来执行。其中，管理设备可以包括基于属性加密算法生成的主公钥和主私钥，区块链中存储有管理设备基于主公钥、主私钥和预分配接收账户对应的亲属关系属性列表生成的预分配接收账户的关系子私钥。基于此，该基于区块链管理数字遗产的方法，可以包括以下步骤：

步骤一，基于从区块链的合约状态中获取的属性签名策略对应的已证明账户列表的情况，确定数字遗产的接收账户。

在本实施例中，属性签名策略对应的已证明账户列表可以是区块链基于预分配接收账户发送的第一交易生成的。第一交易中可以包括用于证明预分配接收账户与目标账户的亲属关系的关系证明信息，该关系证明信息可以包括预分配接收账户、属性签名和属性签名对应的属性签名策略。属性签名是预分配接收账户基于属性签名策略和其关系子私钥进行属性签名得到的，在其亲属关系属性列表与属性签名策略相匹配的情况中，签名成功。

在一些可选的实现方式中，属性签名策略可以与法定继承顺序对应，以及上述步骤一可以具体如下进行：

判断合约状态中属性签名策略对应的已证明账户列表是否为空。

如果合约状态中属性签名策略对应的已证明账户列表不为空，则根据属性签名策略对应的已证明账户列表和法定继承顺序，确定接收账户。

如果合约状态中各属性签名策略对应的已证明账户列表为空，则基于本地存储的目标账户对应的亲属关系属性列表和法定继承顺序，确定接收账户。

步骤二，向区块链发送用于分配目标账户的数字遗产的第二交易。

在本实施例中，第二交易可以包括目标账户和接收账户。区块链节点可以接收和执行第二交易，并将目标账户的数字遗产转移到接收账户。

在一些可选的实现方式中，上述基于区块链管理数字遗产的方法还可以包括以下内容：

1），响应于确定区块链中未存储目标账户对应的遗产分配规则，生成目标账户对应的遗产预分配信息。

可选的，目标账户对应的遗产预分配信息，可以通过以下方式生成：a),从区块链获取目标账户对应的亲属关系属性列表的哈希值，基于哈希值确定本地预先存储的目标账户对应的亲属关系属性列表是否正确。b)，响应于确定本地存储的目标账户对应的亲属关系属性列表正确，基于本地存储的目标账户对应的亲属关系属性列表和法定继承顺序生成遗产预分配信息。

2），向区块链发送用于上传遗产预分配信息的第三交易，其中，遗产预分配信息包括被分配数字遗产对应的目标账户和预分配接收账户。

根据另一方面的实施例，提供了一种基于区块链管理数字遗产的装置，设置于管理设备，其中，管理设备可以是任何具有计算、处理能力的设备、平台或设备集群。

图9示出了根据一个实施例的基于区块链管理数字遗产的装置的示意性框图。上述管理设备包括基于属性加密算法生成的主公钥和主私钥，上述区块链中存储有上述管理设备基于上述主公钥、上述主私钥和预分配接收账户对应的亲属关系属性列表生成的预分配接收账户的关系子私钥，上述装置900包括：确定单元901，配置为基于从区块链的合约状态中获取的属性签名策略对应的已证明账户列表的情况，确定数字遗产的接收账户，其中，属性签名策略对应的已证明账户列表是上述区块链基于预分配接收账户发送的第一交易生成的，第一交易包括用于证明预分配接收账户与目标账户的亲属关系的关系证明信息，上述关系证明信息包括预分配接收账户、属性签名和上述属性签名对应的属性签名策略，上述属性签名是预分配接收账户基于上述属性签名策略和其关系子私钥进行属性签名得到的，在其亲属关系属性列表与上述属性签名策略相匹配的情况中，签名成功；分配单元902，配置为向上述区块链发送用于分配上述目标账户的数字遗产的第二交易，上述第二交易包括上述目标账户和接收账户，以供上述区块链将上述目标账户的数字遗产转移到上述接收账户。

在本实施例的一些可选的实现方式中，装置900还包括：生成单元（图中未示出），配置为响应于确定上述区块链中未存储上述目标账户对应的遗产分配规则，生成上述目标账户对应的遗产预分配信息；发送单元（图中未示出），配置为向上述区块链发送用于上传上述遗产预分配信息的第三交易，其中，上述遗产预分配信息包括被分配数字遗产对应的目标账户和预分配接收账户。

在本实施例的一些可选的实现方式中，上述生成单元进一步配置为：从上述区块链获取上述目标账户对应的亲属关系属性列表的哈希值，基于上述哈希值确定本地预先存储的上述目标账户对应的亲属关系属性列表是否正确；响应于确定本地存储的上述目标账户对应的亲属关系属性列表正确，基于上述目标账户对应的亲属关系属性列表和法定继承顺序生成遗产预分配信息。

在本实施例的一些可选的实现方式中，属性签名策略与法定继承顺序对应，确定单元901进一步配置为：响应于确定上述合约状态中属性签名策略对应的已证明账户列表不为空，根据属性签名策略对应的已证明账户列表和法定继承顺序，确定接收账户；响应于确定上述合约状态中属性签名策略对应的已证明账户列表为空，基于存储的上述目标账户对应的亲属关系属性列表和法定继承顺序，确定接收账户。

根据另一方面的实施例，还提供一种计算机可读存储介质，其上存储有计算机程序，当上述计算机程序在计算机中执行时，令计算机执行基于区块链管理数字遗产的方法。

根据再一方面的实施例，还提供一种计算设备，包括存储器和处理器，其特征在于，上述存储器中存储有可执行代码，上述处理器执行上述可执行代码时，实现基于区块链管理数字遗产的方法。

在20世纪90年代，对于一个技术的改进可以很明显地区分是硬件上的改进（例如，对二极管、晶体管、开关等电路结构的改进）还是软件上的改进（对于方法流程的改进）。然而，随着技术的发展，当今的很多方法流程的改进已经可以视为硬件电路结构的直接改进。设计人员几乎都通过将改进的方法流程编程到硬件电路中来得到相应的硬件电路结构。因此，不能说一个方法流程的改进就不能用硬件实体模块来实现。例如，可编程逻辑器件（Programmable Logic Device, PLD）（例如现场可编程门阵列（Field Programmable GateArray，FPGA））就是这样一种集成电路，其逻辑功能由用户对器件编程来确定。由设计人员自行编程来把一个数字系统“集成”在一片PLD上，而不需要请芯片制造厂商来设计和制作专用的集成电路芯片。而且，如今，取代手工地制作集成电路芯片，这种编程也多半改用“逻辑编译器（logic compiler）”软件来实现，它与程序开发撰写时所用的软件编译器相类似，而要编译之前的原始代码也得用特定的编程语言来撰写，此称之为硬件描述语言（Hardware Description Language，HDL），而HDL也并非仅有一种，而是有许多种，如ABEL（Advanced Boolean Expression Language）、AHDL（Altera Hardware DescriptionLanguage）、Confluence、CUPL（Cornell University Programming Language）、HDCal、JHDL（Java Hardware Description Language）、Lava、Lola、MyHDL、PALASM、RHDL（RubyHardware Description Language）等，目前最普遍使用的是VHDL（Very-High-SpeedIntegrated Circuit Hardware Description Language）与Verilog。本领域技术人员也应该清楚，只需要将方法流程用上述几种硬件描述语言稍作逻辑编程并编程到集成电路中，就可以很容易得到实现该逻辑方法流程的硬件电路。

控制器可以按任何适当的方式实现，例如，控制器可以采取例如微处理器或处理器以及存储可由该（微）处理器执行的计算机可读程序代码（例如软件或固件）的计算机可读介质、逻辑门、开关、专用集成电路（Application Specific Integrated Circuit，ASIC）、可编程逻辑控制器和嵌入微控制器的形式，控制器的例子包括但不限于以下微控制器：ARC 625D、Atmel AT91SAM、Microchip PIC18F26K20 以及Silicone Labs C8051F320，存储器控制器还可以被实现为存储器的控制逻辑的一部分。本领域技术人员也知道，除了以纯计算机可读程序代码方式实现控制器以外，完全可以通过将方法步骤进行逻辑编程来使得控制器以逻辑门、开关、专用集成电路、可编程逻辑控制器和嵌入微控制器等的形式来实现相同功能。因此这种控制器可以被认为是一种硬件部件，而对其内包括的用于实现各种功能的装置也可以视为硬件部件内的结构。或者甚至，可以将用于实现各种功能的装置视为既可以是实现方法的软件模块又可以是硬件部件内的结构。

上述实施例阐明的系统、装置、模块或单元，具体可以由计算机芯片或实体实现，或者由具有某种功能的产品来实现。一种典型的实现设备为服务器系统。当然，本申请不排除随着未来计算机技术的发展，实现上述实施例功能的计算机例如可以为个人计算机、膝上型计算机、车载人机交互设备、蜂窝电话、相机电话、智能电话、个人数字助理、媒体播放器、导航设备、电子邮件设备、游戏控制台、平板计算机、可穿戴设备或者这些设备中的任何设备的组合。

虽然本说明书一个或多个实施例提供了如实施例或流程图所述的方法操作步骤，但基于常规或者无创造性的手段可以包括更多或者更少的操作步骤。实施例中列举的步骤顺序仅仅为众多步骤执行顺序中的一种方式，不代表唯一的执行顺序。在实际中的装置或终端产品执行时，可以按照实施例或者附图所示的方法顺序执行或者并行执行（例如并行处理器或者多线程处理的环境，甚至为分布式数据处理环境）。术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、产品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、产品或者设备所固有的要素。在没有更多限制的情况下，并不排除在包括所述要素的过程、方法、产品或者设备中还存在另外的相同或等同要素。例如若使用到第一，第二等词语用来表示名称，而并不表示任何特定的顺序。

为了描述的方便，描述以上装置时以功能分为各种模块分别描述。当然，在实施本说明书一个或多个时可以把各模块的功能在同一个或多个软件和/或硬件中实现，也可以将实现同一功能的模块由多个子模块或子单元的组合实现等。以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

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

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

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

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

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

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

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

本说明书一个或多个实施例可以在由计算机执行的计算机可执行指令的一般上下文中描述，例如程序模块。一般地，程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等等。也可以在分布式计算环境中实践本本说明书一个或多个实施例，在这些分布式计算环境中，由通过通信网络而被连接的远程处理设备来执行任务。在分布式计算环境中，程序模块可以位于包括存储设备在内的本地和远程计算机存储介质中。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。在本说明书的描述中，参考术语“一个实施例”、“一些实施例”、“示例”、“具体示例”、或“一些示例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特点包含于本说明书的至少一个实施例或示例中。在本说明书中，对上述术语的示意性表述不必须针对的是相同的实施例或示例。而且，描述的具体特征、结构、材料或者特点可以在任一个或多个实施例或示例中以合适的方式结合。此外，在不相互矛盾的情况下，本领域的技术人员可以将本说明书中描述的不同实施例或示例以及不同实施例或示例的特征进行结合和组合。

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

Claims (21)

1.一种基于区块链管理数字遗产的系统，其中，所述系统包括管理设备和区块链，区块链节点用于响应于接收到至少一个第一交易，对于每个第一交易，对其包括的基于属性加密算法生成的属性签名进行验证，其中，生成属性签名时所涉及的属性包括亲属关系属性，其中，所述至少一个第一交易分别由至少一个第一账户发送，每个所述第一交易还包括所述属性签名对应的属性签名策略，所述属性签名策略包括一个或多个预设亲属关系，所述属性签名用于在验证通过的情况下指示所述第一账户与目标账户的亲属关系满足所述属性签名策略；

在属性签名验证通过之后，区块链节点用于在合约状态中记录与属性签名策略对应的已证明账户列表，其中，所述已证明账户列表中的已证明账户包括属性签名验证通过的、与目标账户的亲属关系满足所述已证明账户列表对应的属性签名策略的账户；

所述管理设备用于从所述合约状态获取与属性签名策略对应的已证明账户列表，并基于从区块链的合约状态中获取的属性签名策略对应的已证明账户列表的情况，向区块链节点发送用于分配所述目标账户的数字遗产的第二交易，其中，所述第二交易包括所述目标账户和接收账户；

区块链节点用于接收和执行所述第二交易，将所述目标账户的数字遗产转移到所述接收账户。

2.根据权利要求1所述的系统，其中，所述管理设备包括基于属性加密算法生成的主公钥和主私钥，所述属性签名是所述第一账户基于属性签名策略和其关系子私钥进行属性签名得到的，所述关系子私钥由所述管理设备基于所述主公钥、所述主私钥和所述第一账户对应的亲属关系属性列表生成，所述亲属关系属性列表包括多项，每项包括第二账户、以及所述第二账户对应的用户与所述第一账户对应的用户之间的亲属关系，所述属性签名在所述亲属关系属性列表与所述属性签名策略相匹配的情况中成功生成。

3.根据权利要求1所述的系统，其中，区块链节点还用于基于属性签名策略和预先获取的主公钥对所述属性签名进行验证。

4.根据权利要求1所述的系统，其中，所述管理设备还用于在所述区块链中未存储被分配数字遗产的目标账户对应的遗产分配规则的情况下，向所述区块链发送上传遗产预分配信息的第三交易，其中，所述遗产预分配信息包括被分配数字遗产对应的目标账户和预分配接收账户，其中，所述第一账户为预分配接收账户；

区块链节点用于执行所述第三交易，存储所述遗产预分配信息。

5.根据权利要求4所述的系统，其中，所述管理设备还用于：

从区块链获取预存的目标账户对应的亲属关系属性列表的哈希值，基于所述哈希值确定本地预先存储的目标账户对应的亲属关系属性列表是否正确；

响应于确定本地存储的所述目标账户对应的亲属关系属性列表正确，基于所述目标账户对应的亲属关系属性列表和法定继承顺序生成遗产预分配信息。

6.根据权利要求1所述的系统，其中，所述管理设备还用于在所述合约状态中各属性签名策略对应的已证明账户列表为空的情况下，基于存储的所述目标账户对应的亲属关系属性列表和法定继承顺序，确定所述第二交易中的接收账户。

7.根据权利要求1所述的系统，其中，属性签名策略与法定继承顺序对应，以及所述管理设备还用于在所述合约状态中属性签名策略对应的已证明账户列表不为空的情况下，从所述区块链获取属性签名策略对应的已证明账户列表，根据属性签名策略对应的已证明账户列表和法定继承顺序，确定所述第二交易中的接收账户。

8.根据权利要求1所述的系统，所述管理设备还用于在所述区块链中存储有所述目标账户对应的遗产分配规则的情况下，发送用于分配所述目标账户的数字遗产的第四交易，其中，所述第四交易包括所述目标账户，所述遗产分配规则包括接收账户和分配比例；

区块链节点执行所述第四交易，基于所述目标账户的遗产分配规则中的接收账户和分配比例对所述目标账户的数字遗产进行转移。

9.根据权利要求2所述的系统，其中，所述系统还包括用户账户，所述用户账户用于向所述区块链上传亲属关系申请信息，其中，所述亲属关系申请信息包括目标亲属账户和亲属关系；

所述管理设备还用于从所述区块链获取所述亲属关系申请信息；

所述管理设备还用于：获取所述用户账户和所述目标亲属账户对应的实体身份信息，基于获取的实体身份信息对所述亲属关系申请信息进行验证；验证通过，针对所述用户账户和所述目标亲属账户分别生成对应的亲属关系属性标签，并更新所述用户账户和所述目标亲属账户对应的亲属关系属性列表；基于所述主公钥、所述主私钥和对应的亲属关系属性列表，分别生成所述用户账户和所述目标亲属账户对应的关系子私钥；将所述用户账户和所述目标亲属账户对应的亲属关系属性列表和关系子私钥上传到所述区块链；

区块链节点用于接收所述用户账户和所述目标亲属账户对应的亲属关系属性列表和关系子私钥；与所述用户账户关联的存储其对应的亲属关系属性列表和关系子私钥，与所述目标亲属账户关联的存储其对应的亲属关系属性列表和关系子私钥。

10.根据权利要求9所述的系统，其中，所述用户账户用于从所述区块链获取其对应亲属关系属性列表和关系子私钥，并进行存储。

11.根据权利要求9所述的系统，其中，所述目标亲属账户用于从所述区块链获取其对应的亲属关系属性列表和关系子私钥，并进行存储。

12.根据权利要求9所述的系统，其中，所述管理设备用于上传所述用户账户和所述目标亲属账户对应的亲属关系属性列表的哈希值；

区块链节点用于与所述用户账户关联的存储其对应的亲属关系属性列表的哈希值，与所述目标亲属账户关联的存储其对应的亲属关系属性列表的哈希值。

13.根据权利要求2所述的系统，其中，区块链节点用于接收用户设备发送的注册信息，其中，所述注册信息包括账户公钥；以及向所述用户设备发送注册后的用户账户；

区块链节点用于接收所述用户账户发送的账户认证信息，其中，所述账户认证信息包括用户身份信息；

所述管理设备用于从所述区块链获取所述用户身份信息，在对所述用户身份信息校验通过之后，对所述用户账户进行认证，认证通过，生成用户的身份属性列表，所述身份属性列表包括用户账户和用户身份属性；基于所述身份属性列表、所述主公钥和所述主私钥生成子私钥；上传所述用户账户对应的所述身份属性列表、所述子私钥和认证状态；

区块链节点与所述用户账户关联地存储所述身份属性列表、所述子私钥和所述认证状态。

14.根据权利要求13所述的系统，其中，所述用户设备用于从所述区块链获取其对应的所述身份属性列表、所述子私钥和所述认证状态，进行存储。

15.一种基于区块链管理数字遗产的方法，应用于管理设备，所述管理设备包括基于属性加密算法生成的主公钥和主私钥，所述区块链中存储有所述管理设备基于所述主公钥、所述主私钥和预分配接收账户对应的亲属关系属性列表生成的预分配接收账户的关系子私钥，所述方法包括：

基于从区块链的合约状态中获取的属性签名策略对应的已证明账户列表的情况，确定数字遗产的接收账户，其中，属性签名策略包括一个或多个预设亲属关系，属性签名策略对应的已证明账户列表是所述区块链基于预分配接收账户发送的第一交易生成的，第一交易包括用于证明预分配接收账户与目标账户的亲属关系的关系证明信息，所述关系证明信息包括预分配接收账户、属性签名和所述属性签名对应的属性签名策略，所述属性签名是预分配接收账户基于所述属性签名策略和其关系子私钥进行属性签名得到的，在其亲属关系属性列表与所述属性签名策略相匹配的情况中，签名成功，其中，生成属性签名时所涉及的属性包括亲属关系属性；

向所述区块链发送用于分配所述目标账户的数字遗产的第二交易，所述第二交易包括所述目标账户和接收账户，以供所述区块链将所述目标账户的数字遗产转移到所述接收账户。

16.根据权利要求15所述的方法，其中，所述方法还包括：

响应于确定所述区块链中未存储所述目标账户对应的遗产分配规则，生成所述目标账户对应的遗产预分配信息；

向所述区块链发送用于上传所述遗产预分配信息的第三交易，其中，所述遗产预分配信息包括被分配数字遗产对应的目标账户和预分配接收账户。

17.根据权利要求16所述的方法，其中，所述生成所述目标账户对应的遗产预分配信息，包括：

从所述区块链获取所述目标账户对应的亲属关系属性列表的哈希值，基于所述哈希值确定本地预先存储的所述目标账户对应的亲属关系属性列表是否正确；

响应于确定本地存储的所述目标账户对应的亲属关系属性列表正确，基于所述目标账户对应的亲属关系属性列表和法定继承顺序生成遗产预分配信息。

18.根据权利要求17所述的方法，其中，属性签名策略与法定继承顺序对应，所述基于从区块链的合约状态中获取的属性签名策略对应的已证明账户列表的情况，确定数字遗产的接收账户，包括：

响应于确定所述合约状态中属性签名策略对应的已证明账户列表不为空，根据属性签名策略对应的已证明账户列表和法定继承顺序，确定接收账户；

响应于确定所述合约状态中属性签名策略对应的已证明账户列表为空，基于存储的所述目标账户对应的亲属关系属性列表和法定继承顺序，确定接收账户。

19.一种基于区块链管理数字遗产的装置，设置于管理设备，所述管理设备包括基于属性加密算法生成的主公钥和主私钥，所述区块链中存储有所述管理设备基于所述主公钥、所述主私钥和预分配接收账户对应的亲属关系属性列表生成的预分配接收账户的关系子私钥，所述装置包括：

确定单元，配置为基于从区块链的合约状态中获取的属性签名策略对应的已证明账户列表的情况，确定数字遗产的接收账户，其中，属性签名策略包括一个或多个预设亲属关系，属性签名策略对应的已证明账户列表是所述区块链基于预分配接收账户发送的第一交易生成的，第一交易包括用于证明预分配接收账户与目标账户的亲属关系的关系证明信息，所述关系证明信息包括预分配接收账户、属性签名和所述属性签名对应的属性签名策略，所述属性签名是预分配接收账户基于所述属性签名策略和其关系子私钥进行属性签名得到的，在其亲属关系属性列表与所述属性签名策略相匹配的情况中，签名成功，其中，生成属性签名时所涉及的属性包括亲属关系属性；

分配单元，配置为向所述区块链发送用于分配所述目标账户的数字遗产的第二交易，所述第二交易包括所述目标账户和接收账户，以供所述区块链将所述目标账户的数字遗产转移到所述接收账户。

20.一种计算机可读存储介质，其上存储有计算机程序，当所述计算机程序在计算机中执行时，令计算机执行权利要求15-18中任一项所述的方法。

21.一种计算设备，包括存储器和处理器，其特征在于，所述存储器中存储有可执行代码，所述处理器执行所述可执行代码时，实现权利要求15-18中任一项所述的方法。

Images