Intelligent contract electronic payment method based on block chain

Abstract

The invention discloses an intelligent contract electronic payment method based on a block chain, and relates to the technical field of intelligent contract electronic payment, and the method comprises the steps: obtaining a local sending moment, a propagation time delay, time delay jitter and clock skew, calculating a transaction arrival phase and a time distance between the transaction arrival phase and a time slot boundary, and generating a risk sign; determining a cut-off block number according to the risk sign, generating a boundary statement and writing the boundary statement into a transaction body; the transaction body is signed and broadcasted at the actual sending moment; and after receiving, the node performs checking according to the cut-off block number and the phase label, and generates and archives a receipt abstract. According to the invention, the security, stability and transparency of electronic payment can be improved.

Description

Technical Field

[0001] This invention relates to the field of smart contract electronic payment technology, and in particular to a blockchain-based smart contract electronic payment method. Background Technology

[0002] With the continuous development of electronic payment infrastructure, blockchain-based payment methods have been widely applied in various scenarios such as offline payments, cross-border e-commerce, small-amount subscriptions, and hourly billing. A typical transaction process includes the terminal initiating a signature, broadcasting the transaction over the network, propagating it to the execution node, entering the mempool to await block packaging, and finally completing on-chain confirmation. Because mainstream public blockchains use a fixed-interval block generation mechanism, transactions packaged within each time slot must be selected and determined by the node from the mempool according to the current strategy. Real-world network transmission paths have uncontrollable physical propagation delays, and congestion on the link can also cause random fluctuations in propagation delays. Furthermore, there is often a slight deviation between the local clock of the terminal device and the reference clock used by the on-chain nodes. These factors combined mean that the same transaction may be included in different blocks at different times and under different network conditions, thus affecting its ordering position and execution fee.

[0003] Current technologies lack explicit mechanisms to identify whether a transaction is within a sensitive block boundary, and also lack methods to verify and constrain the expected order and cost conditions during cross-block execution. Common industry practices include increasing transaction fee caps, adding priority fees, extending transaction waiting times, or using multi-channel rebroadcasting. While these methods improve average success rates to some extent, they lead to increased costs and reduced efficiency, and still fail to provide clear execution guarantees and rejection feedback under the time-slot boundary conditions of individual transactions. This uncertainty further makes it difficult for users and merchants to predict the execution time, cost, and order position of specific transactions, which is detrimental to the security, traceability, and auditing requirements of critical payment scenarios. Therefore, there is an urgent need for a new electronic payment method that can identify and respond to block boundary sensitive behaviors, ensuring deterministic execution of transactions when preset security conditions are met. Summary of the Invention

[0004] The purpose of this invention is to address the shortcomings of existing technologies where transactions are affected by propagation delays and clock deviations at block boundaries, leading to uncertainties in block execution, fees, and sorting results. This invention proposes a blockchain-based smart contract electronic payment method.

[0005] To address the problems existing in the prior art, the present invention adopts the following technical solution:

[0006] Blockchain-based smart contract electronic payment methods include:

[0007] The system acquires the local transmission time, end-to-end propagation delay, delay jitter, clock skew, and time slot period parameters. Based on these parameters, it calculates the phase tag and beat frequency distance, and generates a risk flag based on the beat frequency distance.

[0008] The cutoff block number is determined based on the risk indicator and combined with the phase label to form a boundary statement. The boundary statement is then written into the payment transaction body to generate a transaction body to be signed.

[0009] Based on the risk flag, the local sending time is time-off processed to obtain the actual sending time. At the actual sending time, the transaction body to be signed is then broadcast.

[0010] After receiving the signed transaction, the cutoff block number and phase tag are verified to obtain the verification result;

[0011] A receipt summary is generated based on the phase label, cutoff block number, and verification results.

[0012] Preferably, the local transmission time, end-to-end propagation delay, delay jitter, clock skew, and time slot period parameters are obtained. The phase tag and beat frequency distance are calculated based on these parameters, and a risk flag is generated based on the beat frequency distance, including:

[0013] Acquire local transmission time, end-to-end propagation delay, delay jitter, clock skew, time slot period parameters and beat frequency threshold, and perform standardized processing with unified units and time base;

[0014] The arrival phase is obtained by adding the local transmission time, end-to-end propagation delay, delay jitter and clock deviation, and then taking the remainder relative to the time slot period parameter.

[0015] The minimum time interval between the arriving phase and the boundary of the adjacent time slot is taken as the beat frequency distance;

[0016] The arriving phase is discretized according to the set quantization step size to obtain the phase tag;

[0017] A risk flag is generated if the beat frequency distance is not greater than the beat frequency threshold; otherwise, a risk flag is generated if the distance is not greater than the beat frequency threshold.

[0018] Preferably, the cutoff block number is determined based on the risk flag, and a boundary statement is formed by combining it with the phase tag. The boundary statement is then written into the payment transaction body to generate a transaction body to be signed, including:

[0019] Read the current chain header block number and determine the target containing block number as the first candidate block after the current chain header block number;

[0020] The cutoff block number is generated based on the risk flag. When the risk flag is negative, the cutoff block number is set to the target containing block number. When the risk flag is positive, the cutoff block number is set to the target containing block number and execution is restricted to subsequent blocks.

[0021] Combine the cutoff block number with the phase label to form a boundary declaration;

[0022] The boundary declaration is written into the payment transaction body to form the transaction body to be signed.

[0023] Preferably, the local transmission time is time-offset based on the risk flag to obtain the actual transmission time. After signing the transaction body to be signed at the actual transmission time, it is broadcast, including:

[0024] When the risk flag is not set, the micro-motion transmission amount is set to zero; otherwise, the micro-motion transmission amount is set to the smaller of the difference between the beat frequency threshold and the beat frequency distance and the upper limit of the micro-motion transmission amount. The upper limit of the micro-motion transmission amount is a safety threshold determined based on the time slot period and historical propagation jitter statistics.

[0025] Add the local transmission time to the micro-move transmission amount to obtain the actual transmission time;

[0026] At the actual time of transmission, the transaction body to be signed is signed to obtain a signed transaction, and a transaction identifier is generated based on the signed transaction;

[0027] The signed transaction is broadcast to the execution node at the actual time of transmission.

[0028] Preferably, after receiving the signed transaction, the cutoff block number and phase tag are verified to obtain the verification result, including:

[0029] Read the boundary declaration from the signed transaction, obtain the cutoff block number and phase tag, and load the slot period parameters;

[0030] The current block number is compared with the cutoff block number. If the current block number is later than the cutoff block number, the process backs up and returns an error code. Otherwise, the current block timestamp is moduloed relative to the time slot period parameter to obtain the on-chain arrival phase.

[0031] The on-chain arrival phase is discretized according to the set quantization step size to obtain the on-chain phase tag;

[0032] The on-chain phase tag is compared with the phase tag according to the quantization tolerance. If the difference between the two is greater than the quantization tolerance, the process is rolled back and an error code is returned. Otherwise, the transfer is executed. The quantization tolerance is a configuration parameter set according to the historical phase deviation distribution.

[0033] Preferably, a receipt summary is generated based on the phase label, cutoff block number, and verification result, including:

[0034] Assemble the transaction identifier, cutoff block number, phase tag, current block number, on-chain arrival phase, and error code into a receipt field group;

[0035] Generate a receipt summary based on the receipt field group, and archive the receipt summary.

[0036] Preferably, the beat frequency threshold is adaptively updated, wherein the adaptive update is used to ensure that the failure rate near the boundary does not exceed the target failure rate upper limit and remains stable as the network propagation and clock deviation change.

[0037] Preferably, adaptively updating the beat frequency threshold includes:

[0038] Calculate the difference between the time slot period parameter and the on-chain arrival phase, compare the difference with the on-chain arrival phase, and take the smaller value as the on-chain boundary distance;

[0039] Use the standard deviation of the chain boundary distance as the group width;

[0040] The chain boundary distance is grouped according to the group width, and the failure rate of each group is obtained by calculating the ratio of the number of failed samples in the group to the total number of samples in the group.

[0041] The smallest group boundary with a failure rate not exceeding the target failure rate upper limit is selected as the candidate beat frequency threshold, and the beat frequency threshold is updated using a smoothing coefficient. The beat frequency threshold update formula is as follows:

[0042]

[0043] In the formula, For the updated beat frequency threshold, For smoothing coefficients, This is the current beat frequency threshold. This represents the candidate beat frequency threshold.

[0044] Compared with the prior art, the beneficial effects of the present invention are:

[0045] 1. This invention performs unified benchmark processing on local transmission time, end-to-end propagation delay, delay jitter and clock deviation, calculates arrival phase and beat frequency distance and generates risk flags, and then uses cutoff block number and phase tag to form boundary declaration, so that smart contracts first perform cutoff block verification on the chain and then perform phase consistency verification, suppressing cost and sorting mutations caused by cross blocks.

[0046] 2. This invention obtains the actual sending time by performing time offset processing on the local sending time based on the risk flag off-chain, and completes the signing and broadcasting at that time, so that the expected arrival location is far away from the boundary sensitive area without changing the written boundary declaration; after execution on-chain, the receipt field group is assembled with fields such as the current block number, on-chain arrival phase and error code, and the receipt digest is calculated and archived to form an evidence carrier that can be independently recalculated and verified, so that the reasons and context of success and rejection can be audited and traced, improving transparency and anti-tampering capabilities.

[0047] 3. This invention selects the smallest group boundary that meets the upper limit of the target failure rate as a candidate for the beat frequency threshold by using the failure rate of the on-chain boundary distance in each group, and updates the beat frequency threshold with a smoothing coefficient so that the threshold adaptively converges with changes in network latency and jitter, thereby stabilizing the success rate and confirmation time without excessively increasing costs or extending waiting time. Attached Figure Description

[0048] The accompanying drawings, which are included to provide a further understanding of the invention and form part of this application, illustrate exemplary embodiments of the invention and, together with their description, serve to explain the invention and do not constitute an undue limitation thereof. In the drawings:

[0049] Figure 1 This is a flowchart illustrating a blockchain-based smart contract electronic payment method according to an embodiment of the present invention.

[0050] Figure 2 This is a flowchart illustrating a risk marker generation method according to an embodiment of the present invention;

[0051] Figure 3 This is a flowchart illustrating a method for generating a transaction body to be signed according to an embodiment of the present invention.

[0052] Figure 4 This is a flowchart illustrating a signed transaction broadcasting method according to an embodiment of the present invention.

[0053] Figure 5 This is a flowchart illustrating a method for verifying the cutoff block number and phase label according to an embodiment of the present invention. Detailed Implementation

[0054] The technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments.

[0055] Example: This example provides a blockchain-based smart contract electronic payment method. See [link to example]. Figure 1 Specifically, including:

[0056] In embodiments of the present invention, local transmission time, end-to-end propagation delay, delay jitter, clock skew, and time slot period parameters are obtained. A phase tag and beat frequency distance are calculated based on these parameters, and a risk flag is generated based on the beat frequency distance. (See [link to relevant documentation]). Figure 2 ,include:

[0057] Acquire local transmission time, end-to-end propagation delay, delay jitter, clock skew, time slot period parameters and beat frequency threshold, and perform standardized processing with unified units and time base;

[0058] Specifically, when a terminal or gateway initiates a smart contract electronic payment transaction, it first obtains the local transmission time, which is the current time recorded when the terminal or gateway triggers the transaction initiation operation; then, it obtains the end-to-end propagation delay, which is calculated by measuring the historical round-trip time between the terminal or gateway and the blockchain execution node, selecting the average or stable value from multiple measurements as the final end-to-end propagation delay; next, it obtains the delay jitter, which is the fluctuation range of multiple end-to-end propagation delays under the same communication link, determined by statistically analyzing the variance or range of historical end-to-end propagation delays; then, it obtains the clock skew, which is the time difference between the terminal or gateway's local clock and the blockchain execution node's clock, calculated by periodically synchronizing the block timestamps published by the execution node and calculating the average difference between the local clock's displayed time and the block timestamp; simultaneously, it obtains the time difference from the consensus rules of the blockchain network or the time of blocks already generated on the chain. The time slot period parameter is extracted from the time stamp sequence. The time interval between the generation of multiple consecutive blocks is statistically analyzed, and a fixed period value is taken as the time slot period parameter. The beat frequency threshold is also obtained. This threshold is obtained based on the historical transaction beat frequency distance data accumulated by the terminal or gateway. In the initial stage, the initial value can be set with reference to the typical propagation characteristics of the blockchain network, and then dynamically adjusted as transaction execution data is accumulated. After obtaining all the above parameters, these parameters are standardized by unifying the units and time base. The time units of local transmission time, end-to-end propagation delay, delay jitter, clock deviation, and time slot period parameter are uniformly converted to the same unit, such as milliseconds or microseconds. At the same time, the block timestamp base of the blockchain execution node is used as the unified time base. The local transmission time, clock deviation, and other time-related parameters are all adjusted to this unified time base to eliminate the error caused by the difference in clock bases of different devices in subsequent calculations.

[0059] The arrival phase is obtained by adding the local transmission time, end-to-end propagation delay, delay jitter and clock deviation, and then taking the remainder relative to the time slot period parameter.

[0060] The minimum time interval between the arriving phase and the boundary of the adjacent time slot is taken as the beat frequency distance;

[0061] Specifically, in a block production system with a fixed time slot cycle, the actual arrival time of any transaction is equal to the sum of the local transmission time, end-to-end propagation delay, delay jitter, and clock skew. Since the system operates on a cyclical basis, this absolute time needs to be projected onto a single time slot using modulo operations to obtain the arrival phase. This approach is consistent with the calculation of the position of a cyclic process in communication and signal processing, eliminating the cumulative effects across multiple cycles and retaining only the relative position. Furthermore, the minimum time interval from the arrival phase to the nearest time slot boundary is used as the beat frequency distance. This interval characterizes the minimum disturbance amplitude required to cross from the current phase into an adjacent time slot. When the instantaneous change in network jitter or timing error exceeds this interval, a block crossing occurs, causing abrupt changes in the cost and ordering of block-based discrete adjustments. Therefore, using summation and modulo operations to obtain the arrival phase and using the minimum interval as a metric allows for accurate characterization of boundary sensitivity with a single computable scalar, providing a direct basis for risk assessment and opportune transmission.

[0062] Specifically, the standardized local transmission time, end-to-end propagation delay, delay jitter, and clock skew are first summed to obtain the estimated arrival time of the transaction at the blockchain execution node. Then, based on this estimated arrival time, a modulo operation is performed relative to the standardized time slot period parameter. This modulo operation determines the specific position of the estimated arrival time within the corresponding time slot period; this position is the arrival phase. After obtaining the arrival phase, the boundaries of the two adjacent time slots to which the arrival phase belongs are determined. One boundary is the start time of the time slot to which the arrival phase belongs, and the other boundary is the end time of the time slot to which the arrival phase belongs, i.e., the start time of the next time slot. Next, the time intervals between the arrival phase and these two adjacent time slot boundaries are calculated. The time interval between the arrival phase and the start time of its time slot is equal to the arrival phase itself, and the time interval between the arrival phase and the end time of its time slot is equal to the time slot period parameter minus the arrival phase. Finally, the smaller of the two calculated time intervals is selected; this smaller time interval is the beat frequency distance.

[0063] The arriving phase is discretized according to the set quantization step size to obtain the phase tag;

[0064] A risk flag is generated if the beat frequency distance is not greater than the beat frequency threshold; otherwise, a risk flag is generated if the beat frequency distance is not greater than the beat frequency threshold.

[0065] Specifically, blocks are generated at a fixed beat. The position of a transaction within a beat is a continuous quantity, subject to slight fluctuations due to measurement resolution, propagation perturbations, and clock drift. The arrival phase is discretized into phase labels according to a set quantization step size. This is equivalent to setting equal-width intervals within the beat, mapping continuous positions to finite labels. This limits the measurement error to half a quantization step size, facilitating on-chain consistency comparisons in constant time and reducing the probability of false positives. The beat distance represents the minimum time change required to reach the nearest time slot boundary. When the beat distance is less than or equal to the beat threshold, any slight perturbation may push a transaction into an adjacent beat, altering fees and order; therefore, a risk flag is generated. When the beat distance is greater than the beat threshold, crossing into an adjacent beat requires a larger perturbation; the transaction is in a stable region, and a risk flag is generated.

[0066] Specifically, the quantization step size is first set based on the time slot period of the blockchain network and the actual computational accuracy requirements. This quantization step size must ensure that the different positions of the arrival phase within the time slot period can be accurately distinguished, while avoiding an increase in the complexity of subsequent on-chain verification due to an excessively small step size. Then, the time slot period is divided into multiple continuous and non-overlapping discrete intervals according to the set quantization step size, with each discrete interval corresponding to a unique numerical value or code identifier. Next, it is determined which discrete interval the previously calculated arrival phase falls into, and the unique numerical value or code identifier corresponding to that discrete interval is used as the phase label, completing the discretization process of the arrival phase. The previously calculated beat frequency distance is retrieved and compared with the system's preset beat frequency threshold. If the beat frequency distance is less than or equal to the beat frequency threshold, it means that the transaction is within the beat frequency window when it arrives at the execution node, and there is a risk of crossing to the next time slot due to minor disturbances. In this case, a risk flag is generated as "yes". If the beat frequency distance is greater than the beat frequency threshold, it means that the transaction is within the safe window when it arrives at the execution node, and the risk of crossing the time slot is low. In this case, a risk flag is generated as "no".

[0067] In an embodiment of the present invention, the cutoff block number is determined based on the risk flag and combined with the phase tag to form a boundary declaration. The boundary declaration is then written into the payment transaction body to generate a transaction body to be signed. See [link to previous section]. Figure 3 ,include:

[0068] Read the current chain header block number and determine the target containing block number as the first candidate block after the current chain header block number;

[0069] The cutoff block number is generated based on the risk flag. When the risk flag is negative, the cutoff block number is set to the target containing block number. When the risk flag is positive, the cutoff block number is set to the target containing block number and execution is restricted to subsequent blocks.

[0070] Specifically, block generation follows a fixed rhythm and carries transactions in discrete blocks. For a transaction to be accepted on-chain, it must satisfy the fundamental constraints of causal order and propagation completion. Therefore, using the first candidate block after the current chain header block number as the target containing block number can provide the earliest feasible execution window without violating causality. Since propagation delay and jitter may cause slight fluctuations in the actual arrival time near the rhythm boundary, sliding from the target containing block number to subsequent blocks will introduce abrupt changes in the basic fees and sorting space updated by block, thus causing uncertainty in the fees and order of the same transaction. Accordingly, the cutoff block number is set as the target containing block number, so that transactions are only accepted within this window. If it is determined to be in a high-risk situation at the boundary, it is further restricted to prohibit execution across subsequent blocks. The hard restriction of the time window eliminates the fee jumps and sorting reordering caused by crossing blocks, realizes the determinism of execution timing and the stabilization of settlement conditions, and provides a single numerical constraint that can be directly verified for subsequent on-chain verification.

[0071] Specifically, the terminal or gateway first reads the current chain head block number from the latest block data synchronized from the blockchain network. This chain head block number is the number of the last block in the current blockchain network that has completed consensus confirmation. Based on the block generation rules and time slot cycle of the blockchain network, the first block to be generated after the current chain head block number in the block generation order is determined as the first candidate block. The number of this first candidate block is used as the target containing block number, that is, the block number in which the transaction is expected to be packaged and included. After determining the target containing block number, the previously generated risk flag is retrieved, and the cutoff block number is generated based on the status of the risk flag. If the risk flag is negative, it indicates that the transaction arrives at the execution node within a safe window, and the risk of execution across time slots is low. In this case, the cutoff block number is directly set to the target containing block number, allowing the transaction to be packaged and executed within the target containing block. If the risk flag is positive, it indicates that the transaction arrives at the execution node within a beat window, and there is a risk of crossing to the next time slot due to minor disturbances. In this case, the cutoff block number is still set to the target containing block number, and additional execution constraints are added to restrict the transaction from crossing to subsequent blocks after the target containing block for execution. This ensures that the transaction can only attempt to be packaged within the target containing block, avoiding cost jumps or abnormal sorting issues caused by crossing slots.

[0072] Combine the cutoff block number with the phase label to form a boundary declaration;

[0073] Write the boundary declaration into the payment transaction body to form a transaction body to be signed;

[0074] Specifically, the cutoff block number and phase tag are combined into a boundary declaration and submitted along with the payment transaction body. This allows on-chain verification to simultaneously constrain the absolute time window and the relative position within the time slot: the cutoff block number corresponds to the latest executable point in the discrete block sequence, used to eliminate cost and ordering abrupt changes caused by crossing into subsequent blocks; the phase tag originates from the quantization of the arrival phase, essentially a discrete mapping of the modulo operation result, capable of comparing with the current block time within a constant time, thereby determining whether the transaction is in the vicinity of a high-risk boundary. Both are merged into a single declaration and written into the transaction body to be signed. After signing, it remains immutable during propagation and consensus. Nodes only need to read this declaration during execution to complete the cutoff block verification and phase consistency verification, without the need for additional channels or external state queries. This reduces verification complexity and establishes a one-to-one correspondence between the off-chain measured arrival position and the on-chain discrete beat, ensuring the determinism of the execution result and the reproducibility of backtracking audits.

[0075] Specifically, the terminal or gateway first retrieves the previously determined cutoff block number and the generated phase tag. Following a preset data structure format, these two key parameters are integrated to ensure a complete association between the transaction packaging time constraint represented by the cutoff block number and the transaction arrival phase information represented by the phase tag, and to ensure they can be accurately identified and read by the blockchain smart contract. This integration operation forms a boundary statement, clearly reflecting the execution constraints of the transaction in the time dimension. After combining the boundary statements, the terminal or gateway retrieves the pre-constructed payment transaction body containing core transaction information such as the receiving address, payment amount, and fee limit. The integrated boundary statement is embedded into the payment transaction body as an extended field. During embedding, it is crucial to ensure that the parameter format of the boundary statement is compatible with the existing data format of the payment transaction body to avoid format conflicts that prevent the transaction from being parsed by blockchain nodes. After the boundary statement is embedded, the payment transaction body becomes a transaction awaiting signature, awaiting subsequent signing operations to achieve legitimacy for propagation and execution within the blockchain network.

[0076] In an embodiment of the present invention, the local transmission time is time-offset based on the risk flag to obtain the actual transmission time. The transaction body to be signed is then broadcast after being signed at the actual transmission time. (See [link]). Figure 4 ,include:

[0077] When the risk flag is not set, the micro-motion transmission amount is set to zero; otherwise, the micro-motion transmission amount is set to the smaller of the difference between the beat frequency threshold and the beat frequency distance and the upper limit of the micro-motion transmission amount. The upper limit of the micro-motion transmission amount is a safety threshold determined based on the time slot period and historical propagation jitter statistics.

[0078] Add the local transmission time to the micro-move transmission amount to obtain the actual transmission time;

[0079] Specifically, blocks are distributed in a fixed-beat rhythm. Transactions are most sensitive to minor time disturbances when approaching the beat boundary. To reduce the probability of crossing into subsequent blocks, the decision to adjust the sending time is first made based on a risk indicator: if the risk indicator is negative, no adjustment is made to avoid unnecessary waiting; if the risk indicator is positive, the micro-shift sending amount is set to the smaller of the beat frequency threshold minus the beat frequency distance and the upper limit of the micro-shift sending amount. The upper limit of the micro-shift sending amount is given based on the time slot period and historical propagation jitter statistics to ensure that the time adjustment is sufficient to leave the high-risk zone without exceeding the safety margin and business waiting limits. Subsequently, the local sending time is added to the micro-shift sending amount to obtain the actual sending time. The expected arrival position is moved from the boundary proximity to the stable zone by a minimum necessary time shift, while keeping the cutoff block number and phase label unchanged. This ensures that subsequent on-chain verification still uses the same boundary declaration, thereby stabilizing fees and ordering and improving the certainty of single execution without increasing redundant verification.

[0080] Specifically, the terminal or gateway first retrieves the previously generated risk flag and, in conjunction with the beat frequency threshold, beat frequency distance, and a pre-determined upper limit for micro-move transmission, sets the micro-move transmission amount. If the risk flag is negative, it indicates that the transaction is within a safe window and there is no need to avoid cross-slot risks by offsetting the transmission time; in this case, the micro-move transmission amount is set to zero. If the risk flag is positive, it indicates that the transaction is within a beat frequency window and needs to move away from the time slot boundary by offsetting the transmission time. In this case, the difference between the beat frequency threshold and the beat frequency distance is first calculated, and then this difference is compared with the upper limit for micro-move transmission amount. The smaller of the two values ​​is selected as the final micro-move transmission amount. After determining the micro-move transmission amount, the terminal or gateway retrieves the previously recorded local transmission time and sums the local transmission time with the micro-move transmission amount. The result is the actual time when the transaction initiates broadcasting, which is the actual transmission time.

[0081] At the actual time of transmission, the transaction body to be signed is signed to obtain a signed transaction, and a transaction identifier is generated based on the signed transaction;

[0082] The signed transaction is broadcast to the execution node at the actual time of transmission;

[0083] Specifically, signing and immediately broadcasting the transaction body to be signed at the actual sending moment is based on the determinism and immutability of digital signatures and hash digests: the message covered by the signature must be completely consistent with the payload to be propagated; the smaller the time interval between signing and broadcasting, the better it can eliminate replay windows and invalid signatures caused by minor changes in cost parameters and random numbers before sending; the digest value of the signed transaction serves as a transaction identifier, enabling unique identification and deduplication during peer-to-peer propagation, preventing the same payload from being processed repeatedly due to multi-source forwarding; under the propagation and sorting mechanism of the execution nodes, the actual arrival time and the signed payload jointly determine the probability of being included in the target block. Therefore, broadcasting immediately at the actual sending moment can directly convert the time offset effect obtained from the previous steps into a higher probability of inclusion in the same block. At the same time, any intermediate node can instantly verify the integrity and source based on the signature, thereby achieving the coordinated goals of authentication, deduplication, and opportunistic sending without adding additional verification processes.

[0084] Specifically, when the preset actual sending time arrives, the terminal or gateway uses its locally securely stored private key to perform an asymmetric cryptographic signature operation on the transaction to be signed. This signing process verifies the integrity of the transaction and confirms the legitimate identity of the transaction initiator. After the signing operation is completed, a signed transaction is formed, containing signature information, boundary declarations, and core transaction data. Subsequently, the terminal or gateway reads all the data content of the signed transaction and performs a hash calculation on all the data content according to the hash calculation rules commonly used in blockchain networks to obtain a unique and tamper-proof hash value. This hash value is used to uniquely identify the transaction in the blockchain network. While generating the transaction identifier, the terminal or gateway follows the node communication protocol of the blockchain network and transmits the signed transaction to the execution node in the blockchain network in real time, ensuring that the broadcast of the signed transaction is completed strictly at the actual sending time, so that the execution node can receive the signed transaction in a timely manner and enter the subsequent transaction verification and packaging process.

[0085] In an embodiment of the present invention, after receiving a signed transaction, the cutoff block number and phase tag are verified to obtain the verification result, see [link to relevant documentation]. Figure 5 ,include:

[0086] Read the boundary declaration from the signed transaction, obtain the cutoff block number and phase tag, and load the slot period parameters;

[0087] The current block number is compared with the cutoff block number. If the current block number is later than the cutoff block number, the process backs up and returns an error code. Otherwise, the current block timestamp is moduloed relative to the time slot period parameter to obtain the on-chain arrival phase.

[0088] Specifically, the contract first reads the boundary declaration and loads the time slot period parameter to determine the timing of the two-level constraint ruling on-chain. First, it compares the current block number with the deadline block number. If the current block number is later than the deadline block number, it indicates that the transaction has exceeded the agreed-upon latest execution window. In this case, it immediately rolls back and returns an error code, eliminating the underlying costs and ordering mutations caused by crossing into subsequent blocks from the source. Only when the current block number is not later than the deadline block number does it proceed to the second level of verification. The current block timestamp is moduloed against the time slot period parameter to obtain the on-chain arrival phase, mapping the absolute time to the position within a single time slot. This facilitates subsequent consistency comparison with the phase tag using constant time, thus completing the joint verification of the time window and the position within the tick with minimal information. This ensures the determinism and auditability of the execution result without the need for external data channels.

[0089] Specifically, after receiving a signed transaction, the blockchain execution node parses the extended fields of the signed transaction by the smart contract, extracts the boundary declaration formed by the previous combination, and obtains the cutoff block number and phase tag contained in the boundary declaration. The smart contract retrieves and loads the time slot period parameters from the consensus rules of the blockchain network or the preset system configuration to ensure that the time slot period used for subsequent calculations is consistent with that at the time of transaction initiation. The smart contract then reads the block number currently being processed for the transaction as the current block number and compares it with the cutoff block number obtained from the boundary declaration. If the current block number is greater than the cutoff block number, it indicates that the transaction has exceeded the allowed block size range. The smart contract immediately terminates the execution of the current transaction and reverts to the state before the transaction execution, while generating and returning the corresponding error code to indicate that the transaction failed due to exceeding the cutoff block limit. If the current block number is less than or equal to the cutoff block number, it indicates that the transaction is still within the allowed block size range. The smart contract reads the timestamp of the current block, performs a modulo operation on the timestamp relative to the loaded time slot period parameter, and determines the specific position of the current block timestamp within the corresponding time slot period based on the operation result. This position result is the on-chain arrival phase.

[0090] The on-chain arrival phase is discretized according to the set quantization step size to obtain the on-chain phase tag;

[0091] The on-chain phase tag is compared with the phase tag according to the quantization tolerance. If the difference between the two is greater than the quantization tolerance, the process is rolled back and an error code is returned. Otherwise, the transfer is executed. The quantization tolerance is a configuration parameter set according to the historical phase deviation distribution.

[0092] Specifically, blocks are processed at a fixed pace. The on-chain timestamp and the arrival position measured by the terminal will have slight deviations due to sampling errors and synchronization drift. To determine the consistency of computation completion on-chain, the on-chain arrival phase is first divided into equal-width intervals according to a set quantization step size and mapped to on-chain phase labels. This limits the small disturbances to within half a quantization step size, converting continuous time positions into finite labels for constant time comparison. Subsequently, the quantization tolerance is used as the allowable deviation threshold to compare the differences between the on-chain phase labels and the phase labels. The quantization tolerance is set based on the historical phase deviation distribution to accommodate small deviations caused by measurement noise and clock drift. Deviations exceeding the threshold indicate that the arrival position has crossed the critical interval. Continuing execution would lead to unacceptable changes in fees and sorting conditions. Therefore, when the difference is greater than the quantization tolerance, a rollback is performed and an error code is returned. When the difference is less than the quantization tolerance, the transfer is executed, thus achieving stable and reliable consistency determination with minimal data volume.

[0093] Specifically, the smart contract retrieves the same quantization step size as when the transaction is initiated. This quantization step size is used to divide the time slot period into multiple continuous and non-overlapping discrete intervals, each interval corresponding to a unique numerical value or coded identifier. The smart contract determines which discrete interval the previously obtained on-chain arrival phase falls into, and determines the unique numerical value or coded identifier corresponding to that interval as the on-chain phase label, thus completing the discretization processing of the on-chain arrival phase. After obtaining the on-chain phase tag, the smart contract retrieves the phase tag obtained from the boundary declaration and simultaneously retrieves the quantization tolerance. This quantization tolerance is a pre-set configuration parameter based on the deviation distribution of on-chain phase tags and phase tags in historical transactions of the blockchain network, used to accommodate phase deviations within a reasonable range. The difference between the on-chain phase tag and the phase tag is calculated and compared with the quantization tolerance. If the difference is greater than the quantization tolerance, it indicates that the deviation of the transaction's arrival phase exceeds a reasonable range, which may be abnormal. The smart contract immediately terminates the execution process of the current transaction and rolls back to the state before the transaction execution, while generating and returning the corresponding error code to indicate that the transaction failed due to the phase deviation exceeding the limit. If the difference is less than or equal to the quantization tolerance, it indicates that the deviation of the transaction's arrival phase is within a reasonable range, and the smart contract continues to execute the transfer operation in the transaction.

[0094] In an embodiment of the present invention, a receipt summary is generated based on the phase label, cutoff block number, and verification result, including:

[0095] Assemble the transaction identifier, cutoff block number, phase tag, current block number, on-chain arrival phase, and error code into a receipt field group;

[0096] Generate a receipt summary based on the receipt field group, and archive the receipt summary;

[0097] Specifically, the transaction identifier, cutoff block number, phase tag, current block number, on-chain arrival phase, and error code are assembled into a receipt field group because the result of a single execution is determined by both the absolute position in the block sequence and the relative position within the tick, and must form a one-to-one correspondence with the signed payload. To ensure verifiability and immutability during transmission and storage, a fixed-length digest is calculated for the receipt field group concatenated in a fixed field order. Utilizing the collision resistance and avalanche effect of cryptographic hashes, even minor changes to any field will cause significant changes in the digest, thus achieving strong binding and tamper visibility with minimal data volume. The receipt digest and receipt field group are archived together, allowing any third party to independently recalculate and compare to verify the execution or rejection conclusion of the payment under a specified block and phase. This eliminates the need to store the complete transaction payload for an extended period, reducing storage and transmission overhead and ensuring the reproducibility of the audit process.

[0098] In an embodiment of the present invention, adaptive updating of the beat frequency threshold includes:

[0099] Calculate the difference between the time slot period parameter and the on-chain arrival phase, compare the difference with the on-chain arrival phase, and take the smaller value as the on-chain boundary distance;

[0100] Use the standard deviation of the chain boundary distance as the group width;

[0101] The chain boundary distance is grouped according to the group width, and the failure rate of each group is obtained by calculating the ratio of the number of failed samples in the group to the total number of samples in the group.

[0102] Specifically, when the terminal or gateway performs adaptive updates to the beat frequency threshold, it first retrieves the time slot period parameter of the blockchain network and the on-chain arrival phase recorded in historical transactions, calculating the difference between the time slot period parameter and each on-chain arrival phase. Then, it compares this difference with the corresponding on-chain arrival phase, selecting the smaller value as the on-chain boundary distance for that transaction, thereby quantifying the actual proximity of the transaction arrival time to the time slot boundary. After obtaining the on-chain boundary distances for multiple transactions, it calculates the standard deviation of these on-chain boundary distances, determining this standard deviation as the grouping width for data grouping, ensuring that the grouping width reflects the overall dispersion of the on-chain boundary distances. Then, according to the determined grouping width, all on-chain boundary distances are divided into multiple continuous and non-overlapping interval groups, each interval group covering a certain range of on-chain boundary distances. For each interval group, the number of failed transactions in all transaction samples contained in the group is counted as the number of failed samples in the group, and the total number of transaction samples contained in the group is counted as the total number of samples in the group. The ratio of the number of failed samples in the group to the total number of samples in the group is calculated. This ratio is the failure rate corresponding to the interval group, which is used as the basis for updating the beat frequency threshold in the future.

[0103] The smallest group boundary with a failure rate not exceeding the target failure rate upper limit is selected as the candidate beat frequency threshold, and the beat frequency threshold is updated using a smoothing coefficient. The beat frequency threshold update formula is as follows:

[0104]

[0105] In the formula, For the updated beat frequency threshold, For smoothing coefficients, This is the current beat frequency threshold. For candidate beat frequency thresholds;

[0106] Specifically, by statistically analyzing the failure rate from smallest to largest boundary distance, a monotonically decreasing risk curve can be obtained. Selecting the smallest group boundary that ensures the failure rate does not exceed the target upper limit as the candidate beat frequency threshold maximizes the available time window while meeting reliability objectives and avoiding excessive conservatism. Directly changing the threshold to a candidate value is susceptible to jitter due to small sample fluctuations and instantaneous congestion. Therefore, a smooth update is adopted, setting the new beat frequency threshold as the weighted sum of the current beat frequency threshold and the candidate beat frequency threshold using a smoothing coefficient. This ensures the updated value lies between the two, thus suppressing high-frequency oscillations while maintaining responsiveness. A smoothing coefficient between zero and one allows the threshold to gradually converge under long-term stability conditions and follows environmental changes at a controllable speed, reducing the probability of false triggers and false rejections while ensuring the continuity and reproducibility of subsequent judgment and transmission strategies.

[0107] The above description is only a preferred embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any equivalent substitutions or modifications made by those skilled in the art within the scope of the technology disclosed in the present invention, based on the technical solution and inventive concept of the present invention, should be covered within the scope of protection of the present invention.

Claims

1. A blockchain-based smart contract electronic payment method, characterized in that, Includes the following steps: The system acquires the local transmission time, end-to-end propagation delay, delay jitter, clock skew, and time slot period parameters. Based on these parameters, it calculates the phase tag and beat frequency distance, and generates a risk flag based on the beat frequency distance. The cutoff block number is determined based on the risk indicator and combined with the phase label to form a boundary statement. The boundary statement is then written into the payment transaction body to generate a transaction body to be signed. Based on the risk flag, the local sending time is time-off processed to obtain the actual sending time. At the actual sending time, the transaction body to be signed is then broadcast. After receiving the signed transaction, the cutoff block number and phase tag are verified to obtain the verification result; A receipt summary is generated based on the phase label, cutoff block number, and verification results.

2. The blockchain-based smart contract electronic payment method according to claim 1, characterized in that, The system acquires local transmission time, end-to-end propagation delay, delay jitter, clock skew, and time slot period parameters. Based on these parameters, it calculates the phase tag and beat frequency distance, and generates a risk flag based on the beat frequency distance, including: Acquire local transmission time, end-to-end propagation delay, delay jitter, clock skew, time slot period parameters and beat frequency threshold, and perform standardized processing with unified units and time base; The arrival phase is obtained by adding the local transmission time, end-to-end propagation delay, delay jitter and clock deviation, and then taking the remainder relative to the time slot period parameter. The arriving phase is discretized according to the set quantization step size to obtain the phase tag; The minimum time interval between the arriving phase and the boundary of the adjacent time slot is taken as the beat frequency distance; A risk flag is generated if the beat frequency distance is not greater than the beat frequency threshold; otherwise, a risk flag is generated if the distance is not greater than the beat frequency threshold.

3. The blockchain-based smart contract electronic payment method according to claim 1, characterized in that, The cutoff block number is determined based on the risk flag, and combined with the phase tag to form a boundary statement. The boundary statement is then written into the payment transaction body to generate a transaction body to be signed, including: Read the current chain header block number and determine the target containing block number as the first candidate block after the current chain header block number; The cutoff block number is generated based on the risk flag. When the risk flag is negative, the cutoff block number is set to the target containing block number. When the risk flag is positive, the cutoff block number is set to the target containing block number and execution is restricted to subsequent blocks. Combine the cutoff block number with the phase label to form a boundary declaration; The boundary declaration is written into the payment transaction body to form the transaction body to be signed.

4. The blockchain-based smart contract electronic payment method according to claim 1, characterized in that, Based on the risk flag, the local transmission time is time-offset to obtain the actual transmission time. At this actual transmission time, the transaction body to be signed is then broadcast, including: When the risk flag is not set, the micro-motion transmission amount is set to zero; otherwise, the micro-motion transmission amount is set to the smaller of the difference between the beat frequency threshold and the beat frequency distance and the upper limit of the micro-motion transmission amount. The upper limit of the micro-motion transmission amount is a safety threshold determined based on the time slot period and historical propagation jitter statistics. Add the local transmission time to the micro-move transmission amount to obtain the actual transmission time; At the actual time of transmission, the transaction body to be signed is signed to obtain a signed transaction, and a transaction identifier is generated based on the signed transaction; The signed transaction is broadcast to the execution node at the actual time of transmission.

5. The blockchain-based smart contract electronic payment method according to claim 4, characterized in that, After receiving the signed transaction, the cutoff block number and phase tag are verified to obtain the verification results, including: Read the boundary declaration from the signed transaction, obtain the cutoff block number and phase tag, and load the slot period parameters; The current block number is compared with the cutoff block number. If the current block number is later than the cutoff block number, the process backs up and returns an error code. Otherwise, the current block timestamp is moduloed relative to the time slot period parameter to obtain the on-chain arrival phase. The on-chain arrival phase is discretized according to the set quantization step size to obtain the on-chain phase tag; The on-chain phase tag is compared with the phase tag according to the quantization tolerance. If the difference between the two is greater than the quantization tolerance, the process is rolled back and an error code is returned. Otherwise, the transfer is executed. The quantization tolerance is a configuration parameter set according to the historical phase deviation distribution.

6. The blockchain-based smart contract electronic payment method according to claim 5, characterized in that, A receipt summary is generated based on the phase label, cutoff block number, and verification results, including: Assemble the transaction identifier, cutoff block number, phase tag, current block number, on-chain arrival phase, and error code into a receipt field group; Generate a receipt summary based on the receipt field group, and archive the receipt summary.

7. The blockchain-based smart contract electronic payment method according to claim 6, characterized in that, The beat frequency threshold is adaptively updated to ensure that the failure rate near the boundary does not exceed the target failure rate limit and remains stable as the network propagation and clock deviation change.

8. The blockchain-based smart contract electronic payment method according to claim 7, characterized in that, Adaptive updates to the beat frequency threshold include: Calculate the difference between the time slot period parameter and the on-chain arrival phase, compare the difference with the on-chain arrival phase, and take the smaller value as the on-chain boundary distance; Use the standard deviation of the chain boundary distance as the group width; The chain boundary distance is grouped according to the group width, and the failure rate of each group is obtained by calculating the ratio of the number of failed samples in the group to the total number of samples in the group. The smallest group boundary with a failure rate not exceeding the target failure rate upper limit is selected as the candidate beat frequency threshold, and the beat frequency threshold is updated using a smoothing coefficient. The beat frequency threshold update formula is as follows: In the formula, For the updated beat frequency threshold, For smoothing coefficients, This is the current beat frequency threshold. This represents the candidate beat frequency threshold.

Images