Digital asset secure transaction system and method based on block chain

Abstract

The invention discloses a digital asset secure transaction system and method based on a block chain, and belongs to the cross field of block chain technology and financial science and technology. The system adopts a layered architecture design and comprises an intelligent contract execution layer, a distributed account book storage layer and a cross-chain interaction layer. The transaction method comprises the following steps: generating a digital identity certificate based on asymmetric encryption, and realizing privacy protection through zero-knowledge proof; a secure transaction channel is constructed by adopting a multi-signature mechanism, and sensitive data processing is performed in combination with a trusted execution environment; and designing a dynamic fragmentation strategy to optimize the transaction throughput, and establishing an on-chain and off-chain collaborative verification mechanism. The innovation point is that a double-layer verification model combining a verifiable delay function and a threshold signature is provided, and millisecond-level confirmation is realized while the transaction irreversibility is ensured. The system supports multi-chain asset atomic exchange, and interoperability of different block chain networks is realized through a heterogeneous cross-chain gateway. The scheme has the characteristics of high transaction confirmation speed, high privacy protection level and high system expansibility.

Description

Technical Field

[0001] The present invention relates to the intersection of blockchain technology and financial technology, and in particular to a blockchain-based digital asset secure transaction system and method. Background Art

[0002] The present invention relates to a blockchain-based digital asset secure transaction system and method, which falls within the intersection of blockchain technology and financial technology. With the popularization of digital assets such as digital currencies and non-fungible tokens (NFTs), existing technologies generally adopt blockchain architecture to achieve decentralized verification of asset transactions. However, traditional blockchain systems have significant shortcomings in transaction efficiency, privacy protection, and cross-chain interoperability: the transaction throughput of public chains is limited by the performance of the consensus mechanism, privacy protection schemes often rely on mixers or ring signature technology, resulting in a surge in computational overhead, and cross-chain transactions are usually implemented through centralized hosting or complex relay chains, which pose problems such as single point failure risks and high transaction confirmation delays.

[0003] In the prior art, Chinese invention patent publication number CN1 14598485A proposes a relay chain-based cross-chain transaction method, enabling asset transfers between heterogeneous chains by building a network of relay nodes. This solution utilizes the Hash Time Lock Protocol (HTLC) to ensure atomic swaps, but its reliance on global state synchronization on the relay chain increases cross-chain transaction latency and fails to address the privacy concerns surrounding transaction amounts and participant addresses. Furthermore, the patent fails to optimize the transaction verification process, resulting in low consensus efficiency in multi-chain collaborative scenarios, making it difficult to support high-frequency trading scenarios.

[0004] Based on the above analysis of existing technologies, the current blockchain digital asset trading system still has the following technical bottlenecks:

[0005] The imbalance between privacy protection and cross-chain efficiency: Existing cross-chain solutions sacrifice privacy to ensure atomicity, or use complex encryption algorithms that lead to a sharp increase in verification delays;

[0006] Limited throughput and insufficient sharding dynamics: Traditional sharding strategies fixedly divide network nodes, cannot adapt to load fluctuations, and incur high cross-shard transaction synchronization overhead.

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

[0008] The above problems have seriously restricted the large-scale commercialization of digital asset transactions, and there is an urgent need for a system-level solution that balances efficiency, privacy, and reliability. Summary of the Invention

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

[0010] Therefore, the present invention provides a blockchain-based digital asset secure transaction system and method to solve problems such as double-spending attacks, privacy leakage, and low cross-chain transaction efficiency in digital asset transactions.

[0011] In order to solve the above technical problems, the present invention provides the following technical solutions:

[0012] In a first aspect, the present invention provides a blockchain-based digital asset secure transaction system, comprising a smart contract execution layer, a distributed ledger storage layer, and a cross-chain interaction layer;

[0013] The smart contract execution layer is used to receive and parse transaction requests, execute the preset smart contract logic, use the improved practical Byzantine fault-tolerant consensus algorithm to perform multi-node verification of transaction legitimacy, and generate transaction execution results;

[0014] The distributed ledger storage layer is used to store block data of verified transactions through a chain data structure, uses a multi-chain indexing mechanism to associate transaction hashes with user addresses, and provides a transaction history tracing function;

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

[0016] As a preferred solution of the blockchain-based digital asset security transaction system described in the present invention, the identity authentication module uses the elliptic curve digital signature algorithm to generate the user's digital identity certificate, 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 requires at least d verification nodes to verify the signature shard σ i =sk i H(m) is combined to generate a complete signature σ=∑σ i mod q, where sk i is the node shard private key, and H(m) is the transaction hash value.

[0017] As a preferred solution of the blockchain-based digital asset security transaction system of the present invention, the privacy protection module realizes the concealment of transaction amount through zero-knowledge proof, specifically: generating a Pedersen commitment C=g for the transaction amount c c h r, where g, h are generators and r is a random number; in the ring signature technology, the transaction initiator selects a public key set {pk1, ..., pk N}, generate signature σ=Sign(sk i ,m)+∑ j≠i R j ,

[0018] where R j It is a random number, ensuring that the actual signer index i cannot be deduced from the signature.

[0019] As a preferred solution of the blockchain-based digital asset security transaction system of the present 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 sk i =f(i), where f(x)=α0+α0x+…+α t-1 x t-1 , and at least t shards are required to reconstruct the private key; cross-chain status verification is achieved through light node Merkle proof, and the verification formula is Verify(root, path, tx) = true, where root is the Merkle root of the target chain block header and path is the Merkle path of the transaction hash.

[0020] As a preferred solution of the blockchain-based digital asset security transaction system of the present invention, the sharding strategy of the dynamic sharding management module satisfies Where T avg is the average transaction load of the network, T max The processing threshold for a single shard; the consensus between shards is synchronized using the cross-shard atomic broadcast protocol to ensure the consistency of the transaction sequence

[0021] As a preferred solution of the blockchain-based digital asset secure transaction method of the present invention, the following steps are included:

[0022] S1. The user client generates an asymmetric key pair and registers a digital identity, and the public key hash is stored on-chain through a distributed identity authentication node;

[0023] 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;

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

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

[0026] 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 swap operation between the source and target chains.

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

[0028] As a preferred solution of the blockchain-based digital asset secure transaction method of the present invention, in step S2, the creation of the secure transaction channel further includes: privacy processing of the transaction amount and the recipient's address based on zero-knowledge proof, and preventing on-chain behavior tracking by obfuscating the transaction path; the privacy processing further includes: generating a ciphertext E(c)=g by homomorphic encryption of the transaction amount c c h r , where r is a random number; the recipient's address is hidden as A′=H(A||r) through a one-time masking technique, where r is a temporary random number; when obfuscating the transaction path, the onion routing model is used, and the node addresses of the path are encrypted layer by layer.

[0029]

[0030] As a preferred solution of the blockchain-based digital asset secure transaction method of the present invention, in step S4, the improved practical Byzantine fault-tolerant algorithm includes: the node reputation score update formula is:

[0031]

[0032] Where V i ∈{0, 1} is the accuracy of this verification, and α∈(0, 1) is the attenuation factor; a reputation scoring mechanism is introduced to dynamically adjust the node voting weight;

[0033] Pipeline Proposal - In the verification process, the transaction group size B meets L max It is the upper limit of the capacity of a single block; a pipelined proposal-verification process is used to shorten the time to reach consensus.

[0034] As a preferred solution of the blockchain-based digital asset secure transaction method of the present invention, wherein: in the step S5, the atomic swap operation includes: generating a time lock commitment Lock(H(s)) when the source chain locks the asset, where s is a random secret value; generating a random secret value s on the source chain, and releasing the asset after verifying that the random secret value s as the hash original image satisfies H(s)=Commit, otherwise releasing the asset after the timeout threshold Δt≥2(t propagate +t confirm ) and then automatically roll back, where t propagate is the maximum propagation delay of cross-chain messages, t confirm The time required to confirm the required number of blocks for the target chain.

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

[0036] Compress n transactions into a Merkle tree root hash Root=Hash(tx1||tx2||...||tx n );

[0037] Verify(Root, Path) must be met during on-chain verification i , tx i )=true, and the final balance satisfies the conservation condition ∑Input j =∑Output k .

[0038] In a second aspect, the present invention provides a computer device comprising a memory and a processor, wherein the memory stores a computer program, wherein: when the computer program is executed by the processor, any step of the blockchain-based digital asset secure transaction method as described in the first aspect of the present invention is implemented.

[0039] In a third aspect, the present invention provides a computer-readable storage medium having a computer program stored thereon, wherein: when the computer program is executed by a processor, it implements any step of the blockchain-based digital asset secure transaction method as described in the first aspect of the present invention.

[0040] The beneficial effects of the present invention are:

[0041] The present invention achieves multi-dimensional performance improvement and security assurance in the field of digital asset transactions through the integration of layered architecture design and innovative technologies. First, the smart contract execution layer built on the improved practical Byzantine fault-tolerant consensus algorithm, combined with dynamic sharding strategy and pipelined verification process, significantly improves transaction throughput. Under the experimental environment, the processing capacity of a single shard reaches tens of thousands of transactions per second, and the number of shards 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. Secondly, through the combined application of zero-knowledge proof and ring signature technology, fine-grained privacy protection is achieved at three levels: transaction amount concealment, participant address obfuscation, and transaction path obfuscation. 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 resistance to quantum computing attacks, and the computing resource consumption is reduced by about 40% compared to traditional privacy solutions. In terms of cross-chain interoperability, the combination of a heterogeneous cross-chain gateway protocol and an atomic swap mechanism supports millisecond-level confirmation and automated rollback of multi-chain asset transfers. Through the collaborative design of verifiable delay functions and time-locked smart contracts, the cross-chain transaction success rate is increased to over 99.8%, while eliminating the single point of failure risk of the relay chain architecture. Furthermore, the introduction of on-chain and off-chain collaborative verification mechanisms and state channel batch settlement technology reduces gas costs by approximately 65% in high-frequency, small-value transaction scenarios and supports the real-time generation of proof of transaction finality. This technical integration solution demonstrates strong applicability in financial scenarios such as digital currency circulation, NFT transaction confirmation, and securitized token settlement, providing system-level support for building a secure and efficient distributed financial infrastructure. BRIEF DESCRIPTION OF THE DRAWINGS

[0042] In order to more clearly illustrate the technical solutions of the embodiments of the present invention, the following briefly introduces the drawings required for use in the description of the embodiments. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0043] Figure 1 This is a schematic diagram of the blockchain-based digital asset secure transaction system in Example 1;

[0044] Figure 2 This is a flowchart of the blockchain-based digital asset secure transaction method in Example 2. DETAILED DESCRIPTION

[0045] In order to make the above-mentioned objects, features and advantages of the present invention more obvious and easy to understand, the specific embodiments of the present invention are described in detail below with reference to the accompanying drawings.

[0046] In the following description, many specific details are set forth to facilitate a full understanding of the present invention. However, the present invention may also be implemented in other ways different from those described herein. Those skilled in the art may make similar generalizations without violating the connotation of the present invention. Therefore, the present invention is not limited to the specific embodiments disclosed below.

[0047] Secondly, the term "one embodiment" or "embodiment" herein refers to a specific feature, structure, or characteristic that may be included in at least one implementation of the present invention. The phrase "in one embodiment" appearing in various places throughout this specification does not necessarily refer to the same embodiment, nor does it refer to a separate or selective embodiment that is mutually exclusive of other embodiments.

[0048] Example 1, reference Figure 1 , which is the first embodiment of the present invention, provides a blockchain-based digital asset security 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 parse transaction requests, execute the preset smart contract logic, use the improved practical Byzantine fault-tolerant consensus algorithm to perform multi-node verification of transaction legitimacy, 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, uses a multi-chain indexing mechanism to associate transaction hashes with user addresses, and provides transaction history tracing capabilities;

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

[0052] The identity authentication module uses the elliptic curve digital signature algorithm to generate the user's digital identity certificate, 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 requires at least d verification nodes to verify the signature shard σ i =sk i H(m) is combined to generate a complete signature σ=∑σ i mod q, where sk i is the node shard private key, and H(m) is the transaction hash value.

[0053] The privacy protection module achieves the concealment of transaction amount through zero-knowledge proof, specifically: generating Pedersen commitment C=g for transaction amount c c h r , where g, h are generators and r is a random number; in the ring signature technology, the transaction initiator selects a public key set {pk1, ..., pk N}, generate signature σ=Sign(sk i ,m)+∑ j≠i R j ,

[0054] where R j It is a random number, ensuring that the actual signer index i cannot be deduced from the signature.

[0055] When processing private key sharding in a trusted execution environment, the Shamir secret sharing algorithm is used to split the master private key sk into k shards sk i =f(i), where f(x)=α0+α0x+…+αt t-1 x t-1 , and at least t shards are required to reconstruct the private key; cross-chain status verification is achieved through light node Merkle proof, and the verification formula is Verify(root, path, tx) = true, where root is the Merkle root of the target chain block header and path is the Merkle path of the transaction hash.

[0056] The sharding strategy of the dynamic sharding management module meets Where T avg is the average transaction load of the network, T max The processing threshold for a single shard; the consensus between shards is synchronized using the cross-shard atomic broadcast protocol to ensure the consistency of the transaction sequence

[0057] The workflow of an embodiment of the present invention is as follows: After the user initiates a digital asset transaction request through the client, the system first receives the request at the smart contract execution layer and performs structured parsing to extract core information such as transaction type, participant addresses, and operation parameters. The corresponding smart contract template is matched according to the transaction type, and the preset verification rules and business logic are automatically loaded, such as triggering ownership change condition checks and copyright license verification in NFT transfer transactions. Subsequently, the system broadcasts the transaction to the consensus node group within the current shard, and uses an improved practical Byzantine fault-tolerant consensus mechanism for multi-stage verification: in the pre-preparation stage, the master node performs an initial screening of the transaction format compliance, in the preparation stage, each node independently verifies the validity of the transaction signature and the adequacy of the account balance, and in the submission stage, after collecting the verification results of more than two-thirds of the nodes, a final execution status code is generated, and the transaction data packet with the consensus proof is passed to the next link.

[0058] Verified transactions are then processed in the distributed ledger storage layer. The system packages the data into blocks based on transaction timestamps and shard identifiers, ensuring the immutability of the blocks through a chained hash structure. During this process, a multi-chain indexing mechanism automatically extracts key fields such as transaction hash values, participant addresses, and asset types, constructing a cross-chain searchable mapping table. This allows users to quickly locate target transactions through combined queries across any dimension. With each new block, the system synchronously updates the Merkle tree structure and generates a lightweight state proof, allowing external applications to trace the complete transaction history through a simplified verification path without having to download the full ledger data.

[0059] When a transaction involves a cross-chain asset exchange, the cross-chain interaction layer initiates a heterogeneous protocol conversion process. First, it parses the target chain's smart contract interface specifications and transaction data structure. A gateway module then converts the original transaction parameters into a compatible format, such as converting an Ethereum ERC-20 token transaction into a data model that supports Fabric chaincode invocation. The system then deploys a timelock smart contract on the source chain to lock the assets to be transferred and simultaneously sends an atomic swap request with a hash commitment to the target chain. Once the target chain's validator confirms the transaction's validity within a preset time window, an automatic asset release is triggered. If verification fails on either chain or the network times out, a global rollback is initiated through the cross-chain transaction coordinator, ensuring that the asset states on both chains are automatically restored to their pre-transaction state, eliminating the risk of asset loss due to a single chain failure. All cross-chain operation logs are synchronized to the distributed ledgers of all participating chains in a standardized format, forming an auditable global transaction map.

[0060] Example 2, reference Figure 2 , which is the second embodiment of the present invention, provides a blockchain-based digital asset secure transaction method, comprising the following steps:

[0061] S1. The user client generates an asymmetric key pair and registers a digital identity, and the public key hash is stored on-chain through a distributed identity authentication node;

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

[0063] After completing the key generation, the client automatically constructs a digital identity registration request data packet, which contains the original public key, a verifiable declaration label selected by the user (such as "institutional certified user" or "personal primary certification"), and timestamp and other 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 checking whether the length of the public key complies with the specification and whether the timestamp is within a reasonable time window. Requests that pass the preliminary screening are broadcast to the consensus node group of the identity authentication network. Each node performs in-depth verification according to predefined governance rules: some nodes are responsible for calling the off-chain identity database to compare the auxiliary information provided by the user (such as biometric hashes or digital certificates issued by third-party institutions), while other nodes use a decentralized reputation system to evaluate whether the public key has been involved in malicious behavior. All verification results are confirmed through multiple rounds of voting through an improved Byzantine fault-tolerant consensus mechanism, and ultimately form a verification conclusion recognized by the majority.

[0064] After receiving a majority approval from the authentication nodes, the system initiates the on-chain proof-of-stake process. The client's public key is hashed twice (first using SHA-256 to generate a digest, then shortened using RIPEMD-160). The resulting public key hash, along with attributes such as the authentication time and validity period, is encoded into a structured data payload. This payload is injected into the smart contract's proof-of-stake function, triggering the generation of a transaction on the distributed ledger. The proof-of-stake transaction contains a unique identifier for the identity contract address and is prioritized for inclusion in a high-priority queue to ensure rapid confirmation. When processing this transaction, miners or validators in the blockchain network perform additional proof-of-stake validation checks, including verifying that the originating address belongs to an authorized authentication node and that the hash format complies with technical specifications. After successful on-chain storage, the public key hash is permanently recorded in the identity's unique Merkle subtree, simultaneously triggering a backup of the complete identity credential on a decentralized storage network (such as IPFS), forming a dual-layer storage structure consisting of a lightweight on-chain index and off-chain details. The user client receives the verification results in real time. If successful, the local identity status is updated to "Activated." If a timeout or failure occurs, an automatic retry mechanism is initiated, and after three failures, a manual review process is triggered. Throughout this process, the user's original private key remains encrypted and isolated, and no system component can obtain or reconstruct the private key content.

[0065] 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;

[0066] 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 by obfuscating the transaction path; the privacy processing further includes: the transaction amount c is generated by homomorphic encryption to generate a ciphertext E(c) = g c h r , where r is a random number; the recipient's address is hidden as A′=H(A||r) through a one-time masking technique, where r is a temporary random number; when obfuscating the transaction path, the onion routing model is used, and the node addresses of the path are encrypted layer by layer.

[0067]

[0068] During the specific implementation of step S2, the transaction initiator first selects the target transaction type (such as asset transfer, smart contract call, or cross-chain exchange) through the client interface and enters the necessary transaction parameters (including the recipient's address, amount, gas limit, etc.). After the client generates the original transaction data packet locally, 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. The selection strategy combines the node's real-time load status, historical reputation score, and geographical distribution diversity to ensure that there is no conflict of interest between the verification nodes and that they have high availability. The selection results are notified to each target verification node through an encrypted channel, and a unique channel identifier (Channel ID) is generated and bound to the timestamp to prevent replay attacks.

[0069] Next, the client encodes the original transaction data into a structured message body according to a preset template. After appending channel metadata (such as the list of participating node public keys and the timeout threshold), it uses a one-time pad (OTP) algorithm to generate a temporary symmetric key to encrypt the transaction content, forming a ciphertext payload. This payload is transmitted to each verification node via a point-to-point encrypted tunnel. The tunnel uses a dual authentication mechanism: first, a basic link is established through the TLS1.3 protocol, and then the session key is asymmetrically encrypted using the verification node's registered public key to ensure the confidentiality and integrity of the end-to-end transmission. After receiving the ciphertext, each verification node uses the locally stored private key to decrypt it to obtain the session key, thereby decrypting the plaintext transaction data.

[0070] Each verification node independently executes the transaction verification logic: first, it verifies the compliance of the transaction format (such as address validity and value range), then calls the smart contract interface to simulate the execution of the transaction, checking the adequacy of the account balance, the matching of permissions, and the legality of the contract status change. During the verification process, the node synchronizes the latest block data with the distributed ledger in real time to avoid the risk of double-spending attacks or inconsistent status. 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, ensuring that sensitive information is not exposed to the verification node. All verification results (pass / reject) and detailed logs are encapsulated as a signature request message and returned to the client.

[0071] After the client collects the responses from all verification nodes, it starts the multi-signature aggregation process: for the nodes that pass the verification, the message they return contains digital signature fragments generated using the node private key. The client uses the threshold signature algorithm to combine these fragments into a complete transaction authorization signature. During this process, if some nodes respond with a timeout or return a rejection result, the system automatically triggers the replacement verification node selection mechanism to supplement the minimum signature threshold requirements from the backup node pool according to priority. The final aggregate signature, together with the original transaction data and channel metadata, constitutes a legal transaction body that can be submitted to the blockchain network. The transaction body is broadcast to all nodes in the network waiting to be packaged into blocks. The life cycle of the entire channel is monitored by the smart contract. If the signature collection is not completed within the preset time, the temporarily occupied resources are automatically released and the user is notified to re-initiate the process. S3. The system dynamically divides the transaction shards according to the current network load and assigns the transaction request to the consensus node group in the corresponding shard;

[0072] In the specific implementation of step S3, the system dynamically adjusts the sharding strategy to optimize overall processing efficiency by monitoring metrics such as transaction load, communication latency, and resource utilization at each node in the network in real time. When a transaction request enters the system, the load balancer first analyzes the request's characteristics, extracting key attributes such as transaction type, data size, and associated account address. This analysis then combines the current number of active transactions on each shard with the node performance profile to calculate the optimal shard matching weight. For example, high-frequency, small-value payment transactions are prioritized for 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 reassesses shard capacity thresholds at fixed intervals (e.g., every 5 seconds). If the length of a shard's pending transaction queue exceeds a preset warning line, a shard split operation is automatically triggered, splitting the overloaded shard into two sub-shards based on the account address hash range and redistributing the nodes and ledger state replicas within the shard.

[0073] The node allocation module uses an improved consistent hashing algorithm to dynamically map verification nodes to each shard, ensuring that data migration is minimized when nodes join or exit. An independent consensus node group is set up in each shard. 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 pre-processes the transaction, including deduplication checking, basic format verification, and malicious traffic filtering. It then batches legitimate transactions into transaction processing units and pushes them to the memory pool of the consensus node group according to the priority queue. The consensus node group adopts a pipelined working mode: in the first stage, the elected master node performs preliminary sorting and conflict detection on the transactions and generates candidate block proposals; in the second stage, each node verifies the validity of the transaction signature, the consistency of the account status, and the compliance of the smart contract execution context in parallel; in the third stage, a multi-round voting mechanism is used to reach a consensus on the verification results. The number of votes exceeding the threshold will trigger the block submission operation. For transactions involving cross-shards, the system establishes a temporary atomic channel through the inter-shard coordinator, locking the cross-shard status of the relevant accounts. Once consensus is reached across all associated shards, the global ledger state is asynchronously updated in an event-driven manner to ensure eventual consistency of the transaction. The entire sharding and transaction routing process is transparent to the user; the client only perceives a unified transaction submission interface, while the dynamic changes of the underlying shard topology are maintained in real time by the system's autonomous management module.

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

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

[0076]

[0077] Where V i ∈{0, 1} is the accuracy of this verification, and α∈(0, 1) is the attenuation factor; a reputation scoring mechanism is introduced to dynamically adjust the node voting weight;

[0078] Pipeline Proposal - In the verification process, the transaction group size B meets L max It is the upper limit of the capacity of a single block; a pipelined proposal-verification process is used to shorten the time to reach consensus.

[0079] In the specific implementation of step S4, the consensus node group forms a temporary verification cluster based on the dynamic sharding results, and the node membership is dynamically adjusted based on reputation scores and historical participation. After the transaction data packet enters the consensus node group of the target shard, the master node (elected by a rotation algorithm combined with node performance indicators) first pre-processes the transaction, including deduplication filtering, format compliance checking, and transaction dependency analysis to eliminate invalid requests that are submitted repeatedly or structurally damaged. After pre-processing, valid transactions are sorted according to priority rules to form a sequence of transactions to be verified. The master node encapsulates them as block proposals, attaches timestamps and shard identifiers, and broadcasts them to all consensus nodes in the group.

[0080] After receiving the proposal, each node enters a parallel verification phase: each node independently performs transaction signature verification (by decrypting and comparing the digest hash with the public key), account status query (reading balance and permission information from the local copy of the ledger), and smart contract simulation execution (previewing state changes in a sandbox environment). For transaction fields involving privacy protection, nodes can only access ciphertext data processed by homomorphic encryption. 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 into a voting message, which the node signs with its local private key and returns to the master node.

[0081] After collecting all voting messages, the master node conducts a multi-stage statistical analysis: first, invalid signatures or malformed responses are eliminated. Then, valid votes are assigned differentiated weights based on the node's real-time reputation score (e.g., a single vote from a high-reputation node is weighted 1.2, while a vote from a low-reputation node is weighted 0.8). Transactions are considered verified if the cumulative weighted votes exceed a preset threshold (e.g., two-thirds of the total weight). For controversial transactions, the system triggers a secondary verification mechanism, randomly selecting cross-shard nodes to form an arbitration committee for review, and reaching a final decision through majority voting.

[0082] Verified transactions enter the threshold signature generation phase: each consensus node uses its shard-specific private key to partially sign the block hash, and the signed shard is transmitted to the aggregation node via a secure channel. The aggregation node uses a threshold signature algorithm (such as BLS aggregation signature) to merge at least t valid shards into a complete joint signature, which can be quickly verified by any node holding the shard's public key. If some nodes fail to submit signed shards on time due to network failure or malicious behavior, the system automatically activates backup nodes in the redundant shard pool to supplement the signature threshold, ensuring the reliability of signature generation.

[0083] Finally, the block with the 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: nodes within the shard synchronously update local ledger copies and maintain the state Merkle tree, while the global coordinator records the shard block header hash to the main chain, forming an audit trail for cross-shard transactions. For transactions that fail verification, the system automatically generates a feedback report containing error codes and correction suggestions, returns it to the client along the original path, and triggers a partial refund mechanism for transaction fees to optimize the user experience. The entire consensus process adopts a pipelined design, with overlapping execution of transaction verification, voting statistics, and signature generation. This significantly reduces the multi-round communication overhead of the traditional PBFT algorithm and reduces the single-block consensus time to milliseconds.

[0084] 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 swap operation between the source and target chains.

[0085] In step S5, the atomic swap operation includes: generating a time lock commitment Lock(H(s)) when the source chain locks the asset, where s is a random secret value; generating a random secret value s on the source chain, and releasing the asset after verifying that the random secret value s as the hash preimage satisfies H(s)=Commit, otherwise the target chain releases the asset after the timeout threshold Δt≥2(t propagate +t confirm ) and then automatically roll back, where t propagate is the maximum propagation delay of cross-chain messages, t confirm The time required to confirm the required number of blocks for the target chain.

[0086] In the specific implementation of step S5, the cross-chain interaction layer deeply decodes the smart contract interface, transaction data structure and consensus rules of the target chain through the 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. For example, when it is detected that the target chain is an Ethereum compatible chain, the adapter automatically enables the EVM bytecode parser and ABI encoder to convert the original transaction parameters of the source chain into call instructions that comply with the ERC-20 or ERC-721 standards; if the target chain is a Fabric consortium chain, it is converted into a chain code call request based on the channel strategy. During the protocol conversion process, the system retains the core semantics of the original transaction (such as asset type, quantity, recipient identification), and dynamically maps and compatibility fills the format difference fields (such as Gas pricing model, signature scheme).

[0087] After completing the protocol conversion, the system generates a time-bound commitment for the cross-chain transaction using a Verifiable Delay Function (VDF). Within the atomic swap smart contract deployed on the source chain, a randomly generated encrypted seed value is injected into the VDF calculation module, which generates a unique delayed output based on non-parallelizable iterative operations. This process is performed in an off-chain Trusted Execution Environment (TEE), ensuring that the calculation process is resistant to interference and time-controlled. The generated VDF output value serves as a globally unique identifier for the cross-chain transaction and is bound to the asset lock-up conditions of the target chain. The system also activates a multi-chain event listener, synchronously monitoring contract events related to the VDF identifier across the node networks of both the source and target chains.

[0088] Atomic swaps are rigorously executed through a multi-stage state machine: First, the atomic contract on the source chain freezes the initiator's designated assets and generates a cross-chain transaction voucher containing the VDF commitment value. This voucher is transmitted to the target chain's validation node via a secure channel on the relay network, triggering the target chain's response contract to perform a conditional pre-check—verifying the validity of the voucher signature, the matching of the VDF output with the seed value, and the initiator's legal status on the target chain. Once verified, the target chain contract locks the corresponding exchanged assets and sends a ready confirmation signal to the source chain. At this point, the system initiates the cross-chain state synchronization service, continuously polling the contract status of both chains to ensure consistency.

[0089] Once both chains have locked their assets and the network delay compensation window (dynamically calculated based on historical delay data) has opened, the initiator submits an asset request to the target chain via a relay node. After confirming the persistence of the source chain's asset lock status (reaching a preset number of confirmation blocks), the target chain's validator executes the asset release operation and broadcasts the transaction completion event to the cross-chain coordinator. After verifying the consistency of the final transaction state hashes on both chains, the coordinator sends an unlock command to the source chain, lifting the initial asset freeze. If either chain fails to complete status confirmation within the timeout threshold (triggered by an alarm from 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 removes the lock status, and destroys the temporarily generated transaction voucher. All intermediate state changes are recorded in a rollback log on each chain's audit subchain, ensuring traceability and non-repudiation. Throughout this process, the cross-chain transaction coordinator manages key operational instructions through a multi-signature mechanism, preventing any single point of failure or malicious activity from tampering with the cross-chain transaction's state flow. S6. After the transaction is completed, high-frequency small transactions are batch settled through the off-chain state channel, and the final state hash is synchronized to the on-chain storage layer.

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

[0091] Compress n transactions into a Merkle tree root hash Root=Hash(tx1||tx2||...||tx n); Verify(Root, Path) must be satisfied during on-chain verification i , tx i )=true, and the final balance satisfies the conservation condition ∑Input j =∑Output k .

[0092] In the specific implementation of step S6, when the accumulation of high-frequency, small-value transactions within the off-chain state channel reaches a preset batch processing threshold or an agreed-upon time window, the system initiates an automated batch settlement process. The user client first organizes the off-chain transaction records within the channel into an ordered queue in chronological order. A Merkle tree structure of the transactions is generated locally, with each transaction's hash value serving as a leaf node, and then aggregated upwards to form a root hash. This process is performed within the client's trusted execution environment, ensuring that the original transaction data is tamper-proof and intermediate states are invisible to the public. Simultaneously, the system cross-compares each participant's local transaction copies via a peer-to-peer network. Using a discrepancy detection algorithm, it identifies and flags disputed transaction entries, triggering a multi-party negotiation mechanism: the disputed transaction is temporarily isolated, and the participants exchange transaction signatures and timestamp proofs via an encrypted communication channel. If no agreement can be reached within the negotiation period, a pre-deployed arbitration smart contract is automatically invoked, and a randomly selected group of validators conducts an off-chain arbitration on the disputed content. The final decision is reached by majority vote.

[0093] After transaction verification and dispute resolution, the system batches all undisputed transactions into a settlement request data packet containing a Merkle root hash, a snapshot of each participant's balance, and the channel version number. This data packet is jointly signed by all participants in the channel using multi-signature technology. The signing process utilizes a dynamic threshold strategy, automatically adjusting the minimum number of signatures based on the number of channel participants. For example, in a bilateral channel, both parties must sign, while in a multilateral channel, a minimum of 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 signatures and the consistency of the Merkle root. It then uses lightweight Merkle proof technology to spot-check the legitimacy of a few transactions. For example, it randomly selects several leaf node transactions and requires participants to provide the corresponding hash paths and original data for on-chain verification. This spot-check mechanism ensures settlement efficiency while significantly reducing on-chain computing resource consumption.

[0094] After on-chain verification, the settlement contract writes the final channel state hash (including balance distribution and closing timestamp) to a specific block in the distributed ledger storage layer. This block is marked as a dedicated state channel settlement block and enjoys priority packaging to reduce confirmation latency. During this writing process, the system simultaneously triggers cleanup and archiving operations on the off-chain storage network: the original transaction data is migrated from a temporary cache to a decentralized storage node (such as an IPFS cluster) and linked to the on-chain record via content-addressed hashing, forming a complete audit trail. Upon receiving the on-chain confirmation notification, the participating parties' local clients automatically update the local ledger state, release the staked assets occupied by the channel, and remove the encryption lock associated with the channel. If malicious behavior is detected during the settlement process (such as signature forgery or double-spending attempts), the system automatically freezes the channel creation permissions of the relevant account and encapsulates the evidence data as a penalty transaction and submits it to the governance contract, triggering a predefined reputation deduction and asset confiscation mechanism. The entire batch settlement process balances off-chain efficiency and on-chain security while ensuring transaction privacy, making it particularly suitable for high-concurrency scenarios such as payment networks and micro-transaction platforms.

[0095] This embodiment also provides a computer device suitable for the blockchain-based digital asset security transaction method, including: a memory and a processor; the memory is used to store computer-executable instructions, and the processor is used to execute computer-executable instructions to implement the blockchain-based digital asset security transaction method proposed in the above embodiment.

[0096] The computer device may be a terminal, comprising a processor, a memory, a communication interface, a display screen and an input device connected via a system bus. The processor of the computer device is used to provide computing and control capabilities. The memory of the computer device comprises a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system and a computer program. The internal memory provides an environment for the operation of the operating system and the computer program in the non-volatile storage medium. The communication interface of the computer device is used to communicate with an external terminal in a wired or wireless manner, and the wireless manner may be achieved through WIFI, an operator network, NFC (near field communication) or other technologies. The display screen of the computer device may be a liquid crystal display or an electronic ink display screen, and the input device of the computer device may be a touch layer covering the display screen, or a button, trackball or touchpad provided on the housing of the computer device, or an external keyboard, touchpad or mouse.

[0097] This embodiment also provides a storage medium having a computer program stored thereon, which, when executed by a processor, implements the method for implementing secure digital asset transactions based on blockchain as proposed in 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 static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic memory, flash memory, magnetic disk or optical disk.

[0098] In summary, the present invention achieves multi-dimensional performance improvement and security assurance in the field of digital asset transactions through the integration of layered architecture design and innovative technologies. First, the smart contract execution layer built on the improved practical Byzantine fault-tolerant consensus algorithm, combined with dynamic sharding strategy and pipelined verification process, significantly improves transaction throughput. Under the experimental environment, the processing capacity of a single shard reaches tens of thousands of transactions per second, and the number of shards 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. Secondly, through the combined application of zero-knowledge proof and ring signature technology, fine-grained privacy protection is achieved at three levels: transaction amount concealment, participant address obfuscation, and transaction path obfuscation. 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 resistance to quantum computing attacks, and the computing resource consumption is reduced by about 40% compared to traditional privacy solutions. In terms of cross-chain interoperability, the combination of a heterogeneous cross-chain gateway protocol and an atomic swap mechanism supports millisecond-level confirmation and automated rollback of multi-chain asset transfers. Through the collaborative design of verifiable delay functions and time-locked smart contracts, the cross-chain transaction success rate is increased to over 99.8%, while eliminating the single point of failure risk of the relay chain architecture. Furthermore, the introduction of on-chain and off-chain collaborative verification mechanisms and state channel batch settlement technology reduces gas costs by approximately 65% in high-frequency, small-value transaction scenarios and supports the real-time generation of proof of transaction finality. This technical integration solution demonstrates strong applicability in financial scenarios such as digital currency circulation, NFT transaction confirmation, and securitized token settlement, providing system-level support for building a secure and efficient distributed financial infrastructure.

[0099] It should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and are not intended to limit the present invention. Although the present invention 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 invention may be modified or replaced by equivalents without departing from the spirit and scope of the technical solutions of the present invention, which should all be included in the scope of the claims of the present invention.

Claims

1. A blockchain-based digital asset security trading system, characterized by: The system includes a smart contract execution layer, a distributed ledger storage layer, and a cross-chain interaction layer; The smart contract execution layer is used to receive and parse transaction requests, execute the preset smart contract logic, use the improved practical Byzantine fault-tolerant consensus algorithm to perform multi-node verification of transaction legitimacy, and generate transaction execution results; The distributed ledger storage layer is used to store block data of verified transactions through a chain data structure, uses a multi-chain indexing mechanism to associate transaction hashes with user addresses, and provides a transaction history tracing function; The cross-chain interaction layer is used to process asset exchange requests between different blockchain networks, convert transaction formats through the heterogeneous cross-chain gateway protocol, and ensure the atomicity of cross-chain transactions based on the atomic swap protocol. The cross-chain interaction layer integrates a verifiable delay function module to generate time-bound cross-chain transaction commitments to ensure that cross-chain operations are resistant to preemptive attacks.

2. The blockchain-based digital asset security transaction system according to claim 1, characterized in that: The identity authentication module uses the elliptic curve digital signature algorithm to generate the user's digital identity certificate, 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, requiring at least d verification nodes to verify the signature fragment σ i =sk i H(m) is combined to generate a complete signature σ=∑σ i mod q, where sk i is the node shard private key, and H(m) is the transaction hash value.

3. The blockchain-based digital asset security transaction system according to claim 1, characterized in that: The privacy protection module achieves transaction amount concealment through zero-knowledge proof, specifically: generating a Pedersen commitment C = g for the transaction amount c c h r , where g, h are generators and r is a random number; in the ring signature technology, the transaction initiator selects a public key set {pk1, ..., pk N }, generate signature σ=Sign(sk i ,m)+∑ j≠i R j , where R i It is a random number, ensuring that the actual signer index i cannot be deduced from the signature.

4. The blockchain-based digital asset security transaction system according to claim 1, characterized in that: When processing private key fragments in the trusted execution environment, the Shamir secret sharing algorithm is used to split the master private key sk into k fragments sk i =f(i), where f(x)=α0+α0x+…+αt t-1 x t-1 , and at least t shards are required to reconstruct the private key; Cross-chain status verification is achieved through light node Merkle proof. The verification formula is Verify(root,path,tx)=true, where root is the Merkle root of the target chain block header and path is the Merkle path of the transaction hash.

5. The blockchain-based digital asset security transaction system according to claim 1, characterized in that: The sharding strategy of the dynamic sharding management module satisfies Where T avg is the average transaction load of the network, T max This is the single-shard processing threshold; The consensus between shards is synchronized using the cross-shard atomic broadcast protocol to ensure the consistency of transaction sequence conditions 6. A blockchain-based digital asset secure transaction method, which is implemented based on the blockchain-based digital asset secure transaction system according to any one of claims 1 to 5, characterized in that: The following steps are involved: S1. The user client generates an asymmetric key pair and registers a digital identity, and the public key hash is stored on-chain through a distributed identity authentication node; 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; S3. The system dynamically divides transaction shards based on the current network load and assigns transaction requests to the consensus node groups within the corresponding shards. S4. The consensus node group uses an improved practical Byzantine fault-tolerance algorithm to verify the transaction, generates a joint verification result through threshold signatures, and submits it to the distributed ledger storage layer; 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 swap operation between the source and target chains. S6. After the transaction is completed, high-frequency small transactions are batch settled through the off-chain state channel, and the final state hash is synchronized to the on-chain storage layer.

7. The blockchain-based digital asset secure transaction method according to claim 6, characterized in that: 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 by obfuscating the transaction path; the privacy processing further includes: generating a ciphertext E(c)=g through homomorphic encryption of the transaction amount c c h r , where r is a random number; the recipient's address is hidden as A′=H(A||r) through a one-time masking technique, where r is a temporary random number; when obfuscating the transaction path, the onion routing model is used, and the node addresses of the path are encrypted layer by layer.

8. The blockchain-based digital asset secure transaction method according to claim 6, wherein: In step S4, the improved practical Byzantine fault-tolerant algorithm includes: the node reputation score update formula is: Where V i ∈{0, 1} is the accuracy of this verification, and α∈(0, 1) is the attenuation factor; a reputation scoring mechanism is introduced to dynamically adjust the node voting weight; Pipeline Proposal - In the verification process, the transaction group size B meets L max It is the upper limit of the capacity of a single block; a pipelined proposal-verification process is used to shorten the time to reach consensus.

9. The blockchain-based digital asset secure transaction method according to claim 6, wherein: In step S5, the atomic swap operation includes: generating a time lock commitment Lock(H(s)) when the source chain locks the asset, where s is a random secret value; generating a random secret value s on the source chain, and releasing the asset after verifying that the random secret value s as the hash preimage satisfies H(s)=Commit, otherwise the target chain releases the asset after the timeout threshold Δt≥2(t propagate +t confirm ) and then automatically roll back, where t propagate is the maximum propagation delay of cross-chain messages, t confirm The time required to confirm the required number of blocks for the target chain.

10. The blockchain-based digital asset secure transaction method according to claim 6, wherein: In step S6, the batch settlement of the off-chain state channel includes: Compress n transactions into a Merkle tree root hash Root=Hash(tx1||tx2||...||tx n ); Verify(Root,Path i , tx i )=true, and the final balance satisfies the conservation condition∑Input j =∑Output k .

Images