Digital asset hosting system

Abstract

The invention relates to a digital asset hosting system. The digital asset hosting system comprises a consensus node device and a plurality of MPC node devices of the block chain system, the consensus node device comprises a plurality of verification nodes, the plurality of MPC node devices perform indirect communication through the consensus node device, and when any verification node receives to-be-transmitted information sent by the MPC node device, the to-be-transmitted information is transmitted to the MPC node device. And after the consensus node device synchronizes the to-be-transmitted information to the block chain system based on a preset consensus algorithm, the to-be-transmitted information is sent to the target MPC node device. By adopting the system, the network communication complexity can be reduced, the response efficiency can be improved, and compliance requirements and auditing can be met.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of electric communication, in particular to a digital asset custody system. BACKGROUND

[0002] With the rapid development of digital assets, people's demand for the safety, efficiency and compliance of digital asset custody wallets is increasingly urgent.

[0003] In the traditional technology, threshold signature technology provides strong technical support for the safety of digital asset custody wallets. However, the current threshold signature wallet often involves multiple rounds of complex interaction due to security considerations. Under the existing architecture, as the number of participants in the threshold signature increases, the complexity of the communication network also increases in a quadratic manner, resulting in increased network latency and complexity, which seriously reduces system performance. In addition, most current digital asset custody wallets do not integrate with compliance requirements, increasing the difficulty of integrating later compliance requirements.

[0004] Therefore, the current threshold signature wallet still has the problems of high network communication complexity, low response efficiency, lack of one-stop compliance verification and recommended audit. SUMMARY

[0005] Therefore, it is necessary to provide a digital asset custody system that can reduce network communication complexity, improve response efficiency, and meet compliance requirements and audit in view of the above technical problems.

[0006] The present application provides a digital asset custody system, which comprises a consensus node device of a blockchain system and a plurality of MPC node devices, the consensus node device comprises a plurality of verification nodes, and the plurality of MPC node devices indirectly communicate through the consensus node device.

[0007] When any verification node receives the to-be-transmitted information sent by the MPC node device, the consensus node device synchronizes the to-be-transmitted information to the blockchain system based on a preset consensus algorithm, and then sends the to-be-transmitted information to a target MPC node device.

[0008] In one embodiment, the preset consensus algorithm comprises:

[0009] In response to the current consensus stage, a plurality of verification nodes generate random seed information based on their own private keys; the random seed information comprises a verifiable random output value and a proof;

[0010] Each verification node scores based on a plurality of random seed information, and determines the verification node corresponding to the random seed information whose score meets a preset condition as a leader node;

[0011] The leader node generates or submits a target block based on the information to be transmitted.

[0012] In one of the embodiments, the generating the random seed information based on the private key of the node itself includes:

[0013] obtaining a current election round number and historical block information of the blockchain system, the current election round number being a round number for determining a leader node;

[0014] generating the random seed information based on the private key of the verification node, the historical block and the current election round number.

[0015] In one of the embodiments, the scoring based on the multiple random seed information and determining the verification node corresponding to the random seed information satisfying a preset condition as the leader node includes:

[0016] sending the random seed information generated by the node itself to other verification nodes and receiving the random seed information sent by other verification nodes;

[0017] verifying whether the verifiable random output value in the random seed information is correct based on the proof in the random seed information;

[0018] if yes, performing double hash processing based on the verifiable random output value, and calculating the score of each verification node based on a preset deterministic algorithm, the number of verification nodes, a preset weight factor and a random compensation factor, determining the verification node corresponding to the random seed information satisfying a preset condition as a potential leader node, and determining the leader node based on the potential leader nodes determined by the multiple verification nodes;

[0019] if no, rejecting the random seed information provided by the verification node and removing the verification node from the list of potential leader nodes.

[0020] In one of the embodiments, the determining the leader node based on the potential leader nodes determined by the multiple verification nodes includes:

[0021] if the number of verification nodes determined as potential leader nodes satisfies a preset threshold, the verification node is determined as the leader node;

[0022] if the number of all the verification nodes determined as potential leader nodes does not satisfy the preset threshold or exceeds a predefined election time, the current election round is incremented, the random seed information is regenerated by each verification node and the leader node is determined again until the leader node is determined.

[0023] In one of the embodiments, the generating or submitting a target block based on the information to be transmitted includes:

[0024] generating a pre-generation request or a pre-commit request corresponding to the target block;

[0025] broadcasting the pre-generation request or the pre-commit request to other verification nodes;

[0026] obtaining signature results generated by other verification nodes for the pre-generation request or the pre-commit request; if a plurality of the signature results satisfy aggregation conditions, obtaining an aggregated signature based on the plurality of the signature results; and broadcasting the aggregated signature to other verification nodes.

[0027] In one embodiment, when the to-be-transmitted information satisfies a preset triggering condition, the leader node is further configured to generate temporary random value information;

[0028] The MPC node device is further configured to: obtain the temporary random value information sent by the leader node; perform signature on a to-be-signed message based on the temporary random value information and a private key shard of the MPC node device to generate a signature share; send the signature share to other MPC node devices through the consensus node device; and obtain a signature result based on the signature share and signature shares from other MPC node devices.

[0029] In one embodiment, the to-be-transmitted information includes device running state.

[0030] When the MPC node device fails, the digital asset management system is further configured to restore the MPC node device to a state before the failure based on device running state corresponding to the MPC node device stored in the blockchain system.

[0031] In one embodiment, the digital asset management system further includes a key management device; the key management device runs in a trusted execution environment; and the number of the key management devices matches the number of the verification nodes.

[0032] In one embodiment, the digital asset management system further includes an identity information management device and an identity verification device; the identity information management device is in communication connection with an identity verification system, stores user identity information, and is configured to:

[0033] in response to verification demand information sent by the identity verification device, obtain an attribute value in the user identity information that matches the verification demand information and at least one Merkle tree path corresponding to the attribute value;

[0034] generate verification response information based on a user private key, the attribute value, and the Merkle tree path;

[0035] send the verification response information and an issuing authority public key to the identity verification device.

[0036] The identity verification device is also used for:

[0037] Based on the attribute value and the Merkle tree path, a first root hash value is calculated;

[0038] A second root hash value corresponding to the verification response information is obtained;

[0039] Based on the comparison result of the first root hash value and the second root hash value, and the attribute value, it is determined whether the verification response information is valid.

[0040] The digital asset management system, through the digital asset management system including the consensus node device of the blockchain system and the plurality of MPC node devices, the consensus node device includes a plurality of verification nodes, and the plurality of MPC node devices indirectly communicate through the consensus node device, when any one of the verification nodes receives the to-be-transmitted information sent by the MPC node device, the consensus node device synchronizes the to-be-transmitted information to the blockchain system based on a preset consensus algorithm, and then sends the to-be-transmitted information to the target MPC node device. Compared with the communication between the MPC node devices in the traditional technology through P2P, the complexity of network communication can be greatly reduced. Through the consensus algorithm of the decentralized consensus node device, the information sent by the MPC node device is consensus and chained, which can ensure the traceability of the multi-party secure computing process, so that timely data recovery can be performed when part of the nodes fail, and more complete audit data can be provided in response to the needs of the regulatory agency. To achieve fast and effective supervision, in this way, while maintaining the decentralized characteristics, the communication efficiency can be improved, and the security and robustness of the digital asset management system are improved, and the technical effects of reducing network communication complexity, improving response efficiency and meeting compliance requirements and auditing are achieved as a whole. BRIEF DESCRIPTION OF DRAWINGS

[0041] Figure 1 It is an application environment diagram of the digital asset management system in one embodiment;

[0042] Figure 2 It is a timing diagram of multi-party secure computing in one embodiment;

[0043] Figure 3 It is a timing diagram of multi-party secure computing in the traditional technology;

[0044] Figure 4 It is a stage diagram of multi-party secure computing in one embodiment;

[0045] Figure 5 It is a stage diagram of multi-party secure computing in the traditional technology;

[0046] Figure 6A schematic diagram of the architecture of multi-party secure computation in the prior art;

[0047] Figure 7 A schematic diagram of the architecture of a digital asset custody system in an embodiment;

[0048] Figure 8 A timing diagram of leader node election in an embodiment;

[0049] Figure 9 An internal structure diagram of a computer device in an embodiment. DETAILED DESCRIPTION

[0050] In order to make the purposes, technical solutions and advantages of the present application clearer, further detailed description will be made to the present application in combination with the drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present application and do not limit the present application.

[0051] In an embodiment, as shown in Figure 1 The present application provides a digital asset custody system, which comprises a consensus node device 2 of a blockchain 3 system and a plurality of MPC node devices 1, the consensus node device 2 comprises a plurality of verification nodes, and the plurality of MPC node devices 1 indirectly communicate through the consensus node device 2.

[0052] When any verification node receives the to-be-transmitted information sent by the MPC node device 1, the consensus node device 2 synchronizes the to-be-transmitted information to the blockchain 3 system based on a preset consensus algorithm, and then sends the to-be-transmitted information to a target MPC node device.

[0053] Among them, the MPC node device 1 can be a device participating in multi-party secure computation, which is used to complete a specific task (such as signature generation) through collaborative computation without leaking private data. The plurality of MPC nodes can be deployed through a distributed network.

[0054] In the embodiment, the MPC node device 1 indirectly communicates through the consensus node device 2 as a message queue. When the MPC node device 1 is ready to interact with other MPC node devices 1, it can send information to the consensus node device 2, and the consensus node device 2 forwards the sent information to the target MPC node device. The target MPC node device can be the MPC node device 1 to which the to-be-transmitted information is expected to be sent.

[0055] The consensus node device 2 can be a computing device participating in the network consensus process in the blockchain 3 system, which is used to create, receive and verify transaction information of new blocks. In the embodiment, the consensus node device 2 serves as a message queue, which, before sending the to-be-transmitted information to the target MPC node device, reaches a consensus on the to-be-transmitted information and stores the to-be-transmitted information in the block information of the blockchain 3 system.

[0056] In the embodiment, when any one of the verification nodes receives the to-be-transmitted information sent by the MPC node device 1, the consensus node device 2 sends the to-be-transmitted information to the target MPC node device after synchronizing the to-be-transmitted information to the blockchain 3 system based on a preset consensus algorithm.

[0057] The preset consensus algorithm can be an algorithm for achieving consistency among distributed nodes and is preset by the blockchain 3 system to ensure that all participants can reach a consensus on the validity of a transaction. The preset consensus algorithm can be an existing consensus algorithm, such as a delegated proof of stake, a Byzantine fault tolerance algorithm, a hybrid consensus mechanism, and the like, which are not limited in the embodiment.

[0058] Synchronizing the to-be-transmitted information to the blockchain 3 system can be creating a target block in the blockchain 3 system and submitting the to-be-transmitted information to the target block after the consensus algorithm is passed, that is, all participants reach a consensus on the to-be-transmitted information. The target block is a new block to be confirmed by consensus according to a block generation request and can include transaction data, a timestamp, and the like.

[0059] The digital asset custody system provided in the embodiment includes a consensus node device and a plurality of MPC node devices of a blockchain system. The consensus node device includes a plurality of verification nodes, and the plurality of MPC node devices indirectly communicate through the consensus node device. When any one of the verification nodes receives to-be-transmitted information sent by the MPC node device, the consensus node device sends the to-be-transmitted information to a target MPC node device after synchronizing the to-be-transmitted information to the blockchain system based on a preset consensus algorithm. Compared with the communication between MPC node devices through P2P in the prior art, the complexity of network communication can be greatly reduced. Through the consensus algorithm of the decentralized consensus node device, the information sent by the MPC node device is consensus and chained, which can ensure the traceability of the multi-party secure computing process, so that data recovery can be performed in time when some nodes fail, and more complete audit data can be provided in response to the needs of regulatory agencies to achieve fast and effective regulation. In this way, while maintaining the decentralized feature, the communication efficiency can be improved, and the security and robustness of the digital asset custody system can be improved, thereby achieving the technical effects of reducing network communication complexity, improving response efficiency, and meeting compliance requirements and audit.

[0060] In one of the embodiments, the preset consensus algorithm includes:

[0061] In response to the current consensus phase, the plurality of verification nodes generate random seed information based on their own private keys; the random seed information includes a verifiable random output value and a proof;

[0062] Each verification node scores based on multiple random seed information, and determines the verification node corresponding to the random seed information whose score meets a preset condition as a leader node;

[0063] The leader node generates or submits a target block based on the to-be-transmitted information.

[0064] The random seed information can be a generation result based on a pseudo-random number. In this embodiment, the random seed information can be a basis for electing a leader node. For example, the random seed information can be generated by a cryptography algorithm. The random seed information includes a verifiable random output value and a proof. The verifiable random output value can be an output value whose true source is verified, and the proof can be used as evidence for verification.

[0065] In an exemplary embodiment, the random seed information can be generated by using a VRF verifiable random function, so as to ensure randomness while allowing others to verify the validity of the result through a public key.

[0066] The leader node can be a verification node used for processing core business in a signature process. The determination of the verification node can be made by indirect communication of multiple verification nodes and common determination. The leader node can be generated in a distributed voting manner among verification nodes participating in generation and sending of random seed information.

[0067] Further, the leader node can be selected by each verification node obtaining random seed information of other verification nodes, verifying and electing according to a preset rule. In an exemplary embodiment, a hash value of the random seed information of each verification node can be generated by a hash function, and the leader node can be selected by sorting and taking the remainder of the hash value.

[0068] Further, the leader node can also be selected by multiple verification nodes following the same rule for determining the leader node. In an exemplary embodiment, the rule for determining the leader node can be to broadcast the random seed information to other nodes, each verification node verifies and scores the multiple random seed information, and selects the one with the highest score as the leader node. In another exemplary embodiment, the rule for determining the leader node is that each verification node judges whether it is possible to be a leader node according to the random seed information, and broadcasts the random seed information through a consensus node device, which is verified by multiple verification nodes, so as to elect the leader node.

[0069] The leader node is used to request the blockchain system to generate or submit a new block on behalf of all or part of the verification nodes. In different stages of the consensus process, the leader node can be replaced through a re-election mechanism, i.e., the work of pre-generating and submitting the target block can be completed by different leader nodes, for example, in two rounds, a plurality of verification nodes respectively generate random seed information based on their own private keys, and determine the same or different leader nodes through scoring, and the above leader nodes respectively complete the work of generating and submitting the target block.

[0070] In one embodiment, generating random seed information based on the private key includes:

[0071] Obtaining the current election round number and the historical block information of the blockchain system; the current election round number is the round number of determining the leader node;

[0072] Generating random seed information based on the private key of the verification node, the historical block and the current election round number.

[0073] The current election round number can be a round number used to identify the current election leader node in the system running, thereby ensuring the uniqueness of the random seed information in different rounds in time or sequence. For example, the current election round number can be stored in the blockchain system, so that it can be obtained by reading from the blockchain system.

[0074] The historical block can be the confirmed previous block data in the blockchain system. Using the historical block to generate random seed information can use the hash value of the latest block to generate random seed information. In this way, the verifiability and traceability of the election process can be ensured.

[0075] For example, each verification node can obtain the current election round number and the historical block data, and then use its own private key, the historical block data and the current election round number as input to generate a pseudo-random number and a corresponding mathematical proof through a verifiable random function (VRF) algorithm, and finally encapsulate the above content as random seed information. By combining the global state parameters of the system with the node private key, the unpredictability and tamper resistance of random seed generation can be enhanced, and the uniqueness and independence of each election stage can be ensured by the round number.

[0076] The digital asset custody system provided by the embodiment can significantly reduce the risk of the central node election being predicted or manipulated by taking the global state of the system and the time parameter into the random seed generation process as input parameters for generating random seed information; through the multi-link parameter verification mechanism, the possibility of malicious nodes destroying the credibility of the system by forging rounds or tampering with historical data can be reduced, thereby achieving the effect of improving the security and reliability of the digital asset custody system while maintaining the advantages of the decentralized architecture.

[0077] In one of the embodiments, the scoring is based on the plurality of random seed information, and the verification node corresponding to the random seed information whose score meets the preset condition is determined as the leader node, including:

[0078] sending the random seed information generated by itself to other verification nodes, and receiving the random seed information sent by other verification nodes;

[0079] verifying whether the verifiable random output value in the random seed information is correct based on the proof in the random seed information;

[0080] If yes, performing double hash processing based on the verifiable random output value, and calculating the score of each verification node based on the preset deterministic algorithm, the number of verification nodes, the preset weight factor and the random compensation factor, determining the verification node corresponding to the random seed information whose score meets the preset condition as a potential leader node, and determining the leader node based on the potential leader nodes determined by the plurality of verification nodes.

[0081] If no, rejecting the random seed information provided by the verification node, and removing the verification node from the potential leader node list.

[0082] The preset condition for the score can be the number or proportion of the highest score obtained by the verification node in other verification nodes, which exceeds the preset threshold or the preset proportion.

[0083] In one of the embodiments, the leader node is determined based on the potential leader nodes determined by the plurality of verification nodes, including:

[0084] If the number of verification nodes determined as potential leader nodes meets the preset threshold, the verification node is taken as the leader node.

[0085] If the number of all verification nodes determined as potential leader nodes does not meet the preset threshold or exceeds the predefined election time, the current election round is incremented, the random seed information is regenerated by each verification node, and the leader node is determined again until the leader node is determined.

[0086] The potential leader node can be a candidate verification node satisfying a preset screening condition, which can include a hash value sorting, a mathematical operation result, or the like to determine whether the verification node meets the condition. The verification result can be a determination information of other nodes on the legitimacy of the random seed information. For example, the verification result can be a binary feedback result of "verification passed" or "verification failed".

[0087] The preset threshold can be a minimum number or proportion requirement of the verification results returned by other verification nodes in the process of electing the leader node. For example, the preset threshold can be generated by system pre-configuration or dynamic negotiation. Further, the preset threshold can include more than 51% of the verification nodes, verification passed, or at least t nodes confirmed. The number of verification results can be the total number of verification results returned by other verification nodes collected and counted by the current verification node. In this embodiment, the leader node can be a verification node with the right to coordinate the calculation after being confirmed by the majority of nodes.

[0088] The leader node confirmation or round update is realized by comparing the number of verification results with the preset threshold. For example, when the number of verification results reaches the threshold, the current verification node can broadcast confirmation information containing its own identity and VRF proof to other verification nodes through the consensus node device; when the number of verification results does not reach the threshold, the current verification node increments the confirmation round counter and checks whether it exceeds the maximum round limit. If it does not exceed, a new round of election process is started, and the random seed information is regenerated. If the current confirmation round exceeds the maximum round limit, an abnormal handling mechanism such as forced random selection node or system suspension can be triggered. This process combines threshold-driven consensus confirmation and round control to ensure that the election of the leader node converges within a limited number of times, avoiding resource consumption caused by node abnormalities or network failures.

[0089] For example, if the number of verification nodes determined as potential leader nodes meets the preset threshold, the verification node can be used as the leader node. The current verification node can determine the preset threshold based on its own random seed information and the total number of verification nodes participating in the consensus, and determine whether the number of verification nodes determined as potential leader nodes meets the preset threshold, so as to use the verification node as the leader node.

[0090] If the condition is not met, the verification request of other verification nodes can also be received, and the matching of the random number and the proof is verified by the VRF public key. When the collected verification results exceed the preset threshold (for example, two-thirds majority), the corresponding verification node can be confirmed as the final leader node; if the threshold is not reached, the round update mechanism is triggered, the current confirmation round is incremented, and the election process is restarted.

[0091] In one specific embodiment, when any one of the verification nodes receives the information sent by the MPC node device, the verification node first saves the received information to be sent to the buffer pool, and synchronizes the information to the chain through the consensus of the aggregated signature, including: each verification node uses the private key held by itself to generate a corresponding verifiable random output value and proof, and then broadcasts the pair of data to other verification nodes in the network. After each verification node collects the verifiable random output and proof from other verification nodes, it can score and calculate the verifiable random result of each node according to a set of preset deterministic algorithms, thereby obtaining the final score of each node, and the node with the highest score is elected as the leader node in this round of consensus process.

[0092] The digital asset management system provided by the embodiment can determine whether the current verification node is a potential leader node based on the random seed information and the number of verification nodes, so as to quickly screen potential candidate nodes through quantitative rules and reduce the redundancy of global broadcasting; determine the leader node or update the round based on whether the number of verification results meets the condition based on a preset threshold; combine the dynamic round mechanism and the abnormal processing strategy to improve the determinacy and attack resistance of the central node election process; use the round increment and the re-election process to ensure that the system reaches consensus within a reasonable time, so as to optimize the resource utilization efficiency while maintaining the decentralized characteristics, and reduce the communication delay.

[0093] In one of the embodiments, based on the information to be transmitted, the generating or submitting the target block includes:

[0094] generating or submitting a pre-generation request or a pre-submission request corresponding to the target block;

[0095] broadcasting the pre-generation request or the pre-submission request to other verification nodes;

[0096] obtaining signature results generated by other verification nodes for the pre-generation request or the pre-submission request; if a plurality of signature results meet an aggregation condition, obtaining an aggregated signature based on the plurality of signature results; and broadcasting the aggregated signature to other verification nodes.

[0097] The pre-generation request can be an instruction containing new block metadata (such as previous block hash, timestamp, etc.) for triggering a consensus node device to create a new block. The leader node broadcasts the request to all non-leader verification nodes.

[0098] Further, after receiving the block generation request, the consensus node device can verify the legality of the block generation request according to the blockchain protocol rules. After verification, the consensus node generates the target block and broadcasts it to all verification nodes.

[0099] The signature result can be a signature fragment that is partially signed by the verification node based on the private key share for the target block, and needs to be combined with other private key shares based on other private key shares of other verification nodes to form a complete and correct signature result. It can be understood that the threshold signature technology requires at least t fragments to recover the complete signature, for example, implemented by using a Shamir secret sharing scheme. The Shamir secret sharing scheme can be a technology of dividing a private key into n shares and recovering the private key by t shares. For example, the Shamir secret sharing scheme can include a (3 of 5) threshold configuration.

[0100] Each verification node uses a private key to partially sign the pre-generation request or the pre-commit request to generate a signature fragment. Further, the signature result can be directly sent by the verification node to the leader node through the single-point directed network.

[0101] The aggregated signature is a result obtained by merging multiple signature results into a single signature. For example, based on the aggregation characteristics of the BLS (Boneh Lynn Shacham) signature, multiple signatures can be compressed into a fixed length. In one specific embodiment, the leader node merges multiple signature results into a complete signature by using a preset aggregation algorithm after collecting more than a threshold number of signature results. The threshold can refer to the minimum number of signature results required to generate a valid signature.

[0102] Further, the aggregated signature is broadcast to non-leader verification nodes. When a certain threshold number of non-leader verification nodes verify the aggregated signature information and confirm the block information, the block verification is completed and the block is written into the ledger of the non-leader verification nodes.

[0103] In one specific embodiment, the leader node is first responsible for constructing a pre-generation request for the current block and broadcasting it to all non-leader verification nodes. After receiving the pre-generation request, each non-leader node locally verifies the block content. If the verification is passed, the non-leader node signs the request using its own private key and returns the signature result to the leader node. When the leader node collects valid signatures from no less than two-thirds of the non-leader nodes, it aggregates the signatures using its own private key to generate an aggregated signature result. Subsequently, the aggregated signature is broadcast to all verification nodes. After receiving the aggregated signature, the non-leader verification node verifies it again. If the verification is passed, the consensus in the pre-generation stage is considered to be reached, and the pre-commit stage is entered.

[0104] In one embodiment, a new leader node is elected again after entering the block pre-commit stage. The leader node is responsible for generating a pre-commit request for a block and broadcasting it to all non-leader verification nodes. After receiving the pre-commit request, the non-leader verification nodes first verify the pre-commit content of the current block. If the verification is passed, the request is signed using the private key of the non-leader verification node, and the signature result is returned to the leader node. When the leader node receives valid signatures from no less than two-thirds of the non-leader nodes, it aggregates the signatures using its own private key to generate an aggregated signature result, which is broadcast to all verification nodes. After receiving the aggregated signature, the other verification nodes will verify it again. If the aggregated signature verification is passed, the pre-commit consensus is formally reached, and the final block information will be written into the blockchain. At the same time, the message from the MPC node device will also be recorded with the block and broadcast to all other MPC node devices, achieving state synchronization and data consistency.

[0105] In one embodiment, based on the verification results of other verification nodes, the current verification node is selected as the leader node, or the current confirmation round is updated, including:

[0106] If the number of verification results of other verification nodes meets the preset threshold, the current verification node is selected as the leader node.

[0107] If the number of verification results of other verification nodes does not meet the preset threshold, the current confirmation round is updated, and the leader node in the verification node is determined based on the random seed information.

[0108] In one embodiment, the MPC node device is further configured to:

[0109] In the pre-signing stage, a random multiplication triple is generated offline based on a preset protocol.

[0110] In the online interaction stage, the random multiplication triple and the private key shards are used to sign the message to be signed to generate a signature share; the signature share is sent to other MPC node devices through the consensus node device; and based on the signature share and the signature share from other MPC node devices, the final signature result is obtained through aggregation calculation.

[0111] In the embodiment, the multi-party secure computation is improved and divided into a pre-signing stage and an online interaction stage. The pre-signing stage is used to pre-generate the computing resources required for multi-party secure computation, thereby significantly reducing the number of interactions required in the online interaction stage and improving the computing efficiency while ensuring the validity of the signature.

[0112] The random multiplication triple can be three elements (a, b, c) satisfying a multiplication relationship, where c = a * b. In the process of generating the random multiplication triple, each element has randomness and unpredictability. For example, the generation of the triple can be distributed by secret sharing technology to allocate the generation task and verify the correctness.

[0113] The preset protocol can be a set of rules for distributed generation of random multiplication triples, used to ensure the correctness, randomness of the triple, and the inability of the participating nodes to individually derive the values of the other elements. For example, the protocol can include steps such as exchanging data between nodes through encrypted communication, verifying whether c is equal to the product of a and b, etc. For example, the preset protocol can use a protocol based on homomorphic encryption and secret sharing. Based on the preset protocol to generate a random multiplication triple, the steps of performing secret sharing tasks, encrypted communication to verify the correctness of the triple, and ensuring privacy protection can be performed by each node to hide intermediate calculation values and reduce the number of interactions between nodes.

[0114] The private key fragment can be a private key fragment divided by threshold signature technology, such as independent fragments generated based on Shamir secret sharing, each of which needs to meet a threshold condition to recover the complete private key.

[0115] The signature fragment can be a partial signature result generated by combining the private key fragment with the random multiplication triple elements to sign the message to be signed by the MPC node device, which needs to be combined with the fragments of other nodes to form a valid signature. For example, the signature fragment can include an intermediate signature value generated by an encryption algorithm and a proof of the legality of the source.

[0116] Generating a signature fragment based on a random multiplication triple and a private key fragment can be achieved by multiplying the private key fragment with the triple elements, then performing an encryption algorithm (such as an elliptic curve signature algorithm), hiding intermediate data using the triple multiplication relationship, and adding a digital signature to prove the legality of the source, thereby improving the security of the private key fragment while reducing communication overhead.

[0117] Generating an aggregated signature based on a preset signature algorithm can be achieved by verifying whether the number of fragments exceeds the threshold, checking the legality of the fragments and triple verification information, and merging valid fragments using a BLS algorithm to obtain an aggregated signature, thereby quickly filtering valid data and reducing the amount of signature data.

[0118] The digital asset management system provided in this embodiment can prevent private key fragments from being exposed due to intermediate value leakage by the multiplication relationship of the random multiplication triple and the privacy protection mechanism, thereby improving key security. By reducing the number of direct interactions between nodes through a preset protocol and combining the encrypted transmission method of signature fragments, the network communication complexity can be reduced, thereby achieving the technical effects of improving privacy security, communication efficiency, and improving the reliability of signature aggregation.

[0119] In one of the embodiments, when the information to be transmitted satisfies a preset triggering condition, the leader node is further configured to generate temporary random value information;

[0120] The MPC node device is further configured to: obtain the temporary random value information sent by the leader node; based on the temporary random value information and the private key shard of the MPC node device, sign the message to be signed to generate a signature share; send the signature share to other MPC node devices through the consensus node device; and based on the signature share and the signature share from other MPC node devices, obtain a signature result.

[0121] The temporary random value information can be a random value R agg .

[0122] For example, the temporary random value R agg includes a partial random number R i of each verification node and verification commitment information C i for verifying the authenticity of R i . Further, the temporary random value R agg can be generated by aggregating R i of multiple verification nodes.

[0123] In one specific embodiment, in the process of generating the random seed information, each verification node synchronously generates its respective partial random number R i and corresponding verification commitment information C i . Further, a pseudo-random number can be generated by the random seed information as the partial random number R i . In the process of determining the leader node by the random seed information, each verification node or the finally determined leader node collects and aggregates the partial random numbers R i of all verification nodes, generates a final aggregated random value R agg , and embeds the value into the current pre-generated block information. In the process of generating the pre-generation request, the leader node can synchronously or asynchronously complete the calculation of the aggregated random value R agg , and use the aggregated temporary random number value for the calculation of the signature share of the MPC node. Since this process does not additionally occupy computing resources or communication rounds, the core task of the pre-signing phase can be completed, thereby significantly improving the signature efficiency of the system and effectively reducing the resource consumption.

[0124] In one of the embodiments, when the MPC node device fails, the digital asset management system is further configured to restore the MPC node device to a state before the failure based on the MPC node device running state log stored by the blockchain system.

[0125] It can be understood that the consensus node device acts as a message queue, and when receiving a message requested by the MPC node device to be broadcast to other MPC node devices, the consensus process will be started, and the message of the MPC node device will be consensus and chained to the blockchain system. Therefore, when the MPC node device fails, the state of the MPC node device can be quickly recovered through the block information in the blockchain system.

[0126] The blockchain system can be a decentralized data storage network realized by using a distributed ledger technology, and transaction data can be written to a specific storage location on the chain through an intelligent contract interface. The interaction state and related information of the MPC node device are stored in the blockchain system, and the integrity of data update is ensured through blockchain protocol verification, so as to ensure the traceability of the signature process, facilitate data recovery and compliance inspection of regulatory agencies, avoid the risk of single point failure of centralized storage through the distributed characteristics of the blockchain, and thus improve the data credibility and system recovery ability.

[0127] The digital asset management system can recover based on signature state information, which can retrieve the latest state information from the blockchain system through other normal nodes to rebuild the current signature process progress. In one specific embodiment, if the failure occurs in the signature aggregation stage, the system can also reassign a new consensus node device as a new message queue to complete the remaining multi-party secure computation interaction processing. Through the above-mentioned automatic reconstruction of system running state based on pre-stored trusted state information, the need for manual intervention can be reduced, and the system fault tolerance and availability can be improved.

[0128] The digital asset management system provided in the embodiment can ensure data credible storage by recording the interaction information of the MPC node device to the blockchain system, and can improve data reliability by using the tamper-proof and distributed storage characteristics of the blockchain, and can further improve system fault tolerance and enhance the continuity and security of digital asset management services by realizing automatic fault positioning and process reconstruction based on pre-stored state information.

[0129] In one embodiment, the digital asset management system further includes a key management device; the key management device runs in a trusted execution environment; the number of key management devices matches the number of verification nodes.

[0130] The key management device can be used to generate, store, distribute and manage keys in the digital asset management system, and can realize key management by using a hardware security module (HSM) and a key management protocol based on the PKCS11 standard.

[0131] The trusted execution environment can be a secure area constructed by hardware or software isolation technology, such as Intel SGX, ARM TrustZone, virtualization-based trusted environment, etc. For example, the key management device can be protected by means of memory encryption, code verification, etc.

[0132] The number of key management devices matches the number of verification nodes. There can be a one-to-one matching relationship between the key management device and the verification node, so that each verification node is equipped with a dedicated key management device. There can also be a one-to-many or many-to-one matching relationship between the key management device and the verification node, which is not limited in this embodiment.

[0133] The digital asset management system provided in this embodiment can use the hardware-level isolation characteristics of the trusted execution environment and the specialized functions of the key management device to improve the anti-attack capability of sensitive data such as private keys, by deploying key management devices running in a trusted execution environment, combining the one-to-one correspondence between the key management device and the verification node, and the key distribution, operation verification and state synchronization collaboration mechanism. Through the matching relationship between the key management device and the verification node, the flexibility of system expansion can be improved, while avoiding the performance bottleneck caused by key management centralization, thereby improving the overall security of the system.

[0134] In one of the embodiments, the digital asset management system further comprises an identity information management device and an identity verification device; the identity information management device is in communication connection with the identity verification system and stores user identity information, and is used for:

[0135] In response to the verification demand information sent by the identity verification device, the attribute value in the user identity information matched with the verification demand information and at least one Merkle tree path corresponding to the attribute value are obtained;

[0136] Based on the user private key, the attribute value and the Merkle tree path, verification response information is generated;

[0137] The verification response information and the certificate authority public key are sent to the identity verification device;

[0138] The identity verification device is further used for:

[0139] Based on the attribute value and the Merkle tree path, a first root hash value is calculated;

[0140] A second root hash value corresponding to the verification response information is obtained;

[0141] Based on the comparison result of the first root hash value and the second root hash value, and the attribute value, it is determined whether the verification response information is valid.

[0142] The verification requirement information can be an instruction for requesting a specific user to perform identity attribute verification, and contains a user unique identifier and a required attribute type (such as name, certificate number, etc.). For example, the verification requirement information can be constructed and sent by the identity verification device according to a verification request (such as a login, transaction authorization, etc.) initiated by the user. The verification requirement information can be transmitted in the form of a request package, a compressed package, a two-dimensional code, etc., to the user unique identifier and the required attribute type.

[0143] The identity verification device can be a special device for performing user identity verification, and is used to initiate verification requirement information to the identity information management device and confirm the validity of the verification response information. By structuring the verification requirement information, the identity verification device can clearly verify the target, for example, the specific attribute type that needs to be verified can be determined according to the verification requirement information, and the instruction containing the user identifier and the attribute type is sent to the identity information management device, thereby reducing invalid data transmission.

[0144] The user identity information can be a set of user attributes stored in the identity information management device, such as name, certificate number, etc. The user identity information can be constructed in the form of a Merkle tree. The Merkle tree path can be a hash path from a leaf node to a root node in the Merkle tree, used to prove the integrity of the attribute value, which can be generated by the identity information management device according to the stored Merkle tree structure.

[0145] The certificate authority public key can be a public key provided by an authority. After the user completes registration at the certificate authority, the certificate authority can provide the user with certificate information signed by the certificate authority private key, and the certificate authority public key can be used to verify the authenticity of the signature and the legality of the Merkle tree root hash.

[0146] After receiving the verification requirement information, the identity information management device can retrieve the attribute value matching the required attribute type in the verification requirement information, such as the user's name or certificate number, and then generate the Merkle tree path corresponding to the attribute value to ensure data integrity, and sign the attribute value and the path using the user's private key to form signed data, and encapsulate the attribute value, the path, the signed data, and the certificate authority public key as the verification response information. The above-mentioned method combines zero-knowledge proof with hierarchical signature verification to ensure the trusted source and content integrity of the response information without exposing the complete identity data. Further, the Merkle tree path corresponding to the attribute value can include the Merkle tree path where the attribute value is located, and can also include branch paths of other Merkle trees other than the current attribute value. For example, the hash value of each necessary branch path of the Merkle tree required to obtain the Merkle tree root hash value according to the attribute value can be obtained in sequence according to the leaf node where the attribute value is located.

[0147] The identity verification device can verify the validity of the signature data by using the certificate authority public key after receiving the verification response information, and verify the integrity of the attribute value through the Merkle tree path, so as to realize lightweight verification of the data segment. For example, when verifying the user's name, only the path corresponding to the attribute needs to be transmitted instead of all the identity information, thereby effectively reducing the data transmission amount and improving the security of the user's privacy information.

[0148] The attribute value can be a specific parameter used to identify a user or a data feature, such as a user's name, age, etc., which can be transmitted to the identity verification device through the verification response information.

[0149] The Merkle tree path can be a hash hierarchical structure from the leaf node to the root node in the Merkle tree. For example, the Merkle tree path can include a sequence of hash values calculated layer by layer from the leaf node storing the attribute value upwards.

[0150] The first root hash value can be a root hash value result obtained by reconstructing the Merkle tree path through recursive hash operation, which can be calculated by combining the current node hash and the sibling node hash.

[0151] The second root hash value can be a Merkle tree root node hash value pre-published by the certificate authority, which can be obtained through a trusted channel, such as a blockchain record, an additional field of the verification response information, etc. For example, the second root hash value can be transmitted through a signature data packet verified by the certificate authority public key, or can be obtained by querying the public record database of the certificate authority.

[0152] The comparison result can be a determination conclusion of whether the first root hash value and the second root hash value are consistent, which can be obtained by bit-by-bit comparison. Determining whether the verification response information is valid can be a comprehensive evaluation based on the comparison result and the attribute value business compliance. In one specific embodiment, the device first verifies the consistency of the hash value, then checks whether the attribute value meets the business rules (such as whether the age is within the legal range), and finally outputs the conclusion of verification success or failure. The double verification mechanism of bit-by-bit comparison of hash values and business rule verification can ensure data integrity and source credibility, prevent intermediate tampering of attribute values, and at the same time can avoid the risk of impersonation that may exist only by relying on signature verification.

[0153] The digital asset management system provided by the embodiment sends structured verification requirement information through the identity verification device to specify the attribute type to be verified, generates verification response information based on the Merkle tree path and the user private key through the identity information management device to realize zero-knowledge proof of the data segment, and performs hierarchical verification through the identity verification device based on the certification authority public key and the Merkle tree path to ensure credibility, realizes transmission of necessary attribute values and paths, thereby reducing the risk of sensitive information leakage, and can optimize the efficiency of the identity verification link without sacrificing security and decentralization characteristics, thereby improving system security; the first root hash value is calculated based on the attribute value and the Merkle tree path to verify data integrity, the second root hash value is obtained through a trusted channel as a verification benchmark, and the validity of the verification response is comprehensively judged through comparison of the hash value and the attribute value compliance, thereby strengthening data credibility, and compared with a single verification method, the security of the verification process can be improved.

[0154] In one of the embodiments, the identity verification device is further configured to:

[0155] Based on the verification response information, a preset compliance check interface is called to obtain a compliance check result;

[0156] Based on the compliance check result, a response result is generated for the business processing request sent by the user;

[0157] The business processing request and the response result are stored in the blockchain system.

[0158] The compliance check interface can be a preset API or service endpoint configured to execute specific compliance verification rules, such as anti-money laundering, KYC compliance check, etc. For example, the compliance check interface can include an anti-money laundering rule verification API, a transaction risk assessment service interface based on machine learning, etc. The compliance check result can be a verification result returned by the interface, which can include a confirmation result of whether the user request meets the preset compliance standard. For example, the compliance check result can include an identification of the transaction risk rating as high risk or low risk.

[0159] For example, in the case where the verification response request meets the root hash value comparison result, the relevant attribute value is used as an input parameter to call the compliance check interface, thereby obtaining the compliance check result.

[0160] Based on the compliance check result, the response result can be generated according to the compliance check result to determine whether the user request is compliant; if it is compliant, an allowed response result is generated, such as transaction confirmation; if it is not compliant, a result of rejecting the response is generated, and further, a reason can be added; the response result can include a business request identifier and a processing timestamp.

[0161] The business processing request and the response result are stored to the blockchain system, which can be packaged as transaction data; new block metadata containing the transaction data is generated, and the new block is broadcast to the blockchain network through the consensus node device, so that the transparent and auditable business processing record is provided by using the tamper-proof feature of the blockchain, and the system credibility is enhanced.

[0162] The digital asset custody system provided by the embodiment can reduce the operational risk in the compliance level by calling the preset compliance check interface to perform compliance verification, generate an automatic response based on the verification result, and store the business data to the blockchain system, so that the tamper-proof and traceability of the record can be ensured, and the technical effects of improving compliance automation, audit transparency, and risk control can be achieved.

[0163] In order to more clearly set forth the technical solutions of the present application, a detailed embodiment is further provided.

[0164] In one embodiment, a digital asset custody system is provided, including a blockchain threshold signature custody wallet system, which generates private key fragments of each participant through multi-party secure computation (MPC) technology, and generates a transaction signature through collaborative calculation of participants reaching a threshold value when trading assets. The digital asset custody system of the embodiment can significantly improve the efficiency and parallel processing capability of multi-party computation by optimizing the interactive calculation process of signature and pre-signature, and can enhance the high availability and scalability of the system through a decentralized network architecture. Further, the digital asset custody system of the embodiment further integrates the KYC / AML solution into the wallet function, so that the integration of security and compliance can be realized.

[0165] In the digital asset custody system of the embodiment, a lightweight blockchain architecture is included, which combines the Pedersen DKG protocol with the BLS aggregate signature algorithm, and designs a threshold signature function for the latter, randomly selects a leader node through a verifiable random function (VRF), and deeply integrates with a BFT consensus algorithm, to build a BFT consensus protocol based on VRF and aggregate threshold signature. The architecture ensures the tamper-proof and transparent nature of the information transmission in the message queue. By designing an efficient message transmission protocol, the system realizes the secure exchange of calculation results between participants, and provides verifiability for each calculation step. In addition, the system uses on-chain historical message records to monitor the status of each node in real time, and can quickly recover to the state before the failure when the node fails, thereby significantly improving the fault tolerance and scalability of the system.

[0166] The digital asset management system of the embodiment includes a consensus node device of a blockchain system and a plurality of MPC node devices, the consensus node device includes a plurality of verification nodes, and the plurality of MPC node devices indirectly communicate through the consensus node device.

[0167] When any one of the verification nodes receives the information sent by the MPC node device, the verification node is configured to generate random seed information and determine a leader node in the consensus node device based on the random seed information; the leader node includes a leader node and an aggregator node;

[0168] The leader node is configured to send a block generation request to generate a target block; the aggregator node is configured to generate an aggregated signature based on signature fragments generated by the plurality of verification nodes for the target block; and broadcast the aggregated signature to the blockchain system.

[0169] In the multi-party secure computing process of the MPC node device, the private key can be securely divided into a plurality of shares based on the Pedersen DKG secret sharing protocol, ensuring the security of private key management. Subsequently, the standard ECDSA signature algorithm is transformed to make it more suitable for sharding and aggregation technology. On this basis, combined with the SPDZ protocol and the Beaver triple protocol, collaborative computing between multiple participants is realized, and the calculation process of the signature values r and s is decentralized into r i and s i . This design enables each node to complete its own signature share calculation (r i , s i ) in a non-interactive manner, and finally aggregates the calculation results (r, s) of each node through the SPDZ protocol and the Beaver triple protocol. Through the above method, asynchronous or parallel signature calculation can be realized, thereby significantly improving the efficiency of signature generation and system expansion capability, as shown in Figure 2 .

[0170] Compared with the traditional MPC computing node interaction method shown in Figure 3 , the digital asset management system of the embodiment optimizes the interaction process, and the MPC computing nodes only need to interact and aggregate the results between nodes in the last round of online interaction. Similarly, the pre-signature process is also optimized, as shown in Figure 4 , compared with the traditional scheme of Figure 5 , the embodiment only performs message interaction between MPC computing nodes in the last round, thereby significantly improving the parallel computing capability and scalability of the system, reducing the communication overhead between nodes, and providing a feasible technical path for efficient signature calculation in a large-scale distributed environment.

[0171] In addition, in addition to realizing the pre-signature by combining the SPDZ protocol and the Beaver triple protocol, the embodiment also provides another multi-party secure computing manner, that is, in the process in which the MPC node device indirectly communicates through the consensus node device, when the to-be-transmitted information meets a preset triggering condition, the leader node is also used for generating a temporary random value Ragg; the MPC node device is also used for: obtaining the temporary random value Ragg sent by the leader node; based on the temporary random value and a private key shard of the MPC node device, signing a to-be-signed message to generate a signature share; sending the signature share to other MPC node devices through the consensus node device; based on the signature share and the signature share from other MPC node devices, obtaining a final signature result. Since the process does not additionally occupy computing resources or communication rounds, the core task of the pre-signature stage can be completed, so that the system signature efficiency is significantly improved and the resource consumption is effectively reduced.

[0172] In terms of security, each verification node of the embodiment also includes a Sidecar node architecture, which runs in a trusted execution environment (TEE) and is deeply integrated with a key management system (KMS), ensuring the security of the private key at the hardware level. The embodiment also reconstructs the communication network of the ECDSA threshold calculation node from a traditional centralized architecture (such as Figure 6 ) to a decentralized communication network (such as Figure 7 ). By fully utilizing the characteristics of the blockchain, the fault tolerance and scalability of the system can be significantly enhanced, providing a more robust and flexible communication infrastructure for threshold signature calculation.

[0173] The threshold signature process of the embodiment includes:

[0174] The threshold signature EdDSA algorithm and the distributed private key generation algorithm (DKG) are used to generate the private key share. During the running of the consensus algorithm of the embodiment, the pre-computation task is performed to generate the random number R agg that needs to be completed based on the public interaction in the EdDSA partial signature. When the threshold signature is formally online, the pre-computed R agg value is obtained from the blockchain, the partial signature S i is locally generated, and then shared with other threshold signature nodes through the blockchain of the embodiment. Finally, when each threshold node receives more than the threshold S i , the final signature S is calculated through the aggregation algorithm to complete the threshold signature process based on the blockchain designed by the embodiment.

[0175] In the embodiment, the consensus process includes a verifiable random function (VRF) to randomly select a leader node.

[0176] As shown in Figure 8 , the first stage: VRF dynamic leader node election.

[0177] Generate random seed: Each verifier calculates VRF output: (seed i , pi i ) = VRF(sk i , H(prev_block + round)), then broadcasts the VRF result to other nodes, and so on, until all verifiers receive the VRF result from other nodes, then each verifier node locally executes a leader election algorithm based on VRF and dynamic reputation weight to calculate the score of each node, and the node with the highest score is the leader of the round. If elected as the leader, it will assume the role of the current block "proposer" and "aggregator". As shown in Figure 8 , the verifier node 04 is a malicious node, and the other verifier nodes fail to verify its verifiable random credential 04, and the verifier node 03 corresponding to the verifiable random credential 03 has the highest score and is elected as the leader. In the proposal stage, the proposer not only packages the block information to be consensus, but also writes its own VRF proof (seed i , pi i ) of being elected as the proposer into the block header and broadcasts it to other verifiers. After receiving the block proposal broadcast, the other verifiers not only verify the proposed block information, but also verify the VRF result (seed i , pi i ) of the elected leader. Among them, the leader election algorithm based on VRF and dynamic reputation weight can generate a random compensation factor using the hash weight random scaling algorithm, obtain a dynamic reputation weight using the dynamic reputation scoring algorithm, and compensate and adjust the scoring result of VRF through the random compensation factor and the dynamic reputation weight to obtain the verification result. The scoring algorithm is: Score i = HashToNum i · WF i · PRF i · K, wherein HashToNum i is a large integer obtained by twice hash conversion of the random number result of VRF, WF i is the composite reputation weight of each verification node, PRF i is a random compensation factor (introducing controllable randomness, range adjustable), and K is a scaling factor (used for numerical normalization adjustment to avoid floating point operation error K=10 18 ).

[0178] Second stage: Propose & Threshold-Vote.

[0179] Block proposal: The leader node selected in the first stage is responsible for generating a new block Block and broadcasting the new block Block and the VRF proof of the elected leader.

[0180] BLS signature voting: Each validator verifies the correctness of the block information sent by the leader after receiving it. If the verification is successful, it first generates a pre-calculation task R i = r·G, and then generate the BLS partial signature σ together with the new block Block i =Sign(sk i ,H(Block)‖R i ). The signature fragment σ i and R i Send them to the leader node of this round (selected in the first phase). i is the private key of the current verification node, H is the Sha-256 hash function, r is a random number randomly selected by the current verification node, and G is the generator of the elliptic curve.

[0181] Aggregation and broadcast: The leader node collects at least t partial signatures σ sent by verification nodes i and R i After that, first generate the aggregate signature σ agg =Aggregate(σ1,...,σ t ); then aggregate the pre-calculated results R agg =Agg(R1, ...,R t ); finally broadcast (σ agg , R agg ) to all verification nodes to enter the next round of consensus process.

[0182] At the same time, a dual-mode aggregation and verification process, "optimistic path and fallback path," was introduced to address the potential impact of some signature anomalies on consensus liveness. Under the optimistic path, the system assumes that the signatures provided by most verification nodes are valid, allowing for rapid aggregation and verification. Once an abnormal signature is detected, the system switches to the fallback path, verifying and eliminating abnormal signatures one by one to ensure the correctness of the final result. During the fallback path, verification nodes with abnormal behavior will be marked and subject to a decaying penalty in the reputation model, reducing their probability of being selected as leaders in the future.

[0183] In order to verify the security of the verifiable random function of this application compared to the traditional PBFT consensus algorithm, the applicant selected 10 users as validators, set certain weights based on one or more relevant indicators such as user characteristics or behavior patterns, activity, contribution, etc., and verified the two consensus algorithms.

[0184] In this experiment, the characteristics of the traditional deterministic round-robin election algorithm and the consensus election algorithm of this application are compared by running the election algorithm several times.

[0185] In the consensus algorithm of the present embodiment, after 100 runs, the number of times that the 10 validators are selected in the consensus algorithm is 94, 96, 92, 103, 105, 109, 103, 96, 97 and 106, respectively. In the traditional consensus algorithm, after 100 runs, the number of times that the 10 validators are selected is 101, 100, 100, 100, 100, 100, 100, 100, 100 and 100, respectively.

[0186] Through the distribution uniformity analysis, the standard deviation and the coefficient of variation of the traditional algorithm are 0.30 and 0.0030, respectively, while those of the consensus algorithm of the present embodiment are 5.49 and 0.0548, respectively.

[0187] As can be seen from the distribution uniformity, the traditional PBFT algorithm shows extremely high determinacy and uniformity, almost mechanically selecting each validator about 100 times (standard deviation is only 0.30). Such extremely uniform distribution is actually a predictable distribution. The consensus algorithm of the present embodiment exhibits a distribution characteristic more in line with randomness (standard deviation is 5.49), which although looks “less uniform”, actually reflects the characteristics of a true random process. Under ideal random conditions, the selection distribution in the short term will not be absolutely uniform, but in the long term, it still remains relatively fair.

[0188] From the selection randomness, the consensus algorithm of the present embodiment performs outstandingly in the randomness index, with a transfer diversity of 100% (1.0), which is much higher than the 10% (0.1) of the original algorithm; the transfer entropy (information entropy) is as high as 6.6007, almost twice that of the traditional algorithm (3.3219); and the number of unique transfer modes is 100, while the traditional algorithm has only 10 transfer modes. This shows that the consensus algorithm of the present embodiment introduces extremely high randomness and unpredictability, preventing any attack to predict the order of proposers.

[0189] From the prediction difficulty, the consensus algorithm of the present embodiment greatly reduces the sequence predictability, wherein the predictability of the traditional algorithm is 100% (1.0), i.e. completely predictable, while the predictability of the consensus algorithm of the present embodiment is reduced to 49.43%, the prediction difficulty is increased by 50.57%, which makes it difficult for an attacker to predict the proposer of the next block, thereby improving the security of the protocol.

[0190] From the balance between short-term fairness and long-term fairness, the consensus algorithm of the present embodiment maintains the long-term fairness (the number of times that each validator is selected is relatively balanced, ranging from 9.19% to 10.89%) while introducing short-term randomness. The standard deviation of short-term fairness increases (from 0.0012 to 0.0187), which is no longer a mechanical uniform distribution, which actually enhances the resistance of the system to attacks against known proposer sequences.

[0191] Therefore, compared with the traditional PBFT consensus algorithm, the consensus algorithm of the embodiment can achieve the following technical effects: (1) enhanced security: by introducing true randomness and unpredictability, attacks against known proposer order, such as long-range attacks and predictive DOS attacks, are prevented. (2) increased randomness: the transfer diversity is increased by 10 times, and the information entropy is almost doubled, making the system behavior more unpredictable and more random. (3) balanced fairness: while maintaining the long-term fairness of the verifier selection ratio, short-term random fluctuations are introduced, which is more in line with the characteristics of a real random process. (4) reduced predictability: the sequence predictability is reduced from 100% to about 50%, significantly increasing the difficulty of prediction.

[0192] The consensus process of the embodiment, through the way of signature aggregation, compared with the case that each verifier needs to verify the signatures of all other verifiers in the traditional PBFT consensus algorithm, the complexity of which is O(n-1), the embodiment can reduce the verification complexity from O(n-1) to O(1) by combining multiple signatures into a single signature. The embodiment also uses a leader-centric approach, so that non-leaders only send messages to the leader, and the leader is responsible for aggregation and then broadcasts the results. Compared with the case that in the traditional consensus algorithm, the verifier broadcasts the message to all other verifiers, the network communication volume is significantly reduced from O(n²) to O(n). Through the mechanism of batch signature verification, by using a hybrid strategy of trying to aggregate verification first and then verifying one by one when aggregation signature verification fails, high efficiency can be maintained in most cases, while malicious nodes can be detected and isolated. Through the mechanism of detecting and isolating malicious nodes one by one when aggregation signature verification fails, the problem that one malicious signature can cause the entire aggregation signature verification to fail can be effectively avoided.

[0193] Therefore, the threshold signature optimized consensus algorithm of the embodiment can achieve lower network message complexity (from O(n²) to O(n)), lower verification calculation complexity (from O(n-1) to O(1)), smaller signature storage space (single aggregated signature vs multiple individual signatures), and shorter consensus completion time.

[0194] In order to verify the technical effects of the consensus process of the present application compared with the traditional PBFT-based consensus algorithm, the applicant set up three experimental groups, each using a network environment of 4 nodes, 20 nodes and 50 nodes, to compare the consensus algorithm of the embodiment with the traditional algorithm.

[0195] When the number of nodes is 4, the traditional consensus algorithm completes 81 rounds in total, the final block height is 81, the total running time is 58.484 seconds, the average time consumption of each round is 0.209 seconds, the fastest round takes 0.204 seconds, the slowest round takes 0.216 seconds, and the average number of blocks generated per second is 1.385. The consensus algorithm of the embodiment completes 82 rounds in total, the final block height is 82, the total running time is 60.073 seconds, the average time consumption of each round is 0.220 seconds, the fastest round takes 0.209 seconds, the slowest round takes 0.227 seconds, and the average number of blocks generated per second is 1.365.

[0196] When the number of nodes is 20, the traditional consensus algorithm completes 48 rounds in total, the final block height is 48, the total running time is 37.573 seconds, the average time consumption of each round is 0.258 seconds, the fastest round takes 0.233 seconds, the slowest round takes 0.273 seconds, and the average number of blocks generated per second is 1.278. The consensus algorithm of the embodiment completes 51 rounds in total, the final block height is 51, the total running time is 39.261 seconds, the average time consumption of each round is 0.246 seconds, the fastest round takes 0.220 seconds, the slowest round takes 0.266 seconds, and the average number of blocks generated per second is 1.299.

[0197] When the number of nodes is 50, the traditional consensus algorithm completes 40 rounds in total, the final block height is 40, the total running time is 37.880 seconds, the average time consumption of each round is 0.409 seconds, the fastest round takes 0.354 seconds, the slowest round takes 0.460 seconds, and the average number of blocks generated per second is 1.056. The consensus algorithm of the embodiment completes 38 rounds in total, the final block height is 38, the total running time is 31.339 seconds, the average time consumption of each round is 0.285 seconds, the fastest round takes 0.253 seconds, the slowest round takes 0.320 seconds, and the average number of blocks generated per second is 1.213.

[0198] It can be seen that in a small-scale network environment (such as only 4 nodes), the performance difference between the two algorithms is not obvious. However, as the number of nodes participating in the consensus process gradually increases to 20 or even 50, the consensus algorithm of the embodiment exhibits significant advantages, effectively improving the overall performance and scalability of the system with a large number of nodes, and maintaining stable running efficiency.

[0199] The digital asset custody system provided by the embodiment reduces the network communication complexity to O(n) through the decentralized message queue scheme based on the blockchain decentralized communication architecture, and compared with the traditional O(n2) full network broadcast, the network communication can be significantly optimized. Thanks to the tamper-proof, traceable and anti-malicious attack features of the blockchain technology, the embodiment effectively improves the security, reliability and traceability of message interaction. At the same time, by persistently storing the interaction state of the threshold node in the blockchain, the system can quickly realize node fault recovery, that is, when the node fails, the state information stored in the blockchain can be called to quickly recover to the state before the failure, ensuring the continuity of system operation. By designing a threshold signature function for the aggregate signature algorithm (BLS), randomly selecting a leader node through VRF, and deeply integrating with the BFT consensus protocol, the communication complexity of the BFT consensus algorithm can be optimized from O(n2) to O(n), thereby significantly improving the message interaction efficiency of the blockchain system. The protocol not only effectively solves the bottleneck problem of the traditional threshold signature system in communication efficiency and reliability, but also opens up a new technical path for building a high-performance and highly available blockchain threshold signature system. In particular, for the key management problem involved in the combination of the BFT consensus algorithm and the threshold signature, the embodiment decouples the consensus function and the key management function coupled in the traditional blockchain node through the Sidecar (sidecar) node architecture, and configures an independent Sidecar node for each blockchain consensus node to specifically handle key-related transactions. The Sidecar node runs in a trusted execution environment (TEE) and is deeply integrated with the key management system (KMS), ensuring the security of the private key at the hardware level. This architecture design not only supports dynamic private key refresh without affecting the normal operation of the node, but also keeps the public key unchanged, thereby significantly improving the security and availability of the system and providing a more flexible and secure solution for key management of the blockchain system.

[0200] In the digital asset custody system of the embodiment, an identity information management device is further included, which can be a VC file management device, and is used to implement a KYC / AML scheme based on the W3C DID standard. By deeply integrating the Decentralized Identifiers (DIDs) standard of W3C, zero-knowledge proof (ZKP) and Merkle Tree technology, the security of the user end can be effectively enhanced. The user can import and manage the VC file issued by the issuing authority through the identity information management device.

[0201] In particular, the digital asset custodian system can include a DID identity system, a Merkle tree component, a zero-knowledge proof component, a verifiable credential (VC) component, an identity information management component, an anti-money laundering (AML) platform, and a blockchain system.

[0202] The DID identity system is based on the W3C standard and creates a unique DID (e.g., did:ethr:0x...) for the user. The Merkle tree is used to shard the user's KYC information into leaf nodes, generate a root hash through hashing, and store it in the blockchain or IPFS. The zero-knowledge proof component is used to generate ZKP proof data validity when the user selectively discloses information without revealing privacy. The verifiable credential (VC) component is used by the issuing authority to sign the Merkle root hash to generate a VC containing user identity, compliance proof, etc. The identity information management device is used to store and manage VCs and generate ZKP proofs. The anti-money laundering platform can be integrated with Chainalysis, TRM Labs, etc. API for real-time verification of transaction compliance. The blockchain system is used to store root hash values, VC metadata, and transaction records to ensure tamper resistance and traceability.

[0203] During the user's registration and identity verification process, the participating nodes include verification, issuing authorities, wallet systems, and regulatory authorities. The user submits KYC information, generates a DID, manages VCs, and responds to verification requests through a dedicated device. The issuing authority verifies the authenticity of the KYC information, generates and signs the VC to ensure compliance. The wallet system initiates a verification request (QR code), verifies the validity of the VC, and integrates AML tools to monitor transactions. The regulatory authority audits on-chain data, traces suspicious transactions, and ensures compliance.

[0204] First stage: user registration and KYC information submission.

[0205] Create DID: The user generates a DID key pair (public key / private key) through the VC device and registers the DID (e.g., did:ethr:0x...).

[0206] Build Merkle tree: The user shards the KYC information (e.g., ID number, name, address) into leaf nodes and generates a Merkle tree through SHA-256 hashing.

[0207] For example, the leaf nodes can include ["name: Zhang San", "id: 123456...", "address: Beijing..."].

[0208] Submit root hash: The user submits the Merkle root hash to the issuing authority and stores the leaf node hash in IPFS or the blockchain.

[0209] Second stage: issuing authority issues VC.

[0210] KYC verification: Issuer verifies the authenticity of the KYC information submitted by the user (e.g., through government databases or biometric identification).

[0211] Generate VC: Issuer signs the root hash and generates a VC containing: (1) did: user DID; (2) root_hash: Merkle root hash; (3) signature: Issuer's digital signature.

[0212] Store VC: User imports the VC information into the VC device and stores it through a dedicated device.

[0213] Third stage: Wallet verification request.

[0214] Generate verification QR code: Wallet system (e.g., digital asset custodian wallet) generates a QR code containing: (1) required_attributes: list of attributes that need to be verified (e.g., "age ≥ 18 years old"); (2) nonce: random number to prevent replay attacks.

[0215] User response verification: User scans the QR code using the VC device, and the dedicated device parses the request.

[0216] Select attributes: User selects the minimum necessary attributes to disclose (e.g., only "age").

[0217] Generate ZKP: Based on the Merkle tree path and attribute values, generate ZKP to prove the validity of the data.

[0218] Sign: User private key signs the ZKP and attribute values.

[0219] Response: Generate a QR code containing the ZKP, attribute values, signature, and issuer public key to the wallet system, and the wallet system obtains the required information by scanning the VC device's QR code.

[0220] Fourth stage: Wallet verification and compliance check.

[0221] Verify ZKP validity: Wallet system verifies the VC signature with the issuer's public key; verifies that the attributes disclosed by the user are consistent with the root hash through the Merkle path; and verifies whether the ZKP meets the requirements (e.g., "age ≥ 18 years old").

[0222] AML compliance check: Call Chainalysis / Travel Rule API, check whether the user's address is associated with the sanctions list, and mark suspicious transactions (e.g., large transfers, frequent splitting); if compliant, allow transactions; otherwise, freeze assets and notify regulatory authorities.

[0223] Fifth stage: Transaction and audit.

[0224] Transaction execution: After verification, users can conduct digital asset custody or transactions.

[0225] Data on-chain: Transaction records, verification results, and AML reports are encrypted and stored in the blockchain system to ensure traceability.

[0226] Regulatory audit: Regulators track KYC verification and transaction activities through DID chain records.

[0227] This embodiment provides a digital asset custody system that utilizes a decentralized, privacy-preserving, and verifiable KYC solution, deeply integrating the W3C Decentralized Identifiers (DIDs) standard, zero-knowledge proofs (ZKPs), and Merkle Tree technology. A user's KYC information is constructed as a Merkle tree, where each leaf node represents an attribute (such as ID number, name, gender, etc.). This Merkle tree is generated through hash encoding and submitted to the issuing authority. The issuing authority signs the Merkle root hash to generate the user's Verifiable Credential (VC) file. Users can import the VC file signed by the issuing authority through their VC device. During the verification phase, when the wallet system requires the user to provide KYC information, it generates a QR code containing the required information. After the user's device scans the QR code, a verifiable VC QR code is generated based on the principle of minimal disclosure. The code is then submitted to the wallet system by scanning the VC device's QR code through the signature system. The wallet system verifies the validity of the VC by combining the issuing authority's public key, the Merkle tree root signature, the user's disclosed KYC information, and its corresponding Merkle tree path. Only after verification is passed can the user proceed with subsequent operations. All verification data is encrypted and stored on the blockchain, ensuring tamper-proofing and traceability. This solution significantly reduces the risk of user information leakage while eliminating the burden on financial institutions to store user KYC information. Furthermore, the wallet system is deeply integrated with authoritative anti-money laundering (AML) platforms such as Chainalysis, Travel Rule, TRM Lab, and Forge Trust. Smart contracts automatically verify each transaction before it is processed, ensuring security, compliance, traceability, and auditability. This not only ensures the secure circulation of digital assets but also meets government regulatory requirements for financial institutions, making digital asset businesses comparable to traditional assets in terms of compliance while also being more convenient, efficient, and cost-effective.

[0228] It should be understood that although the steps involved in the above-described embodiments are not necessarily performed in the order given. Unless explicitly stated otherwise herein, the steps are not strictly limited in order of execution, and can be performed in other orders. Moreover, at least some of the steps involved in the above-described embodiments can include multiple steps or stages, which are not necessarily performed at the same time, but can be performed at different times, and the order of execution of these steps or stages is not necessarily sequential, but can be performed alternately or alternately with at least part of other steps or stages.

[0229] The various devices in the digital asset management system described above can be implemented in whole or in part by software, hardware and combinations thereof. The various devices described above can be embedded in the processor in the computer device in hardware form or independent of the processor in the computer device, or can be stored in the memory in the computer device in software form, so that the processor can call and execute the operations corresponding to the above various modules.

[0230] In one embodiment, a computer device is provided, which can be a terminal, and its internal structure diagram can be as shown in Figure 9 The computer device includes a processor, a memory, a communication interface, a display screen and an input device connected by a system bus. The processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system and a computer program. The internal memory provides an environment for the operating system and the computer program in the non-volatile storage medium to run. The communication interface of the computer device is used to communicate with external terminals in wired or wireless manner. Wireless mode can be achieved through WIFI, mobile cellular network, NFC (near field communication) or other technologies. The computer program is executed by the processor to implement the MPC node device, consensus node device, identity information management device, etc. as described in the above embodiments. The display screen of the computer device can be a liquid crystal display screen or an electronic ink display screen. The input device of the computer device can be a touch layer overlaid on the display screen, or a key, trackball or touchpad provided on the shell of the computer device, or an external keyboard, touchpad or mouse, etc.

[0231] Those skilled in the art can understand that Figure 9 The structure shown in the above

[0232] It should be noted that the user information (including but not limited to user equipment information, user personal information, etc.) and data (including but not limited to data for analysis, stored data, displayed data, etc.) involved in the present application are all information and data authorized by the user or authorized by all parties.

[0233] It can be understood by those skilled in the art that all or part of the processes in the above-mentioned embodiment methods can be completed by instructing related hardware through a computer program. The computer program can be stored in a non-volatile computer readable storage medium. When the computer program is executed, it can include the processes of the above-mentioned embodiments of each method. Any reference to memory, database or other medium used in the embodiments provided by the present application can include at least one of non-volatile and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical storage, high-density embedded non-volatile memory, resistive memory (ReRAM), magnetoresistive random access memory (MRAM), ferroelectric memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. As an illustration but not limitation, RAM can be in various forms, such as static random access memory (SRAM) or dynamic random access memory (DRAM), etc. The database involved in the embodiments provided by the present application can include at least one of a relational database and a non-relational database. The non-relational database can include a distributed database based on a block chain, etc., without being limited thereto. The processor involved in the embodiments provided by the present application can be a general-purpose processor, a central processing unit, a graphics processing unit, a digital signal processor, a programmable logic device, a data processing logic device based on quantum computing, etc., without being limited thereto.

[0234] The technical features of the above embodiments can be combined in any way. In order to make the description concise, not all possible combinations of the technical features in the above embodiments are described, but as long as the combination of the technical features does not exist contradictory, it should be considered as the scope of the present application.

[0235] The above-described embodiments are merely illustrative of several embodiments of the present application, and the description is relatively specific and detailed, but should not be understood as a limitation on the scope of the patent. It should be noted that for those skilled in the art, without departing from the concept of the present application, a number of modifications and improvements can be made, which are all within the scope of the present application. Therefore, the scope of protection of the present application should be subject to the appended claims.

Claims

1. A digital asset custody system, characterized in that: The digital asset custody system includes a consensus node device of the blockchain system and multiple MPC node devices, wherein the consensus node device includes multiple verification nodes, and the multiple MPC node devices communicate indirectly through the consensus node device. When any verification node receives the information to be transmitted sent by the MPC node device, the consensus node device synchronizes the information to be transmitted to the blockchain system based on the preset consensus algorithm, and then sends the information to be transmitted to the target MPC node device.

2. The digital asset custody system according to claim 1, characterized in that: The preset consensus algorithm includes: In response to the current consensus phase, the plurality of verification nodes generate random seed information based on their own private keys; the random seed information includes a verifiable random output value and a certificate; Each verification node scores the random seed information based on the plurality of random seed information, and determines the verification node corresponding to the random seed information whose score meets the preset conditions as the leader node; The leader node generates or submits a target block based on the information to be transmitted.

3. The digital asset custody system according to claim 2, characterized in that: The random seed information generated based on the own private key includes: Obtaining a current election round number and historical block information of the blockchain system; the current election round number is the round for determining the leader node; The random seed information is generated based on the private key of the verification node, the historical block and the current election round number.

4. The digital asset custody system according to claim 2, wherein: Scoring the plurality of random seed information and determining the verification node corresponding to the random seed information whose score meets a preset condition as the leader node includes: Send the random seed information generated by itself to other verification nodes, and receive random seed information sent by other verification nodes; Verifying whether the verifiable random output value in the random seed information is correct based on the proof in the random seed information; If correct, double hashing is performed based on the verifiable random output value, and a score of each verification node is calculated based on a preset deterministic algorithm, the number of verification nodes, a preset weight factor, and a random compensation factor. The verification node corresponding to the random seed information whose score meets the preset conditions is determined as a potential leader node; the leader node is determined based on the potential leader nodes determined by the multiple verification nodes; If not, reject the random seed information provided by the verification node and remove the verification node from the list of potential leader nodes.

5. The digital asset custody system according to claim 4, characterized in that: The potential leader node determined based on the plurality of verification nodes, wherein determining the leader node comprises: If the number of the verification nodes determined as potential leader nodes meets a preset threshold, the verification node is used as the leader node; If the number of all verification nodes determined as potential leader nodes does not meet the preset threshold or exceeds the predefined election time, the current election round is incremented, and each verification node regenerates the random seed information and re-determines the leader node until the leader node is determined.

6. The digital asset custody system according to claim 2, wherein: Generating or submitting a target block based on the information to be transmitted includes: Generate a pre-generate request or pre-commit request corresponding to the target block; Broadcasting the pre-generation request or the pre-submission request to the other verification nodes; Obtain signature results generated by other verification nodes for the pre-generation request or the pre-submission request; if multiple signature results meet the aggregation condition, obtain an aggregate signature based on the multiple signature results; and broadcast the aggregate signature to other verification nodes.

7. The digital asset custody system according to claim 2, wherein: When the information to be transmitted meets a preset trigger condition, the leader node is further configured to generate temporary random value information; The MPC node device is further configured to: obtain temporary random value information sent by the leader node; sign the message to be signed based on the temporary random value information and its own private key shard to generate a signature share; Sending the signature share to the other MPC node devices through the consensus node device; A signature result is obtained based on the signature share and signature shares from other MPC node devices.

8. The digital asset custody system according to claim 1, wherein: The information to be transmitted includes the operating status of the device, When the MPC node device fails, the digital asset custody system is also used to quickly restore the MPC node device to a state before the failure based on the device operating status corresponding to the MPC node device stored in the blockchain system.

9. The digital asset custody system according to claim 1, wherein: The digital asset custody system also includes a key management device; the key management device runs in a trusted execution environment; the number of the key management devices matches the number of the verification nodes.

10. The digital asset custody system according to claim 1, wherein: The digital asset custody system further includes an identity information management device and an identity authentication device; the identity information management device is in communication with the identity authentication system and stores user identity information for: In response to the verification requirement information sent by the identity authentication device, obtaining an attribute value in the user identity information that matches the verification requirement information, and at least one Merkle tree path corresponding to the attribute value; Generate verification response information based on the user private key, the attribute value and the Merkle tree path; Sending the verification response information and the issuing authority's public key to the identity verification device; The authentication device is also used to: Calculate a first root hash value based on the attribute value and the Merkle tree path; Obtain the second root hash value corresponding to the verification response information; Based on a comparison result of the first root hash value and the second root hash value, and the attribute value, it is determined whether the verification response information is valid.

Images