Blockchain transaction disclosure method and electronic device

Abstract

The application provides a blockchain transaction disclosure method and an electronic device, and belongs to the technical field of blockchains. A transaction initiator needs to submit a VDF result when submitting a real transaction to a transaction pool, and the VDF result must be obtained through continuous and non-parallel calculation, so that any participant cannot quickly calculate the result and construct a malicious transaction to perform a pre-emptive attack before the transaction is chained. Secondly, the transaction information four-tuple is encrypted and then submitted, so that miners cannot predict the transaction value, and the review attack of malicious miners can be fundamentally eliminated. An additional reward is provided when the transaction is submitted, which can encourage each miner on the chain to actively calculate the VDF and process the transaction preferentially, forming a competitive decryption environment. At the same time, each transaction needs to provide an additional reward higher than the normal fee consumption, which can significantly increase the economic burden of malicious attacks, thereby effectively limiting the risk of DoS attacks caused by excessive transaction issuance.

Description

Technical Field

[0001] This application relates to the fields of consortium blockchain and private blockchain technology, and in particular to a blockchain transaction disclosure method and electronic device. Background Technology

[0002] Frontrunning attacks are a common malicious node attack behavior in consortium blockchain / private blockchain systems: malicious nodes tamper with the order of business processing in the pending transaction queue by illegally jumping in line or delaying processing, in order to gain illicit profits. Common attack types include pre-running attacks, post-running attacks, and sandwich attacks. Frontrunning attacks are common attack behaviors on blockchains with smart contracts (such as Ethereum). Specifically, it refers to attackers bribing miners (packaging nodes) with higher gas fees in the transaction pool while waiting to be packaged, thereby seizing user profits. Common frontrunning attacks include the following categories:

[0003] Pre-emptive attack: Attackers scan the memory pool, jump the queue with higher gas fees, and profit by taking advantage of the market influence of the original transaction; Backdoor attack: closely follow large transactions (such as large swaps on DEXs) and profit from price fluctuations; Sandwich attack: Placing a transaction at the beginning and end forces the victim to buy at a high price and sell at a low price, allowing the attacker to profit from the difference.

[0004] Currently, most solutions for defending against preemptive attacks are based on distributed commitment-disclosure schemes. While their computational process is simple, they often suffer from the following problems: 1) Vulnerable to censorship attacks by malicious miner block processing nodes: Miner block processing nodes may have business biases, be illegally guided to have their own interests, or be bribed by other transaction submitters. For transactions in different transaction pool waiting queues, they may refuse to include them in their own blocks or maliciously delay the time of transaction entry into the block, thus objectively facilitating the formation of a preemptive attack.

[0005] 2) Transaction submitters abuse transaction requests: In order to increase the probability of their transactions being recorded on the blockchain, transaction initiators often submit multiple commitments for a single transaction and selectively display them, which essentially constitutes a DoS attack. Summary of the Invention

[0006] To address the aforementioned issues, the main objective of this application is to propose a blockchain transaction disclosure method and electronic device, which aims to effectively prevent censorship attacks by malicious miner block processing nodes and the abuse of transaction requests by transaction submitters.

[0007] To achieve the above objectives, a first aspect of this application proposes a blockchain transaction disclosure method, the method comprising: Each node deploys a transaction disclosure contract on the blockchain. The transaction disclosure contract includes a request challenge function, an initialization parameter table, and a transaction registration table. Each node confirms the verifiable delay function algorithm parameters and writes the confirmed verifiable delay function algorithm parameters into the initialization parameter table. The verifiable delay function algorithm parameters include verifiable delay function calculation parameters, verifiable delay function calculation duration, and security algorithm parameters. The transaction initiator generates a transaction information quadruple based on the locally generated transaction content, generates a corresponding transaction hash value from the transaction information quadruple, and generates a corresponding transaction signature from the transaction hash value using a private key. Then, the initiator sends a transaction registration request to the blockchain. The transaction information quadruple includes the function name called, the on-chain address of the transaction initiator, the destination address, and the transaction parameters. After receiving the transaction registration request, the on-chain miner block processing node calls the request challenge function in the transaction disclosure contract to verify the transaction hash value and the transaction signature, completes the registration, generates a registration code, and writes the registration code, the transaction hash value, and the transaction signature into the transaction registration table; After registration is completed, the transaction initiator calculates the verifiable delay function result based on the transaction hash value, the registration code, and the initialization parameter table of the transaction disclosure contract, and encrypts the transaction information quadruple and the verifiable delay function result. The transaction initiator selects several mining block processing nodes to submit real transactions to the transaction pool transaction waiting queue, and provides an additional reward higher than the normal cost consumption of the transaction information quadruple, and sets a scheduling weight higher than the normal business resource consumption standard. The real transaction includes the registration code, the ciphertext of the transaction information quadruple, the ciphertext of the verifiable delay function result, and the fallback time, which is the maximum on-chain time that the transaction initiator can tolerate. The miner block processing node obtains the transaction hash value and the registration code based on the transaction registration table within the fallback period, decrypts the ciphertext of the transaction information quadruple and the ciphertext of the verifiable delay function result, and initiates block production consensus with other miner block processing nodes on the chain to obtain the additional reward for priority execution of business processing.

[0008] In one embodiment of this application, the method further includes: The calculation duration of the verifiable delay function is determined based on the block time of the blockchain, wherein the calculation duration of the verifiable delay function is less than the block time, and the difference between the calculation duration of the verifiable delay function and the block time is less than a preset duration.

[0009] In one embodiment of this application, after receiving the transaction registration request, the on-chain miner block processing node calls the request challenge function in the transaction disclosure contract to verify the transaction hash value and the transaction signature, including: After receiving the transaction registration request, the on-chain miner block processing node obtains the corresponding public key from the on-chain address of the transaction initiator; The request challenge function in the transaction disclosure contract is invoked, and the public key, the transaction hash value, and the transaction signature are used to perform calculations to check whether the transaction signature is generated by signing the transaction hash value with the private key corresponding to the public key.

[0010] In one embodiment of this application, the transaction initiator encrypts the transaction information quadruple and the verifiable delay function result, including: The transaction initiator generates a symmetric key locally; The transaction initiator encrypts the transaction information quadruple based on the symmetric key to obtain the ciphertext of the transaction information quadruple. The transaction initiator performs reversible masking on the verifiable delay function result based on the symmetric key to obtain the ciphertext of the verifiable delay function result.

[0011] In one embodiment of this application, the miner block processing node obtains the transaction hash value and the registration code based on the transaction registration table within the fallback time period, in order to decrypt the ciphertext of the transaction information quadruple and the ciphertext of the verifiable delay function result, including: The miner block processing node obtains the transaction hash value and the registration code based on the transaction registration table within the fallback time, and calculates the verifiable delay function result according to the transaction hash value, the registration code, and the initialization parameter table of the transaction disclosure contract; The miner block processing node performs inverse mask calculation based on the verifiable delay function result and the ciphertext of the verifiable delay function result to obtain the symmetric key; The miner block processing node decrypts the ciphertext of the transaction information quadruple using the symmetric key to obtain the plaintext of the transaction information quadruple.

[0012] In one embodiment of this application, after the transaction initiator selects several miner block processing nodes to submit real transactions to the transaction pool transaction waiting queue, the method further includes: The transaction initiator monitors whether the real transaction enters the transaction pool's transaction waiting queue; If the real transaction is detected not to enter the transaction pool waiting queue within a set time, the transaction initiator will reselect a miner block processing node to submit the real transaction to the transaction pool waiting queue again.

[0013] In one embodiment of this application, the transaction disclosure contract further includes a public symmetric key function. After the transaction initiator selects several miner block processing nodes to submit real transactions to the transaction pool transaction waiting queue, the method further includes: The timer starts after the real transaction enters the transaction waiting queue in the transaction pool, and after the fallback time has elapsed, the transaction initiator calls the public symmetric function in the transaction disclosure contract on the chain through one or more miner block processing nodes to publicize the symmetric key.

[0014] In one embodiment of this application, when a miner block processing node discovers that the actual transaction has not yet been successfully uploaded to the blockchain, but the symmetric key has been publicized, the method includes: The miner block processing node decrypts the ciphertext of the transaction information quadruple using the symmetric key and initiates block production consensus with other miner block processing nodes on the chain.

[0015] In one embodiment of this application, before the transaction initiator generates a transaction information quadruple based on locally generated transaction content, the method further includes: The transaction initiator generates a public-private key pair locally and publishes the public key to generate an external account address on the blockchain. The external account address is the on-chain address of the transaction initiator.

[0016] To achieve the above objectives, a second aspect of this application provides an electronic device, which includes a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement the method described in any embodiment of this application.

[0017] In the technical solution provided in this application, when a transaction initiator submits a real transaction to the transaction pool's waiting queue, they must simultaneously submit the VDF result. The VDF result can only be obtained through continuous, non-parallel computation, which forcibly introduces a definite time delay. This delay prevents any participant (including miner block processing nodes and attackers) from quickly calculating the result and constructing malicious transactions for preemptive attacks before the transaction is officially packaged into a block. Secondly, by encrypting the transaction information quadruple before submission, miner block processing nodes cannot predict the value of the transaction content, fundamentally eliminating censorship attacks by malicious miner block processing nodes. Providing additional rewards and setting scheduling weights simultaneously when submitting a transaction incentivizes each miner block processing node on the chain to actively calculate the VDF and prioritize transaction processing, forming an orderly business processing environment and a competitive decryption environment. Furthermore, each transaction requires additional rewards exceeding normal costs and resource allocation requirements higher than standard standards, significantly increasing the economic burden of malicious attacks and raising the resource consumption threshold for malicious operations. This effectively limits the risk of DoS (Denial of Service) attacks caused by excessive transaction issuance.

[0018] It should be understood that the above general description and the following detailed description are merely exemplary and do not limit this application. Attached Figure Description

[0019] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the specification, serve to explain the principles of this application.

[0020] Figure 1 This is a flowchart of a blockchain transaction disclosure method provided in an embodiment of this application.

[0021] Figure 2 This is a flowchart illustrating the steps of an on-chain miner block processing node, provided in one embodiment of this application, to verify the transaction hash value and the transaction signature by calling the request challenge function in the transaction disclosure contract after receiving the transaction registration request.

[0022] Figure 3 This is a flowchart illustrating the steps of a transaction initiator encrypting a transaction information quadruple and a verifiable delay function result, as provided in one embodiment of this application.

[0023] Figure 4 This is a flowchart illustrating the steps of a miner block processing node, provided in one embodiment of this application, to obtain the transaction hash value and the registration code based on the transaction registration table within the fallback time, in order to decrypt the ciphertext of the transaction information quadruple and the ciphertext of the verifiable delay function result.

[0024] Figure 5 This is a schematic diagram of the overall interactive architecture and process flow of the system provided in an embodiment of this application.

[0025] Figure 6 This is a schematic diagram of the hardware structure of the electronic device provided in the embodiments of this application. Detailed Implementation

[0026] To make the objectives, implementation methods, and advantages of this application clearer, exemplary embodiments will now be described more fully with reference to the accompanying drawings. However, these exemplary embodiments can be implemented in many forms and should not be construed as limited to the examples set forth herein; rather, these exemplary embodiments are provided to make the description of this application more comprehensive and complete, and to fully convey the concept of the exemplary embodiments to those skilled in the art. It should be noted that the brief descriptions of terminology in this application are merely for the convenience of understanding the embodiments described below, and are not intended to limit the embodiments of this application. Unless otherwise stated, these terms should be understood in their ordinary and common meaning.

[0027] In the description of this application, it should be understood that the terms "first," "second," and "third" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Therefore, a feature defined as "first," "second," or "third" may explicitly or implicitly include one or more features.

[0028] The flowcharts shown in the accompanying drawings are merely illustrative and do not necessarily include all content and operations / steps, nor do they necessarily have to be performed in the described order. For example, some operations / steps can be broken down, while others can be combined or partially combined; therefore, the actual execution order may change depending on the specific circumstances.

[0029] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0030] The technical solution in this application is only applicable to compliant and licensed blockchain systems such as consortium blockchains and private blockchains, and is intended for legitimate scenarios such as enterprise business data, financial compliance data, and inter-institutional data exchange. It is not applicable to any virtual currency, token issuance, or encrypted asset trading scenarios, and does not involve virtual currency mining, computing power competition, token rewards, or related technologies and businesses. All blockchain transactions in this solution refer to legitimate business data exchanges between institutions and do not include any virtual asset trading activities.

[0031] Frontrunning attacks are common attacks on blockchains with smart contracts (such as Ethereum). Specifically, they refer to attacks where attackers bribe miners (packaging nodes) by setting higher gas fees for transactions waiting to be packaged in the transaction pool, thereby seizing the user's profits.

[0032] The proposed technology proposes a scheme to resist front-running attacks. Transaction submitters are required to spend additional time calculating the Virtual Transaction Function (VDF) during the submission and presentation process. Since VDF computation is not parallelizable, attackers must also complete the computation to disrupt the transaction's entry into the block, thus preventing front-running attacks. Furthermore, the non-parallel nature of VDF computation also reduces the possibility of transaction submitters flooding the block with transactions.

[0033] However, miners can still achieve the effect of censorship attacks by delaying transaction submissions, thus not solving the problem of censorship attacks by malicious miners; and since miners' VDF computing power far exceeds that of ordinary transaction submitters, when miners delay transaction submissions, they can construct a transaction and generate a VDF proof in a relatively short time (such as the time it takes to produce a block), thus achieving a hedging effect against malicious attacks.

[0034] Based on this, this application proposes a blockchain transaction disclosure method to effectively prevent censorship attacks by malicious miner block processing nodes and curb the abuse of transaction requests by transaction submitters. The blockchain transactions described in this application specifically refer to legitimate and compliant business data interactions, excluding virtual currency transactions; the blockchain is primarily applicable to legitimate scenarios such as consortium blockchains and private blockchains, and does not support virtual currency-related technology applications.

[0035] Before introducing this technical solution, we will first explain the Verifiable Delay Function (VDF).

[0036] A Virtual Function (VDF) is a mathematical function whose core characteristic is that computation must consume a fixed time T, which cannot be significantly shortened through parallel computing, but the result can be verified quickly. It acts like a "time lock," ensuring that the computation process cannot be accelerated while maintaining extremely high verification efficiency. For example, computation might take one hour, but verification only takes one second. This characteristic makes it an ideal tool for preventing front-end attacks in blockchain scenarios.

[0037] VDF functions must meet the following conditions: (1) Time consumption: The computation is time-consuming and difficult to be significantly reduced by parallel computing; (2) Rapid verification: The verification time for proving the calculation results needs to be significantly, at least logarithmically, less than the calculation time; (3) Uniqueness: The same input corresponds to a unique output result (but the proof of the result does not require uniqueness); (4) Seriality: The probability that an attacker can calculate the result of VDF in less than T time is negligible.

[0038] VDF generally includes three processes: setup, evaluation (Eval), and verification. The setup phase accepts security parameters. And time parameters (actual time elapsed) The parameters ek used for computation and the verification parameters vk can be determined. The computation phase accepts the computation parameters ek and the input x, and after a sufficiently long computation time, generates the output y and the proof. (Right now The verification phase accepts vk, x, y, and It can quickly verify and output whether it passes or fails (i.e., accept / reject). ).

[0039] The most common VDF formula in the industry is the repeated square formula shown in Equation 1 below: (Equation 1).

[0040] In Equation 1, N is the modulus parameter in the publicly disclosed parameters. T is the time parameter .

[0041] Equation 1 means: Squaring the input x, squaring the result again, and repeating this process T times (total time taken). The final result is modulo N. The repetition of the square cannot be parallelized, and the result is only known in the last calculation, thus satisfying the time-consuming and unique requirements of the VDF algorithm. Generally, the larger the value of T, the higher the difficulty of the VDF problem, and the longer the average computation time.

[0042] To make the computation easily verifiable in order to meet the requirements of VDF, a proof is needed. Proof that the conditions are met. There are various forms, common ones include the integer N-multiplicative group based on Euler's totient function, Boneh interactive verification, and the Wislowski verification protocol, etc., which will not be specified in this paper. Proof The result, along with y, x, and vk, will be sent to the verifier for verification. Generally, the time spent verifying the result should be much less than the time spent calculating Eval, and can be considered negligible in comparison. Table 1 below shows a set of comparison data for the proof Verify based on the repeated square Eval + the multiplicative group of integers N: Table 1

[0043] In compliant consortium blockchains and private blockchains, VDF is used to ensure the fairness of business transaction processing. For example, when T=100,000, computation takes 670 seconds, but verification only takes 1.1 seconds. This efficiency difference allows VDF to prevent attacks without slowing down the system.

[0044] Reference Figure 1 , Figure 1 This is a flowchart of a blockchain transaction disclosure method provided in an embodiment of this application, including but not limited to steps S110 to S170.

[0045] Step S110: Each node deploys a transaction disclosure contract on the blockchain. The transaction disclosure contract includes a request challenge function, an initialization parameter table, and a transaction registration table.

[0046] This application provides a blockchain transaction disclosure method. This application is applied to compliant blockchain systems such as consortium blockchains and private blockchains. It requires a fixed block interval and the ability to run transaction queues and smart contracts. This embodiment does not limit the specific public / consortium blockchain type, but requires a fixed block interval, an Ethereum-like transaction pool, and smart contract functionality. All nodes mentioned below are nodes with write transaction permissions to the blockchain (i.e., block-producing nodes).

[0047] Specifically, a blockchain is a distributed ledger composed of blocks linked chronologically. Each block contains transaction data and the hash value of the previous block, forming an immutable data chain. Its core characteristics include decentralization, data immutability, and transparency.

[0048] Nodes are devices connected to a blockchain network, responsible for storing the ledger, verifying transactions, and participating in consensus. The main types include: Full node: Stores complete blockchain data and can independently verify all transactions (e.g., a Bitcoin full node needs to store approximately 500GB of data).

[0049] Light nodes: only store block headers and rely on full nodes to verify transactions (such as mobile wallets).

[0050] Miner block processing nodes: These are authorized full nodes, primarily responsible for generating new blocks and packaging transactions. These nodes are uniformly authorized and managed by an institution, completing block processing according to preset consensus rules. They do not involve mechanisms related to computing power competition, token rewards, or transaction fees. Unlike special full nodes, they do not have the additional responsibility of generating new blocks. Miners are special nodes that participate in consensus competition, vying for the right to record transactions by calculating Proof-of-Work (PoW) or Proof-of-Stake (PoS) to obtain block rewards and transaction fees. For example, Bitcoin miners package transactions by calculating hash values.

[0051] Transaction initiators are ordinary users of the blockchain network who initiate transactions through External Accounts (EOAs). EOAs are controlled by private keys and can actively initiate data exchange transfers or call smart contracts, but they do not participate in network maintenance. After a transaction initiator initiates a transaction, full nodes verify and propagate the transaction, and mining block processing nodes package the valid transaction into a block. Full nodes provide the network infrastructure, mining block processing nodes ensure the normal confirmation of transactions, and transaction initiators complete various legitimate business data exchanges to drive economic activities.

[0052] The solution proposed in this application mainly includes the following roles: (1) Transaction disclosure contract, which is a smart contract that needs to be deployed on the blockchain. It is responsible for the implementation and recording of the request disclosure function of the entire transaction disclosure process, including the following functions and features: a) The request_challenge() function is called by the transaction initiator, who submits a four-tuple of transaction parameters and a hash. The smart contract verifies these parameters, and if the verification is successful, it returns the registration number RegID.

[0053] b) The function show_secret(), which discloses the symmetric key, is called by the initiator of a successfully registered transaction. It can disclose the symmetric key K of the transaction with the corresponding registration number.

[0054] c) Initialize the parameter table to store system parameters such as VDF algorithm parameters and encryption algorithm.

[0055] d) Transaction registration form, used to maintain the status record of all registered transactions.

[0056] (2) The transaction initiator is any EOA (External Owner Address) on the blockchain. It does not need to be a node; it only serves as a business access account and can be simply a blockchain wallet. It is responsible for calling the contract's `request_challenge()` function during the transaction initiation process and must be able to compute the VDF problem. Finally, after encrypting the VDF computation result and providing additional computation rewards through system scheduling configuration, it attempts to submit the transaction to the blockchain. The transaction initiator only needs to be readable on the blockchain.

[0057] (3) Miner block processing node. This application only discusses block-producing nodes with write permissions, i.e., miner block processing nodes, which can select transactions from the transaction waiting queue pool, package them, and send them to other nodes for consensus. The miner block processing node discussed in this invention also needs to have VDF computing capabilities to process the calculation and verification of the transactions involved in this invention.

[0058] The scheme of this application includes four stages: initialization stage, transaction initiation and registration stage, transaction submission stage, and transaction on-chain stage.

[0059] The main purpose of the initialization phase is to deploy the transaction disclosure contract on the blockchain and initialize the VDF algorithm parameters.

[0060] Specifically, the launch of a blockchain network or the addition of a new node typically follows this process: (1) Key pair generation: Each node (participant) independently generates a pair of asymmetric encryption keys locally. The private key (sk) must be kept absolutely secret and is the ultimate proof of identity; while the public key (pk) can be made public and used to verify identity.

[0061] (2) Public Key Publication and Identity Binding: Nodes "publicize" the generated public key to other nodes in the network. This process essentially binds your public key to a network address (called an External Account Address, or EOA, in Ethereum), making it your unique identity on the chain. The person who owns the corresponding private key has control over that address.

[0062] (3) Consensus Chain Building: Nodes with key pairs and addresses can start communicating with each other and follow the pre-defined compliance consensus rules and specific consensus algorithms (such as Proof-of-Work, Proof-of-Stake, etc.) to jointly maintain the consistency of the ledger, and finally form a continuously growing "chain".

[0063] However, if a node joins an existing consortium blockchain or private blockchain (such as the Bitcoin or Ethereum mainnet), then the "chain building" step is omitted. The node will directly use the existing blockchain data and sign the initiated transactions using its own private key to prove the legitimacy of the operation.

[0064] Steps S110-S120 belong to the initialization phase, which only needs to be executed once. All nodes reach a consensus and deploy a smart contract code named "Transaction Disclosure Contract" onto the blockchain. The Transaction Disclosure Contract includes a challenge request function `request_challenge()`, a public symmetric key display function `show_secret()`, an initialization parameter table, and a transaction registration table.

[0065] In step S120, each node confirms the verifiable delay function algorithm parameters and writes the confirmed verifiable delay function algorithm parameters into the initialization parameter table. The verifiable delay function algorithm parameters include the verifiable delay function calculation parameters, the calculation duration of the verifiable delay function, and the security algorithm parameters.

[0066] All nodes jointly confirm and write a set of crucial system parameters, which form the baseline for all subsequent calculations and verifications. The system parameters mainly include verifiable delay function algorithm parameters, which include verifiable delay function calculation parameters, verifiable delay function calculation duration, and security algorithm parameters.

[0067] The verifiable delay function calculation parameters include the VDF formula, the proof algorithm, and its calculation parameters. For example, the perfect square formula shown in Equation 1 above can be selected as the VDF formula, and Boneh's proof can be used to determine the modulus parameter N using the transaction chain genesis block hash.

[0068] The computation time of the verifiable delay function must be slightly less than the block time. Specifically, the computation time of the verifiable delay function can be determined based on the blockchain's block time, where the computation time of the verifiable delay function is less than the block time, and the difference between the computation time of the verifiable delay function and the block time is less than a preset time (e.g., 2 seconds). Taking the perfect square formula shown in Equation 1 above as an example of the VDF formula, based on the blockchain's block time t, a sufficiently large base number of consecutive squares, Tbase, is set to ensure that the time for most blockchain nodes to solve the VDF and calculate Eval is slightly less than the block time t. For example, given an average block time of 10 seconds, for most current general-purpose hardware machines, Tbase=10000 times results in an average computation time of approximately 8 seconds; therefore, Tbase=10000. This design provides a buffer time for block verification and forces attackers to complete the full computation before they can perform unauthorized operations and participate in the competition, thus resisting attacks and other threats. As hardware performance improves (e.g., increased CPU computing power), the computation time for the same Tbase will decrease. At this point, Tbase needs to be increased through a consensus mechanism (e.g., to 15,000 times) to maintain a reasonable ratio between computation time and block interval. This adjustment ensures that VDF's latency defense effect remains effective. Fixing the computation time prevents computing power monopoly and ensures decentralized characteristics. Dynamically adjusting Tbase allows the system to cope with hardware advancements over the long term and avoids frequent hard forks.

[0069] Security algorithm parameters may include the hash algorithm (such as SHA256) and symmetric encryption algorithm (such as AES128) used in the disclosure process.

[0070] In this step, after determining the system parameters, these system parameters need to be written into the initialization parameter table in the transaction disclosure contract.

[0071] In step S130, the transaction initiator generates a transaction information quadruple based on the locally generated transaction content, generates a corresponding transaction hash value from the transaction information quadruple, and generates a corresponding transaction signature from the transaction hash value using the private key. Then, the initiator sends a transaction registration request to the blockchain. The transaction information quadruple includes the function name called, the on-chain address of the transaction initiator, the destination address, and the transaction parameters.

[0072] In this embodiment, steps S130-S140 belong to the transaction initiation and registration stage. Before step S130, the transaction initiator first generates a public-private key pair locally and publishes the public key to generate an external account address on the blockchain. This external account address is the on-chain address of the transaction initiator. This step is the core process for blockchain users to establish their unique identity in the system. The transaction initiator generates a pair of asymmetric encryption keys in a local secure environment. The private key (sk) must be kept strictly confidential and is the sole proof of identity ownership. The public key (pk) can be published and used to verify the authenticity of the signature. By publishing the public key to the blockchain network, a string address starting with 0x can be generated, which is the on-chain address of the transaction initiator.

[0073] Next, the transaction initiator generates a transaction information quadruple Q based on the locally generated transaction content: (fname, EOAaddr, SCaddr, params). Here, fname is the name of the function being called; EOAaddr is the on-chain address of the transaction initiator, which is also the origin of the transaction; SCaddr is the destination address, which can be a contract or another external account; and params are the transaction parameters. These parameters are legitimate business data and do not include cryptocurrency token addresses, token amounts, exchange rates, or other parameters related to cryptocurrency transactions. This transaction information quadruple Q is like a handwritten "transaction order," clearly specifying: who (EOAaddr), which function (fname) of which contract (SCaddr) is being called, and the specific operation content (params).

[0074] The quadruple Q is then computed using a cryptographic hash function (such as SHA-256) to obtain a fixed-length, unique "digital fingerprint," namely the transaction hash value HashQ. The transaction initiator's private key (sk) is then used to digitally sign the transaction hash value HashQ, resulting in the transaction signature sigQ. The transaction initiator then sends a transaction registration request to the blockchain through any mining block processing node.

[0075] The brilliance of this design lies in the fact that, due to the irreversibility of hash algorithms, miner block processing nodes cannot deduce the original quadruple Q from the transaction hash value HashQ. Furthermore, since the on-chain address (EOAaddr) of the transaction initiator is unknown to the miner block processing nodes, they only see a string of meaningless random characters. Therefore, miner block processing nodes have neither the specific motivation nor the ability to censor or attack a particular transaction.

[0076] In step S140, after receiving the transaction registration request, the on-chain miner block processing node calls the request challenge function in the transaction disclosure contract to verify the transaction hash value and transaction signature, completes the registration, generates a registration code, and writes the registration code, transaction hash value, and transaction signature into the transaction registration table.

[0077] In this step, when the on-chain miner block processing node receives a transaction registration request, it initiates an automated on-chain process involving verification, registration, and recording. As a node in the blockchain network, the miner block processing node receives the registration request from the transaction initiator. This request contains two core pieces of data: the transaction hash (HashQ) and the transaction signature (sigQ). The miner block processing node executes a predefined operation: calling the request challenge function in the transaction disclosure contract deployed on the blockchain. The request challenge function uses the transaction initiator's public key (pk) to verify whether the transaction signature (sigQ) was indeed signed by the corresponding private key against the transaction hash (HashQ). This proves that the transaction was indeed initiated by the private key holder and that the transaction content (i.e., the transaction information quadruple Q) has not been tampered with after signing. Once verification is successful, the contract executes the registration operation and generates a globally unique registration code (RegID) on the chain. Finally, the system writes the key information of this registration into a structured transaction registration table. Key information includes the registration code, transaction hash value, transaction signature, and the on-chain address of the transaction initiator. For example, referring to the transaction registration table shown in Table 2 below, the transaction registration table can record the transaction registration code (RegID), the on-chain address of the transaction initiator, the transaction hash value, the transaction signature, and the symmetric key K. It should be noted that the symmetric key K is not written into the transaction registration table along with the registration code (RegID), the on-chain address of the transaction initiator, the transaction hash value, and the transaction signature during transaction registration. Instead, it is written into the transaction registration table by the transaction initiator after the subsequent transaction has entered the transaction waiting queue pool for a period of time (such as after a fallback period) to publicize the symmetric key K.

[0078] Table 2

[0079] In this embodiment, without exposing the specific content of the transaction, an undeniable and traceable "registration" file is established for the transaction on the blockchain. This ensures the credibility of the transaction, protects transaction privacy through cryptographic technology, and eliminates the incentive for miner block processing nodes to conduct specific transaction reviews because they cannot interpret the transaction content.

[0080] Reference Figure 2 , Figure 2 This application provides a flowchart of the steps by which an on-chain miner block processing node, after receiving the transaction registration request, calls the request challenge function in the transaction disclosure contract to verify the transaction hash value and the transaction signature, including but not limited to steps S210 to S220.

[0081] In step S210, after receiving the transaction registration request, the on-chain miner block processing node obtains the corresponding public key from the on-chain address of the transaction initiator. Step S220: Call the request challenge function in the transaction disclosure contract, and use the public key, transaction hash value and transaction signature to perform calculations to check whether the transaction signature is generated by signing the transaction hash value with the private key corresponding to the public key.

[0082] In this embodiment, the miner block processing node obtains the public key from the on-chain address of the transaction initiator and calls the request challenge function in the transaction disclosure contract to perform calculations using the public key, transaction hash value, and transaction signature. The public key is used to decrypt the transaction signature (i.e., the hash value encrypted with the private key) to obtain the original hash value. The transaction hash value is recalculated and compared with the decrypted hash value; if they match, the verification is successful. Here, since the transaction signature is the result of encrypting the transaction hash value with the private key, and the public key and private key appear in pairs, the public key can decrypt data encrypted with the private key. Verification is successful if and only if the transaction signature can be successfully decrypted by the public key, and the decrypted data is completely consistent with the transaction hash value, proving that the transaction was indeed initiated by the private key holder corresponding to the address.

[0083] This verification mechanism ensures that the transaction truly originates from the claimed initiator, that the transaction content has not been tampered with during transmission, and that the initiator cannot later deny initiating the transaction.

[0084] Step S150: After registration is completed, the transaction initiator calculates the verifiable delay function result based on the transaction hash value, registration code, and initialization parameter table of the transaction disclosure contract, and encrypts the transaction information quadruple and the verifiable delay function result.

[0085] In this embodiment, steps S150-S160 belong to the transaction submission stage. After registration is completed, the transaction initiator confirms from the transaction disclosure contract whether the transaction it initiated has been registered and records the transaction registration code (RegID). Then, it reads the verifiable delay function algorithm parameters from the initialization parameter table of the transaction disclosure contract and uses (HashQ||RegID) as the input of the VDF function (formula) to calculate the VDF result. That is, the hash value HasQ of the transaction information quadruple and the registration code RegID are concatenated to form (HashQ||RegID), which is used as the input of the VDF function. By running the VDF function, a deterministic calculation result y is obtained, and a concise mathematical proof is generated, which allows other nodes to quickly verify the correctness of y without having to recalculate the entire time-consuming process. Taking the VDF function using the repeated square formula described in Equation 1 above as an example, (HashQ||RegID) can be used as the x parameter in Equation 1 to calculate the VDF result y and the proof π. In this system, the hash value HasQ of the transaction information quadruple represents the specific content of the transaction, ensuring that the VDF calculation result is closely related to this specific transaction. The registration code RegID is generated only after the transaction is registered on the chain. Malicious miner block processing nodes cannot know this ID before registration is completed, so it is impossible for them to calculate the VDF result in advance to launch an attack. Even if two transactions have exactly the same content (i.e., the hash value HasQ of the transaction information quadruple is the same), as long as the registration time is different, their registration codes RegID will be different, and thus their VDF results will also be different, effectively preventing replay attacks.

[0086] This application's embodiment establishes a time lock that cannot be quickly bypassed by requiring the VDF result to be calculated based on (HashQ||RegID) after transaction registration but before submission to the transaction pool's waiting queue. It leverages the computational characteristics of VDF to forcibly insert a necessary, real computation time between transaction submission and final on-chain processing. Therefore, attackers cannot forge the same VDF result to offset transactions in a short time because the serial computation characteristic of VDF mandates actual time consumption. For example, if the VDF calculation for transaction A takes 10 seconds, an attacker cannot complete the same calculation and jump the queue within 10 seconds. Malicious miner block processing nodes attempting to profit unfairly by delaying transactions must wait for the VDF calculation to complete, and the calculation time is controlled by the transaction initiator (e.g., setting a timeout period), which miner block processing nodes cannot circumvent. The VDF result, as a key field for transaction verification, ensures that only completed transactions are uploaded to the chain, preventing unverified transactions from being quickly packaged.

[0087] Next, the transaction information quadruple and the verifiable delay function result are encrypted to ensure that the transaction details are kept confidential from the miner's block processing node before decryption and that the encrypted content cannot be modified during transmission.

[0088] Reference Figure 3 , Figure 3 This is a flowchart of the steps for a transaction initiator to encrypt a transaction information quadruple and a verifiable delay function result, as provided in an embodiment of this application, including but not limited to steps S310 to S330.

[0089] Step S310: The transaction initiator generates a symmetric key locally; Step S320: The transaction initiator encrypts the transaction information quadruple based on the symmetric key to obtain the ciphertext of the transaction information quadruple. In step S330, the transaction initiator performs reversible masking on the verifiable delay function result based on the symmetric key to obtain the ciphertext of the verifiable delay function result.

[0090] In this embodiment, the transaction initiator first randomly generates a symmetric key K in the local environment. This symmetric key K is temporary and used only for the secure transmission of this transaction. Then, the generated symmetric key K is used to encrypt the transaction information quadruple Q, generating the ciphertext EncK(Q). The encryption algorithm can be a standard symmetric encryption algorithm such as AES. Simultaneously, the generated symmetric key K is used to perform reversible masking on the verifiable delay function result (VDF result), obtaining the verifiable delay function result ciphertext SK(y). The reversible masking ensures that the original value can be recovered later. For example, addition can be used as the masking algorithm, such as SKy = K + y. Since the inverse operation of addition in the integer field can be directly implemented using subtraction, this meets the requirements. It is understood that, in addition to addition, other reversible operations such as XOR can also be considered. In practical applications, the most suitable algorithm can be selected according to specific security requirements and computing environment.

[0091] This application embodiment encrypts the transaction information quadruple Q using a symmetric key K, ensuring that transaction details are kept confidential from the miner's block processing node before decryption, and that the encrypted content cannot be modified during transmission. Each transaction uses a different random symmetric key, avoiding the risk of key reuse. By applying a reversible mask to the verifiable delay function result using the symmetric key K, the true VDF result can be hidden, preventing malicious miner block processing nodes from directly obtaining it.

[0092] In step S160, the transaction initiator selects several miner block processing nodes to submit real transactions to the transaction pool's transaction waiting queue, and sets a scheduling weight higher than the normal business resource consumption standard to provide an additional reward higher than the normal cost consumption of the transaction information quadruple. The real transaction includes a registration code, a transaction information quadruple ciphertext, a verifiable delay function result ciphertext, and a fallback time. The fallback time is the maximum on-chain time that the transaction initiator can tolerate.

[0093] In this embodiment, after encrypting the transaction information quadruple and the verifiable delay function result (VDF result), the transaction initiator selects several mining block processing nodes and submits the actual transaction for on-chain use. The transaction includes a registration code RegID, the ciphertext of the transaction information quadruple EncK(Q), the ciphertext of the verifiable delay function result SK(y), and a fallback time ts. Simultaneously, a system scheduling weight higher than the normal level needs to be configured. This configuration belongs to the internal business scheduling mechanism of the consortium blockchain and does not involve any virtual currency or fund payment content. It provides an additional reward higher than the normal Gas consumption of the original transaction information quadruple corresponding to this exchange. This additional reward is a supplement to the legitimate transaction fees and does not involve any virtual currency payment. The fallback time ts is a time set by the transaction initiator, meaning that after the transaction is placed in the transaction pool waiting queue, the additional reward of the scheduling weight will become invalid after the fallback time ts (even if the transaction is correctly decrypted and processed, it will revert to normal business priority; even if the transaction is correctly decrypted and processed, the additional reward will be returned to the transaction initiator). Simultaneously, the transaction initiator will disclose the symmetric key K in the transaction disclosure contract. The fallback time ts represents the maximum on-chain time the transaction initiator can tolerate, determined by the initiator, and must be at least greater than the block production time to be valid. The additional reward for priority execution can only be obtained after the miner's block processing node decrypts the ciphertext EncK(Q) of the transaction information quadruple, obtains the plaintext transaction information quadruple, submits it to other nodes for consensus, and before the symmetric key K is disclosed.

[0094] After the transaction initiator selects several mining block processing nodes to submit a real transaction to the transaction pool's transaction waiting queue, they need to monitor whether the real transaction has entered the transaction pool's transaction waiting queue. If it is detected that the real transaction has not entered the transaction pool's transaction waiting queue within a set time, the mining block processing nodes need to be reselected to resubmit the real transaction to the transaction pool's transaction waiting queue, in order to prevent any mining block processing node from performing local calculations without submitting a transaction.

[0095] Once a real transaction enters the transaction pool's waiting queue, the transaction initiator can start a timer. After a fallback period ts, one or more miner block processing nodes will call the public symmetric function in the on-chain transaction disclosure contract to publicize the symmetric key K. The publicized symmetric key K can then be written into the transaction's transaction register.

[0096] In this embodiment, the extra reward for differentiated scheduling weights is only valid within the fallback time window ts. This provides a clear incentive for miner block processing nodes to participate in the competition. If they want to receive the extra reward and have priority in executing their transactions, they must successfully decrypt and package the transaction within the fallback time window ts. Once the timeout occurs, the scheduling weights revert to the normal level, the rewards for block processing nodes processing transactions according to the unified rules become invalid, and miners only receive the basic gas fees. This effectively guides the behavior of miner block processing nodes in the direction desired by the system. If a miner block processing node attempts to harm the initiator's interests through "delaying" tactics (e.g., waiting for a more suitable time to process the transaction or for a more favorable market price), the initiator can immediately end this stalemate by publicizing the symmetric key K, allowing the transaction to be completed. That is, by publicizing the symmetric key K after the fallback time window ts, it is ensured that regardless of the choice of the miner block processing node (cooperation or confrontation), the transaction will eventually be executed on the blockchain. Whether malicious miner block processing nodes collude to refuse decryption or attempt to delay indefinitely to find other attack opportunities, this mechanism ensures that the transaction initiator always retains the initiative to ultimately complete the transaction.

[0097] In step S170, within the fallback time, the miner block processing node obtains the transaction hash value, transaction signature, transaction information quadruple ciphertext, and verifiable delay function result ciphertext based on the transaction registration table, decrypts the transaction information quadruple ciphertext and verifiable delay function result ciphertext, and initiates block production consensus with other miner block processing nodes on the chain to obtain additional rewards and prioritize business execution.

[0098] This step is part of the transaction on-chain phase. The transaction initiator submits the transaction (including registration code, ciphertext of the transaction information quadruple, ciphertext of the verifiable delay function result, and fallback time) and additional rewards for differentiated scheduling to the transaction pool's transaction waiting queue through the miner block processing nodes. Each miner block processing node can then discover this transaction in the transaction pool's transaction waiting queue. Because this transaction has a higher scheduling priority than the Gas of ordinary business transactions compared to regular transaction parameters, and because miner block processing nodes cannot see the plaintext content of the transaction and cannot determine whether there is a conflict of interest, all miner block processing nodes will by default prioritize processing this transaction. Furthermore, to obtain the additional reward for priority access to business processing, miner block processing nodes will strive to decrypt the ciphertext EncK(Q) of the transaction information quadruple within the fallback time ts and initiate consensus first.

[0099] Specifically, refer to Figure 4 , Figure 4 This is a flowchart of the steps provided in one embodiment of the present application for a miner block processing node to obtain the transaction hash value and the registration code based on the transaction registration table within the catch-all time period, in order to decrypt the ciphertext of the transaction information quadruple and the ciphertext of the verifiable delay function result, including but not limited to steps S410 to S430.

[0100] In step S410, the miner block processing node obtains the transaction hash value and registration code based on the transaction registration table within the fallback time, and calculates the verifiable delay function result based on the transaction hash value, registration code, and the initialization parameter table of the transaction disclosure contract. Step S420: The miner block processing node performs inverse mask calculation based on the verifiable delay function result and the ciphertext of the verifiable delay function result to obtain the symmetric key; In step S430, the miner block processing node decrypts the ciphertext of the transaction information quadruple using the symmetric key to obtain the plaintext of the transaction information quadruple.

[0101] In this embodiment, the miner block processing node queries and obtains the corresponding transaction hash value (HashQ) and registration code (RegID) from the on-chain transaction registration table, reads the VDF algorithm parameters from the initialization parameter table in the transaction disclosure contract, and calculates the VDF result using (HashQ||RegID) as the input of the VDF function (formula). Then, based on the VDF result y and the ciphertext SK(y) of the verifiable delay function result in the transaction registration table, an inverse mask calculation is performed to obtain the symmetric key K. Taking the mask algorithm as addition SKy=K+y as an example, the inverse addition operation can be performed, i.e., K=SK(y)-y, to obtain the symmetric key K. The obtained symmetric key K is then used to decrypt the ciphertext EncK(Q) of the transaction information quadruple to obtain the plaintext of the transaction information quadruple. Here, the VDF calculation ensures that attackers cannot instantly complete transaction copying; only the miner block processing node that successfully decrypts and uploads the transaction first can obtain the additional reward and priority execution rights.

[0102] After receiving the decrypted transaction information quadruple in plaintext, the mining block processing node processes the transaction according to the standard blockchain process. This means the mining block processing node needs to submit a proposal containing the transaction information quadruple in plaintext, the VDF result, and a mathematical proof to other mining block processing nodes in the network. Upon receiving the proposal, other mining block processing nodes will verify the proof π (i.e., confirm that the VDF calculation was indeed performed correctly) and verify the consistency between the transaction content and the registration record. Once a majority of mining block processing nodes in the network have verified the transaction, it can be officially included in a new block.

[0103] In some embodiments, if a transaction has entered the transaction pool's waiting queue and has not yet been recorded on the blockchain after a grace period, the transaction initiator will publish the symmetric key K in the transaction disclosure contract. At this point, the mining block processing node does not need to recalculate the VDF result; it only needs to directly decrypt the ciphertext of the transaction information quadruple based on the published symmetric key K to obtain the plaintext transaction information quadruple, and then process the transaction according to the standard blockchain process. Since the symmetric key K is now public, any mining block processing node can decrypt the transaction, therefore, the mining block processing node can only execute the processing according to regular business rules and can only receive normal transaction fees. Thus, even without mining block processing nodes competing to decrypt, the transaction initiator can ensure the transaction is executed by publishing the symmetric key K.

[0104] In this embodiment, all miner block processing nodes operate in accordance with the platform's maintenance rules to ensure the orderly operation of the overall business. All nodes are economically rational agents pursuing maximum profit; malicious delays by a single miner block processing node cannot prevent other miner block processing nodes from competing for business processing rights. This competitive and collaborative scheduling mechanism ensures that even with the presence of some malicious miner block processing nodes, transactions can still be processed in a timely manner, maintaining the system's activity and fairness.

[0105] As mentioned above, the blockchain transaction disclosure scheme provided in this application includes four stages (initialization stage, transaction initiation and registration stage, transaction submission stage, and transaction on-chain stage). The initialization stage only needs to be executed once. The transaction initiation and registration stage is initiated by the transaction initiator, who creates a transaction locally and calls the request challenge function of the transaction disclosure contract for registration. In the transaction submission stage, the transaction initiator calculates the VDF result locally, encrypts the VDF result using a key mask, and then sends the encrypted transaction content along with an additional reward to the node for priority execution, placing it in the transaction pool's transaction waiting queue. The transaction on-chain stage is executed by the miner block processing node, which sequentially completes the VDF solution, decryption, and on-chain processing for the transactions in the transaction pool's transaction waiting queue, competing for priority execution rights to solve the VDF problem, decrypt, and add the transaction to the block to obtain the additional reward. For details, please refer to... Figure 5 , Figure 5 This is a schematic diagram of the overall interactive architecture and process flow of the system provided in an embodiment of this application.

[0106] In this embodiment, when submitting a real transaction to the transaction pool's waiting queue, the transaction initiator must simultaneously submit the VDF result. The VDF result requires continuous, non-parallel computation, which introduces a predetermined time delay. This delay prevents any participant (including miner block processing nodes and attackers) from quickly calculating the result and constructing malicious transactions for preemptive attacks before the transaction is officially packaged into a block. Secondly, by encrypting the transaction information quadruple before submission, miner block processing nodes cannot predict the value of the transaction content, fundamentally eliminating censorship attacks by malicious miner block processing nodes. Providing additional rewards and setting scheduling weights simultaneously with transaction submission incentivizes on-chain miner block processing nodes to actively calculate the VDF and prioritize transaction processing, creating an orderly business processing environment and a competitive decryption environment. Furthermore, each transaction requires additional rewards exceeding normal costs and resource allocation requirements higher than standard standards, significantly increasing the economic burden of malicious attacks and raising the resource consumption threshold for malicious operations. This effectively limits the risk of DoS (Denial of Service) attacks caused by excessive transaction issuance.

[0107] This application also provides an electronic device, which includes a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement the above-described method. This electronic device can be any smart terminal, including tablet computers, in-vehicle computers, etc.

[0108] Please see Figure 6 , Figure 6 This is a schematic diagram of the hardware structure of an electronic device provided in an embodiment of this application. The electronic device includes: The processor 601 can be implemented using a general-purpose CPU (Central Processing Unit), microprocessor, application-specific integrated circuit (ASIC), or one or more integrated circuits, and is used to execute relevant programs to implement the technical solutions provided in the embodiments of this application. The memory 602 can be implemented as a read-only memory (ROM), a static storage device, a dynamic storage device, or a random access memory (RAM). The memory 602 can store the operating system and other applications. When the technical solutions provided in the embodiments of this specification are implemented through software or firmware, the relevant program code is stored in the memory 602 and is called and executed by the processor 601. The input / output interface 603 is used to implement information input and output; The communication interface 604 is used to enable communication and interaction between this device and other devices. Communication can be achieved through wired means (such as USB, network cable, etc.) or wireless means (such as mobile network, WIFI, Bluetooth, etc.). Bus 605 transmits information between various components of the device (e.g., processor 601, memory 602, input / output interface 603, and communication interface 605); The processor 601, memory 602, input / output interface 603, and communication interface 604 are connected to each other within the device via bus 605.

[0109] This application also provides a storage medium, which is a computer-readable storage medium, storing a computer program that, when executed by a processor, implements the above-described method.

[0110] Memory, as a non-transitory computer-readable storage medium, can be used to store non-transitory software programs and non-transitory computer-executable programs. Furthermore, memory may include high-speed random access memory, and may also include non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some embodiments, memory may optionally include memory remotely located relative to the processor, and these remote memories can be connected to the processor via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

[0111] The embodiments described in this application are for the purpose of more clearly illustrating the technical solutions of the embodiments of this application, and do not constitute a limitation on the technical solutions provided by the embodiments of this application. As those skilled in the art will know, with the evolution of technology and the emergence of new application scenarios, the technical solutions provided by the embodiments of this application are also applicable to similar technical problems.

[0112] Those skilled in the art will understand that the technical solutions shown in the figures do not constitute a limitation on the embodiments of this application, and may include more or fewer steps than shown, or combine certain steps, or different steps.

[0113] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs.

[0114] Those skilled in the art will understand that all or some of the steps in the methods disclosed above, as well as the functional modules / units in the systems and devices, can be implemented as software, firmware, hardware, or suitable combinations thereof.

[0115] The terms “first,” “second,” “third,” “fourth,” etc. (if present) in the specification and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms “comprising” and “having,” and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0116] It should be understood that in this application, "at least one (item)" means one or more, and "more than" means two or more. "And / or" is used to describe the relationship between related objects, indicating that three relationships can exist. For example, "A and / or B" can represent three cases: only A exists, only B exists, and both A and B exist simultaneously, where A and B can be singular or plural. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. "At least one (item) of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one (item) of a, b, or c can represent: a, b, c, "a and b", "a and c", "b and c", or "a and b and c", where a, b, and c can be single or multiple.

[0117] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of the units described above is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0118] The units described above as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0119] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0120] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes multiple instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing programs, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0121] The preferred embodiments of the present application have been described above with reference to the accompanying drawings, but this does not limit the scope of the claims of the present application. Any modifications, equivalent substitutions, and improvements made by those skilled in the art without departing from the scope and substance of the embodiments of the present application shall be within the scope of the claims of the present application.

Claims

1. A blockchain transaction disclosure method applicable to consortium blockchains and private blockchains, characterized in that, The method includes: Each node deploys a transaction disclosure contract on the blockchain. The transaction disclosure contract includes a request challenge function, an initialization parameter table, and a transaction registration table. Each node confirms the verifiable delay function algorithm parameters and writes the confirmed verifiable delay function algorithm parameters into the initialization parameter table. The verifiable delay function algorithm parameters include verifiable delay function calculation parameters, verifiable delay function calculation duration, and security algorithm parameters. The transaction initiator generates a transaction information quadruple based on the locally generated transaction content, generates a corresponding transaction hash value from the transaction information quadruple, and generates a corresponding transaction signature from the transaction hash value using a private key. Then, the initiator sends a transaction registration request to the blockchain. The transaction information quadruple includes the function name called, the on-chain address of the transaction initiator, the destination address, and the transaction parameters. After receiving the transaction registration request, the block processing node on the chain calls the request challenge function in the transaction disclosure contract to verify the transaction hash value and the transaction signature, completes the registration, generates a registration code, and writes the registration code, the transaction hash value, and the transaction signature into the transaction registration table; After registration is completed, the transaction initiator calculates the verifiable delay function result based on the transaction hash value, the registration code, and the initialization parameter table of the transaction disclosure contract, and encrypts the transaction information quadruple and the verifiable delay function result. The transaction initiator selects several block processing nodes to submit real transactions to the transaction waiting queue and sets a scheduling weight higher than the normal business resource consumption standard. The real transaction includes the registration code, the transaction information quadruple ciphertext, the verifiable delay function result ciphertext, and the fallback time, which is the maximum on-chain time that the transaction initiator can tolerate. The block processing node obtains the transaction hash value and the registration code based on the transaction registration table within the fallback time, decrypts the ciphertext of the transaction information quadruple and the ciphertext of the verifiable delay function result, and initiates block production consensus with other block processing nodes on the chain to prioritize the execution of business processing.

2. The method according to claim 1, characterized in that, The method further includes: The calculation duration of the verifiable delay function is determined based on the block time of the blockchain, wherein the calculation duration of the verifiable delay function is less than the block time, and the difference between the calculation duration of the verifiable delay function and the block time is less than a preset duration.

3. The method according to claim 1, characterized in that, After receiving the transaction registration request, the on-chain block processing node calls the request challenge function in the transaction disclosure contract to verify the transaction hash value and the transaction signature, including: After receiving the transaction registration request, the on-chain block processing node obtains the corresponding public key from the on-chain address of the transaction initiator; The request challenge function in the transaction disclosure contract is invoked, and the public key, the transaction hash value, and the transaction signature are used to perform calculations to check whether the transaction signature is generated by signing the transaction hash value with the private key corresponding to the public key.

4. The method according to claim 1, characterized in that, The transaction initiator encrypts the transaction information quadruple and the verifiable delay function result, including: The transaction initiator generates a symmetric key locally; The transaction initiator encrypts the transaction information quadruple based on the symmetric key to obtain the ciphertext of the transaction information quadruple. The transaction initiator performs reversible masking on the verifiable delay function result based on the symmetric key to obtain the ciphertext of the verifiable delay function result.

5. The method according to claim 4, characterized in that, The block processing node obtains the transaction hash value and the registration code based on the transaction registration table within the fallback time period, in order to decrypt the ciphertext of the transaction information quadruple and the ciphertext of the verifiable delay function result, including: The block processing node obtains the transaction hash value and the registration code based on the transaction registration table within the fallback time period, and calculates the verifiable delay function result according to the transaction hash value, the registration code, and the initialization parameter table of the transaction disclosure contract; The block processing node performs inverse mask calculation based on the verifiable delay function result and the ciphertext of the verifiable delay function result to obtain the symmetric key; The block processing node decrypts the ciphertext of the transaction information quadruple using the symmetric key to obtain the plaintext of the transaction information quadruple.

6. The method according to claim 1, characterized in that, After the transaction initiator selects several block processing nodes to submit the actual transaction to the transaction waiting queue, the method further includes: The transaction initiator monitors whether the real transaction has entered the transaction waiting queue; If it is detected that the real transaction has not entered the transaction waiting queue within a set time, the transaction initiator will reselect a block processing node to submit the real transaction to the transaction waiting queue again.

7. The method according to claim 1 or 6, characterized in that, The transaction disclosure contract also includes a public symmetric key function. After the transaction initiator selects several block processing nodes to submit the real transaction to the transaction waiting queue, the method further includes: The timer starts after the real transaction enters the transaction waiting queue, and after the fallback period, the transaction initiator calls the public symmetric function in the transaction disclosure contract on the chain through one or more block processing nodes to publicize the symmetric key.

8. The method according to claim 7, characterized in that, When a block processing node discovers that the actual transaction has not yet been successfully uploaded to the blockchain, but the symmetric key has been made public, the method includes: The block processing node decrypts the ciphertext of the transaction information quadruple using the symmetric key and initiates block production consensus with other block processing nodes on the chain.

9. The method according to claim 1, characterized in that, Before the transaction initiator generates the transaction information quadruple based on the locally generated transaction content, the method further includes: The transaction initiator generates a public-private key pair locally and publishes the public key to generate an external account address on the blockchain. The external account address is the on-chain address of the transaction initiator.

10. An electronic device, characterized in that, The electronic device includes a memory and a processor, the memory storing a computer program, and the processor executing the computer program to implement the method according to any one of claims 1 to 9.

Images