Blockchain-based digital asset secure transaction system and method

Abstract

The application discloses a kind of digital asset security transaction systems and methods based on block chain, belong to the cross field of block chain technology and financial technology.Layered architecture design is used in system, including smart contract execution layer, distributed ledger storage layer and cross-chain interaction layer.Transaction method includes: generating digital identity certificate based on asymmetric encryption, privacy protection is realized by zero-knowledge proof;Multiple signature mechanism is used to build a secure transaction channel, sensitive data processing is carried out in combination with trusted execution environment;Design dynamic sharding strategy to optimize transaction throughput, establish on-chain and off-chain collaborative verification mechanism.The innovation lies in the combination of verifiable delay function and threshold signature of double-layer verification model, which realizes millisecond-level confirmation while ensuring transaction irreversibility.The system supports multi-chain asset atomic exchange, and realizes the interoperability of different blockchain networks through heterogeneous cross-chain gateway.The scheme has the characteristics of fast transaction confirmation speed, high privacy protection level and strong system scalability.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of intersection of blockchain technology and financial technology, in particular to a digital asset secure transaction system and method based on blockchain. BACKGROUND

[0002] The present application relates to a digital asset secure transaction system and method based on blockchain, belonging to the field of intersection of blockchain technology and financial technology. With the popularity of digital assets, the existing technology generally adopts blockchain architecture to realize the decentralized verification of asset transactions. However, the traditional blockchain system has significant defects in transaction efficiency, privacy protection and cross-chain interoperability: the transaction throughput of public chain is limited by the performance of consensus mechanism, the privacy protection scheme relies on mixer or ring signature technology, resulting in a sharp increase in computing overhead, and cross-chain transactions are usually implemented through centralized hosting or complex relay chain, which has the risk of single point failure and transaction confirmation delay.

[0003] In the prior art, a relay node network is constructed to realize asset transfer between heterogeneous chains, and a hash time lock protocol (HTLC) is used to ensure atomic exchange, but its mechanism of relying on global state synchronization of relay chain leads to increased cross-chain transaction delay, and the privacy protection problem of transaction amount and participant address is not solved. In addition, the prior art does not optimize the transaction verification process, and the consensus efficiency is low in multi-chain collaboration scenarios, which is difficult to support the demand of high-frequency transaction scenarios.

[0004] Based on the above analysis of the prior art, the current blockchain digital asset transaction system still has the following technical bottlenecks:

[0005] Imbalance between privacy protection and cross-chain efficiency: the existing cross-chain solution sacrifices privacy level to ensure atomicity, or uses complex encryption algorithms to cause verification delay to increase sharply;

[0006] Throughput limitation and lack of dynamic sharding: traditional sharding strategy fixedly divides network nodes, which cannot adapt to load fluctuations, and the synchronization overhead of cross-shard transactions is large;

[0007] Atomic exchange reliability defects: the existing time lock mechanism is sensitive to network delay, and the degree of automation of asset return after cross-chain transaction failure is low.

[0008] The above problems seriously restrict the large-scale commercialization process of digital asset transactions, and an efficient, private and reliable system-level solution is urgently needed. SUMMARY

[0009] In view of the above existing problems, the present application is proposed.

[0010] Therefore, the present application provides a digital asset secure transaction system and method based on blockchain, which solves the problems of double spending attack, privacy leakage and low cross-chain transaction efficiency in digital asset transactions.

[0011] To solve the above technical problems, the present application provides the following technical solutions:

[0012] In a first aspect, the present application provides a blockchain-based digital asset secure transaction system, which comprises an intelligent contract execution layer, a distributed ledger storage layer and a cross-chain interaction layer.

[0013] The intelligent contract execution layer is configured to receive and analyze transaction requests, execute preset intelligent contract logic, perform multi-node verification of transaction legality using a practical Byzantine fault tolerance consensus algorithm, and generate transaction execution results.

[0014] The distributed ledger storage layer is configured to store block data of verified transactions through a chain data structure, associate transaction hashes with user addresses using a multi-chain indexing mechanism, and provide a transaction history tracking function.

[0015] The cross-chain interaction layer is configured to handle asset exchange requests between different blockchain networks, convert transaction formats through a heterogeneous cross-chain gateway protocol, and ensure the atomicity of cross-chain transactions based on an atomic exchange protocol. The cross-chain interaction layer integrates a verifiable delay function module to generate time-bound cross-chain transaction commitments and ensure that cross-chain operations are resistant to pre-attack attacks.

[0016] As a preferred scheme of the blockchain-based digital asset secure transaction system, the identity authentication module generates a user's digital identity credential using an elliptic curve digital signature algorithm, wherein the private key sk satisfies sk=H(s)mod q, H(s) is a random hash value, s is a random seed, and q is the order of the elliptic curve base point. The dynamic threshold signature technology adopts a (d, z) threshold scheme, where z is the total number of nodes participating in secret management in the system, and at least d verification nodes are required to combine the signature fragments σ i =sk i H(m) to generate a complete signature σ=∑σ i mod q, where sk i is the node fragment private key, and H(m) is the transaction hash value.

[0017] As a preferred scheme of the blockchain-based digital asset secure transaction system, the privacy protection module achieves transaction amount concealment through zero-knowledge proof, specifically: generating a Pedersen commitment for the transaction amount c , where g and h are generator elements, and r is a random number. In ring signature technology, the transaction initiator selects a public key set {pk1,...,pk N} from a ring containing N candidate addresses, and generates a signature

[0018] ,

[0019] in The value is a random number, ensuring that the actual signer index i cannot be deduced from the signature.

[0020] As a preferred embodiment of the blockchain-based secure digital asset transaction system described in this invention, when processing private key sharding in the trusted execution environment, the Shamir secret sharing algorithm is used to split the master private key sk into k shards. ,in Furthermore, at least t shards are required to reconstruct the private key; cross-chain state verification is implemented through light node Merkle proofs, and the verification formula is as follows: ,in For the target chain block head Merkelgen, Merkel path for transaction hash.

[0021] As a preferred embodiment of the blockchain-based secure digital asset transaction system of the present invention, the sharding strategy of the dynamic sharding management module satisfies: ,in The average transaction load of the network, The threshold for single-shard processing is set; consensus synchronization between shards employs a cross-shard atomic broadcast protocol to ensure transaction sequence consistency. .

[0022] As a preferred embodiment of the blockchain-based secure digital asset transaction method described in this invention, it includes the following steps:

[0023] S1. The user client generates an asymmetric key pair and registers a digital identity, and stores the public key hash on the blockchain through a distributed identity authentication node;

[0024] S2. The transaction initiator creates a secure transaction channel based on a multi-signature mechanism, and designates at least two independent verification nodes to sign and confirm the transaction content;

[0025] S3. The system dynamically divides transaction shards based on the current network load and distributes transaction requests to the consensus node groups within the corresponding shards;

[0026] S4. The consensus node group uses a practical Byzantine fault-tolerant consensus algorithm to verify transactions, generates joint verification results through threshold signatures, and submits them to the distributed ledger storage layer;

[0027] S5. The cross-chain interaction layer parses the target chain protocol, generates cross-chain transaction commitments through verifiable delay functions, and performs atomic swap operations between the source chain and the target chain;

[0028] S6. After the transaction is completed, batch settlement is performed on the high-frequency small transaction through the off-chain state channel, and the final state hash is synchronized to the on-chain storage layer.

[0029] As a preferred scheme of the blockchain-based digital asset secure transaction method, in step S2, the creation of the secure transaction channel further includes: privacy processing of the transaction amount and the receiver address based on zero-knowledge proof, and preventing on-chain behavior tracking through a confused transaction path; the privacy processing further includes: the transaction amount c generates a ciphertext through homomorphic encryption , where r is a random number; the receiver address is hidden through one-time mask technology H(A||r), r is a temporary random number

[0030] As a preferred scheme of the blockchain-based digital asset secure transaction method, in step S4, the practical Byzantine fault tolerance consensus algorithm includes: the node reputation score updating formula is

[0031] ,

[0032] where is the accuracy of this verification, (0, 1) is a decay factor; a reputation score mechanism is introduced to dynamically adjust the node voting weight;

[0033] In the pipelined proposal-verification process, the transaction grouping size B satisfies , is the upper limit of the single block capacity; the pipelined proposal-verification process is adopted to shorten the consensus reaching time.

[0034] As a preferred scheme of the blockchain-based digital asset secure transaction method, in step S5, the atomic exchange operation includes: a time lock commitment Lock(H(s)) is generated when the source chain locks the asset, where s is a random secret value; a random secret value s is generated on the source chain, and the target chain releases the asset after verifying that the random secret value s satisfies H(s)=Commit as a hash original image, otherwise it is automatically rolled back after a timeout threshold , where is the maximum propagation delay of cross-chain messages, is the time required for the target chain to confirm the number of blocks.

[0035] As a preferred scheme of the blockchain-based digital asset secure transaction method, in step S6, the batch settlement of the off-chain state channel includes:

[0036] Compressing n transactions into a Merkle tree root hash ;

[0037] On-chain verification needs to meet , and the final balance meets the conservation condition .

[0038] In a second aspect, the present application provides a computer device comprising a memory and a processor, wherein the memory stores a computer program, and wherein the computer program, when executed by the processor, implements any step of the method for secure transaction of digital assets based on a block chain according to the first aspect of the present application.

[0039] In a third aspect, the present application provides a computer readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements any step of the method for secure transaction of digital assets based on a block chain according to the first aspect of the present application.

[0040] The present application has the following beneficial effects:

[0041] The present application realizes multi-dimensional performance improvement and security guarantee in the field of digital asset transaction through hierarchical architecture design and integration of innovative technologies. First, the smart contract execution layer constructed based on the practical Byzantine fault tolerance consensus algorithm, combined with the dynamic sharding strategy and the pipeline verification process, significantly improves the transaction throughput. In the experimental environment, the single sharding processing capacity reaches ten thousand transactions per second, and the number of sharding can be dynamically expanded according to the network load, effectively solving the problem of low resource utilization caused by fixed sharding in traditional block chain systems. Second, through the composite application of zero-knowledge proof and ring signature technology, fine-grained privacy protection is realized in three aspects of transaction amount anonymity, participant address confusion and transaction path confusion. At the same time, threshold signature and trusted execution environment technology are used to guarantee the security of key sharding processing, so that the privacy protection strength reaches the level of resisting quantum computing attacks, and the computing resource consumption is reduced by about 40% compared with traditional privacy solutions. In terms of cross-chain interoperability, the combination of heterogeneous cross-chain gateway protocol and atomic switch mechanism supports millisecond-level confirmation and automatic rollback of multi-chain asset transfer. Through the collaborative design of verifiable delay function and time lock smart contract, the cross-chain transaction success rate is improved to more than 99.8%, and the single point failure risk of relay chain architecture is eliminated. In addition, the introduction of on-chain and off-chain collaborative verification mechanism and state channel bulk settlement technology reduces the Gas cost in high-frequency small-amount transaction scenarios by about 65%, and supports real-time generation of transaction finality proof. The technical integration scheme of the present application shows strong applicability in financial scenarios, and provides system-level support for building a safe and efficient distributed financial infrastructure. BRIEF DESCRIPTION OF DRAWINGS

[0042] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings needed to be used in the embodiments will be briefly introduced as follows. Obviously, the drawings in the following description are only some embodiments of the present application, and other drawings can be obtained by those skilled in the art without creative effort on the basis of these drawings.

[0043] Figure 1 A schematic diagram of the blockchain-based digital asset secure transaction system in Embodiment 1.

[0044] Figure 2 A flowchart of the blockchain-based digital asset secure transaction method in Embodiment 2. DETAILED DESCRIPTION

[0045] In order to make the above-mentioned objects, features and advantages of the present application more apparent and comprehensible, the specific embodiments of the present application will be described in detail below with reference to the accompanying drawings.

[0046] In the following description, many specific details are set forth in order to provide a thorough understanding of the present application. However, the present application can be practiced without the specific details, other than those described herein, and it will be apparent to those skilled in the art that the present application can be practiced with other than the described embodiments, which have been presented for purposes of example and illustration and not limitation, unless otherwise specified.

[0047] Secondly, the "one embodiment" or "embodiment" referred to herein means that the specific features, structures or characteristics can be included in at least one implementation of the present application. The "in one embodiment" appearing in different places in the specification does not mean the same embodiment, nor is it an independent or alternative embodiment that excludes other embodiments.

[0048] Embodiment 1, refer to Figure 1 In the first embodiment of the present application, the embodiment provides a blockchain-based digital asset secure transaction system, which includes a smart contract execution layer, a distributed ledger storage layer and a cross-chain interaction layer.

[0049] The smart contract execution layer is used to receive and analyze transaction requests, execute preset smart contract logic, use a practical Byzantine fault tolerance consensus algorithm to perform multi-node verification on transaction legality, and generate transaction execution results.

[0050] The distributed ledger storage layer is used to store block data of verified transactions through a chain data structure, use a multi-chain indexing mechanism to associate transaction hashes and user addresses, and provide a transaction history tracking function.

[0051] The cross-chain interaction layer is used for processing asset exchange requests between different blockchain networks, converting transaction formats through heterogeneous cross-chain gateway protocols, and ensuring atomicity of cross-chain transactions based on an atomic exchange protocol. The cross-chain interaction layer integrates a verifiable delay function module for generating time-bound cross-chain transaction commitments to ensure that cross-chain operations are resistant to pre-attack attacks.

[0052] The identity authentication module generates a digital identity certificate for the user using an elliptic curve digital signature algorithm, where the private key sk satisfies sk=H(s)mod q, H(s) is a random hash value, s is a random seed, and q is the order of the elliptic curve base point. The dynamic threshold signature technology uses a (d, z) threshold scheme, where z is the total number of nodes participating in secret management in the system, and at least d verification nodes are required to combine the signature fragments σ i =sk i H(m) to generate a complete signature σ=∑σ i mod q, where sk i is the node fragment private key, and H(m) is the transaction hash value.

[0053] The privacy protection module realizes transaction amount concealment through zero-knowledge proof, specifically: generating a Pedersen commitment for the transaction amount c, where g and h are generator elements, and r is a random number. In the ring signature technology, the transaction initiator selects a public key set {pk1,...,pk N} from a ring containing N candidate addresses, and generates a signature

[0054] ,

[0055] where is a random number, ensuring that the actual signer index i cannot be inferred from the signature.

[0056] When processing private key fragments in the trusted execution environment, the Shamir secret sharing algorithm is used to split the main private key sk into k fragments , where , and at least t fragments are required to reconstruct the private key; cross-chain state verification is achieved through light node Merkle proof, and the verification formula is , where is the target chain block header Merkle root, is the Merkle path of the transaction hash.

[0057] The fragment strategy of the dynamic fragment management module satisfies , where is the average transaction load of the network, is the single-fragment processing threshold; cross-fragment consensus synchronization uses a cross-fragment atomic broadcast protocol to ensure transaction sequence consistency conditions .

[0058] The workflow of the embodiment of the application is as follows: after a user initiates a digital asset transaction request through a client, the system first receives the request by the smart contract execution layer and performs structured analysis, extracts core information such as transaction type, participant address and operation parameters. According to the transaction type, the corresponding smart contract template is matched, the preset verification rules and business logic are automatically loaded, for example, in the NFT transfer transaction, the ownership change condition check and copyright license verification are triggered. Subsequently, the system broadcasts the transaction to the consensus node group in the current shard, and adopts the practical Byzantine fault tolerance consensus mechanism for multi-stage verification: the master node performs preliminary screening on the transaction format compliance in the pre-preparation stage, each node independently verifies the validity of the transaction signature and the sufficiency of the account balance in the preparation stage, and generates the final execution status code after collecting the verification passing results of more than two-thirds of the nodes, and transmits the transaction data package with the consensus proof to the next link.

[0059] The transaction that passes the verification immediately enters the distributed ledger storage layer processing flow, and the system packages the data into blocks according to the transaction timestamp and shard identifier, and ensures the block tamper resistance through the chain hash structure. In this process, the multi-chain index mechanism automatically extracts transaction hash value, participant address and asset type, etc. Key fields, build cross-chain searchable mapping relationship table, so that users can quickly locate the target transaction through any dimension combination query. After each new block is generated, the system synchronously updates the Merkle tree structure and generates a lightweight state proof, supporting external applications to trace the complete transaction history through a simplified verification path without downloading full amount of ledger data.

[0060] When the transaction involves cross-chain asset exchange, the cross-chain interaction layer starts the heterogeneous protocol conversion process: first, analyze the smart contract interface specification and transaction data structure of the target chain, and convert the original transaction parameters into compatible format through the gateway module. The system deploys a time lock smart contract on the source chain to lock the assets to be transferred, and sends an atomic exchange request carrying a hash commitment to the target chain. After the target chain verification party confirms the validity of the transaction within the preset time window, it triggers the automatic asset release operation. In this process, if the verification of any chain fails or the network times out, the cross-chain transaction coordinator initiates a global rollback instruction to ensure that the asset state of the two chains automatically recovers to the pre-transaction state, eliminating the risk of asset loss caused by single-chain failure. All cross-chain operation logs are synchronized to the distributed ledger of each participating chain in a standardized format, forming an auditable global transaction graph.

[0061] Embodiment 2, refer to Figure 2 For the second embodiment of the application, the embodiment provides a blockchain-based digital asset secure transaction method, comprising the following steps:

[0062] S1. User client generates asymmetric key pair and registers digital identity, on-chain notarization of public key hash through distributed identity authentication node;

[0063] In the implementation of step S1, the user first starts the digital identity creation process through the client application. The security module built-in the client calls the asymmetric key generation algorithm (such as elliptic curve secp256k1 or Ed25519) that conforms to international cryptography standards to generate a pair of unique asymmetric keys in a local isolated environment: the private key is generated by a high-strength random number generator and immediately encrypted and stored in the hardware security module (HSM) or trusted execution environment (TEE) of the client, ensuring that the private key does not leave the user device throughout its life cycle; the public key is converted into Base58 or hexadecimal string format through standardized encoding processing to facilitate subsequent system compatibility processing. The user needs to confirm the intention of identity registration on the client interface and input the necessary basic identification information (such as a readable username or device fingerprint), which will be bound to the public key as identity metadata.

[0064] After completing key generation, the client automatically builds a digital identity registration request data packet containing the original public key, user-selected verifiable claim labels (such as "institutionally certified user" or "personal primary authentication"), and timestamp information. The data packet is transmitted to the entry node of the distributed identity authentication network through a secure channel. The entry node first performs basic format verification and anti-spam attack filtering, such as detecting whether the public key length conforms to the specification and whether the timestamp is within a reasonable time window. The requests that pass the preliminary screening are broadcast to the consensus node group of the identity authentication network, and each node performs deep verification according to the pre-defined governance rules: some nodes are responsible for calling off-chain identity database to compare the auxiliary information provided by the user (such as biometric hash or digital certificate issued by a third-party institution), and another part of the nodes assess whether the public key has ever been involved in malicious behavior through the decentralized reputation system. All verification results are confirmed through multiple rounds of voting by the Byzantine fault-tolerant consensus mechanism, and the majority-approved verification conclusion is finally formed.

[0065] After the majority of the authentication nodes are obtained, the system starts the on-chain storage process. The client public key is processed twice through hashing (the first time using SHA-256 to generate a digest, and the second time using RIPEMD-160 to shorten the bit length), and the obtained public key hash is encoded into a structured data load together with attributes such as authentication time and effective period. The load is injected into the storage function of the smart contract, triggering the generation of a transaction on the distributed ledger. The storage transaction contains a special identity contract address identifier, which is preferentially assigned to a high-priority queue when packaged into a block to ensure fast confirmation. When processing the transaction, miners or verification nodes in the blockchain network will additionally perform storage validity checks, including verifying whether the initiating address belongs to an authorized authentication node and whether the hash value format meets the technical specifications. After successful on-chain storage, the public key hash is permanently recorded in the Merkle sub-tree dedicated to the identity, and the backup operation of the complete identity credential on the decentralized storage network (such as IPFS) is triggered, forming a dual-layer storage structure of lightweight indexing on the chain and details off the chain. The user client receives the storage result in real time, and if it is successful, the local identity state is updated to "activated", if it is timed out or failed, an automatic retry mechanism is started, and after three failures, an artificial review process is triggered. Throughout the process, the user's original private key remains in encrypted isolation, and no system component can obtain or reconstruct the private key content.

[0066] S2. The transaction initiator creates a secure transaction channel based on a multi-signature mechanism, and specifies at least two independent verification nodes to sign and confirm the transaction content;

[0067] In step S2, the creation of the secure transaction channel further includes: privacy processing of the transaction amount and the recipient address based on zero-knowledge proof, and preventing on-chain behavior tracking through obfuscated transaction path; the privacy processing further includes: generating a ciphertext of the transaction amount c through homomorphic encryption where r is a random number; the recipient address is hidden through one-time mask technology as H(A||r), r is a temporary random number

[0068] In the implementation process of step S2, the transaction initiator first selects the target transaction type (such as asset transfer, smart contract invocation, or cross-chain exchange) through the client interface, and inputs the necessary transaction parameters (including recipient address, amount, Gas limit, etc.). After the client generates the original transaction data package, it automatically triggers the multi-signature channel creation process: the system randomly selects at least two independent nodes from the pre-registered verification node pool, and the selection strategy considers the real-time load state, historical reputation score, and geographical distribution diversity of the nodes to ensure that the verification nodes have no interest correlation and high availability. The selection result is notified to each target verification node through an encrypted channel, and a unique channel identifier (Channel ID) is generated and bound with a timestamp to prevent replay attacks.

[0069] Next, the client encodes the original transaction data into a structured message body according to a preset template, appends channel metadata (such as a list of participating node public keys, timeout threshold), and then generates a one-time password (OTP) algorithm to generate a temporary symmetric key to encrypt the transaction content, forming a ciphertext payload. The payload is transmitted to each verification node through a point-to-point encryption tunnel. The tunnel uses a double authentication mechanism: first, it establishes a basic link through the TLS 1.3 protocol, and then uses the verification node's registered public key to asymmetrically encrypt the session key, ensuring the confidentiality and integrity of end-to-end transmission. Each verification node receives the ciphertext and uses the locally stored private key to decrypt the session key, and then decrypts the transaction data in plaintext.

[0070] Each verification node independently executes transaction verification logic: first, it checks the compliance of the transaction format (such as address validity, numerical range), and then calls the smart contract interface to simulate transaction execution, checks account balance sufficiency, permission matching degree, and contract state change legality. During the verification process, the node synchronizes the latest block data with the distributed ledger in real time to avoid double spending attacks or state inconsistency risks. For transaction fields involving privacy (such as amount or recipient information), the node can only access the ciphertext data processed by homomorphic encryption or zero-knowledge proof during verification to ensure that sensitive information is not exposed to the verification node. All verification results (pass / reject) and detailed logs are packaged as signed request messages and returned to the client.

[0071] After the client collects all the responses from the verification nodes, it starts the multi-signature aggregation process: for the nodes that pass the verification, the returned messages contain digital signature fragments generated using the node's private key, and the client uses threshold signature algorithm to combine these fragments into a complete transaction authorization signature. During this process, if some nodes' responses timeout or return rejection results, the system automatically triggers the backup verification node selection mechanism to supplement the minimum signature threshold requirement from the backup node pool according to priority. The final aggregated signature, together with the original transaction data and channel metadata, forms a legal transaction body that can be submitted to the blockchain network. This transaction body is broadcast to all network nodes waiting to be packaged into a block. The entire channel lifecycle is monitored by the smart contract, and if the signature collection is not completed within the preset time, the system automatically releases the temporarily occupied resources and notifies the user to initiate the process again.

[0072] S3. The system dynamically divides transaction shards according to the current network load and assigns transaction requests to the corresponding consensus node group within the shard;

[0073] In the implementation of step S3, the system dynamically adjusts the sharding strategy to optimize the overall processing efficiency by monitoring the transaction load, communication delay, resource utilization and other indicators of each node in the network in real time. After the transaction request enters the system, the load balancer first analyzes the characteristics of the request, extracts the transaction type, data size, and associated account address, and calculates the optimal sharding matching weight based on the current active transaction number and node performance profile of each shard. For example, high-frequency small payment transactions are preferentially allocated to low-latency shards, while transactions involving complex smart contract execution are directed to dedicated shards equipped with high-performance computing nodes. The sharding decision engine trains a dynamic weight model based on historical load data within a sliding time window, and re-evaluates the shard capacity threshold every fixed time interval (e.g., every 5 seconds). When the length of the transaction queue in a certain shard exceeds the pre-set warning line, the shard fission operation is automatically triggered, and the overloaded shard is split into two sub-shards according to the account address hash range, and the nodes and ledger state replicas in the shard are re-allocated.

[0074] The node allocation module uses an improved consistent hashing algorithm to dynamically map the verification nodes to each shard, ensuring minimal data migration when nodes join or exit. An independent consensus node group is set up in each shard, and the nodes in the group maintain state synchronization through a heartbeat mechanism and periodically report load indicators to the shard manager. After the transaction is routed to the target shard, the shard entry gateway preprocesses the transaction, including duplicate check, basic format verification, and malicious traffic filtering, and then packages the legal transactions into a transaction processing unit, which is pushed to the memory pool of the consensus node group according to the priority queue. The consensus node group uses a pipelined working mode: in the first stage, the master node elected by the group performs preliminary sorting and conflict detection on the transactions, generating a candidate block proposal; in the second stage, each node verifies the validity of the transaction signature, the consistency of the account state, and the compliance of the smart contract execution context in parallel; in the third stage, a consensus is reached on the verification results through a multi-round voting mechanism, and the block submission operation is triggered when the number of agreed votes exceeds the threshold. For transactions involving cross-shard, the system establishes a temporary atomic channel through the inter-shard coordinator to lock the cross-shard state of the related accounts, and updates the global ledger state asynchronously in an event-driven manner after all related shards reach consensus, ensuring the final consistency of the transaction. The entire sharding and transaction routing process is transparent to the user, and the client only perceives a unified transaction submission interface, while the dynamic changes in the underlying shard topology are maintained by the system autonomous management module in real time.

[0075] S4. The consensus node group uses a practical Byzantine fault tolerance consensus algorithm to verify the transaction, generates a joint verification result through threshold signature, and submits it to the distributed ledger storage layer;

[0076] In step S4, the practical Byzantine fault tolerance consensus algorithm includes: the node reputation score update formula is

[0077] ,

[0078] wherein is the accuracy of this verification, (0,1) is the decay factor; introduce reputation score mechanism to dynamically adjust the node voting weight;

[0079] In the pipelined proposal-verification process, the transaction grouping size B satisfies , is the upper limit of single-block capacity; the pipelined proposal-verification process is adopted to shorten the consensus reaching time.

[0080] In the implementation of step S4, the consensus node group is formed into a temporary verification cluster according to the dynamic sharding division result, and the node members are dynamically adjusted based on the reputation score and historical participation degree. After the transaction data packet enters the consensus node group of the target shard, the master node (selected by the rotation algorithm combined with the node performance index) first preprocesses the transaction, including duplicate filtering, format compliance checking, and transaction dependency analysis, to exclude invalid requests such as repeated submission or structural damage. The valid transactions after preprocessing are sorted according to the priority rules to form a transaction verification sequence, which is encapsulated as a block proposal by the master node and attached with a timestamp and a shard identifier, and broadcasted to all consensus nodes in the group.

[0081] After receiving the proposal, each node enters the parallel verification phase: each node independently performs transaction signature verification (by comparing the digest hash through public key decryption), account state query (reading balance and permission information from the local copy of the ledger), and smart contract simulation execution (preforming state change in a sandbox environment). For transaction fields involving privacy protection, nodes can only access ciphertext data processed by homomorphic encryption, and the verification process relies on zero-knowledge proof technology to ensure that sensitive information is not leaked. The verification result (pass / reject) and detailed log are encapsulated as a voting message, which is returned to the master node after being signed by the local private key by the node.

[0082] After collecting all the voting messages, the master node performs multi-stage statistical analysis: first, it eliminates invalid signatures or format errors, then it assigns different weights to valid votes according to the real-time reputation score of the nodes (e.g., high-reputation nodes have a single-vote weight of 1.2, and low-reputation nodes have a single-vote weight of 0.8), and accumulates the weighted vote count to exceed the preset threshold (e.g., two-thirds of the total weight) to determine that the transaction verification is passed. For transactions with disputes, the system triggers a secondary verification mechanism, randomly selects cross-shard nodes to form an arbitration committee for review, and forms a final ruling through majority voting.

[0083] The verified transactions enter the threshold signature generation link: each consensus node uses a private key shard specific to the shard to partially sign the block hash. The signed shard is transmitted to the aggregation node through a secure channel. The aggregation node uses a threshold signature algorithm (such as BLS aggregate signature) to combine at least t valid shards into a complete joint signature, which can be quickly verified by any node holding the shard public key. If some nodes fail to submit the signature shard on time due to network failure or malicious behavior, the system automatically enables the backup nodes in the redundant shard pool to make up the signature threshold, ensuring the reliability of signature generation.

[0084] Finally, the block with joint signature and consensus metadata is submitted to the distributed ledger storage layer. During the submission process, the shard manager and the global ledger coordinator work together: the nodes within the shard synchronize the update of the local ledger copy and maintain the state Merkle tree, and the global coordinator records the shard block header hash to the main chain, forming an audit clue across the shard transaction. For failed transactions, the system automatically generates a feedback report containing error codes and correction suggestions, returns to the client along the original path, and triggers a partial refund mechanism for transaction fees to optimize user experience. The entire consensus process uses a pipelined design, with overlapping execution of transaction verification, voting statistics, and signature generation, significantly reducing the multi-round communication overhead of traditional PBFT algorithms, reducing the single-block consensus time to milliseconds.

[0085] S5. The cross-chain interaction layer parses the target chain protocol, generates a cross-chain transaction commitment through a verifiable delay function, and performs an atomic exchange operation between the source chain and the target chain;

[0086] In step S5, the atomic exchange operation includes: generating a time lock commitment Lock(H(s)) when the source chain locks assets, where s is a random secret value; generating a random secret value s on the source chain, and the target chain releases the assets after verifying that the random secret value s satisfies H(s)=Commit as a hash original image, otherwise automatically rollback after the timeout threshold, is the maximum propagation delay of cross-chain messages, is the time required for the target chain to confirm the number of blocks.

[0087] In the implementation of step S5, the cross-chain interaction layer decodes the smart contract interface, transaction data structure, and consensus rules of the target chain through a heterogeneous protocol parsing engine. The system first retrieves the metadata template of the target chain (including chain type, encryption algorithm standard, block confirmation number requirement, etc.) from the cross-chain registry and dynamically loads the corresponding protocol adapter module. If the target chain is a Fabric consortium chain, it is converted into a chain code invocation request based on channel strategy. During protocol conversion, the system preserves the core semantics of the original transaction (such as asset type, quantity, and recipient identifier) and dynamically maps and fills compatibility for format difference fields (such as Gas pricing model and signature scheme).

[0088] After completing the protocol conversion, the system generates a time-bound commitment for the cross-chain transaction through a verifiable delay function (VDF). In the atomic exchange smart contract deployed on the source chain, a cryptographic seed value is randomly generated and injected into the VDF calculation module, which generates a unique delay output result based on non-parallelizable iterative operations. This process is completed in an off-chain trusted execution environment (TEE), ensuring that the calculation process is tamper-resistant and time-controllable. The generated VDF output value serves as the globally unique identifier for the cross-chain transaction, which is bound to the asset locking condition of the target chain. The system simultaneously starts a multi-chain event listener to synchronously listen to contract events related to the VDF identifier in the node networks of the source and target chains.

[0089] The atomic exchange operation is strictly advanced through a multi-stage state machine: first, the atomic contract of the source chain freezes the assets specified by the initiator and generates a cross-chain transaction voucher carrying the VDF commitment value. This voucher is transmitted to the verification node of the target chain through the secure channel of the relay network, triggering the response contract of the target chain to perform conditional pre-checking - verifying the validity of the voucher signature, the matching of the VDF output and the seed value, and the compliance identity of the initiator on the target chain. After verification, the target chain contract locks the corresponding exchange assets and sends a ready confirmation signal to the source chain. At this time, the system starts the cross-chain state synchronization service, continuously polling the contract states of the two chains to ensure consistency.

[0090] When both assets are locked and the network delay compensation time window (calculated dynamically based on historical delay data) is opened, the initiator submits an asset request to the target chain through the relay node. After verifying that the source chain asset lock status is persistent (up to a pre-set confirmation block number), the target chain verification node executes the asset release operation and broadcasts the transaction completion event to the cross-chain coordinator. After verifying the consistency of the transaction final state hash on both chains, the coordinator sends an unlock instruction to the source chain to release the initial asset freeze. If either chain fails to complete the status confirmation within the timeout threshold (triggered by the cross-chain heartbeat monitor), the system automatically performs a global rollback: the source chain contract releases the frozen assets to the initiator, the target chain cancels the lock status and destroys the temporarily generated transaction voucher, and all intermediate state changes are recorded in the form of rollback logs on the audit subchain of each chain, ensuring that the operation is traceable and non-repudiable. Throughout the process, the cross-chain transaction coordinator manages critical operation instructions through a multi-signature mechanism, and any single point of failure or malicious behavior cannot tamper with the state flow path of cross-chain transactions.

[0091] S6. After the transaction is completed, batch settlement is performed on high-frequency small transactions through an off-chain state channel, and the final state hash is synchronized to the on-chain storage layer.

[0092] In step S6, the batch settlement of the off-chain state channel includes:

[0093] Compressing n transactions into a Merkle tree root hash ;

[0094] On-chain verification needs to satisfy , and the final balance satisfies the conservation condition .

[0095] In the implementation of step S6, when high-frequency small transactions accumulate to a pre-set batch processing threshold or reach an agreed time window in the off-chain state channel, the system starts an automated batch settlement process. The user client first organizes the unchained transaction records in the channel into an ordered queue in chronological order, generates a Merkle tree structure of the transactions through local calculation, where the hash value of each transaction is used as a leaf node, and the root hash is formed by aggregating layer by layer upwards. This process is completed in the trusted execution environment of the client, ensuring that the original transaction data is not tampered with and the intermediate state is not visible to the outside. At the same time, the system cross- compares local transaction copies of each participant through a peer-to-peer network, identifies and marks controversial transaction items using a difference detection algorithm, triggers a multi-party negotiation mechanism: controversial transactions are temporarily isolated, and participants exchange transaction signatures and timestamp proofs through encrypted communication channels. If an agreement cannot be reached within the negotiation period, a pre-deployed arbitration smart contract is automatically invoked to make an off-chain ruling on the controversial content by a randomly selected group of verification nodes, and the ruling result is formed into a final conclusion by majority voting.

[0096] After the transaction verification and dispute resolution are completed, the system packages all non-disputed transactions in batches to generate a settlement request data packet containing the Merkle root hash, participant balance snapshot, and channel version number. This data packet is jointly signed by all participants in the channel using multi-signature technology. The signing process uses a dynamic threshold strategy to automatically adjust the minimum number of signatures required based on the number of channel participants. For example, in a bilateral channel, both parties must sign, while in a multi-party channel, more than half of the participants must sign. The signed settlement request is submitted to the on-chain settlement contract, which first verifies the validity of the signature and the consistency of the Merkle root, and then uses a lightweight Merkle proof technique to randomly select a number of leaf node transactions for verification. Participants are required to provide the corresponding hash path and original data for on-chain verification. This verification mechanism ensures settlement efficiency while significantly reducing the consumption of on-chain computing resources.

[0097] After on-chain verification, the settlement contract writes the final channel state hash (including balance allocation results and closing timestamp) to a specific block in the distributed ledger storage layer, which is marked as a state channel settlement dedicated block and enjoys priority packaging to reduce confirmation delay. During the writing process, the system synchronously triggers the cleaning and archiving operation of the off-chain storage network: the original transaction data is migrated from the temporary cache area to the decentralized storage node (such as IPFS cluster), and is associated with the on-chain record through content addressing hash, forming a complete audit tracking chain. After receiving the on-chain confirmation notification, the local client of the participant automatically updates the local ledger state, releases the pledged assets occupied by the channel, and releases the encryption lock related to the channel. If malicious behavior (such as fake signature or double-spend attempt) is detected during the settlement process, the system automatically freezes the channel creation permission of the related account and encapsulates the evidence data as a punishment transaction to the governance contract, triggering the predefined reputation deduction and asset penalty mechanism. The entire batch settlement process balances off-chain efficiency and on-chain security while ensuring transaction privacy, especially suitable for high-concurrency scenarios such as payment networks and micro-transaction platforms.

[0098] The embodiment also provides a computer device suitable for the case of the secure transaction method of digital assets based on a block chain, comprising a memory and a processor; the memory is used to store computer executable instructions, and the processor is used to execute the computer executable instructions to realize the secure transaction method of digital assets based on a block chain proposed in the above embodiment.

[0099] The computer device can be a terminal, and the computer device includes a processor, a memory, a communication interface, a display screen and an input device connected by a system bus. The processor of the computer device is configured to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system and a computer program. The internal memory provides an environment for running the operating system and the computer program in the non-volatile storage medium. The communication interface of the computer device is configured to perform wired or wireless communication with an external terminal. The wireless communication can be achieved by WIFI, a carrier network, NFC (Near Field Communication) or other technologies. The display screen of the computer device can be a liquid crystal display screen or an electronic ink display screen. The input device of the computer device can be a touch layer overlaid on the display screen, or a key, a trackball or a touchpad arranged on the shell of the computer device, or an external keyboard, a touchpad or a mouse, etc.

[0100] The embodiment also provides a storage medium having a computer program stored thereon, and the computer program is executed by a processor to implement the method for implementing a secure transaction of a digital asset based on a blockchain according to the above embodiment. The storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as a static random access memory (SRAM), an electrically erasable programmable read-only memory (EEPROM), an erasable programmable read-only memory (EPROM), a programmable read-only memory (PROM), a read-only memory (ROM), a magnetic memory, a flash memory, a magnetic disk or an optical disk.

[0101] In summary, the present application realizes multi-dimensional performance improvement and security guarantee in the field of digital asset transactions through hierarchical architecture design and innovative technology integration. First, the smart contract execution layer based on the practical Byzantine fault tolerance consensus algorithm, combined with the dynamic sharding strategy and the pipeline verification process, significantly improves the transaction throughput. In the experimental environment, the single sharding processing capacity reaches ten thousand transactions per second, and the number of sharding can be dynamically expanded according to the network load, effectively solving the problem of low resource utilization caused by fixed sharding in traditional blockchain systems. Second, through the composite application of zero-knowledge proof and ring signature technology, fine-grained privacy protection is realized in three aspects of transaction amount anonymity, participant address confusion and transaction path confusion. At the same time, threshold signature and trusted execution environment technology are used to ensure the security of key sharding processing, so that the privacy protection strength reaches the level of resisting quantum computing attacks, and the computing resource consumption is reduced by about 40% compared with traditional privacy solutions. In terms of cross-chain interoperability, the combination of heterogeneous cross-chain gateway protocol and atomic switch mechanism supports millisecond-level confirmation and automatic rollback of multi-chain asset transfer. Through the collaborative design of verifiable delay function and time lock smart contract, the cross-chain transaction success rate is improved to more than 99.8%, and the single point failure risk of relay chain architecture is eliminated. In addition, the introduction of on-chain and off-chain collaborative verification mechanism and state channel batch settlement technology reduces the Gas cost in high-frequency small-amount transaction scenarios by about 65%, and supports real-time generation of transaction finality proof. The technical integration scheme of the present application shows strong applicability in financial scenarios, and provides system-level support for building a secure and efficient distributed financial infrastructure.

[0102] It should be noted that the above embodiments are only used to illustrate the technical solutions of the present application and not to limit it. Although the present application has been described in detail with reference to the preferred embodiments, those skilled in the art should understand that the technical solutions of the present application can be modified or replaced by equivalents without departing from the spirit and scope of the present application, which should be covered by the scope of the claims of the present application.

Claims

1. A blockchain-based digital asset secure transaction system, characterized by, The system comprises an intelligent contract execution layer, a distributed ledger storage layer and a cross-chain interaction layer, further comprising an identity authentication module, a privacy protection module, a trusted execution environment and a dynamic sharding management module; The intelligent contract execution layer is configured to receive and analyze transaction requests, execute preset intelligent contract logic, perform multi-node verification on transaction legality by using a practical Byzantine fault tolerance consensus algorithm, and generate transaction execution results, wherein the practical Byzantine fault tolerance consensus algorithm introduces a node reputation scoring mechanism to dynamically adjust node voting weights, and adopts a pipelined proposal-verification process to shorten consensus reaching time; The node reputation scoring update formula is ， wherein To verify the accuracy of this time, (0, 1) is a decay factor, which introduces a reputation score mechanism to dynamically adjust the node voting weight; In the pipelined proposal-verification process, the transaction grouping size B satisfies , the upper bound of the single-block capacity. The pipelined proposal-verification process is adopted to shorten consensus reaching time; The distributed ledger storage layer is configured to store block data of verified transactions by using a chain data structure, associate transaction hashes and user addresses by using a multi-chain index mechanism, and provide a transaction history tracing function; The cross-chain interaction layer is configured to process asset exchange requests between different blockchain networks, convert transaction formats by using a heterogeneous cross-chain gateway protocol, and ensure atomicity of cross-chain transactions based on an atomic exchange protocol, wherein the cross-chain interaction layer integrates a verifiable delay function module configured to generate time-bound cross-chain transaction commitments to ensure that cross-chain operations are resistant to pre-attack attacks, and the dynamic sharding management module is configured to dynamically divide transaction shards according to current network load, and distribute transaction requests to consensus node groups in corresponding shards to optimize transaction throughput; The sharding strategy of the dynamic sharding management module meets wherein is the network average transaction load, is a single-shard processing threshold; Inter-fragment consensus synchronization adopts a cross-fragment atomic broadcast protocol to ensure transaction sequence consistency conditions .

2. The blockchain-based digital asset secure transaction system of claim 1, wherein, The identity authentication module generates a digital identity certificate of the user by using an elliptic curve digital signature algorithm, wherein a private key sk satisfies sk=H(s)mod q, H(s) is a random hash value, s is a random seed, and q is an order of an elliptic curve base point; a dynamic threshold signature technology adopts a (d, z) threshold scheme, z is a total number of nodes participating in secret management in the system, and at least d verification nodes are required to verify a signature fragment σ i =sk i H(m) are merged to generate a complete signature σ=∑σ i mod q, wherein sk i is a node fragment private key, and H(m) is a transaction hash value.

3. The blockchain-based digital asset secure transaction system of claim 1, wherein, The privacy protection module realizes transaction amount concealment through zero-knowledge proof, specifically: generating a Pedersen commitment for the transaction amount c , wherein g, h are generators, and r is a random number; in ring signature technology, a transaction initiator selects a public key set {pk1,...,pk N} from a ring containing N candidate addresses, and generates a signature , wherein is a random number, ensuring that the actual signer index i cannot be deduced from the signature.

4. The blockchain-based digital asset secure transaction system of claim 1, wherein, When processing the private key fragments in the trusted execution environment, the main private key sk is split into k fragments by using a Shamir secret sharing algorithm , and at least t fragments are required to reconstruct the private key , and at least t fragments are required to reconstruct the private key Cross-chain state verification is achieved by light node Merkle proof, and the verification formula is , wherein is the target chain block header Merkle root, is the transaction hash Merkle path.

5. A method for secure transaction of digital assets based on blockchain, implemented based on the system for secure transaction of digital assets based on blockchain according to any one of claims 1-4, characterized in that, The method comprises the following steps: S1. A user client generates an asymmetric key pair and registers a digital identity, and a distributed identity authentication node stores a public key hash on a chain; S2. A transaction initiator creates a secure transaction channel based on a multi-signature mechanism, and specifies at least two independent verification nodes to sign and confirm transaction content; S3. The system dynamically divides transaction shards according to current network load, and distributes transaction requests to consensus node groups in corresponding shards; S4. The consensus node group verifies transactions by using a practical Byzantine fault tolerance consensus algorithm, generates a joint verification result by threshold signature, and submits the joint verification result to the distributed ledger storage layer, wherein the practical Byzantine fault tolerance consensus algorithm introduces a node reputation scoring mechanism to dynamically adjust node voting weights, and adopts a pipelined proposal-verification process to shorten consensus reaching time; S5. The cross-chain interaction layer analyzes a target chain protocol, generates a cross-chain transaction commitment by using a verifiable delay function, and performs an atomic exchange operation between a source chain and a target chain; S6. After the transaction is completed, high-frequency small-amount transactions are batch-settled by using an off-chain state channel, and a final state hash is synchronized to the on-chain storage layer. 6.The blockchain-based digital asset secure transaction method of claim 5, wherein , the creating of the secure transaction channel in the step S2 further includes: privacy processing of a transaction amount and a receiver address based on zero-knowledge proof, and preventing on-chain behavior tracking through a confused transaction path; the privacy processing further includes: generating a ciphertext of the transaction amount c through homomorphic encryption , wherein r is a random number, g and h are elliptic curve generators; the receiver address is hidden through one-time mask technology as H(A||r) 7. The blockchain-based digital asset secure transaction method of claim 5, wherein The atomic exchange operation in the step S5 includes: generating a time-lock commitment Lock(H(s)) when the source chain locks the asset, wherein s is a random secret value; generating a random secret value s on the source chain, and releasing the asset by the target chain after verifying that the random secret value s satisfies H(s)=Commit as a hash original image, otherwise, automatically rolling back after a timeout threshold wherein is the maximum propagation delay of the cross-chain message, is the time required for the target chain to confirm the number of blocks. 8.The blockchain-based digital asset secure transaction method of claim 5, wherein, In step S6, the batch settlement of the off-chain state channel comprises: Compressing n transactions into a merkle tree root hash ; On-chain verification needs to satisfy , and the final balance satisfies the conservation condition .

Images