Digital asset custodial system

Abstract

The application relates to a digital asset custody system. The digital asset custody system 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, the plurality of MPC node devices indirectly communicate through the consensus node device, when any one verification node receives to-be-transmitted information sent by an 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. By adopting the system, network communication complexity can be reduced, response efficiency can be improved, and compliance requirements and auditing can be met.

Description

Technical Field

[0001] This application relates to the field of telecommunications technology, and in particular to a digital asset custody system. Background Technology

[0002] With the rapid development of digital assets, people's demand for secure, efficient, and compliant digital asset custody wallets is becoming increasingly urgent.

[0003] In traditional technologies, threshold signature technology provides strong technical support for the security of digital asset custody wallets. However, current threshold signature wallets, for security reasons, often involve multiple rounds of complex interactions. Under the existing architecture, as the number of participants in the threshold signature increases, the complexity of the communication network also increases exponentially, leading to increased network latency, escalating complexity, and a severe degrade in system performance. Furthermore, most current digital asset custody wallets are not integrated with compliance requirements, increasing the difficulty of integrating compliance requirements later.

[0004] This shows that current threshold signature wallets still suffer from high network communication complexity, low response efficiency, and a lack of one-stop compliance verification and audit recommendations. Summary of the Invention

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

[0006] This application provides a digital asset custody system, which includes consensus node devices of a blockchain system and multiple MPC node devices. The consensus node devices include multiple verification nodes, and the multiple MPC node devices communicate indirectly through the consensus node devices.

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

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

[0009] In response to the current consensus phase, multiple verification nodes generate random seed information based on their own private keys; the random seed information includes verifiable random output values ​​and proofs;

[0010] Each verification node scores based on multiple random seed information, and the verification node corresponding to the random seed information whose score meets the preset conditions is determined as the leader node;

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

[0012] In one embodiment, generating random seed information based on one's own private key includes:

[0013] Obtain the current election round number and the historical block information of the blockchain system; the current election round number is the round in which the leader node is determined;

[0014] The random seed information is generated based on the private key of the verification node, the historical blocks, and the current election round number.

[0015] In one embodiment, the step of scoring based on multiple random seed information and determining the verification node corresponding to the random seed information whose score meets preset conditions as the leader node includes:

[0016] It sends the random seed information it generates to the other verification nodes and receives the random seed information sent by the other verification nodes.

[0017] Based on the proof in the random seed information, verify whether the verifiable random output value in the random seed information is correct;

[0018] If correct, then double hashing is performed based on the verifiable random output value, and a score for 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 nodes corresponding to the random seed information whose scores meet preset conditions are identified as potential leader nodes. The leader node is determined based on the potential leader nodes determined from multiple verification nodes.

[0019] If not, reject the random seed information provided by the verification node and remove the verification node from the list of potential leader nodes.

[0020] In one embodiment, determining the leader node based on the potential leader nodes identified by the plurality of verification nodes includes:

[0021] If the number of verified nodes identified as potential leader nodes meets a preset threshold, then the verified nodes are designated as leader nodes.

[0022] If the number of all verified nodes identified as potential leader nodes does not meet the preset threshold or exceeds the predefined election time, the current election round is incremented, and each verified node regenerates the random seed information and redetermines the leader node until a leader node is determined.

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

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

[0025] Broadcast the pre-generated request or the pre-submission request to the other verification nodes;

[0026] Obtain the signature results generated by other verification nodes for the pre-generated request or the pre-submitted request; if multiple signature results satisfy the aggregation condition, obtain an aggregated signature based on the multiple signature results; broadcast the aggregated signature to the other verification nodes.

[0027] In one embodiment, when the information to be transmitted meets a preset triggering condition, the leader node is also used to generate temporary random value information;

[0028] 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 fragment, and 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 the signature shares from other MPC node devices.

[0029] In one embodiment, the information to be transmitted includes the device's operating status.

[0030] When the MPC node device fails, the digital asset custody system is also used to quickly restore the MPC node device to its pre-failure state based on the device operating status corresponding to the MPC node device stored in the blockchain system.

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

[0032] In one embodiment, the digital asset custody system further includes an identity information management device and an identity verification device; the identity information management device is communicatively connected to the identity verification system, stores user identity information, and is used for:

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

[0034] Based on the user's private key, the attribute value, and the Merkle tree path, a verification response message is generated;

[0035] The verification response information and the issuing authority's public key are sent to the authentication device;

[0036] The authentication device is also used for:

[0037] Calculate the first root hash value based on the attribute value and the Merkle tree path;

[0038] Obtain the second hash value corresponding to the verification response information;

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

[0040] The aforementioned digital asset custody system comprises consensus node devices and multiple MPC node devices within a blockchain system. The consensus node devices include multiple verification nodes, and the multiple MPC node devices communicate indirectly through these consensus node devices. When any verification node receives information to be transmitted from an MPC node device, the consensus node device, based on a preset consensus algorithm, synchronizes the information to be transmitted to the blockchain system and then sends the information to the target MPC node device. Compared to traditional P2P communication between MPC node devices, this significantly reduces network communication complexity. By using a decentralized consensus algorithm to ensure consensus and on-chain recording of information sent by MPC node devices, the traceability of the multi-party secure computation process is guaranteed. This allows for timely data recovery in the event of node failures and provides more complete audit data to meet the needs of regulatory agencies, enabling rapid and effective oversight. Thus, while maintaining decentralized characteristics, this system improves communication efficiency and enhances the security and robustness of the digital asset custody system, achieving the overall technical effects of reducing network communication complexity, improving response efficiency, and meeting compliance and auditing requirements. Attached Figure Description

[0041] Figure 1 This is an application environment diagram of a digital asset custody system in one embodiment;

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

[0043] Figure 3 This is a timing diagram of multi-party secure computation in traditional technologies;

[0044] Figure 4 This is a schematic diagram illustrating the stages of multi-party secure computation in one embodiment;

[0045] Figure 5 This is a schematic diagram illustrating the stages of multi-party secure computation in traditional technologies.

[0046] Figure 6This is a schematic diagram of the architecture for secure multi-party computation in traditional technologies.

[0047] Figure 7 This is a schematic diagram of the architecture of a digital asset custody system in one embodiment;

[0048] Figure 8 This is a timing diagram of the leader node election in one embodiment;

[0049] Figure 9 This is an internal structural diagram of a computer device in one embodiment. Detailed Implementation

[0050] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0051] In one embodiment, such as Figure 1 As shown, this application provides a digital asset custody system, which includes a consensus node device 2 of a blockchain 3 system and multiple MPC node devices 1. The consensus node device 2 includes multiple verification nodes, and the multiple MPC node devices 1 communicate indirectly through the consensus node device 2.

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

[0053] MPC node device 1 can be a device that participates in multi-party secure computation, used to complete specific tasks (such as signature generation) through collaborative computation without leaking each other's private data. Multiple MPC nodes can be deployed through a distributed network.

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

[0055] Consensus node device 2 can be a computing device participating in the network consensus process in the blockchain 3 system, used to create, receive, and verify transaction information for new blocks. In this embodiment, consensus node device 2 acts as a message queue, achieving consensus on the information to be transmitted before sending it to the target MPC node device, and storing it on the blockchain in the block information of the blockchain 3 system.

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

[0057] The preset consensus algorithm can be a pre-defined algorithm in the Blockchain 3 system used to achieve consensus among distributed nodes, ensuring that all participants can reach a consensus on the validity of the transaction. The preset consensus algorithm can be an existing consensus algorithm, such as delegated proof-of-stake, Byzantine fault tolerance algorithm, hybrid consensus mechanism, etc., and this embodiment is not limited to this.

[0058] Synchronizing the information to be transmitted to the Blockchain 3 system can be achieved after the consensus algorithm is passed, meaning all participants reach a consensus on the information to be transmitted. This involves creating a target block in the Blockchain 3 system and submitting the information to be transmitted to the target block. The target block is a new block constructed based on the block generation request, awaiting consensus confirmation, and may include transaction data, timestamps, and other information.

[0059] This embodiment provides a digital asset custody system, which includes consensus node devices and multiple MPC node devices in a blockchain system. The consensus node devices include multiple verification nodes, and the multiple MPC node devices communicate indirectly through the consensus node devices. When any verification node receives information to be transmitted from an MPC node device, the consensus node device synchronizes the information to be transmitted to the blockchain system based on a preset consensus algorithm, and then sends the information to the target MPC node device. Compared with the P2P communication between MPC node devices in traditional technologies, this can greatly reduce the complexity of network communication. Through the consensus algorithm of the decentralized consensus node devices, the information sent by the MPC node devices is consensus-based and uploaded to the chain, which can ensure the traceability of the multi-party secure computation process. This allows for timely data recovery when some nodes fail, and can also provide more complete audit data in response to the needs of regulatory agencies, so as to achieve rapid and effective supervision. In this way, while maintaining the decentralized characteristics, it can improve communication efficiency and enhance the security and robustness of the digital asset custody system. Overall, it achieves the technical effects of reducing network communication complexity, improving response efficiency, and meeting compliance requirements and auditing.

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

[0061] In response to the current consensus phase, multiple verification nodes generate random seed information based on their own private keys; the random seed information includes verifiable random output values ​​and proofs;

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

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

[0064] The random seed information can be generated based on pseudo-random numbers. In this embodiment, the random seed information can serve as the basis for electing a leader node. For example, the random seed information can be generated using a cryptographic algorithm. The random seed information includes a verifiable random output value and a proof. The verifiable random output value can be verified by verifying the true source of the output value, and the proof can be used as evidence for verification.

[0065] In one exemplary embodiment, the random seed information may be generated using a VRF-verifiable random function, thereby ensuring randomness while allowing others to verify the validity of the result via a public key.

[0066] The leader node can be a verification node used to handle core business logic during the signing process. The verification node can be determined jointly by multiple verification nodes through indirect communication. The leader node can be generated through distributed voting among the verification nodes that participated in generating and sending random seed information.

[0067] Furthermore, the leader node can be selected by each validator node obtaining random seed information from other validator nodes and verifying and electing them according to preset rules. In an exemplary embodiment, a hash value of the random seed information of each validator node can be generated using a hash function, and the leader node can be selected by sorting the hash values, taking the remainder, etc.

[0068] Furthermore, the leader node can also be elected by multiple validator nodes following the same rules for determining the leader node. In one exemplary embodiment, the rule for determining the leader node could be to broadcast random seed information to other nodes, with each validator node verifying and scoring multiple random seed information entries, and selecting the node with the highest score as the leader node. In another exemplary embodiment, the rule for determining the leader node is that each validator node independently determines whether it is likely to be the leader node based on the random seed information, and then broadcasts the random seed information through the consensus node device for verification by multiple validator nodes, thereby electing the leader node.

[0069] Leader nodes represent all or some of the validator nodes in requesting the generation or submission of new blocks to the blockchain system. At different stages of the consensus process, leader nodes can be replaced through a re-election mechanism. This means that the pre-generation and submission of the target block can be performed by different leader nodes. For example, in two rounds, multiple validator nodes can generate random seed information based on their private keys, and then determine the same or different leader nodes through a scoring system. These leader nodes will then be responsible for generating and submitting the target block.

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

[0071] Obtain the current election round number and historical block information of the blockchain system; the current election round number is the round in which the leader node is determined;

[0072] Random seed information is generated based on the private key of the verification node, historical blocks, and the current election round number.

[0073] The current election round number can be a round sequence number used to identify the current election leader node during system operation, thereby ensuring the uniqueness of the random seed information in different rounds in terms of time or order. For example, the current election round number can be stored in a blockchain system, thus allowing it to be retrieved from the blockchain system.

[0074] Historical blocks can be confirmed previous block data in the blockchain system. Using historical blocks to generate random seed information can also be achieved by using the hash value of the most recent block to generate random seed information. This method ensures the verifiability and traceability of the election process.

[0075] For example, each verification node can obtain the current election round number and historical block data, then use its own private key, historical block data, and the current election round number as input to generate pseudo-random numbers and corresponding mathematical proofs using a Verifiable Random Function (VRF) algorithm. Finally, the above content is encapsulated as random seed information. By combining the system's global state parameters and the node's private key, the unpredictability and tamper resistance of random seed generation can be enhanced, while the round number ensures the specificity and independence of each election stage.

[0076] This embodiment provides a digital asset custody system that uses the current election round number and historical block data as input parameters to generate random seed information. By incorporating the system's global state and time parameters into the random seed generation process, it can significantly reduce the risk of the central node election being predicted or manipulated. Through a multi-stage parameter verification mechanism, it can reduce the possibility of malicious nodes undermining the system's credibility by forging rounds or tampering with historical data. Thus, while maintaining the advantages of a decentralized architecture, it can improve the security and reliability of the digital asset custody system.

[0077] In one embodiment, scoring is performed based on multiple random seed information, and the verification node corresponding to the random seed information whose score meets preset conditions is determined as the leader node, including:

[0078] It sends the random seed information it generates to other verification nodes and receives random seed information sent by other verification nodes.

[0079] Based on the proof in the random seed information, verify whether the verifiable random output value in the random seed information is correct;

[0080] If correct, double hashing is performed based on the verifiable random output value, and a score for 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. Verification nodes corresponding to random seed information whose scores meet preset conditions are identified as potential leader nodes. The leader node is determined based on the potential leader nodes identified by multiple verification nodes.

[0081] If not, reject the random seed information provided by the validator node and remove the validator node from the list of potential leader nodes.

[0082] The preset conditions for scoring can be the number or proportion of times that the verification node receives the highest score among other verification nodes, exceeding a preset threshold or preset percentage.

[0083] In one embodiment, determining the leader node based on potential leader nodes identified from multiple verification nodes includes:

[0084] If the number of verified nodes identified as potential leader nodes meets a preset threshold, then the verified nodes will be designated as leader nodes.

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

[0086] Among them, potential leader nodes can be candidate verification nodes that meet preset screening conditions. These screening conditions can include methods such as hash value sorting and mathematical operation results to determine whether a verification node meets the conditions. The verification result can be the judgment information of other nodes on the legality of the random seed information. For example, the verification result can be the result of "verification passed" or "verification failed" fed back in binary form.

[0087] The preset threshold can be the minimum number or proportion of verification results returned by other verification nodes during the election of a leader node. For example, the preset threshold can be generated through system pre-configuration or dynamic negotiation. Further, the preset threshold can include requirements such as more than 51% of verification nodes passing verification or at least t nodes confirming the result. The number of verification results can be obtained by collecting and statistically analyzing the total number of verification results returned by other verification nodes. In this embodiment, the leader node can be a verification node that has been verified and confirmed by a majority of nodes and has the authority to coordinate calculations.

[0088] Leader node confirmation or round updates are achieved by comparing the number of verification results with a 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 if it exceeds the maximum round limit. If it does not exceed the limit, a new round of election is initiated, and random seed information is regenerated. If the current confirmation round exceeds the maximum round limit, an exception handling mechanism such as forced random node selection or system pause can be triggered. This process, combining threshold-driven consensus confirmation with round control, ensures that the election of the leader node converges within a limited number of attempts, avoiding resource consumption due to node anomalies or network failures.

[0089] For example, if the number of verification nodes identified as potential leader nodes meets a preset threshold, then the verification node is designated as the leader node. This can be achieved by the current verification node determining the preset threshold based on its own random seed information and the total number of verification nodes participating in the consensus, and then determining whether the number of verification nodes identified as potential leader nodes meets the preset threshold, thereby designating the verification node as the leader node.

[0090] If the conditions are not met, the system can also receive verification requests from other verification nodes and use the VRF public key to verify the matching of the random number with the proof. When the collected verification results exceed a preset threshold (e.g., a two-thirds majority agrees), the corresponding verification node can be confirmed as the final leader node; if the threshold is not reached, a round update mechanism is triggered, the current confirmation round number is incremented, and the election process is restarted.

[0091] In one specific embodiment, when any validator node receives information sent by an MPC node device, the validator node first saves the received information to be sent into a buffer pool, and then reaches a consensus with other validator nodes through aggregated signature consensus to synchronize the information onto the chain. This includes: each validator node using its own private key to generate a corresponding verifiable random output value and proof, and then broadcasting this data to other validator nodes in the network. After collecting verifiable random outputs and proofs from other validator nodes, each validator node can calculate and score the verifiable random results of each node according to a preset deterministic algorithm, thereby obtaining its final score. The node with the highest score is elected as the leader node in this round of consensus process.

[0092] This embodiment provides a digital asset custody system that, based on the random seed information and the number of verification nodes, determines whether the current verification node is a potential leader node. This enables rapid screening of potential candidate nodes through quantitative rules, reducing the redundancy of global broadcasting. By judging whether the number of verification results meets the conditions based on a preset threshold, the system determines the leader node or performs round updates. By combining a dynamic round mechanism with anomaly handling strategies, the system achieves the technical effect of improving the determinism and anti-attack capability of the central node election process. By utilizing the round increment and re-election process, the system ensures that consensus is reached within a reasonable time, thus optimizing resource utilization efficiency and reducing communication latency while maintaining decentralized characteristics.

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

[0094] Generate a pre-generation request or pre-commit request corresponding to the target block;

[0095] Broadcast the pre-generated request or pre-submitted request to other verification nodes;

[0096] Obtain the signature results generated by other verification nodes for the pre-generated request or pre-submitted request; if multiple signature results meet the aggregation conditions, obtain the aggregated signature based on the multiple signature results; broadcast the aggregated signature to other verification nodes.

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

[0098] Furthermore, after receiving a block generation request, the consensus node device can verify the legitimacy of the request according to the blockchain protocol rules. Once verified, the consensus node generates the target block and broadcasts it to all verification nodes.

[0099] The signature result can be a fragment of a target block partially signed by a validator node based on a share of its private key. It needs to be combined with other validators based on different shares of their private key to form a complete and correct signature. Understandably, threshold signature techniques require at least t fragments to recover a complete signature, such as those implemented using the Shamir secret share scheme. The Shamir secret share scheme can be a technique that divides the private key into n shares and requires t shares to recover the private key. For example, the Shamir secret share scheme can include a (3of5) threshold configuration.

[0100] Each validator node uses its private key to partially sign the pre-generated or pre-committed request, generating a signature fragment. Furthermore, the signature result can be sent directly from the validator node to the leader node via a point-to-point network.

[0101] Aggregated signatures combine multiple signature results into a single signature. For example, based on the aggregation properties of BLS (Boneh Lynn Shacham) signatures, multiple signatures can be compressed into a fixed length. In one specific embodiment, after collecting signature results exceeding a threshold, the leader node uses a preset aggregation algorithm to merge multiple signature results into a complete signature. The threshold can refer to the minimum number of signature results required to generate a valid signature.

[0102] Furthermore, the aggregated signature is broadcast to non-leadership verification nodes. When a non-leadership verification node reaches a certain threshold, it verifies the aggregated signature information and confirms the block information, thus completing the block verification and writing the block into its own ledger.

[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 validator nodes. Upon receiving the pre-generation request, each non-leader node performs local verification of the block content; if the verification passes, it 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 at least two-thirds of the non-leader nodes, it aggregates these signatures using its own private key to generate an aggregated signature result. This aggregated signature is then broadcast to all validator nodes. Upon receiving the aggregated signature, the non-leader validators verify it again. If the verification passes, consensus in the pre-generation phase is considered achieved, and the process proceeds to the pre-commit phase.

[0104] In one specific embodiment, after entering the block pre-commit phase, a new leader node is elected again. This leader node is responsible for generating the block pre-commit request and broadcasting it to all non-leader validator nodes. Upon receiving the pre-commit request, each non-leader validator node first verifies the pre-commit content of the current block. If the verification passes, it signs the request using its own private key and returns the signature result to the leader node. When the leader node receives valid signatures from at least two-thirds of the non-leader nodes, it aggregates these signatures using its own private key to generate an aggregated signature result, which is then broadcast to all validator nodes. Other validator nodes, upon receiving the aggregated signature, will verify it again. If the aggregated signature verification passes, the pre-commit consensus is officially reached, and the final block information will be written into the blockchain. Simultaneously, messages from MPC node devices will also be recorded along 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, designating the current verification node as the leader node, or updating the current confirmation round number, includes:

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

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

[0108] In one embodiment, the MPC node device is also used for:

[0109] During the pre-signature stage, random multiplication triples are generated offline based on a preset protocol;

[0110] During the online interaction phase, the message to be signed is signed based on random multiplication triples and private key sharding to generate a signature share; the signature share is sent to other MPC node devices through consensus node devices; based on the signature share and the signature shares from other MPC node devices, the final signature result is obtained through aggregation calculation.

[0111] In this embodiment, the multi-party secure computation is improved and divided into a pre-signature stage and an online interaction stage. The pre-signature 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 computing efficiency while ensuring the validity of the signature.

[0112] A random multiplication triple can be three elements (a, b, c) that satisfy the multiplication relation, where c = a × b. During the generation of random multiplication triples, each element is random and unpredictable. For example, the generation of triples can be accomplished by assigning generation tasks and verifying correctness using secret sharing techniques.

[0113] A pre-defined protocol can be a set of rules for distributed generation of random multiplication triples. This ensures the correctness and randomness of the triples and prevents participating nodes from independently deriving the values ​​of other elements. For example, the protocol may include steps such as encrypted communication between nodes to exchange data and verifying whether c equals the product of a and b. For example, the pre-defined protocol can employ a protocol based on homomorphic encryption and secret sharing. Generating random multiplication triples based on the pre-defined protocol can be achieved through steps such as nodes collaboratively performing secret sharing tasks, encrypted communication to verify the correctness of the triples, and ensuring privacy protection, thereby hiding intermediate calculation values ​​and reducing the number of interactions between nodes.

[0114] Private key fragments can be segments of a private key obtained by using threshold signature technology, such as independent fragments generated based on Shamir secret sharing. Each fragment must meet a threshold condition to recover the complete private key.

[0115] A signature fragment can be a partial signature result generated by an MPC node device using private key fragments and random multiplication triples to sign a message to be signed. It needs to be combined with fragments from other nodes to form a valid signature. For example, a signature fragment can include an intermediate signature value generated by an encryption algorithm and proof of the source's legitimacy.

[0116] The signature fragment can be generated based on random multiplication triples and private key fragmentation. This can be achieved by multiplying the private key fragment with the triple elements, then executing an encryption algorithm (such as elliptic curve signature algorithm), hiding intermediate data using the triple multiplication relationship, and attaching a digital signature to prove the legitimacy of the source. This improves the security of private key fragmentation while reducing communication overhead.

[0117] Generate aggregated signatures based on preset signature algorithms. This can be done by verifying whether the number of fragments exceeds a threshold, checking the legality of fragments and triplet verification information, and using algorithms such as BLS to merge valid fragments to obtain aggregated signatures, thereby quickly filtering valid data and reducing the amount of signature data.

[0118] This embodiment provides a digital asset custody system that, through the synergistic effect of the multiplication relationship of random multiplication triples and a privacy protection mechanism, can prevent private key fragments from being exposed due to intermediate value leakage, thereby improving key security. By reducing the number of direct interactions between nodes through a preset protocol and combining it with the encrypted transmission method of signature fragments, the complexity of network communication can be reduced, thereby achieving the technical effects of improving privacy security, communication efficiency, and reliability of signature aggregation.

[0119] In one embodiment, when the information to be transmitted meets the preset triggering conditions, the leader node is also used to generate temporary random value information;

[0120] MPC node devices are also used for: obtaining temporary random value information sent by the leader node; sharding the message to be signed based on the temporary random value information and their own private key to generate a signature share; sending the signature share to other MPC node devices through the consensus node device; and obtaining the signature result based on the signature share and the signature shares from other MPC node devices.

[0121] The temporary random value information can be a random value R temporarily generated by the leader node in response to a preset trigger condition. agg .

[0122] For example, a temporary random value R agg Includes a partial random number R for each verification node i and for verifying R i Verification of authenticity commitment information C i Furthermore, the temporary random value R agg It can be based on multiple verification nodes. i Aggregation generation.

[0123] In one specific embodiment, during the process of generating random seed information, each verification node synchronously generates its own partial random number R. i and the corresponding verification commitment information C i Furthermore, pseudo-random numbers can be generated using random seed information, serving as a partial random number R. i In the process of determining the leader node using random seed information, each validator node, or the finally determined leader node, collects and aggregates the partial number R of all validator nodes. i Generate the final aggregated random value R agg This value is then embedded into the currently pre-generated block information. During the pre-generation request process, the leader node can synchronously or asynchronously aggregate the random value R. agg The calculation is performed, and the aggregated temporary random value is used to calculate the signature share of the MPC node. Since this process does not consume additional computing resources or communication rounds, it can complete the core tasks of the pre-signature stage, thereby significantly improving the system's signing efficiency and effectively reducing resource consumption.

[0124] In one embodiment, when the MPC node device fails, the digital asset custody system is also used to quickly restore the MPC node device to its pre-failure state based on the MPC node device operation status log stored in the blockchain system.

[0125] Understandably, when a consensus node device acts as a message queue and receives a message from an MPC node device requesting to broadcast to other MPC node devices, it will initiate a consensus process to reach consensus on the message from the MPC node device and upload it to the blockchain system. Therefore, when an MPC node device malfunctions, its state can be quickly restored through the block information in the blockchain system.

[0126] A blockchain system can be a decentralized data storage network implemented using distributed ledger technology. Transaction data can be written to a specific storage location on the chain through smart contract interfaces. The interaction status and related information of MPC node devices are stored in the blockchain system, and the integrity of data updates is ensured through blockchain protocol verification. This ensures the traceability of the signature process, which is beneficial for data recovery and compliance checks by regulatory agencies. The distributed nature of blockchain avoids the single point of failure risk of centralized storage, thereby improving data credibility and system recovery capabilities.

[0127] The digital asset custody system recovers based on signature status information. This can be achieved by retrieving the latest status information from the blockchain system through other normal nodes and reconstructing the current signature process progress. In one specific embodiment, if the failure occurs during the signature aggregation stage, the system can also designate a new consensus node device as the new message queue to complete the remaining multi-party secure computation and interaction processing. By automatically reconstructing the system's operating status using the aforementioned pre-stored trusted status information, the need for manual intervention can be reduced, and the system's fault tolerance and availability can be improved.

[0128] This embodiment provides a digital asset custody system that records the interaction information of MPC node devices to the blockchain system to ensure reliable data storage. Combined with the automatic recovery mechanism based on the blockchain's stored state information, it can improve data reliability by utilizing the blockchain's immutability and distributed storage characteristics. At the same time, by pre-stored state information, it can achieve automatic fault location and process reconstruction, which can further enhance the system's fault tolerance and improve the continuity and security of digital asset custody services.

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

[0130] Among them, key management devices can be used to generate, store, distribute and manage keys in digital asset custody systems. Key management can be achieved by adopting hardware security modules (HSMs) and key management protocols based on the PKCS11 standard.

[0131] A trusted execution environment (TEE) can be a secure area built using hardware or software isolation technologies, such as Intel SGX, ARM TrustZone, or virtualization-based trusted environments. For example, it can include methods such as memory encryption and code verification to protect the runtime space of the key management device.

[0132] The number of key management devices is matched with the number of verification nodes. This can be a one-to-one matching relationship between key management devices and verification nodes, so that each verification node is equipped with a dedicated key management device; or a one-to-many or many-to-one matching relationship between key management devices and verification nodes. This embodiment does not limit this.

[0133] This embodiment provides a digital asset custody system that, by deploying a key management device running in a trusted execution environment (TEE), and combining this device with a one-to-one correspondence with verification nodes, as well as collaborative mechanisms such as key distribution, operation verification, and state synchronization, can leverage the hardware-level isolation characteristics of the TEE and the specialized functions of the key management device to enhance the anti-attack capabilities of sensitive data such as private keys. Furthermore, the matching relationship between the key management device and verification nodes improves the flexibility of system expansion while avoiding performance bottlenecks caused by centralized key management, thus enhancing the overall security of the system.

[0134] In one embodiment, the digital asset custody system further includes an identity information management device and an identity verification device; the identity information management device is communicatively connected to the identity verification system, stores user identity information, and is used for:

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

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

[0137] The verification response information and the issuing authority's public key are sent to the authentication device;

[0138] The authentication device is also used for:

[0139] Calculate the first root hash value based on the attribute value and the Merkle tree path;

[0140] Obtain the second hash value corresponding to the verification response information;

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

[0142] The verification request information can be an instruction used to request a specific user to verify their identity attributes, containing the user's unique identifier and the required attribute type (such as name, ID number, etc.). For example, the verification request information can be constructed and sent by an authentication device based on a user-initiated verification request (such as a login or transaction authorization request). The verification request information can be transmitted in the form of a request packet, compressed file, QR code, or other data format, containing the user's unique identifier and the required attribute type.

[0143] An authentication device can be a dedicated device for performing user authentication, used to send authentication requests to an identity information management device and confirm the validity of the authentication response. By structuring authentication requests, the authentication device can clearly define the authentication target. For example, it can determine the specific attribute type that needs to be verified based on the authentication request information and send an instruction containing the user identifier and attribute type to the identity information management device, thereby reducing invalid data transmission.

[0144] User identity information can be a set of user attributes stored in an identity information management device, such as name and ID number. User identity information can be constructed using a Merkle tree. A Merkle tree path can be a hash path from a leaf node to the root node in the Merkle tree, used to prove the integrity of attribute values; it can be generated by the identity information management device based on the stored Merkle tree structure.

[0145] The issuing authority's public key can be a public key provided by an authoritative institution. After a user completes registration with the issuing authority, the issuing authority may provide the user with credential information signed by the issuing authority's private key. The issuing authority's public key can be used to verify the authenticity of the signature and the validity of the Merkle root hash.

[0146] After receiving a verification request, the identity information management device can retrieve an attribute value that matches the required attribute type in the verification request, such as a user's name or ID number. It then generates a Merkle tree path corresponding to this attribute value to ensure data integrity. The device uses the user's private key to sign the attribute value and path, forming signature data. The attribute value, path, signature data, and the issuing authority's public key are then encapsulated into verification response information. This method, through the combination of zero-knowledge proofs and layered signature verification, ensures the trusted source and integrity of the response information without exposing complete identity data. Furthermore, the Merkle tree path corresponding to the attribute value can include the Merkle tree path where the attribute value resides, and can also include branch paths of other Merkle trees besides the current attribute value. For example, it can sequentially obtain the hash values ​​of each necessary branch path of the Merkle tree required to obtain the Merkle tree root hash value based on the leaf node where the attribute value resides.

[0147] After receiving the verification response information, the authentication device can use the issuing authority's public key to verify the validity of the signature data and verify the integrity of the attribute value through the Merkle tree path. This enables lightweight verification of data fragments. For example, when verifying a user's name, only the path corresponding to that attribute needs to be transmitted instead of all identity information, which can effectively reduce the amount of data transmitted and improve the security of the user's privacy information.

[0148] Attribute values ​​can be specific parameters used to identify user or data characteristics, such as user name, age, etc., and can be transmitted to the authentication device through the verification response information.

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

[0150] The first root hash value can be the root hash value obtained by reconstructing the Merkle tree path through recursive hashing operations, which can be achieved by merging the hash of the current node with the hash of its sibling nodes.

[0151] The second hash value can be the Merkle tree root node hash value pre-published by the issuing authority, and can be obtained through trusted channels, such as blockchain storage, verification response information appended fields, etc. For example, the second hash value can be transmitted through a signed data packet verified by the issuing authority's public key, or it can be obtained by querying the issuing authority's public record database.

[0152] The comparison result can be a determination of whether the first hash value and the second hash value are consistent, which can be obtained through bit-by-bit comparison. Determining the validity of the verification response information can be based on a comprehensive evaluation of the comparison result and the business compliance of the attribute value. In a specific embodiment, the device first verifies the consistency of the hash value, then checks whether the attribute value conforms to business rules (such as whether the age is within the legal range), and finally outputs a conclusion of verification success or failure. This dual verification mechanism, using bit-by-bit comparison of hash values ​​and verification of business rules, ensures data integrity and source credibility, prevents man-in-the-middle tampering of attribute values, and avoids the risk of impersonation that may exist if signature verification is relied upon alone.

[0153] This embodiment provides a digital asset custody system that uses an identity verification device to send structured verification request information to clarify the type of attribute to be verified. An identity information management device generates verification response information based on a Merkle tree path and the user's private key to achieve zero-knowledge proof of the data fragment. The identity verification device performs layered verification using the issuing authority's public key and the Merkle tree path to ensure trustworthiness. This system transmits necessary attribute values ​​and paths, thereby reducing the risk of sensitive information leakage. It optimizes the efficiency of the identity verification process without sacrificing security and decentralization, thus improving system security. By calculating the first hash value based on the attribute value and the Merkle tree path to verify data integrity, and obtaining the second hash value through a trusted path as a verification benchmark, the validity of the verification response is determined by comparing the hash value with the attribute value to comprehensively assess compliance. This strengthens data trustworthiness and, compared to a single verification method, improves the security of the verification process.

[0154] In one embodiment, the authentication device is further used for:

[0155] Based on the verification response information, the preset compliance check interface is invoked to obtain the compliance check results;

[0156] Based on the compliance check results, generate response results for the business processing requests sent by users;

[0157] The business processing requests and response results are stored in the blockchain system.

[0158] The compliance check interface can be a pre-defined API or service endpoint used to execute specific compliance verification rules, such as anti-money laundering and KYC compliance checks. For example, the compliance check interface may include an anti-money laundering rule verification API, a machine learning-based transaction risk assessment service interface, etc. The compliance check result can be the verification result returned by the interface, or it may include a confirmation result indicating whether the user's request meets pre-defined compliance standards. For example, the compliance check result may include an identifier indicating that the transaction risk rating is high or low.

[0159] For example, if the verification response request matches the root hash value comparison result, the relevant attribute value can be used as an input parameter to call the compliance check interface to obtain the compliance check result.

[0160] The response result generated based on the compliance check result can be determined based on the compliance check result to determine whether the user request is compliant; if compliant, an allowed response result is generated, such as transaction confirmation; if non-compliant, a rejection response result is generated. Furthermore, a reason explanation can be attached; the response result can include a business request identifier and a processing timestamp.

[0161] Storing business processing requests and responses in a blockchain system can be achieved by packaging these requests and responses into transaction data, generating new block metadata containing this transaction data, and broadcasting the new block to the blockchain network through consensus node devices. This leverages the immutability of the blockchain to provide transparent and auditable records of business processing, thereby enhancing system credibility.

[0162] This embodiment provides a digital asset custody system that reduces operational risks at the compliance level by calling a preset compliance check interface to perform compliance verification. Based on the verification results, it generates automated responses and stores business data in a blockchain system, ensuring the immutability and traceability of records. This achieves the technical effects of improving compliance automation, audit transparency, and risk control.

[0163] To more clearly illustrate the technical solution of this application, a detailed embodiment is also provided.

[0164] In one embodiment, a digital asset custody system is provided, including a blockchain threshold signature custody wallet system. This system generates private key fragments for each participant using multi-party secure computation (MPC) technology, and during asset transactions, participants who have reached a threshold collaboratively compute and generate a transaction signature. This embodiment's digital asset custody system significantly improves the efficiency and parallel processing capabilities of multi-party computation by optimizing the interactive computation process between signature and pre-signature. Through a decentralized network architecture, it enhances the system's high availability and scalability. Furthermore, this embodiment's digital asset custody system deeply integrates KYC / AML solutions into the wallet functionality, thereby achieving a unified design for security and compliance.

[0165] The digital asset custody system in this embodiment includes a lightweight blockchain architecture that combines the PedersenDKG protocol with the BLS aggregate signature algorithm, and designs a threshold signature function for the latter. A leader node is randomly selected through a verifiable random function (VRF) and deeply integrated with the BFT consensus algorithm to construct a BFT consensus protocol based on VRF and aggregate threshold signatures. This architecture ensures the immutability and transparency of information transmitted in the message queue. By designing an efficient message passing protocol, the system achieves secure exchange of computation results between participants and provides verifiability for each computation step. Furthermore, the system utilizes on-chain historical message records to monitor the status of each node in real time, enabling rapid recovery to the pre-failure state when a node fails, thereby significantly improving the system's fault tolerance and scalability.

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

[0167] When any validator node receives information sent by the MPC node device, the validator node generates random seed information and determines the leader node in the consensus node device based on the random seed information; the leader node includes the leader node and the aggregator node.

[0168] The leader node is used to send block generation requests to generate the target block; the aggregator node is used to generate an aggregate signature based on the signature fragments generated by multiple validator nodes for the target block; and broadcast the aggregate signature to the blockchain system.

[0169] In the multi-party secure computation process of MPC node devices, the private key can be securely divided into multiple shares based on the Pedersen DKG secret sharing protocol to ensure the security of private key management. Subsequently, an equivalent transformation is performed on the standard ECDSA signature algorithm to make it more suitable for sharding aggregation technology. Based on this, combined with the SPDZ protocol and the Beaver triplet protocol, collaborative computation among multiple participants is achieved, distributing the computation process of signature values ​​r and s into r... i and s i This design enables each node to complete its own signature share calculation (r) in a non-interactive manner. i , s i Finally, the computation results (r, s) of each node are aggregated through the SPDZ protocol and the Beaver triple protocol. This method enables asynchronous or parallel signature computation, significantly improving the efficiency of signature generation and system scalability. Figure 2 As shown.

[0170] and Figure 3 Compared to the traditional MPC computing node interaction method shown, the digital asset custody system in this embodiment optimizes the interaction process. MPC computing nodes only need to exchange and aggregate results during the final round of online interaction. Similarly, the pre-signature process has also been optimized, such as... Figure 4 As shown, compared to Figure 5 Compared to traditional methods, this embodiment only performs message interaction between MPC computing nodes in the last round, thereby significantly improving the system's parallel computing capabilities and scalability, reducing communication overhead between nodes, and providing a feasible technical path for efficient signature computation in a large-scale distributed environment.

[0171] In addition to combining the SPDZ protocol and the Beaver triple protocol to achieve pre-signing, this embodiment also provides another multi-party secure computation method. Specifically, during the indirect communication between MPC node devices and consensus node devices, when the information to be transmitted meets preset trigger conditions, the leader node generates a temporary random value (Ragg). The MPC node devices then: obtain the temporary random value Ragg sent by the leader node; fragment the message to be signed based on the temporary random value and their own private key, generating a signature share; send the signature share to other MPC node devices through the consensus node device; and obtain the final signature result based on the signature share and the signature shares from other MPC node devices. Since this process does not require additional computing resources or communication rounds to complete the core tasks of the pre-signing stage, it significantly improves system signing efficiency and effectively reduces resource consumption.

[0172] In terms of security, each verification node in this 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) to ensure the security of private keys at the hardware level. This embodiment also shifts the communication network of the ECDSA threshold computing nodes from a traditional centralized architecture (such as...) Figure 6 (As shown) Reconstructed into a decentralized communication network (such as Figure 7 (As shown). By fully utilizing the characteristics of blockchain, the fault tolerance and scalability of the system can be significantly enhanced, providing a more robust and flexible communication infrastructure for threshold signature computation.

[0173] The threshold signature process in this embodiment includes:

[0174] Private key shares are generated using the EdDSA threshold signature algorithm and the Distributed Key Generation (DKG) algorithm. During the consensus algorithm execution in this embodiment, a pre-computation task is performed to generate a random number R based on the public interactions required to complete the EdDSA partial signature. agg When the threshold signature is officially running online, the pre-computed R is obtained from the blockchain. agg Value, locally generated partial signature S i Then, it is shared with other threshold signature nodes through the blockchain of this embodiment. Finally, when each threshold node receives a portion of S exceeding the threshold, i Then, the final signature S is calculated using an aggregation algorithm, completing the threshold signature process for the blockchain designed in this embodiment.

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

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

[0177] Generate a random seed: Each validator calculates the VRF output: (seed) i , π i )=VRF(sk i The VRF results are then broadcast to other nodes, and so on, until all validators receive the VRF results from other nodes. Each validator node then executes a leader election algorithm locally based on VRF and dynamic reputation weights, calculating a score for each node. The node with the highest score becomes the leader for that round. If elected as the leader, it will assume the roles of "proposer" and "aggregator" for the current block. Figure 8 As shown, validator node 04 is a malicious node, and other validator nodes fail to verify its verifiable random credential 04. Validator node 03, whose verifiable random credential 03 has the highest score, is elected as the leader. During the proposal phase, the proposer, in addition to packaging the block information to be agreed upon, also submits its VRF proof (seed) of being elected as the proposer. i , π i The block proposal is written into the block header and broadcast to other validators. Upon receiving the block proposal broadcast, other validators not only verify the proposed block information but also check the VRF result (seed) of the elected leader. i , π i The verification process is as follows: The leader election algorithm based on VRF and dynamic reputation weights uses a hash weight random scaling algorithm to generate a random compensation factor, a dynamic reputation scoring algorithm to obtain dynamic reputation weights, and then adjusts the VRF scoring results using the random compensation factor and dynamic reputation weights to obtain the verification results. The scoring algorithm is: Score i =HashToNum i WF i ·PRF i ·K, where HashToNum i WF is a large integer derived from the quadratic hash transformation of the random number generated by VRF. i Composite reputation weight (PRF) for each validator node i K is the random compensation factor (introducing controllable randomness with an adjustable range), and K is the scaling factor (used for numerical normalization adjustment to avoid floating-point operation errors, K=10). 18 ).

[0178] Phase Two: Propose & Threshold-Vote.

[0179] Block proposal: The leader node selected in the first phase is responsible for generating new blocks and broadcasting the new blocks 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. If the verification passes, it first generates a pre-computation task R. i =r·G, which is then used together with the new block to generate the BLS partial signature σ. i =Sign(sk i H(Block)‖R i ). The signature fragment σ i and R i These will be sent together to the leadership nodes of this round (selected in the first phase). Among them, sk... i H 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 Broadcasting: The leader node collects partial signatures σ sent by at least t validator nodes. i and R i Then, the aggregate signature σ is generated first. agg =Aggregate(σ1, ..., σ) t Then aggregate the pre-calculated results R. agg =Agg(R1, ...,R t ); final broadcast (σ) agg R agg This allows all verification nodes to proceed to the next round of consensus process.

[0182] Simultaneously, a dual-mode aggregation and verification process, employing both an optimistic and fallback paths, is introduced to address the potential impact of some signature anomalies on consensus liveness. Under the optimistic path, the system assumes that most verification nodes provide valid signatures, thus quickly completing aggregation and verification. Once anomaly signatures are detected, the system switches to the fallback path, verifying and removing anomalous signatures one by one to ensure the correctness of the final result. During the fallback process, verification nodes exhibiting anomalous behavior are flagged and subject to decaying penalties in the reputation model, reducing their probability of being elected as leaders in the future.

[0183] To verify the security of the verifiable random function in this application compared to the traditional PBFT consensus algorithm, the applicant selected 10 users as verifiers and set certain weights based on one or more of the user's characteristics or behavioral patterns, activity level, contribution level, and other relevant indicators to verify 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 were compared by running the election algorithm several times.

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

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

[0187] Therefore, it is evident that the traditional PBFT algorithm exhibits extremely high determinism and uniformity in terms of distribution uniformity, with each validator making approximately 100 selections almost mechanically (standard deviation of only 0.30). This extremely uniform distribution is actually a predictable distribution. In contrast, the consensus algorithm in this embodiment demonstrates a distribution characteristic more consistent with randomness (standard deviation 5.49). Although this may seem "less uniform," it actually reflects the characteristics of a real random process. Under ideal random conditions, the selection distribution will not be absolutely uniform in the short term, but it will remain relatively fair in the long term.

[0188] In terms of randomness, the consensus algorithm in this embodiment demonstrates superior performance in randomness metrics, achieving a transition diversity of 100% (1.0), far exceeding the original algorithm's 10% (0.1); its transition entropy (information entropy) is as high as 6.6007, almost twice that of the traditional algorithm (3.3219); and it has 100 unique transition patterns, compared to only 10 in the traditional algorithm. This indicates that the consensus algorithm in this embodiment introduces extremely high randomness and unpredictability, preventing any attacks attempting to predict the proposer order.

[0189] In terms of prediction difficulty, the consensus algorithm in this embodiment significantly reduces the predictability of the sequence. The predictability of the traditional algorithm is 100% (1.0), which means it is completely predictable, while the predictability of the consensus algorithm in this embodiment is reduced to 49.43%, and the prediction difficulty is increased by 50.57%. This reduction makes it difficult for attackers to predict the proposer of the next block, thereby improving the security of the protocol.

[0190] From the perspective of balancing short-term and long-term fairness, the consensus algorithm in this embodiment introduces short-term randomness while maintaining long-term fairness (the number of choices for each validator is relatively balanced, ranging from 9.19% to 10.89%). The standard deviation of short-term fairness increases (from 0.0012 to 0.0187), and is no longer a mechanically uniform distribution. This actually enhances the system's resistance to attacks targeting the known order of proposers.

[0191] Therefore, compared with the traditional PBFT consensus algorithm, the consensus algorithm of this embodiment can achieve the following technical effects: (1) Enhanced security: By introducing true randomness and unpredictability, it prevents attacks targeting the known order of proposers, such as long-range attacks and predictive DoS attacks. (2) Increased randomness: The transition diversity is increased by 10 times, and the information entropy is almost doubled, making the system behavior more difficult to predict and more random. (3) Balanced fairness: While maintaining a fair validator selection ratio in the long term, short-term random fluctuations are introduced, which is more in line with the characteristics of real random processes. (4) Reduced predictability: The predictability of the sequence is reduced from 100% to about 50%, which greatly increases the difficulty of prediction.

[0192] The consensus process in this embodiment, through signature aggregation, reduces the complexity from O(n-1) to O(1) compared to the traditional PBFT consensus algorithm where each validator needs to verify the signatures of all other validators. This is achieved by merging multiple signatures into a single signature. Furthermore, the embodiment employs a leader-centric approach, where non-leaders only send messages to the leader, who then aggregates and broadcasts the results. This significantly reduces network communication from O(n²) to O(n) compared to traditional consensus algorithms where validators broadcast messages to all other validators. The batch signature verification mechanism, employing a hybrid strategy of first attempting aggregate verification and then verifying individually if failed, maintains high efficiency in most cases while detecting and isolating malicious nodes. The mechanism of detecting and isolating malicious nodes individually when aggregate signature verification fails effectively prevents a single malicious signature from causing the entire aggregate signature verification to fail.

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

[0194] To verify the technical effectiveness of the consensus process in this application compared to the traditional PBFT-based consensus algorithm, the applicant set up three experimental groups, using network environments with 4 nodes, 20 nodes, and 50 nodes respectively, to compare the consensus algorithm of this embodiment with the traditional algorithm.

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

[0196] When the number of nodes is 20, the traditional consensus algorithm completes 48 rounds, resulting in a final block height of 48. Its total running time is 37.573 seconds, with an average round time of 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 in this embodiment completes 51 rounds, resulting in a final block height of 51. Its total running time is 39.261 seconds, with an average round time of 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, resulting in a final block height of 40. Its total running time is 37.880 seconds, with an average round time of 0.409 seconds. The fastest round takes 0.354 seconds, and the slowest round takes 0.460 seconds, resulting in an average of 1.056 blocks generated per second. The consensus algorithm in this embodiment completes 38 rounds, resulting in a final block height of 38. Its total running time is 31.339 seconds, with an average round time of 0.285 seconds. The fastest round takes 0.253 seconds, and the slowest round takes 0.320 seconds, resulting in an average of 1.213 blocks generated per second.

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

[0199] This embodiment provides a digital asset custody system that utilizes a blockchain-based decentralized communication architecture with a message queue scheme. Employing an indirect communication mode, nodes exchange and broadcast messages via a decentralized message queue, reducing network communication complexity to O(n). Compared to the O(n²) complexity of traditional network-wide broadcasting, this represents a significant optimization of network communication. Benefiting from the tamper-proof, traceable, and anti-malicious-attack characteristics of blockchain technology, this embodiment effectively enhances the security, reliability, and traceability of message interaction. Furthermore, by persistently storing the interaction state of threshold nodes on the blockchain, the system can quickly recover from node failures. That is, when a node fails, it can quickly restore to its pre-failure state by accessing the state information stored on the blockchain, ensuring the continuity of system operation. By designing a threshold signature function for the Blockchain Signature Algorithm (BLS), randomly selecting a leader node via VRF, and deeply integrating it with the Blockchain-Future Soft (BFT) consensus protocol, the communication complexity of the BFT consensus algorithm can be optimized from O(n²) to O(n), thereby significantly improving the message interaction efficiency of the blockchain system. This protocol not only effectively solves the bottlenecks in communication efficiency and reliability of traditional threshold signature systems, but also opens up a new technical path for building high-performance, highly available blockchain threshold signature systems. Specifically, addressing the key management issues involved in combining the BFT consensus algorithm with threshold signatures, this embodiment uses a Sidecar node architecture to decouple the consensus function and key management function coupled in traditional blockchain nodes. An independent Sidecar node is configured 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 a Key Management System (KMS), ensuring the security of private keys at the hardware level. This architecture design not only supports dynamic private key updates without affecting normal node operation, but also keeps the public key unchanged, thereby significantly improving system security and availability, and providing a more flexible and secure solution for key management in blockchain systems.

[0200] The digital asset custody system in this embodiment also includes an identity information management device, specifically a VC file management device, used to implement a KYC / AML scheme based on the W3C DID standard. By deeply integrating the W3C's Decentralized Identifiers (DIDs) standard, Zero-Knowledge Proofs (ZKP), and Merkle Tree technology, the security of the user end can be effectively enhanced. Users can import and manage VC files issued by issuing authorities through the identity information management device.

[0201] Specifically, a digital asset custody system may include a DID identity system, Merkle tree components, zero-knowledge proof components, verifiable credential (VC) components, identity information management components, an anti-money laundering (AML) platform, and a blockchain system.

[0202] The DID identity system, based on W3C standards, creates unique DID (e.g., did:ethr:0x...) identifiers for users. A Merkle tree is used to shard user KYC information into leaf nodes, generate a root hash, and store it on a blockchain or IPFS. A zero-knowledge proof component generates ZKP proofs of data validity without compromising privacy when users selectively disclose information. A verifiable credential (VC) component is used by issuing authorities to sign the Merkle root hash, generating a VC containing user identity and compliance proof. An identity information management device stores and manages VCs and generates ZKP proofs. An anti-money laundering platform can integrate APIs from Chainalysis, TRM Labs, etc., for real-time verification of transaction compliance. The blockchain system stores the root hash value, VC metadata, and transaction records, ensuring tamper-proof and traceability.

[0203] During the user registration and identity verification process, participating nodes include verification, issuing authorities, wallet systems, and regulatory agencies. Specifically, users submit KYC information, generate a DID, manage VCs, and respond to verification requests via dedicated devices; issuing authorities verify the authenticity of KYC information, generate and sign VCs to ensure compliance; wallet systems initiate verification requests (QR codes), verify the validity of VCs, and integrate AML tools to monitor transactions; regulatory agencies audit on-chain data, track suspicious transactions, and ensure compliance.

[0204] Phase 1: User registration and KYC information submission.

[0205] Create DID: Users generate a DID key pair (public key / private key) through the VC device and register the DID (e.g., did:ethr:0x...).

[0206] Constructing a Merkle tree: Users shard their KYC information (such as ID number, name, and address) into leaf nodes and generate a Merkle tree using SHA-256 hashing.

[0207] For example, a leaf node may include ["name:Zhang San", "id:123456...", "address:Beijing..."].

[0208] Submit Root Hash: Users submit the Merkle root hash to the issuing authority and store the leaf node hashes in IPFS or the blockchain.

[0209] Phase Two: The issuing authority issues the VC.

[0210] KYC verification: The issuing authority verifies the authenticity of the KYC information submitted by the user (e.g., through government databases or biometrics).

[0211] Generate VC: The issuing authority signs the root hash to generate VC, which includes: (1) did: user DID; (2) root_hash: Merkle root hash; (3) signature: digital signature of the issuing authority.

[0212] VC storage: Users import VC information into the VC device and store it encrypted using a dedicated device.

[0213] Phase 3: Wallet verification request.

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

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

[0216] Select Attributes: Users select the minimum required attributes to disclose (e.g., "Age" only).

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

[0218] Signature: User's private key signature ZKP and attribute value.

[0219] Response: Generate a QR code containing the ZKP, attribute value, signature, and issuing authority public key and send it to the wallet system. The wallet system obtains the required information by scanning the QR code on the VC device.

[0220] Phase 4: Wallet verification and compliance checks.

[0221] Verify ZKP validity: The wallet system verifies the VC signature using the issuing authority's public key; verifies that the user-disclosed attributes match the root hash via the Merkel path; and verifies whether the ZKP meets the requirements (e.g., "age ≥ 18 years old").

[0222] AML compliance check: Call the Chainalysis / Travel Rule API to check if the user's address is associated with the sanctions list and flag suspicious transactions (such as large transfers or frequent splits); if compliant, allow the transaction; otherwise, freeze assets and notify regulatory agencies.

[0223] Phase 5: Transactions and Audits.

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

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

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

[0227] This embodiment provides a digital asset custody system that deeply integrates the W3C's Decentralized Identifiers (DIDs) standard, Zero-Knowledge Proofs (ZKP), and Merkle Tree technology through a decentralized, privacy-preserving, and verifiable KYC scheme. The user's KYC information is constructed as a Merkle tree, where each leaf node represents an attribute (such as ID number, name, gender, etc.), and the 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. The user can import the VC file issued by the issuing authority through a VC device. During the verification process, 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 according to the principle of minimum disclosure and submitted to the wallet system by scanning the VC device's QR code through a signature system. The wallet system combines the issuing authority's public key, the Merkle tree root signature, the user's disclosed KYC information, and its corresponding Merkle tree path to verify the validity of the VC. After successful verification, users can proceed with subsequent operations. All verification data is stored encrypted on the blockchain, ensuring tamper-proof and traceability. This solution significantly reduces the risk of user information leakage while relieving financial institutions of the burden of storing 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, automatically verifying each transaction before it begins through smart contracts, ensuring the security, compliance, traceability, and auditability of transactions. This not only guarantees the secure transfer 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 offering greater convenience, efficiency, and cost-effectiveness.

[0228] It should be understood that the steps involved in the embodiments described above are not necessarily executed in the given order. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some of the steps involved in the embodiments described above may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but may be executed at different times. The execution order of these steps or stages is not necessarily sequential, but may be performed alternately or in turn with other steps or at least some of the steps or stages in other steps.

[0229] The various devices in the aforementioned digital asset custody system can be implemented entirely or partially through software, hardware, or a combination thereof. These devices can be embedded in or independent of the processor in a computer device, or stored in the computer device's memory as software, so that the processor can invoke and execute the operations corresponding to each of the above modules.

[0230] In one embodiment, a computer device is provided, which may be a terminal, and its internal structure diagram may be as follows: Figure 9 As shown, the computer device includes a processor, memory, communication interface, display screen, and input device connected via a system bus. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage media. The communication interface is used for wired or wireless communication with external terminals; wireless communication can be achieved through Wi-Fi, mobile cellular networks, NFC (Near Field Communication), or other technologies. When the computer program is executed by the processor, it implements the MPC node device, consensus node device, identity information management device, etc., as described in the above embodiments. The display screen can be an LCD screen or an e-ink screen. The input device can be a touch layer covering the display screen, buttons, a trackball, or a touchpad mounted on the computer device casing, or an external keyboard, touchpad, or mouse.

[0231] Those skilled in the art will understand that Figure 9 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

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

[0233] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments described above. Any references to memory, databases, or other media used in the embodiments provided in this 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 memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, etc., and are not limited to these.

[0234] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0235] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A digital asset custody system, characterized in that, The digital asset custody system includes consensus node devices of a blockchain system and multiple MPC node devices deployed through a distributed network. The consensus node devices include multiple verification nodes, and the MPC node devices are devices that participate in multi-party secure computation. The multiple MPC node devices communicate indirectly through the consensus node devices. When any verification node receives the information to be transmitted from the MPC node device, the consensus node device, acting as a message queue, reaches a consensus on the information to be transmitted based on a preset consensus algorithm, synchronously stores the information to be transmitted in the block information of the blockchain system, and then sends the information to be transmitted to the target MPC node device. The target MPC node device may be the MPC node device to which the information to be transmitted is intended. The information to be transmitted includes the device's operating status. The digital asset custody system is also used to monitor the device operating status of each MPC node device in real time using on-chain historical message records. When the MPC node device fails, based on the device operating status corresponding to the MPC node device stored in the blockchain system, the MPC node device is quickly restored to its state before the failure.

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, multiple verification nodes generate random seed information based on their own private keys; the random seed information includes verifiable random output values ​​and proofs; Each verification node scores based on multiple random seed information, and the verification node corresponding to the random seed information whose score meets the preset conditions is determined as the leader node; The leader node generates or submits the target block based on the information to be transmitted.

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

4. The digital asset custody system according to claim 2, characterized in that, The step of scoring based on multiple random seed information and determining the verification node corresponding to the random seed information whose score meets preset conditions as the leader node includes: It sends the random seed information it generates to the other verification nodes and receives the random seed information sent by the other verification nodes. Based on the proof in the random seed information, verify whether the verifiable random output value in the random seed information is correct; If correct, then double hashing is performed based on the verifiable random output value, and a score for 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 nodes corresponding to the random seed information whose scores meet preset conditions are identified as potential leader nodes. The leader node is determined based on the potential leader nodes determined from 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 process of determining the potential leader node based on multiple verification nodes includes: If the number of verified nodes identified as potential leader nodes meets a preset threshold, then the verified nodes are designated as leader nodes. If the number of all verified nodes identified as potential leader nodes does not meet the preset threshold or exceeds the predefined election time, the current election round is incremented, and each verified node regenerates the random seed information and redetermines the leader node until a leader node is determined.

6. The digital asset custody system according to claim 2, characterized in that, Based on the information to be transmitted, generating or submitting the target block includes: Generate a pre-generation request or pre-commit request corresponding to the target block; Broadcast the pre-generated request or the pre-submission request to the other verification nodes; Obtain the signature results generated by other verification nodes for the pre-generated request or the pre-submitted request; if multiple signature results satisfy the aggregation condition, obtain an aggregated signature based on the multiple signature results; broadcast the aggregated signature to the other verification nodes.

7. The digital asset custody system according to claim 2, characterized in that, When the information to be transmitted meets the preset triggering conditions, the leader node is also used to generate temporary random value information; The MPC node device is also used to: obtain temporary random value information sent by the leader node; and, based on the temporary random value information and its own private key fragmentation, sign the message to be signed and generate a signature share; The signature share is sent to the other MPC node devices through the consensus node device; The signature result is obtained based on the signature share and the signature shares from other MPC node devices.

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

9. The digital asset custody system according to claim 1, characterized in that, The digital asset custody system also includes an identity information management device and an identity verification device; the identity information management device is communicatively connected to the identity verification system, stores user identity information, and is used for: In response to the verification request information sent by the authentication device, obtain the attribute value in the user identity information that matches the verification request information, and at least one Merkle tree path corresponding to the attribute value; Based on the user's private key, the attribute value, and the Merkle tree path, a verification response message is generated; The verification response information and the issuing authority's public key are sent to the authentication device; The authentication device is also used for: Calculate the first root hash value based on the attribute value and the Merkle tree path; Obtain the second hash value corresponding to the verification response information; Based on the comparison result of the first hash value and the second hash value, and the attribute value, it is determined whether the verification response information is valid.

Images