Timestamp proof method, device and system in blockchain proof of stake consensus system

Abstract

The application discloses a timestamp proof method, device and system in a blockchain proof-of-stake consensus system, and the method comprises the following steps: a relay node starts to execute serial computation of a verifiable delay function to obtain a current output state value when a time slot of a new round of consensus is started, and synchronously increases a clock count value; when a valid bid of a builder arrives, a binding record is generated according to the current output state value, the current clock count value and a block header digest; when a block header acquisition request of a proposer is received, a timestamp receipt is generated according to a target block header corresponding to a target bid and the binding record, and the timestamp receipt is returned to the proposer, so that the proposer sends block header confirmation information to the relay node after local pre-verification is passed; and after receiving valid block header confirmation information, a complete block is sent to the proposer, so that the proposer broadcasts to a verification node for complete block consensus voting by the verification node. The application can realize timestamp proof without relying on centralized hardware.

Description

Technical Field

[0001] The embodiments of the present invention relate to the fields of blockchain and cryptographic security technology, and in particular to a timestamp proof method, apparatus and system in a blockchain proof-of-stake consensus system. Background Technology

[0002] With the development of the Maximum Extractable Value (MEV) ecosystem, the Proposer-Builder Separation (PBS) mechanism has been gradually applied to Proof-of-Stake (PoS) blockchain systems. Under this mechanism, builders continuously submit block bids to relay nodes, while proposers request higher-yielding block headers from relay nodes. However, rational proposers might deliberately delay their requests to wait for higher-value block bids, thereby gaining additional MEV rewards. This type of time-game behavior essentially involves nodes exploiting the asynchronous propagation characteristics and latency uncertainties of the network dynamics environment. To reduce the operational space of time-games, a reliable logical time measurement mechanism that does not rely on centralized hardware is urgently needed to implement timestamp proof in Proof-of-Stake blockchains.

[0003] The background section described above is merely a description made by the inventor based on his understanding, and the above content should not be regarded as evidence of prior art disclosed before the filing date of this application. Summary of the Invention

[0004] This invention provides a timestamp proof method in a blockchain proof-of-stake consensus system, enabling timestamp proof in a proof-of-stake blockchain that does not rely on centralized hardware. This method is applied to relay nodes in a proof-of-stake blockchain system, which also includes builders, proposers, and verification nodes. When the time slot for a new round of consensus is opened, a serial calculation of a verifiable delay function is initiated to obtain the current output state value, and the clock count value is incremented synchronously. The serial calculation is not interrupted or reset due to the arrival of a bid. When a valid bid sent by the builder arrives, a binding record is generated based on the captured current output status value, the captured current clock count value, and the block header digest corresponding to the bid. When a block header retrieval request is received from the proposer, the target bid with the highest yield is selected from the valid bids received. Based on the target block header and binding record corresponding to the target bid, a timestamp receipt is generated and returned to the proposer along with the target block header. This allows the proposer to perform local pre-verification and then send the block header confirmation information to the relay node. After receiving a valid block header confirmation, the complete block is sent to the proposer so that the proposer can broadcast the target block header, timestamp receipt, and complete block to the validator nodes for consensus voting on the complete block.

[0005] Another aspect of the present invention provides a timestamp proof device in a blockchain proof-of-stake consensus system, which enables timestamp proof of proof-of-stake blockchain without relying on centralized hardware. This device is applied to a relay node in the proof-of-stake blockchain system, which further includes builders, proposers, and validators, comprising: The serial calculation module is used to start the serial calculation of the verifiable delay function to obtain the current output status value when the time slot of the new round of consensus is opened, and to synchronously increment the clock count value. The serial calculation is not interrupted or reset due to the arrival of the bid. The binding record generation module is used to generate a binding record when a valid bid sent by the builder arrives, based on the captured current output status value, the captured current clock count value, and the block header digest corresponding to the bid. The timestamp receipt generation module is used to select the highest-yielding target bid from the received valid bids when it receives a block header retrieval request from the proposer. Based on the target block header and binding record corresponding to the target bid, it generates a timestamp receipt and returns the timestamp receipt and the target block header to the proposer so that the proposer can perform local pre-verification and send the block header confirmation information to the relay node. The voting module is used to send the complete block to the proposer after receiving a valid block header confirmation message, so that the proposer can broadcast the target block header, timestamp receipt and complete block to the validator nodes for the validator nodes to vote on the complete block consensus.

[0006] Another aspect of the present invention provides a timestamp proof system in a blockchain proof-of-stake consensus system, which can realize timestamp proof of proof-of-stake blockchain without relying on centralized hardware. The system is applied to a proof-of-stake blockchain system, including relay nodes, builders, proposers and verification nodes. The relay node is used for: When the time slot for a new round of consensus is opened, a serial calculation of a verifiable delay function is initiated to obtain the current output state value, and the clock count value is incremented synchronously. The serial calculation is not interrupted or reset due to the arrival of a bid. When a valid bid sent by the builder arrives, a binding record is generated based on the captured current output status value, the captured current clock count value, and the block header digest corresponding to the bid. When a block header retrieval request is received from a proposer, the target bid with the highest yield is selected from the valid bids received. Based on the target block header and binding record corresponding to the target bid, a timestamp receipt is generated and returned to the proposer along with the target block header. After receiving a valid block header confirmation, the complete block is sent to the proposer. The proposer is used to: after local pre-verification of the timestamp receipt and the target block header, send the block header confirmation information to the relay node; and after receiving the complete block, broadcast the target block header, timestamp receipt, and complete block to the verification node. The verification node is used to: verify and vote on the complete block consensus after receiving the target block header, timestamp receipt and complete block broadcast by the proposer.

[0007] This invention also provides a computer device, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements the timestamp proof method in the blockchain proof-of-stake consensus system described above.

[0008] This invention also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the timestamp proof method in the blockchain proof-of-stake consensus system described above.

[0009] This invention also provides a computer program product, which includes a computer program that, when executed by a processor, implements the timestamp proof method in the blockchain proof-of-stake consensus system described above.

[0010] In this embodiment of the invention, by initiating the serial computation of a verifiable delay function and synchronously incrementing the clock count when the time slot opens, a background VDF clock is achieved that does not rely on an external centralized clock source or trusted time server. This clock records the instantaneous state formed by the current output state value and the current clock count value. Its evolution is guaranteed by the serial computation steps of the verifiable delay function itself and is not affected by network synchronization protocols or physical clock deviations. Thus, in an untrusted proof-of-stake blockchain network environment, a cryptographic time reference independent of network latency is provided for timestamp proof. By capturing the current output state value and the current clock count value and generating a binding record when a valid bid is received, each asynchronously arriving bid is bound to the instantaneous state of the background cryptographic clock. Since this binding record contains the current output state value and clock count value of the verifiable delay function, and the clock count value represents the number of serial computation steps from the opening of the time slot to the arrival of the bid, this binding record can serve as unforgeable cryptographic evidence of the actual arrival time of the bid at the relay node, achieving accurate capture and anchoring of discrete network events on a continuous time axis. The relay node selects the highest-yielding target bid from multiple bids with bound timestamps and generates a corresponding timestamp receipt only upon receiving a block header retrieval request from the proposer. This process ensures that the proposer cannot extend the observation window of candidate bids by intentionally delaying the sending of block header retrieval requests. Because each bid is assigned an immutable timestamp by the background cryptographic clock upon arrival, the timestamp record of the arrived bid is never changed by the proposer's request, thus eliminating the proposer's operational space to exploit network latency uncertainty to obtain additional maximum extractable value, enhancing the fairness and security of the consensus process. By generating a timestamp receipt containing timestamp information and returning it to the proposer along with the target block header, the timestamp receipt can be broadcast to the validator nodes along with the complete block, allowing the validator nodes to independently and publicly verify it during subsequent consensus voting. This mechanism transfers the verification of timestamp proofs from centralized relay nodes to a distributed set of validator nodes, conforming to the decentralized trust model of proof-of-stake blockchain systems, without introducing an additional trusted third party. The proposed timestamp proof method operates entirely on the relay node side, without introducing structural changes to the interaction process between builders, proposers, and validators. Builders still submit bids in the original way, proposers still initiate block header retrieval requests in the original way, and validators still participate in consensus voting in the original way. Therefore, this method can be smoothly deployed on the existing proposer-builder separation architecture without requiring large-scale modifications to the underlying consensus protocol of the blockchain system, demonstrating good engineering compatibility and practical application prospects. Attached Figure Description

[0011] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort. In the drawings: Figure 1 This is a flowchart of the timestamp proof method in the blockchain proof-of-stake consensus system according to an embodiment of the present invention; Figure 2 This is a flowchart illustrating the principle of the method from the perspective of the VDF clock in the relay node's backend, as described in this embodiment of the invention. Figure 3 This is a flowchart of the time validity verification in an embodiment of the present invention; Figure 4 This is a schematic diagram of the timestamp proof method in the blockchain proof-of-stake consensus system according to an embodiment of the present invention; Figure 5 This is a structural diagram of the timestamp proof device in the blockchain proof-of-stake consensus system according to an embodiment of the present invention; Figure 6 This is a structural diagram of the timestamp proof system in the blockchain proof-of-stake consensus system according to an embodiment of the present invention; Figure 7 This is a schematic diagram of a computer device in an embodiment of the present invention. Detailed Implementation

[0012] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the embodiments of the present invention will be further described in detail below with reference to the accompanying drawings. Here, the illustrative embodiments of the present invention and their descriptions are used to explain the present invention, but are not intended to limit the present invention.

[0013] This invention proposes a PoS timestamp proof method based on a verifiable delay function (VDF) oriented towards network dynamics. By introducing a uniformly evolving "background cryptographic clock" (also known as a background VDF clock, recording the instantaneous state formed by the current output state value and the current clock count value) into the untrusted network, discrete arriving bids in the network are decoupled from the continuous time axis, thus capturing the actual arrival time of the bids. The timestamp verification complexity is constant. Without changing the basic process of the existing PBS architecture, a block timestamp proof mechanism is implemented, providing the time verifiability of blocks.

[0014] First, the meanings of the symbols involved in the embodiments of this invention will be explained: Time slot number; Time slot The groove anchor point; : The identifier of the relay node; RSA module; : The RSA group defined by the RSA modulus N; System publicly available parameters; Collision-resistant hash function; : A hash function that maps the input to the RSA group or VDF input domain; : A hash function used to generate the challenging prime numbers for VDF proofs; The initial input of the VDF with a fixed time slot is called the initial input value; : The current output status value of the background VDF clock; : The current output state value captured when the i-th bid arrives; : The current clock count value captured when the i-th bid arrives; : The block header corresponding to the i-th bid; Block header The block header summary; : The independent binding record corresponding to the i-th bid; : The index of the target bid selected by the relay node; The block header corresponding to the selected target bid; The selected target bid's VDF proof contains the challenging prime number; : VDF proof corresponding to the selected target bid; : The timestamped receipt corresponding to the selected target bid; BLS signature; The relay's signature private key; The relay's signature public key; The maximum latency threshold allowed by the system for a block; BLS signature generation algorithm; BLS signature verification algorithm.

[0015] Figure 1 This is a flowchart of the timestamp proof method in the blockchain proof-of-stake consensus system according to an embodiment of the present invention, such as... Figure 1 As shown, this method is applied to relay nodes in a proof-of-stake blockchain system, which also includes builders, proposers, and validators, including: Step 101: When the time slot for a new round of consensus is opened, start the serial calculation of the verifiable delay function to obtain the current output state value, and synchronously increment the clock count value. The serial calculation is not interrupted or reset due to the arrival of the bid. Step 102: When a valid bid sent by the builder arrives, a binding record is generated based on the captured current output status value, the captured current clock count value, and the block header digest corresponding to the bid. Step 103: When a block header retrieval request is received from the proposer, the target bid with the highest profit is selected from the valid bids received. Based on the target block header and binding record corresponding to the target bid, a timestamp receipt is generated and returned to the proposer along with the target block header. This allows the proposer to perform local pre-verification and then send the block header confirmation information to the relay node. Step 104: After receiving a valid block header confirmation, send the complete block to the proposer so that the proposer can broadcast the target block header, timestamp receipt and complete block to the validator nodes for the validator nodes to vote on the complete block consensus.

[0016] Depend on Figure 1As illustrated in the process, in this embodiment of the invention, by initiating the serial computation of the verifiable delay function and synchronously incrementing the clock count when the time slot opens, a background VDF clock is achieved that does not rely on an external centralized clock source or trusted time server. This clock records the instantaneous state formed by the current output state value and the current clock count value. Its evolution is guaranteed by the serial computation steps of the verifiable delay function itself and is not affected by network synchronization protocols or physical clock deviations. Thus, in an untrusted proof-of-stake blockchain network environment, this provides a cryptographic time reference for timestamp proof that is independent of network latency. By capturing the current output state value and the current clock count value and generating a binding record when a valid bid is received, each asynchronously arriving bid is bound to the instantaneous state of the background cryptographic clock. Since this binding record contains the current output state value and clock count value of the verifiable delay function, and the clock count value represents the number of serial computation steps taken from the opening of the time slot to the arrival of the bid, this binding record can serve as unforgeable cryptographic evidence of the actual arrival time of the bid at the relay node, achieving accurate capture and anchoring of discrete network events on a continuous time axis. The relay node selects the highest-yielding target bid from multiple bids with bound timestamps and generates a corresponding timestamp receipt only upon receiving a block header retrieval request from the proposer. This process ensures that the proposer cannot extend the observation window of candidate bids by intentionally delaying the sending of block header retrieval requests. Because each bid is assigned an immutable timestamp by the background cryptographic clock upon arrival, the timestamp record of the arrived bid is never changed by the proposer's request, thus eliminating the proposer's operational space to exploit network latency uncertainty to obtain additional maximum extractable value, enhancing the fairness and security of the consensus process. By generating a timestamp receipt containing timestamp information and returning it to the proposer along with the target block header, the timestamp receipt can be broadcast to the validator nodes along with the complete block, allowing the validator nodes to independently and publicly verify it during subsequent consensus voting. This mechanism transfers the verification of timestamp proofs from centralized relay nodes to a distributed set of validator nodes, conforming to the decentralized trust model of proof-of-stake blockchain systems, without introducing an additional trusted third party. The proposed timestamp proof method operates entirely on the relay node side, without introducing structural changes to the interaction process between builders, proposers, and validators. Builders still submit bids in the original way, proposers still initiate block header retrieval requests in the original way, and validators still participate in consensus voting in the original way. Therefore, this method can be smoothly deployed on the existing proposer-builder separation architecture without requiring large-scale modifications to the underlying consensus protocol of the blockchain system, demonstrating good engineering compatibility and practical application prospects.

[0017] The method proposed in this invention is applied to a PoS blockchain system using the PBS architecture, which includes four types of entities: builders, relay nodes, proposers, and validators.

[0018] 1) Builder: Monitors the transaction flow to construct candidate blocks and submits bids containing block headers and revenue information to relay nodes.

[0019] 2) Relay Node: Receives and verifies bids. Specifically, the relay node maintains a background VDF clock that evolves in fixed steps locally. When a valid bid arrives, it takes a state snapshot of the bid (based on the current output state value and the current clock count value) and generates an independent binding record. When responding to the proposer's block header retrieval request, it returns the target block header of the highest-yielding target bid and the corresponding timestamp receipt.

[0020] 3) Proposer: Initiates a request to retrieve the block header to the relay node within its assigned time slot. It receives the target block header and timestamp receipt corresponding to the target bid, and broadcasts the complete block to the entire network.

[0021] 4) Validator: Receives the block and the attached timestamp receipt, performs public validation to determine whether the block's proposal timing meets the system deadline constraint.

[0022] In network dynamics models, the process of a builder submitting a bid to a relay node is considered a set of network events that arrive dynamically over time. Due to factors such as network propagation delay, node processing capacity, differences in private order flows, and builder bidding strategies, the arrival time of different bids at the relay is uncertain. A rational proposer might exploit this uncertainty by deliberately delaying the request for the block header to expand the candidate bid observation window and obtain higher MEV (Mean Economic Value) gains. This invention does not attempt to eliminate network latency, but rather uses a continuous background VDF (Virtual Data Provider) clock to perform cryptographic snapshots and public verification of bid arrival times, thereby providing a technical basis for determining whether the block header has been observed by the relay within the allowed time window.

[0023] Proof-of-Stake (PoS) blockchain systems can operate in a synchronous network environment. PoS blockchain systems operate using a slot mechanism.

[0024] This embodiment of the invention assumes that the relay is an honest entity and models the proposer as a rational adversary seeking to maximize its gains. This adversary might intentionally delay obtaining the block header. Expand the candidate bidding observation window to wait for higher yield block heads. Assume that the rational adversary has the following capabilities: (1) cannot break the security of the underlying digital signature scheme, hash function and VDF proof system; (2) can listen to, replay or tamper with network messages within its control and may attempt to forge, replace or reuse timestamp receipts; (3) can control some validator nodes, and the total staked equity controlled by them does not exceed one-third of the total staked amount of the underlying PoS system.

[0025] Figure 2 This is a flowchart illustrating the principle of the method from the perspective of the VDF clock in the relay node's backend, as described in this embodiment of the invention. Figure 1 and Figure 2 The method proposed in the embodiments of the present invention will be described in detail below.

[0026] Step 101: When the time slot for a new round of consensus is opened, start the serial calculation of the verifiable delay function to obtain the current output state value, and synchronously increment the clock count value. The serial calculation is not interrupted or reset due to the arrival of the bid. In one embodiment, when a new consensus time slot opens, a serial computation of a verifiable delay function is initiated to obtain the current output state value, including: When a new consensus time slot is opened, the clock count value is initialized to zero. Based on the slot anchor point of the time slot and the identifier of the relay node, the initial input value of the verifiable delay function of the time slot is calculated. Use the initial input value as the initial output state value, start the execution of the verifiable delay function, and obtain the initial output state value; Using the initial output state value as the current output state value, the serial calculation of the verifiable delay function is continuously executed at a constant pace during the duration of the time slot. In each step of the serial calculation, the current output state value of the verifiable delay function is updated to the result of taking the square of the current output state value modulo a preset RSA modulus.

[0027] In the above embodiments, see Figure 2 During the initialization phase of the proof-of-stake blockchain system, public parameters are generated. .in, Represents the RSA group. Represents the RSA modulus. For ordinary collision-resistant hash functions, It maps the input to hash function, A hash function is used to generate challenging prime numbers in VDF proofs. Furthermore, this invention introduces slot anchors. As a time slot The publicly available reference value is used to determine the initial state of the current time slot background VDF clock. Initial slot anchor point. It can be determined by a public random beacon, genesis configuration, or a public random value negotiated by multiple parties.

[0028] In the time slot Initially, the relay node sets the clock count value. Based on the slot anchor point and relay node identifier Generate the initial input value x for the current time slot. Then set the current initial output state value .

[0029] In the time slot During this period, the relay node continuously performs VDF calculations. And synchronously increment the clock count. .

[0030] Step 102: When a valid bid sent by the builder arrives, a binding record is generated based on the captured current output status value, the captured current clock count value, and the block header digest corresponding to the bid. The builder monitors the transaction pool in real time, constructs candidate blocks, and asynchronously sends blocks containing headers to the relay nodes. Bidding for revenue figures.

[0031] When a relay node receives a valid bid submitted by a builder, it records the block header corresponding to that bid as... The relay node immediately obtains the current background VDF status. This represents the current output state value of the verifiable delay function captured when the bid arrives. The current clock count value captured when the bid arrives. .

[0032] In one embodiment, a binding record is generated based on the captured current output status value, the captured current clock count value, and the block header digest corresponding to the bid, including: The block header corresponding to the bid is used as the first block header, and the hash digest of the first block header is calculated as the block header digest; A clock state snapshot is formed by taking the initial input value of the verifiable delay function, the current output state value of the verifiable delay function captured when the bid arrives, and the current clock count value captured when the bid arrives. The clock state snapshot is bound to the block header digest to generate a binding record.

[0033] In the above embodiments, the calculated block header digest can be represented as:

[0034] A binding record can be represented as: , in, It is the fixed initial input of the VDF within the current time slot, that is, the initial input value of the verifiable delay function. and These represent the current output status value and the current clock count value corresponding to the background VDF clock when the bid arrives, respectively.

[0035] In step 103, when a block header retrieval request is received from the proposer, the target bid with the highest profit is selected from the received valid bids. Based on the target block header and binding record corresponding to the target bid, a timestamp receipt is generated and returned to the proposer along with the target block header. This allows the proposer to perform local pre-verification and then send the block header confirmation information to the relay node. When a relay node receives a block header retrieval request from a proposer At that time, lock in the bid with the highest current return, and denote its index as... .

[0036] In one embodiment, a timestamp receipt is generated based on the target block header and binding record corresponding to the target bid, including: Generate a verifiable delay function proof for the binding record corresponding to the target bid; Based on the target block header, binding record, and verifiable delay function proof corresponding to the target bid, a timestamp receipt is generated using a digital signature.

[0037] In one embodiment, generating a verifiable delay function proof for the binding record corresponding to the target bid includes: The challenge prime number of the target bid is calculated based on the initial input value of the verifiable delay function in the binding record corresponding to the target bid, the current output state value of the verifiable delay function captured when the bid arrives, and the current clock count value captured when the bid arrives. Based on the challenge prime number, the current clock count value, and the initial input value, a verifiable delay function proof value is calculated. This verifiable delay function proof value is used to indicate that the current output state value is obtained by serial calculation of the initial input value through clock count steps.

[0038] In the above embodiments, the challenging prime number can be represented as:

[0039] The verifiable proof of the delay function can be expressed as:

[0040] Verifiable delay function proof is used to show It is input through The output obtained from the VDF serial calculation.

[0041] In one embodiment, a timestamp receipt is generated using a digital signature based on the target block header, binding record, and verifiable delay function proof corresponding to the target bid, including: Using the relay node's private key, a digital signature is generated on the combination of the target block header, the binding record, and the verifiable delay function proof using the BLS signature generation algorithm; Construct a timestamp receipt based on the target block header, the binding record, the verifiable delay function proof, and the digital signature.

[0042] In the above embodiments, the relay node uses a private key. Sign the target block header, binding record, and VDF proof:

[0043] Then, an independent timestamp receipt is constructed:

[0044] The relay node will target block header and independent timestamped receipts Return to the proposer. After receiving a valid block header confirmation, send the complete block to the proposer.

[0045] In one embodiment, the step of performing local pre-validation includes: Using the public key of the relay node, the digital signature in the timestamp receipt is verified using the BLS signature verification algorithm to obtain the verification result.

[0046] The proposer receives the target block header returned by the relay node. and independent timestamped receipts Then, verify the digital signature. If the verification passes, a block header confirmation message is sent to the relay, followed by the block header... Independent timestamped receipts The received complete block is broadcast to the validator node.

[0047] In one embodiment, the steps of full block consensus voting include: Perform time validity verification on the received target block header and timestamp receipt; After the time validity verification is passed, a consensus vote is conducted on the complete block.

[0048] Figure 3 This is a flowchart of time validity verification in an embodiment of the present invention. In one embodiment, the steps of time validity verification include: The timestamp receipt is parsed to obtain the target block header, binding record, verifiable delay function proof and digital signature, and the initial input value, current output state value, current clock count value and block header digest are obtained from the binding record; Verify the parsed digital signature; if verification fails, reject the complete block. Verify whether the parsed block header digest matches the hash value of the target block header; if they do not match, reject the complete block. Verify whether the initial input value of the verifiable delay function is generated by the slot anchor point and relay identifier of the current time slot; otherwise, reject the complete block. The verifiable delay function proof is verified, and if the verification fails, the complete block is rejected. Verify whether the clock count value in the timestamp receipt is less than or equal to the maximum delay threshold allowed by the proof-of-stake blockchain system. If it is, the complete block is deemed valid; otherwise, the vote is rejected.

[0049] In the above embodiments, time validity verification includes the following categories: (1) Digital signature verification verify

[0050] If verification fails, the complete block is rejected.

[0051] (2) Block header binding relationship verification

[0052] Verify block header digest:

[0053] If the condition is not met, the complete block is rejected.

[0054] (3) Clock start point consistency verification

[0055] Verification can verify whether the initial input value of the delay function is generated by the slot anchor point and relay identifier of the current time slot:

[0056] If the condition is not met, the complete block is rejected.

[0057] (4) VDF proof verification

[0058] The verifiable delay function proof is verified, and if the verification fails, the complete block is rejected.

[0059] (5) Time boundary determination

[0060] Verify the clock count value in the timestamp receipt. Is it less than or equal to the maximum allowed latency threshold of the proof-of-stake blockchain system (e.g., a 12-second latency threshold corresponding to one time slot)? If all verifications pass, the complete block is deemed valid, a corresponding consensus vote is generated for the valid complete block, and broadcast to the entire network; otherwise, the vote is rejected.

[0061] In one embodiment, verifying the analytically verifiable delay function proof includes: Calculate the challenge prime number and intermediate value based on the initial input value, current output status value, and current clock count value of the received timestamp receipt; Check if the following equation is true; if yes, the verification passes; otherwise, the verification fails:

[0062] in, For an analytical, verifiable proof of the delay function, To challenge prime numbers, The median value. The initial input value for parsing, The current output state value is the parsed value. It is an RSA modulus.

[0063] In the above embodiments, the verification node calculates prime numbers. and median value :

[0064] Then check the proof equation: , If the condition is not met, the complete block is rejected.

[0065] In one embodiment, the method further includes: At the end of the current time slot, release the final verifiable delay function output state value and verifiable delay function proof for the current time slot; The output state value of the final verifiable delay function, the proof of the verifiable delay function, and the current time slot number are hashed to obtain the hash value. The hash value is used as the slot anchor point for the next time slot.

[0066] In the time slot At the end, the relay node releases the final verifiable delay function output state value for the current time slot. Its verifiable delay function proof The slot anchor point of the next time slot is defined as:

[0067] Figure 4 This is a schematic diagram of the timestamp proof method in the blockchain proof-of-stake consensus system of this invention. On the horizontal axis (time axis), the end anchor point of "time slot s-1" becomes the clock start point of "time slot s" after cryptographic transformation, ensuring that the clock continues unforgeably between slots. In the vertical relationship, the background VDF clock, as a "uniform speed reference frame" independent of network messages, forms a decoupled mapping with the randomly arriving bidding events below. No matter when a bid arrives due to network delay, the relay parser can immediately read the current clock state and assign it a unique timestamp, thereby eliminating the opportunity for proposers to manipulate the observation window and seize additional MEV benefits by deliberately delaying the request for block headers.

[0068] The "Request Block Header" action is located at the central hub of the process. It triggers the relay to select the best bid from multiple timestamped bids and generate a proof, which is then handed over to the verification node to determine whether the time boundary is compliant based on the clock reading (count value).

[0069] This invention also provides a timestamp proof device in a blockchain proof-of-stake consensus system, as described in the following embodiments. Since the principle by which this device solves the problem is similar to the timestamp proof method in a blockchain proof-of-stake consensus system, the implementation of this device can refer to the implementation of the timestamp proof method in a blockchain proof-of-stake consensus system; repeated details will not be elaborated further.

[0070] Figure 5 This is a structural diagram of the timestamp proof device in the blockchain proof-of-stake consensus system according to an embodiment of the present invention, as shown below. Figure 5 As shown, this device is used as a relay node in a proof-of-stake blockchain system, which also includes builders, proposers, and validators, including: The serial calculation module 501 is used to start the serial calculation of the verifiable delay function to obtain the current output status value when the time slot of the new round of consensus is opened, and synchronously increment the clock count value. The serial calculation is not interrupted or reset due to the arrival of the bid. The binding record generation module 502 is used to generate a binding record based on the captured current output status value, the captured current clock count value, and the block header digest corresponding to the bid when a valid bid sent by the builder arrives. The timestamp receipt generation module 503 is used to select the target bid with the highest profit from the received valid bids when it receives a block header retrieval request from the proposer. Based on the target block header and binding record corresponding to the target bid, it generates a timestamp receipt and returns the timestamp receipt and the target block header to the proposer so that the proposer can send the block header confirmation information to the relay node after passing the local pre-verification. The voting module 504 is used to send the complete block to the proposer after receiving a valid block header confirmation message, so that the proposer can broadcast the target block header, timestamp receipt and complete block to the validator nodes for the validator nodes to vote on the complete block consensus.

[0071] In one embodiment, the serial computing module is used for: When a new consensus time slot is opened, the clock count value is initialized to zero. Based on the slot anchor point of the time slot and the identifier of the relay node, the initial input value of the verifiable delay function of the time slot is calculated. Use the initial input value as the initial output state value, start the execution of the verifiable delay function, and obtain the initial output state value; Using the initial output state value as the current output state value, the serial calculation of the verifiable delay function is continuously executed at a constant pace during the duration of the time slot. In each step of the serial calculation, the current output state value of the verifiable delay function is updated to the result of taking the square of the current output state value modulo a preset RSA modulus.

[0072] In one embodiment, the binding record generation module is used for: The block header corresponding to the bid is used as the first block header, and the hash digest of the first block header is calculated as the block header digest; A clock state snapshot is formed by taking the initial input value of the verifiable delay function, the current output state value of the verifiable delay function captured when the bid arrives, and the current clock count value captured when the bid arrives. The clock state snapshot is bound to the block header digest to generate a binding record.

[0073] In one embodiment, the timestamp receipt generation module is used for: Generate a verifiable delay function proof for the binding record corresponding to the target bid; Based on the target block header, binding record, and verifiable delay function proof corresponding to the target bid, a timestamp receipt is generated using a digital signature.

[0074] In one embodiment, the timestamp receipt generation module is used for: The challenge prime number of the target bid is calculated based on the initial input value of the verifiable delay function in the binding record corresponding to the target bid, the current output state value of the verifiable delay function captured when the bid arrives, and the current clock count value captured when the bid arrives. Based on the challenge prime number, the current clock count value, and the initial input value, a verifiable delay function proof value is calculated. This verifiable delay function proof value is used to indicate that the current output state value is obtained by serial calculation of the initial input value through clock count steps.

[0075] In one embodiment, the timestamp receipt generation module is used for: Using the relay node's private key, a digital signature is generated on the combination of the target block header, the binding record, and the verifiable delay function proof using the BLS signature generation algorithm; Construct a timestamp receipt based on the target block header, the binding record, the verifiable delay function proof, and the digital signature.

[0076] In one embodiment, the step of performing local pre-validation includes: Using the public key of the relay node, the digital signature in the timestamp receipt is verified using the BLS signature verification algorithm to obtain the verification result.

[0077] In one embodiment, the steps of full block consensus voting include: Perform time validity verification on the received target block header and timestamp receipt; After the time validity verification is passed, a consensus vote is conducted on the complete block.

[0078] In one embodiment, the time validity verification step includes: The timestamp receipt is parsed to obtain the target block header, binding record, verifiable delay function proof and digital signature, and the initial input value, current output state value, current clock count value and block header digest are obtained from the binding record; Verify the parsed digital signature; if verification fails, reject the complete block. Verify whether the parsed block header digest matches the hash value of the target block header; if they do not match, reject the complete block. Verify whether the initial input value of the verifiable delay function is generated by the slot anchor point and relay identifier of the current time slot; otherwise, reject the complete block. The verifiable delay function proof is verified, and if the verification fails, the complete block is rejected. Verify whether the clock count value in the timestamp receipt is less than or equal to the maximum delay threshold allowed by the proof-of-stake blockchain system. If it is, the complete block is deemed valid; otherwise, the vote is rejected.

[0079] Verification of the analytical verifiable delay function proof includes: Calculate the challenge prime number and intermediate value based on the initial input value, current output status value, and current clock count value of the received timestamp receipt; Check if the following equation is true; if yes, the verification passes; otherwise, the verification fails:

[0080] in, For an analytical, verifiable proof of the delay function, To challenge prime numbers, The median value. The initial input value for parsing, The current output state value is the parsed value. It is an RSA modulus.

[0081] In one embodiment, the apparatus further includes a slot anchor point updating module, used for: At the end of the current time slot, release the final verifiable delay function output state value and verifiable delay function proof for the current time slot; The output state value of the final verifiable delay function, the proof of the verifiable delay function, and the current time slot number are hashed to obtain the hash value. The hash value is used as the slot anchor point for the next time slot.

[0082] Figure 6 This is a structural diagram of the timestamp proof system in the blockchain proof-of-stake consensus system according to an embodiment of the present invention, as shown below. Figure 6 As shown, the system is applied to a proof-of-stake blockchain system, including relay node 601, builder 602, proposer 603 and validator node 604; The relay node is used for: When the time slot for a new round of consensus is opened, a serial calculation of a verifiable delay function is initiated to obtain the current output state value, and the clock count value is incremented synchronously. The serial calculation is not interrupted or reset due to the arrival of a bid. When a valid bid sent by the builder arrives, a binding record is generated based on the captured current output status value, the captured current clock count value, and the block header digest corresponding to the bid. When a block header retrieval request is received from a proposer, the target bid with the highest yield is selected from the valid bids received. Based on the target block header and binding record corresponding to the target bid, a timestamp receipt is generated and returned to the proposer along with the target block header. After receiving a valid block header confirmation, the complete block is sent to the proposer. The proposer is used to: after local pre-verification of the timestamp receipt and the target block header, send the block header confirmation information to the relay node; and after receiving the complete block, broadcast the target block header, timestamp receipt, and complete block to the verification node. The verification node is used to: verify and vote on the complete block consensus after receiving the target block header, timestamp receipt and complete block broadcast by the proposer.

[0083] This invention also provides a computer device. Figure 7 This is a schematic diagram of a computer device in an embodiment of the present invention. The computer device 700 includes a memory 710, a processor 720, and a computer program 730 stored in the memory 710 and executable on the processor 720. When the processor 720 executes the computer program 730, it implements the timestamp proof method in a blockchain proof-of-stake consensus system.

[0084] This invention also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the timestamp proof method in the blockchain proof-of-stake consensus system described above.

[0085] This invention also provides a computer program product, which includes a computer program that, when executed by a processor, implements the timestamp proof method in the blockchain proof-of-stake consensus system described above.

[0086] In this embodiment of the invention, by initiating the serial computation of a verifiable delay function and synchronously incrementing the clock count when the time slot opens, a background VDF clock is achieved that does not rely on an external centralized clock source or trusted time server. This clock records the instantaneous state formed by the current output state value and the current clock count value. Its evolution is guaranteed by the serial computation steps of the verifiable delay function itself and is not affected by network synchronization protocols or physical clock deviations. Thus, in an untrusted proof-of-stake blockchain network environment, a cryptographic time reference independent of network latency is provided for timestamp proof. By capturing the current output state value and the current clock count value and generating a binding record when a valid bid is received, each asynchronously arriving bid is bound to the instantaneous state of the background cryptographic clock. Since this binding record contains the current output state value and clock count value of the verifiable delay function, and the clock count value represents the number of serial computation steps from the opening of the time slot to the arrival of the bid, this binding record can serve as unforgeable cryptographic evidence of the actual arrival time of the bid at the relay node, achieving accurate capture and anchoring of discrete network events on a continuous time axis. The relay node selects the highest-yielding target bid from multiple bids with bound timestamps and generates a corresponding timestamp receipt only upon receiving a block header retrieval request from the proposer. This process ensures that the proposer cannot extend the observation window of candidate bids by intentionally delaying the sending of block header retrieval requests. Because each bid is assigned an immutable timestamp by the background cryptographic clock upon arrival, the timestamp record of the arrived bid is never changed by the proposer's request, thus eliminating the proposer's operational space to exploit network latency uncertainty to obtain additional maximum extractable value, enhancing the fairness and security of the consensus process. By generating a timestamp receipt containing timestamp information and returning it to the proposer along with the target block header, the timestamp receipt can be broadcast to the validator nodes along with the complete block, allowing the validator nodes to independently and publicly verify it during subsequent consensus voting. This mechanism transfers the verification of timestamp proofs from centralized relay nodes to a distributed set of validator nodes, conforming to the decentralized trust model of proof-of-stake blockchain systems, without introducing an additional trusted third party. The proposed timestamp proof method operates entirely on the relay node side, without introducing structural changes to the interaction process between builders, proposers, and validators. Builders still submit bids in the original way, proposers still initiate block header retrieval requests in the original way, and validators still participate in consensus voting in the original way. Therefore, this method can be smoothly deployed on the existing proposer-builder separation architecture without requiring large-scale modifications to the underlying consensus protocol of the blockchain system, demonstrating good engineering compatibility and practical application prospects.

[0087] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0088] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0089] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0090] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0091] The specific embodiments described above further illustrate the purpose, technical solution, and beneficial effects of the present invention. It should be understood that the above descriptions are merely specific embodiments of the present invention and are not intended to limit the scope of protection of the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A timestamp proof method in a blockchain proof-of-stake consensus system, characterized in that, Relay nodes are used in proof-of-stake blockchain systems, which also include builders, proposers, and validators, including: When the time slot for a new round of consensus is opened, a serial calculation of a verifiable delay function is initiated to obtain the current output state value, and the clock count value is incremented synchronously. The serial calculation is not interrupted or reset due to the arrival of a bid. When a valid bid sent by the builder arrives, a binding record is generated based on the captured current output status value, the captured current clock count value, and the block header digest corresponding to the bid. When a block header retrieval request is received from the proposer, the target bid with the highest yield is selected from the valid bids received. Based on the target block header and binding record corresponding to the target bid, a timestamp receipt is generated and returned to the proposer along with the target block header. This allows the proposer to perform local pre-verification and then send the block header confirmation information to the relay node. After receiving a valid block header confirmation, the complete block is sent to the proposer so that the proposer can broadcast the target block header, timestamp receipt, and complete block to the validator nodes for consensus voting on the complete block.

2. The method as described in claim 1, characterized in that, When the time slot for a new round of consensus begins, the serial computation of a verifiable delay function is initiated to obtain the current output state value, including: When a new consensus time slot is opened, the clock count value is initialized to zero. Based on the slot anchor point of the time slot and the identifier of the relay node, the initial input value of the verifiable delay function of the time slot is calculated. Use the initial input value as the initial output state value, start the execution of the verifiable delay function, and obtain the initial output state value; Using the initial output state value as the current output state value, the serial calculation of the verifiable delay function is continuously executed at a constant pace during the duration of the time slot. In each step of the serial calculation, the current output state value of the verifiable delay function is updated to the result of taking the square of the current output state value modulo a preset RSA modulus.

3. The method as described in claim 1, characterized in that, Based on the captured current output status value, the captured current clock count value, and the block header digest corresponding to the bid, a binding record is generated, including: The block header corresponding to the bid is used as the first block header, and the hash digest of the first block header is calculated as the block header digest; A clock state snapshot is formed by taking the initial input value of the verifiable delay function, the current output state value of the verifiable delay function captured when the bid arrives, and the current clock count value captured when the bid arrives. The clock state snapshot is bound to the block header digest to generate a binding record.

4. The method as described in claim 1, characterized in that, Based on the target block header and binding record corresponding to the target bid, generate a timestamp receipt, including: Generate a verifiable delay function proof for the binding record corresponding to the target bid; Based on the target block header, binding record, and verifiable delay function proof corresponding to the target bid, a timestamp receipt is generated using a digital signature.

5. The method as described in claim 4, characterized in that, Generate a verifiable delay function proof for the binding record corresponding to the target bid, including: The challenge prime number of the target bid is calculated based on the initial input value of the verifiable delay function in the binding record corresponding to the target bid, the current output state value of the verifiable delay function captured when the bid arrives, and the current clock count value captured when the bid arrives. Based on the challenge prime number, the current clock count value, and the initial input value, a verifiable delay function proof value is calculated. This verifiable delay function proof value is used to indicate that the current output state value is obtained by serial calculation of the initial input value through clock count steps.

6. The method according to claim 4, characterized in that, Based on the target block header, binding record, and verifiable delay function proof corresponding to the target bid, a timestamp receipt is generated using a digital signature, including: Using the relay node's private key, a digital signature is generated on the combination of the target block header, the binding record, and the verifiable delay function proof using the BLS signature generation algorithm; Construct a timestamp receipt based on the target block header, the binding record, the verifiable delay function proof, and the digital signature.

7. The method according to claim 1, characterized in that, The steps for performing local pre-validation include: Using the public key of the relay node, the digital signature in the timestamp receipt is verified using the BLS signature verification algorithm to obtain the verification result.

8. The method according to claim 1, characterized in that, The steps for a complete block consensus vote include: Perform time validity verification on the received target block header and timestamp receipt; After the time validity verification is passed, a consensus vote is conducted on the complete block.

9. The method according to claim 8, characterized in that, The steps for verifying the time validity include: The timestamp receipt is parsed to obtain the target block header, binding record, verifiable delay function proof and digital signature, and the initial input value, current output state value, current clock count value and block header digest are obtained from the binding record; Verify the parsed digital signature; if verification fails, reject the complete block. Verify whether the parsed block header digest matches the hash value of the target block header; if they do not match, reject the complete block. Verify whether the initial input value of the verifiable delay function is generated by the slot anchor point and relay identifier of the current time slot; otherwise, reject the complete block. The verifiable delay function proof is verified, and if the verification fails, the complete block is rejected. Verify whether the clock count value in the timestamp receipt is less than or equal to the maximum delay threshold allowed by the proof-of-stake blockchain system. If it is, the complete block is deemed valid; otherwise, the vote is rejected.

10. The method according to claim 9, characterized in that, Verification of the analytical verifiable delay function proof includes: Calculate the challenge prime number and intermediate value based on the initial input value, current output status value, and current clock count value of the received timestamp receipt; Check if the following equation is true; if yes, the verification passes; otherwise, the verification fails: in, For an analytical, verifiable proof of the delay function, To challenge prime numbers, The median value. The initial input values ​​for parsing, The current output state value is the parsed value. It is an RSA modulus.

11. The method according to claim 1, characterized in that, Also includes: At the end of the current time slot, release the final verifiable delay function output state value and verifiable delay function proof of the current time slot; The output state value of the final verifiable delay function, the proof of the verifiable delay function, and the current time slot number are hashed to obtain the hash value. The hash value is used as the slot anchor point for the next time slot.

12. A timestamp proof device in a blockchain proof-of-stake consensus system, characterized in that, A relay node used in a proof-of-stake blockchain system, which also includes builders, proposers, and validators, including: The serial calculation module is used to start the serial calculation of the verifiable delay function to obtain the current output status value when the time slot of the new round of consensus is opened, and to synchronously increment the clock count value. The serial calculation is not interrupted or reset due to the arrival of the bid. The binding record generation module is used to generate a binding record when a valid bid sent by the builder arrives, based on the captured current output status value, the captured current clock count value, and the block header digest corresponding to the bid. The timestamp receipt generation module is used to select the highest-yielding target bid from the received valid bids when it receives a block header retrieval request from the proposer. Based on the target block header and binding record corresponding to the target bid, it generates a timestamp receipt and returns the timestamp receipt and the target block header to the proposer so that the proposer can perform local pre-verification and send the block header confirmation information to the relay node. The voting module is used to send the complete block to the proposer after receiving a valid block header confirmation message, so that the proposer can broadcast the target block header, timestamp receipt and complete block to the validator nodes for the validator nodes to vote on the complete block consensus.

13. A timestamp proof system in a blockchain proof-of-stake consensus system, characterized in that, It is applied to proof-of-stake blockchain systems, including relay nodes, builders, proposers, and validators; The relay node is used for: When the time slot for a new round of consensus is opened, a serial calculation of a verifiable delay function is initiated to obtain the current output state value, and the clock count value is incremented synchronously. The serial calculation is not interrupted or reset due to the arrival of a bid. When a valid bid sent by the builder arrives, a binding record is generated based on the captured current output status value, the captured current clock count value, and the block header digest corresponding to the bid. When a block header retrieval request is received from a proposer, the target bid with the highest yield is selected from the valid bids received. Based on the target block header and binding record corresponding to the target bid, a timestamp receipt is generated and returned to the proposer along with the target block header. After receiving a valid block header confirmation, the complete block is sent to the proposer. The proposer is used to: after the timestamp receipt and the target block header have passed local pre-verification, send the block header confirmation information to the relay node; After receiving the complete block, broadcast the target block header, timestamp receipt, and the complete block to the validator nodes; The verification node is used to: verify and vote on the complete block consensus after receiving the target block header, timestamp receipt and complete block broadcast by the proposer.

14. A computer device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the method of any one of claims 1 to 11.

15. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the method of any one of claims 1 to 11.

16. A computer program product, characterized in that, The computer program product includes a computer program that, when executed by a processor, implements the method of any one of claims 1 to 11.

Images