A method and system for on-chain multi-way sealed submission and threshold timing disclosure

Abstract

This invention proposes an on-chain multi-channel sealed submission and threshold-based timed disclosure method and system. It includes: encrypting the operation content into ciphertext during submission, exposing a small amount of necessary header information to the network; simultaneously, splitting the decryption key into several small parts, and agreeing on a unified disclosure time window, at which time the key can be unlocked once a sufficient number of parts are collected. To avoid single points of failure or human selection, the sealed packets are sent simultaneously through multiple independent channels. Upon reaching the window, the system performs rapid batch verification on multiple sequential proofs generated based on a verifiable delay function (VDF). If the threshold is reached, the packets are unsealed all at once and then handed over to the existing execution entry point for processing; if a timeout occurs, the threshold is not reached, or a channel is abnormal, a preset fallback strategy automatically retransmits or switches. This scheme does not require modification to existing on-chain processes, significantly reduces information leakage during the propagation phase, suppresses front-running and selective rejection, improves the fairness of price discovery, and maintains stable processing latency through parameter coordination.

Description

Technical Field

[0001] This invention relates to the fields of blockchain and information security technology, and in particular to an on-chain multi-way sealed submission and threshold timing disclosure method and system. Background Technology

[0002] Transactions or "on-chain operations" in blockchain systems are typically first broadcast across the network and enter a processing queue, then selected, sorted, and added to the chain by nodes. In recent years, the rapid development of decentralized finance (DeFi) and account abstraction has significantly improved usability through models such as payment on behalf, aggregated execution, and bulk sending. However, this also exposes high-value operations to public or semi-public environments for extended periods during the dissemination phase. Balancing privacy, preventing front-running, ensuring fair sorting, and maintaining system activity without sacrificing verifiability has become a common challenge for engineering and compliance implementation. Simultaneously, solutions need to possess cross-implementation consistency and operational controllability, facilitating deployment without altering existing execution entry points.

[0003] Existing technologies have proposed several approaches, but limitations and shortcomings remain: First, pure payload encryption only obscures the data body; header information can still be linked, making it easy to be selectively rejected based on cost or feature profiles. Second, while private relay / whitelist channels can reduce external interference, they introduce trust and entry barriers, resulting in insufficient auditability and interoperability. Third, the paradigm and time lock of commitment and disclosure can easily lead to price discovery bias and a high rejection rate when disclosure is asynchronous, parameters drift, or network jitter occurs. Fourth, threshold signature / threshold schemes have advantages in resisting single points of failure and censorship, but they mainly address the "who signs" problem, offering limited support for minimum exposure during the propagation period, alignment of disclosure windows and validity periods, batch verification throughput, and parameter governance across implementations. Furthermore, the activity boundary and fairness are still difficult to guarantee when participants are delayed, shares are lost, or there is a small amount of collusion. Fifth, if multi-way submissions are not designed in conjunction with thresholds, time windows, and validity periods, the path independence and fallback mechanisms are unclear, easily leading to long-tail delays and inconsistent behavior. Unlike the traditional approach of applying time locks to the entire payload / key, this invention introduces a verifiable delay function at the share level and works in conjunction with the t-of-n threshold and unified disclosure window to ensure that thresholding, synchronization and auditability are achieved simultaneously without sacrificing the throughput at the verification end.

[0004] To address the aforementioned pain points, there is an urgent need for an improved solution that minimizes visible information during the propagation phase, achieves synchronous unsealing during the disclosure phase, and maintains liveness even in cases of partial failure. The proposed approach, without altering the underlying execution entry point, comprehensively utilizes methods such as encrypted encapsulation, coordinated threshold and time constraints, unified disclosure window and validity period alignment, multiple independent submission paths, batch verification, and parameter governance to form an auditable, scalable, and easily deployable bypass process. Compared to existing solutions, this approach is expected to simultaneously reduce profiling and front-running risks, improve the fairness of price discovery, stabilize verification overhead, and maintain long-term liveness and cross-implementation consistency through rollback and governance mechanisms. It is applicable to account abstraction and a wider range of on-chain operation scenarios. Summary of the Invention

[0005] The purpose of this invention is to address the shortcomings of existing technologies by proposing an on-chain multi-way sealed submission and threshold timing disclosure method and system.

[0006] The objective of this invention is achieved through the following technical solution: a method for on-chain operation of multiple sealed commits and threshold timing disclosure, the method comprising:

[0007] Generate a minimal visible header for minimal exposure during the propagation phase, carrying only the fixed fields necessary for routing and deduplication;

[0008] The smallest visible header is used as associated data, and the ciphertext payload is obtained by encrypting the operation object with a symmetric key.

[0009] The symmetric key is divided into t-of-n threshold segments, and a one-way verifiable sequential computation is performed on each segment to form a threshold-timed encapsulation carrying sequential proof, so that the segments can be verifiably revealed within the expected time window.

[0010] A sealed data frame is constructed using the minimum visible header, ciphertext payload, and threshold timing encapsulation, and submitted to multiple aggregation nodes via multiple independent communication paths;

[0011] The disclosure window is time-aligned with the validity period metadata of the operation object. At least t valid shares are collected within the preset disclosure window and batch verification is performed. When the threshold condition is met, the symmetric key is restored and the ciphertext payload is decrypted.

[0012] When the threshold is not reached or the path is abnormal, the system will perform retransmission, channel switching or degradation procedures according to the preset state machine to maintain liveness and fairness.

[0013] Furthermore, the minimum visible header includes at least a network identifier, a cost bucket identifier, and a random salt; the bit length of the random salt is preferably not less than 96 bits; the cost bucket identifier is obtained by mapping the cost from fine-grained values ​​to discretized buckets to suppress selective rejection by cost clustering.

[0014] Furthermore, the sealed data frame satisfies a three-segment structure: the minimum visible header, the ciphertext payload obtained by symmetric encryption, and the threshold-timed encapsulation, which are sequentially assembled by fields in a fixed order.

[0015] Furthermore, the specific implementation of a one-way verifiable sequential calculation for each share includes:

[0016] For each threshold share of the symmetric key, a sequential working function is executed to generate a corresponding sequential proof. The threshold share, sequential proof, and common parameters are used to form a threshold timing encapsulation. The sequential working function is a verifiable delay function (VDF) or an equivalent one-way verifiable sequential computation process.

[0017] Furthermore, the threshold timing encapsulation specifically includes:

[0018] =

[0019] in, For the i-th key share, For the sequential proof, Delayed for the goal, for -of- The threshold share number obtained by threshold segmentation Given the total number of shares, any t shares can be used to recover the original key.

[0020] pp represents the set of public parameters for the sequential work and its proof system, and vk represents the verification key material used to verify the share-order sequential proof. And the public verification elements of its aggregate proof.

[0021] Furthermore, the batch verification specifically includes:

[0022] The sequential proof set is aggregated or batch verified in parallel. Only when the number of shares that pass verification is not less than the threshold t, the symmetric key is restored and the ciphertext payload is unsealed. Shares that fail verification or are duplicated are marked and removed to avoid the same share being counted repeatedly.

[0023] Furthermore, the step of aligning the disclosure window with the validity period metadata of the operation object specifically includes:

[0024] The disclosure window The validity period of the operation object satisfy:

[0025]

[0026] in, Effective date For expiration time, To reveal the window's start time, Delaying the target sequence To provide a safety margin to cover network jitter and verification overhead, the disclosure window start time is quantified with fixed granularity.

[0027] Furthermore, the process of submitting the multiple independent communication paths to multiple aggregation nodes satisfies

[0028]

[0029] in, For the number of communication paths, For threshold, To allow an upper bound on the offline path, Maximum latency to the target end For the costs of online dissemination and collection, This is for the cost of batch verification and unblocking.

[0030] On the other hand, the present invention also provides a system for implementing the method, including a header generation module, an inner sealing module, a threshold timing encapsulation module, a sealing frame construction and multiple submission module, a unified disclosure and batch verification module, an expiration date alignment module, and a rollback control module.

[0031] The head generation module is used to generate the minimum visible head that is visible during the propagation phase;

[0032] The inner sealing module is used to symmetrically encrypt the object being operated on and generate a ciphertext payload.

[0033] The threshold timing encapsulation module is used to execute the key. -of- Thresholding; and applying sequential work to each share to form a share-level time lock and a proof that can be quickly verified;

[0034] The sealed frame construction and multiple submission module is used to sequentially assemble the minimum visible header, encrypted payload and threshold timing encapsulation into a sealed data frame in a three-segment structure, and send it to multiple aggregation nodes via multiple mutually exclusive paths.

[0035] The unified disclosure and batch verification module is used to collect at least [data / information] within a preset disclosure window. Prove the valid shares and their order, perform aggregated or parallel batch verification; recover the key and decrypt the ciphertext payload after the threshold condition is met;

[0036] The validity period alignment module is used to align the disclosure window with the validity period metadata of the operation object in terms of time.

[0037] The rollback control module is used to trigger retransmission, channel switching, or degradation strategies based on a preset state machine when the threshold is not reached within the disclosure window, any route fails, or an anomaly occurs.

[0038] Furthermore, it also includes a parameter coordination unit for announcing and verifying the sequential work difficulty, disclosure window width, and cost bucket width at the epoch level; and a frame-level commitment or unique identifier for route deduplication and initial integrity checks, which is calculated based on the minimum visible header, ciphertext payload, and threshold timed encapsulation and preferably uses a domain-separated truncated hash.

[0039] The beneficial effects of this invention are as follows: By adopting a three-segment sealed frame, only the necessary fields of the minimum visible header are exposed, reducing the risks of linkability, profiling, and preemption; during the disclosure phase, a share-level order proof based on a verifiable delay function (VDF) combined with a unified disclosure window establishes a clear inclusion relationship between disclosure and validity period, achieving controlled synchronous unsealing that is not parallelizable but can be quickly verified without the need for a trusted clock, improving sorting fairness and reducing invalidation and tail delay; under partial failure conditions, liveness is maintained by relying on multi-way commit and rollback state machines, and the operating parameters meet the liveness and delay boundaries; aggregated / parallel batch verification combined with epoch-level difficulty coordination stabilizes the verification end overhead; parameters are aligned with versioned announcements to ensure cross-implementation consistency and provide a safe degradation path; frame-level commitments and verification contexts support route deduplication and initial integrity checks without unsealing, facilitating auditing and accountability; the overall solution is compatible with existing execution entry points and is easy to deploy by bypass. Attached Figure Description

[0040] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the embodiments 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.

[0041] Figure 1 This is a system architecture block diagram provided in an embodiment of the present invention;

[0042] Figure 2 This is a schematic diagram of the sealing frame structure provided in an embodiment of the present invention;

[0043] Figure 3 This is a schematic diagram illustrating the alignment timing provided in an embodiment of the present invention;

[0044] Figure 4 This is a schematic diagram of the rollback state machine provided in an embodiment of the present invention.

[0045] For ease of understanding, identical or similar components in the accompanying drawings are represented by the same reference numerals; the designation "×N" indicates multiple channels / multiple instances; the drawings are not drawn to scale and are for illustrative purposes only. The meanings of the reference numerals in the drawings are as follows:

[0046] Functional modules: 100—Header generation module; 110—Inner sealing module; 120—Threshold timing encapsulation module; 130—Multi-channel submission module; 140—Revelation and batch verification module; 150—Execution module; 160—Rollback control module; 170—Parameter coordination unit.

[0047] Equipment / Terminals and Channels:

[0048] 200—Wallet device; 300—Aggregator node cluster; 400—Revelation / verification end; 500—Execution entry point; 601—Multi-path submission × N.

[0049] Data structure: 210—Minimum visible header; 211—Network identifier; 212—Fee bucket identifier; 213—Random salt; 220—Ciphertext payload; 230—Threshold-timed encapsulation; 231—Share entry; 232—Parameter area.

[0050] Timer: 610 — Send Timer 620—Window Timer 630—Retry Timer .

[0051] Timing and parameters: 710—Start point of disclosure window; 720—Target delay; 730—Safety margin; 740—Effect time; 750—Failure time; 760—Disclosure window; 770—Threshold t; 780—Number of paths N; 790—Threshold trigger point.

[0052] Status and process: 801—Pending to send; 802—Revealing waiting; 803—Unblocking; 804—Executing; 805—Success. Detailed Implementation

[0053] To better understand the technical solution of this application, the embodiments of this application will be described in detail below with reference to the accompanying drawings.

[0054] It should be understood that the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0055] The terminology used in the embodiments of this application is for the purpose of describing particular embodiments only and is not intended to be limiting of this application. The singular forms “a,” “the,” and “the” used in the embodiments of this application and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise.

[0056] This invention provides a method for multi-way sealed submission and threshold-timed disclosure of on-chain operations, achieving fair disclosure and robust execution without revealing operational details. This method minimizes information exposure during propagation, performs controlled synchronization during disclosure, and maintains liveness under partial failure conditions, making it suitable for open network environments. When sequential operations are instantiated as VDFs, non-parallel delays can be introduced at the generation end, and verification can be completed at the verification end at a cost far lower than the generation overhead, thereby achieving provable synchronous disclosure without relying on trusted timing; including:

[0057] S1. Generate a minimal visible header for minimal exposure during the propagation phase, carrying only the fixed fields necessary for routing and deduplication;

[0058] Specifically, based on the configuration and cost strategy of the target chain or network, a minimum visibility header (MinHeader) is generated for the operation object to be processed. This header contains only fixed fields necessary for routing and deduplication, such as NetworkID, BucketID, and random salt. In practice, one-time session random numbers can be introduced to reduce cross-batch correlation while maintaining minimum exposure. Furthermore, costs can be mapped from fine-grained values ​​to discrete buckets to suppress selective rejection by cost clustering.

[0059] Preferably, in this embodiment, the bucket width is updated based on recent network cost fluctuations, maintaining a reasonable price discovery granularity while reducing the profile size. A linear-squeezed update driven by rolling statistics is employed.

[0060] ( + )

[0061] in For the next era, the bucket width, For the first Epoch cost dispersion For the scaling and translation coefficients, Width and random salt length are uniformly announced in the versioned parameter list.

[0062] S2. Encrypt the operation object with a symmetric key to obtain the ciphertext payload, and use the smallest visible header as associated data to participate in integrity protection.

[0063] Specifically, for the operation object Generate symmetric key , obtain the encrypted payload A fixed subset of MinHeader is used as associated data for AEAD to bind the header and payload, preventing swapping and mismatching. The operation object can carry validity period metadata for subsequent time alignment with the disclosure window. The AEAD is an authentication encryption system with associated data, which is used to bind the fixed subset of MinHeader and necessary business fields such as paymasterAndData.

[0064] S3. Divide the symmetric key into t-of-n threshold segments, and perform a verifiable delay function (VDF) or an equivalent one-way verifiable sequential computation on each segment to form a threshold timing encapsulation carrying sequential proof, so that the segments can be verifiably revealed within the expected time window.

[0065] Specifically, for implement -of- Thresholding divides the symmetric key into n parts. Given the total number of shares, obtain the share set. , Let t be the threshold number of shares. Taking any t shares will recover the original key. Sequential processing is then applied to each share to generate a sequential proof. This forms a threshold-timed encapsulation called Cap. Sequential operation introduces non-parallel time delays at the computational level, while ensuring that verification is completed at a cost far lower than the generation overhead at the verification end; in terms of implementation, techniques equivalent to Shamir secret sharing and VDF algorithms can be used.

[0066] Cap carries the threshold share, sequence proof, and common parameters, and can be formalized as follows:

[0067] =

[0068] in, For the i-th key share, The target delay is specified. Cap optionally carries a key commitment for post-reconstruction consistency verification. The batch verification metadata includes auxiliary information required for aggregation verification, such as the share index sequence, domain separation label, and aggregation factor. and Together they constitute the verification context.

[0069] `pp` represents the public parameter set used for sequential operation and its proof system, defining the computational domain and difficulty. It is denoted as... in For sequential work / proof system identification, For group / domain or modulus parameters, For generators or base point sets, The difficulty / steps parameter is determined by the target delay. Mapped from, For domain separation tags, This refers to the version / epoch number. The specific components can be replaced with equivalents depending on the implementation.

[0070] vk is the key verification material used to verify the share-order proof. The public verification elements of its aggregate proof may include a verification key, a verification circuit digest, or a commitment. (Note: The last part is a typographical notation and doesn't need a direct translation.) in Refers to the selection of verification algorithm family / parameters. Additional constants (such as generating meta-vectors, structured reference string summaries, etc.) are required for verification. Version / epoch number. vk can be generated by Derivatives may be announced with the Epoch.

[0071] Sequential work difficulty is specifically used to determine common parameters and target delays based on epoch release or collaborative update sequence, stabilize the load on the verification end, and avoid parameter drift between implementations. A closed-loop adjustment rule is employed.

[0072] = clamp ( (1+ (( - ) ), ),

[0073] in For the first The difficulty of an era The measured median reveals the calculation delay for this era. An acceptable delay for the current era. To adjust the step size, Common parameters are distributed in the form of signed parameter announcements, and the verification end performs source and integrity checks.

[0074] S4. Construct sealed data frames and submit them to multiple aggregation nodes via N independent communication paths to reduce the impact of selective rejection and single point of failure;

[0075] Specifically, the MinHeader and encrypted payload are structured in three segments according to equation (1). The Cap is sequentially spliced ​​into a sealed frame, and then... Each independent communication path is submitted to multiple aggregation nodes for caching and forwarding; path independence can be guaranteed from dimensions such as network topology, peer entity or key negotiation to improve robustness against selective rejection and single point of failure.

[0076] Frame (sealed data frame): The sending unit, satisfying the three-segment structure of equation (1):

[0077]

[0078] in For encrypted payload, This is for commitment / verification information used for disclosure and verification.

[0079] The Frame satisfies the three-segment structure of Equation (1); MinHeader is a fixed set of fields necessary for routing and deduplication (e.g., NetworkID, BucketID, Salt), and does not contain key derivation material or operation details. To reduce linkability, the bit length of the random salt preferably satisfies the following: .

[0080] Ciphertext payload AEAD is preferred, and associated data should be bound to at least a fixed subset of MinHeader to prevent data swapping and mismatching. For ease of parsing and backward compatibility, Frame can be configured with a version field and a length prefix.

[0081] Preferably, in this embodiment, without changing the three-segment structure, a versioned optional extension area is set to accommodate newly added fields (such as anti-replay counter, path health summary, and selective rejection evidence pointer). The extension area is explicitly marked with version and type code, and the old version parser can still complete the core process when skipping unknown type codes; if necessary, multi-signature or threshold signature can be added to the extension area to serve governance and auditing.

[0082] S5. Time-align the disclosure window with the validity period metadata of the operation object so that the disclosure and verification activities fall within the validity period in a controlled manner; collect at least t valid shares within the preset disclosure window and perform batch verification; when the threshold condition is met, restore the symmetric key and decrypt the ciphertext payload.

[0083] Specifically, the display window is denoted as The starting point of the window is denoted as... The validity period is denoted as For each batch of reveal windows The validity period of the operation object Aligned with this window, the execution entry point can directly determine the active boundary during the simulation phase; the two satisfy the inclusion relationship of equation (2):

[0084]

[0085] in To provide a safety margin for network coverage and verification of jitter.

[0086] To reduce jitter and facilitate batch alignment, the window start time is set to a fixed granularity. Quantification:

[0087] =

[0088] in This refers to the current moment. Different implementations can share the same... To increase the probability of achieving simultaneous unblocking across regions.

[0089] Upon reaching the preset reveal window, collect at least [data / resources] from the aggregation node. Prove the valid shares and their order, perform aggregated or parallel batch verification; recover the key when a threshold condition is met. And lifted the lockdown get .

[0090] Under the conditions of multi-path submission and threshold disclosure, the number of paths, the threshold limit, and the upper bound of allowed offline paths satisfy equation (3-1), and the end-to-end delay satisfies equation (3-2):

[0091]

[0092]

[0093] in Number of communication paths Tolerable upper bound for offline paths, Upper bound of end-to-end target delay and These are network and verification time estimates, respectively.

[0094] To constrain the synchronization of the display, define the display skew within the window.

[0095]

[0096] in For the first The earliest time revealed by this path, This is the synchronization deviation threshold.

[0097] S6. When the threshold is not reached or the path is abnormal, retransmission, channel switching, or degradation procedures are executed according to the preset state machine to maintain liveness and fairness. Specifically, to deal with long tail and abnormal situations, when the threshold is not reached within the disclosure window, any path fails, or selective rejection occurs, retransmission, channel switching, or degradation is performed according to the preset fallback state machine to maintain liveness and steady-state throughput; the relevant processes can set sending, window, and retry timers, and record failure evidence for auditing or punishment.

[0098] The selective rejection detection and threshold triggering process includes: performing bucket statistics on the reception / disclosure behavior of each path or peer to identify potential biases or rejections. A reception rate differential statistic is defined.

[0099] =

[0100] The superscript r represents the actual transmission path, and ¬r represents the set of reference transmission paths other than r. It is the receiver rate difference (the absolute difference between two receiver rates), used to detect potential bias or rejection.

[0101] when or Or the threshold is not met within the window. When this occurs, the fallback state machine is triggered to perform retransmission, channel switching, or degradation. An abnormal reception threshold set manually.

[0102] Preferably, in this embodiment, to ensure cross-implementation consistency, the sequential working parameters, disclosure window width, cost bucket width, and related thresholds are all identified in the parameter announcement by version number or epoch number and signed by the governance key; the verification end performs a version alignment check before each batch verification, and enters the security degradation path when there is inconsistency.

[0103] Preferably, in this embodiment, MinHeader, Cap adopts a standardized, uniquely decodable TLV encoding and decoding scheme, with fixed field order and type code; Frame can contain frame-level commitments or authentication tags, used to achieve route-level deduplication and initial integrity checks without decrypting the ciphertext (the specific calculation method of the commitment is not limited to a single formula).

[0104] Parsing follows the sequence "header → ciphertext → encapsulation," while verification follows the sequence "structure and version → field validity → frame-level commitment → batch verification preparation → decapsulation after threshold is reached." The implementation layer can uniformly use big-endian or variable-length integer encoding, and field names and value ranges are published fixedly in the system parameter document.

[0105] This embodiment combines Figure 3 and Figure 4 This describes the unified disclosure and expiration date alignment mechanism on the timeline, as well as the parameter constraints and rollback state machine used to ensure activity and fairness. This embodiment is not limited to a specific underlying platform. A disclosure window is set for each batch. And require the validity period of the operation object. The inclusion relationship between the window and equation (2) allows the execution entry point to determine the active boundary during the simulation phase, reducing invalid computation and tail latency; to reduce jitter and facilitate batch alignment, The time slot quantization rules described in Section VI are used for determination, and the formula will not be repeated here.

[0106] During the disclosure phase, each distinct path 601 submits proof of its shareholding and order. Figure 3 (Multiple horizontal lines indicate the timing of each path's reveal); when at least... When a valid share is reached, the key is recovered and unsealed at threshold trigger point 790. The unsealed operation object is then submitted to the execution entry point to complete the simulation and on-chain processing. System operation simultaneously adheres to liveness and latency boundaries: the number of paths, threshold limits, and the upper bound of allowed offline paths satisfy equation (3-1), and the end-to-end latency satisfies equation (3-2). To constrain the disclosure synchronization within the window, a defined disclosure skew is used. And it is required that it does not exceed the synchronization deviation threshold. .when The threshold has been exceeded or the window has expired. When this occurs, it is determined as an "unaligned / threshold not reached" event.

[0107] Abnormal handling adopts Figure 4The rollback state machine shown includes the following state sets: pending transmission, reveal waiting, unsealing, execution, and success. Abnormal branches include window timeout, threshold not reached, and path failure. The state machine is configured with a transmission timer 610, a window timer 620, and a retry timer 630. When window timer 620 expires without triggering the threshold, the machine switches to the retransmission branch. If a path failure or abnormal reception rate is detected, channel switching is triggered. If multiple retries still fail to reach the threshold, a degradation strategy (such as switching to a backup / private channel) is executed. Rollback control is linked with the multiple commit, reveal, and batch verification modules via an event bus to ensure that repeated unsealing or repeated on-chaining does not occur during a single degradation process.

[0108] To stabilize the load on the verification end and suppress parameter drift between implementations, parameter coordination unit 170 operates on common parameters and target delays according to the epoch release order, and adjusts the difficulty parameters according to the closed-loop rules given in aspect six. The parameter announcement carries the version / epoch number and signature. The verification end performs a version alignment check before batch verification; if inconsistencies are found, a security degradation path is initiated. To meet the target maximum latency, when equation (3-2) is detected to be potentially corrupted, parameter coordination is prioritized for improvement. Epochal stability and convergence The backoff state machine reduces unnecessary path switching and increases the parallelism of single retransmission to avoid amplifying tail delay.

[0109] In summary, timing alignment, activity / synchronization constraints, rollback control, and epoch parameter coordination form a closed loop, enabling simultaneous unsealing of operations within the same bucket within a unified window, maintaining threshold probability and fairness under unfavorable network conditions, and providing an auditable degradation path throughout the entire process.

[0110] Without altering the aforementioned terminology and mechanisms, the "operation object / aggregation node / execution entry point / validity period metadata" are mapped to the UserOperation, Bundler, EntryPoint contracts, and validAfter / validUntil fields in the ERC-4337 ecosystem, respectively; the alternative queue corresponds to alt-mempool. The icon numbers in the attached diagrams follow the aforementioned definitions.

[0111] Wallet device 200 discretizes the fee parameters of UserOperation (such as maxFeePerGas, maxPriorityFeePerGas) according to network congestion and maps them to the fee bucket identifier BucketID, generating a minimum visible header 210. Inner sealing module 110 performs AEAD encryption on UserOperation containing fields such as sender, nonce, callData, signature, paymasterAndData, validAfter / validUntil to obtain ciphertext payload C. The associated data is bound to at least a fixed subset of MinHeader and paymasterAndData to prevent field swapping during the propagation stage. Threshold timing encapsulation module 120 performs t-of-n segmentation on the symmetric key and calculates the share-level sequential proof to form Cap. In this embodiment, VDF is selected as the sequential working system to take into account verifiability and high-concurrency batch verification. Multi-way submission module 130 frames the data into Frames according to the three-segment structure of Equation (1), and then... 601 Paths that are independent of each other in terms of peer entity or key negotiation are concurrently submitted to multiple Bundlers (aggregator node cluster 300).

[0112] like Figure 3 As shown, the 400 maintenance disclosure window is displayed on the disclosure / verification end. And align UserOperation's validAfter and validUntil with the window to satisfy equation (2); each Bundler submits its share and order proof within the window period, collecting at least After valid shares are verified through batch processing, the key is recovered and C is unsealed to obtain UserOperation. Subsequently, according to the ERC-4337 standard process, simulateValidation and handleOps are executed sequentially through EntryPoint to complete the on-chain process. To ensure liveness and fairness, the number of paths and the threshold satisfy equation (3-1), and the end-to-end latency satisfies equation (3-2). When the window expires before the threshold is reached, the path fails, or selective rejection occurs, the fallback control module 160 triggers retransmission or channel switching according to the state machine in Figure 4, uniformly revealing that the window still has the first priority, and only when necessary will a private channel be used as a backup.

[0113] To facilitate project implementation, a set of example configurations compatible with the above boundaries are provided: , , , The width of the cost bucket is based on the base fee. Random salt length Revealing the granularity of time slots Pick Suppress jitter; the verification end uses aggregated / parallel batch verification to ensure... Convergence to sub-hundreds of milliseconds. Parameter Coordination Unit 170: Difficulty, target latency, and bucket width based on epoch release order. The verification end performs a version alignment check before batch verification and signs the announcement.

[0114] In one specific scenario, several UserOperations with the same BucketID from 200 pairs of wallet devices are displayed in the same window. Send within the window; when the threshold is reached within the window period. Unsealing is done uniformly, allowing UserOperations within the same bucket to participate in price discovery, significantly suppressing front-running and filtering based on plaintext mempools. To enhance tamper resistance, Cap can carry a key commitment for consistency verification after unsealing; to reduce connectivity, MinHeader does not contain profile fields such as sender, nonce, and function selectors.

[0115] Corresponding to the aforementioned embodiment of the on-chain operation multiple sealed submission and threshold timing disclosure method, the present invention also provides an embodiment of the on-chain operation multiple sealed submission and threshold timing disclosure system.

[0116] like Figure 1 As shown, the system, from left to right, includes: a wallet device 200, an aggregation node cluster 300, a reveal / verify terminal 400, and an execution entry point 500. The wallet device 200 contains a header generation module 100, an inner sealing module 110, a threshold timing encapsulation module 120, a multi-way submission module 130, and a rollback control module 160. The reveal / verify terminal 400 contains a reveal and batch verification module 140 and a parameter coordination unit 170. The execution entry point 500 contains an execution module 150. The wallet device 200 and the aggregation node cluster 300 concurrently transmit sealed data frames through multiple mutually exclusive communication paths 601 (shown as "×N"). During the reveal phase, the aggregation node cluster 300 and the reveal / verify terminal 400 exchange shares and sequence proofs. After reaching the threshold condition, the reveal / verify terminal 400 submits the unsealed operation object to the execution entry point 500 to complete the simulation and on-chain processing.

[0117] The header generation module 100 is used to generate the minimum visible header (MinHeader) during the propagation phase. For example... Figure 2As shown, MinHeader 210 includes at least: a network identifier 211, a cost bucket identifier 212, and a random salt 213; the cost is mapped to discrete buckets in a fine-grained manner to suppress selective rejection by cost clustering, and the random salt is used to break static fingerprints. MinHeader does not contain key derivation material or operation details, thus limiting the leakage surface from the source.

[0118] The inner sealing module 110 is used to symmetrically encrypt the operated object and generate ciphertext payload. AEAD is preferred, and the associated data includes a fixed subset of MinHeader 210 to bind the header and payload, resist "swapping / mixing", and enhance end-to-end integrity. The operation object can carry validity period metadata for subsequent time alignment with the disclosure window (see Equation (2)).

[0119] Threshold timing encapsulation module 120 is used for key implement -of- Thresholding is used to divide the data into segments and apply sequential work to each segment to form a segment-level time lock and a proof that can be quickly verified. Optionally, VDF can be used to perform a non-parallel sequential computation on each segment to obtain the corresponding sequential proof. If you want to "reveal" any segment, you must complete a sequential work of a certain number of steps / difficulty τ, which takes about the same time as the target delay Δ. On the verification side, however, you can use common parameters to perform fast (batch) verification.

[0120] The Cap consists of a set of share entries and a parameter area; see [link to details] for specific fields and notations. Figure 2 and Cap, , The module defines the target sequence delay and the common parameters required for verification, which are then used for batch verification.

[0121] The multiplexed submission module 130 is used to submit the MinHeader and the encrypted payload. The three segments of Cap are sequentially assembled in the three-segment structure of Equation (1) to form a sealed data frame Frame, and sent to multiple aggregation nodes via multiple mutually independent paths 601; the paths remain independent of each other in terms of network topology, peer entity or key negotiation, so as to enhance liveness and resist selective rejection.

[0122] The aggregation node cluster 300 is used to cache and forward sealed data frames, and submits its holding threshold share and order proof to the reveal / verify end 400 during the reveal phase.

[0123] The disclosure and batch verification module 140 collects at least [data / information] within a preset disclosure window. Prove the valid shares and their order, and perform aggregated or parallel batch verification; resume after reaching the threshold condition. And lifted the lockdown The unsealed operation object is submitted to the execution entry point 500, where the execution module 150 completes the simulation and on-chain processing. The parameter coordination unit 170 is used to announce and verify common parameters such as sequential work difficulty, disclosure window width, and cost bucket width at the epoch level to stabilize the load on the verification end and maintain cross-implementation consistency.

[0124] The rollback control module 160 is used to trigger retransmission, channel switching, or degradation strategies based on a preset state machine when the threshold is not reached within the disclosure window, any route fails, or an anomaly occurs, in order to ensure activity under partial failure conditions. The system operating parameters are configured according to equations (3-1) and (3-2) to meet the requirements of the activity boundary and the upper limit of the end-to-end delay. The alignment relationship between the disclosure window and the validity period follows equation (2), which will not be repeated in this section.

[0125] It should be noted that, Figure 1 and Figure 2 The illustration only shows the core structure and data relationships, and does not depict details that are unrelated to this invention or can be directly inferred by those skilled in the art; the above module names are used for functional indication and do not constitute a limitation on physical boundaries, and the software / hardware implementation and the merging or splitting of modules are all equivalent transformations of this invention.

[0126] Without departing from the spirit and essence of this invention, each functional module of the system can be implemented by software modules, hardware circuits, or a combination of software and hardware; the module name is only a functional division and does not constitute a limitation on the physical boundary. In specific implementation, modules can be merged or split as needed, and their technical effects are equivalent.

[0127] Corresponding to the aforementioned embodiment of the on-chain operation multiplexing sealed submission and threshold timing disclosure method, this invention also provides an embodiment of an on-chain operation multiplexing sealed submission and threshold timing disclosure device. It includes a processor, a memory, and a network interface; the program instructions stored in the memory, when executed on the processor, cause the device to complete the collaborative process of header generation, inner sealing, threshold timing encapsulation, sealed frame construction and multiplexing, unified disclosure and batch verification, validity period alignment, and rollback and liveness assurance according to the method of the first aspect. The device can be configured with a secure random number generator and a secure clock for key generation and disclosure window verification; optionally, a sequential work acceleration unit can be configured to reduce the computational overhead at the encapsulation or verification end.

[0128] In one embodiment, the device is deployed as a wallet device. The device generates a minimal visible header (MinHeader) containing only fixed fields necessary for routing and deduplication; it generates a symmetric key and performs AEAD encryption on the target object to obtain a ciphertext payload (C), where a fixed subset of the MinHeader serves as associated data to bind the header and payload. The device executes the key... -of- Thresholding is applied to each share and sequential processing is applied to form a Cap, which is then framed according to Equation (1) and submitted to multiple aggregation nodes via N independent communication paths. The device sets the disclosure window based on the validity period metadata to satisfy Equation (2) with the validity period in order to reduce invalid simulations and tail latency.

[0129] In another embodiment, the device is deployed as an aggregation node. This device receives and caches frames from multiple communication paths, maintaining path health and transmission status; when a disclosure window arrives, it submits its held threshold share and order proof to the disclosure / verification side, or coordinates with other nodes to meet the threshold conditions; it marks and reports missing or invalid shares, and triggers retransmission or channel switching according to a preset backoff strategy to improve activity and resistance to selective rejection.

[0130] In another embodiment, the device is deployed as a reveal / verify terminal. Within the reveal window, the device collects at least t valid shares and their sequential proofs, performs aggregated or parallel batch verification; upon reaching the threshold, it recovers the key and decrypts the ciphertext C, submitting the decrypted operation object to the execution entry point for subsequent processing. To meet the liveness and end-to-end latency targets, the verification terminal's operating parameters are configured according to equations (3-1) and (3-2), and it handles abnormal situations and scenarios where the threshold is not reached in conjunction with the rollback state machine.

[0131] To enhance key and share security, the device may include a TEE or SE for storing keys, threshold shares, and verification parameters. The device can also publish epoch-level parameters (including sequential work difficulty, reveal window width, and fee bucket width) and sign and verify parameter updates to avoid verification inconsistencies caused by parameter drift. The aforementioned wallet device, aggregation node device, and reveal / verify terminal device can be implemented in the same physical device or deployed in a distributed manner and interact through a network, achieving equivalent technical results.

[0132] This invention also provides a computer-readable storage medium or computer program product, wherein program instructions are stored on the medium; when the instructions are executed by a processor of a device, the device performs the process described in the first aspect and produces verifiable technical effects. The medium may be a read-only memory, a random access memory, a magnetic or optical storage medium, flash memory, or a combination thereof.

[0133] When the program instructions are executed, the device performs the following: generates a MinHeader and performs AEAD encryption on the object being operated on to obtain the ciphertext payload. ;Execute on key -of- Threshold segmentation and calculation of share class order proves the formation of Cap; frame according to the three-segment structure of Equation (1) to form Frame and via Multiple submissions are made through independent paths; shares are collected within the disclosure window and aggregated or batch verified in parallel. After reaching the threshold, the key is recovered and the object is unsealed; at the same time, the disclosure window and validity period are guaranteed to satisfy equation (2), and the running parameters are guaranteed to satisfy equation (3-1) and equation (3-2).

[0134] To ensure the reliability and security of program updates, the program product preferably includes a digital signature verification and rollback mechanism; the parameter file and public key materials are verified for origin and integrity during loading; and a rollback state machine is triggered and auditable failure evidence is generated in the event of an anomaly. The program product can be provided as a standalone installation package or pre-installed in the device as firmware, both of which fall within the scope of protection of this invention.

[0135] The above embodiments are used to explain and illustrate the present invention, but not to limit the present invention. Any modifications and changes made to the present invention within the spirit and scope of the claims shall fall within the protection scope of the present invention.

Claims

1. A method for on-chain operation with multiple sealed submissions and threshold timing disclosure, characterized in that, The method comprises: generating a minimum visible header for the minimum exposure of the propagation phase, only carrying fixed fields necessary for routing and deduplication; encrypting the operation object using a symmetric key to obtain a ciphertext payload, taking the minimum visible header as associated data; splitting the symmetric key according to a t-of-n threshold, and performing a one-way verifiable sequential calculation on each share to form a threshold time capsule carrying a sequential proof, so that the share can be verifiably revealed within an expected time window; constructing a sealed data frame using the minimum visible header, the ciphertext payload and the threshold time capsule, and submitting to multiple aggregation nodes via multiple independent communication paths; time-aligning the reveal window with the validity period metadata of the operation object, collecting at least t valid shares within the preset reveal window and performing batch verification, recovering the symmetric key and unsealing the ciphertext payload when the threshold condition is met; when the threshold is not met or the path is abnormal, performing retransmission, channel switching or degradation process according to a preset state machine to maintain activity and fairness.

2. The method of on-chain operated multi-path sealed commitment and threshold-timed reveal according to claim 1, wherein, The minimum visible header at least includes a network identifier, a fee bucket identifier and a random salt; the bit length of the random salt is not less than 96 bits; the fee bucket identifier is obtained by mapping the fee from a fine-grained value to a discretized bucket to suppress selective rejection according to the fee clustering.

3. The method of on-chain operated multi-path sealed commitment and threshold-timed reveal according to claim 1, wherein, The sealed data frame satisfies a three-section structure: the minimum visible header, the ciphertext payload obtained by symmetric encryption and the threshold time capsule are sequentially spliced in a fixed order.

4. The method of on-chain operated multi-path sealed commitment and threshold-timed reveal according to claim 1, wherein, The one-way verifiable sequential calculation performed on each share specifically comprises: performing a sequential work function on each threshold share of the symmetric key to generate a corresponding sequential proof, and using the threshold share, the sequential proof and a public parameter to form a threshold time capsule; the sequential work function is a verifiable delay function VDF or an equivalent one-way verifiable sequential calculation process.

5. The method of on-chain operated multi-path sealed commitment and threshold-timed reveal according to claim 4, wherein, The threshold time capsule specifically comprises: = ； wherein, is the i-th key share, is the sequential proof, is the target delay, is -of- is the threshold number of threshold shares resulting from the threshold split, is the total number of shares, and any t shares enable recovery of the original key, pp is a public parameter, and is a public parameter set of the sequential work and its proof system, vk is a verification key material, and is used to check the share-level sequential proof and the public verification element of its aggregate proof.

6. The method of on-chain operated multi-path sealed commitment and threshold-timed reveal according to claim 5, wherein, The batch verification specifically comprises: performing aggregation verification or parallel batch verification on the sequential proof set, recovering the symmetric key and unsealing the ciphertext payload only when the number of verified shares is not less than the threshold t, and marking and removing the shares that fail to verify or repeat to avoid repeated counting of the same share.

7. The method of on-chain operated multi-path sealed commitment and threshold-timed reveal according to claim 1, wherein, The time alignment of the reveal window and the validity period metadata of the operation object specifically comprises: The reveal window The valid period interval of the operation object Satisfies: ； wherein, is the effective time, is the invalidation time, is the reveal window start time, is the target delay, is a safety margin to cover network jitter and verification overhead, wherein the reveal window start time is quantized in fixed granularity.

8. The method of on-chain operated multi-path sealed commitment and threshold-timed reveal according to claim 1, wherein, The multiple independent communication paths satisfy ； wherein, is a number of communication paths, is a threshold limit, is an allowed offline path upper bound, is a maximum latency indicator to an end target, is a network propagation and collection overhead, is a bulk verification and unsealing overhead.

9. A system for implementing the method of any one of claims 1 to 8, characterized in that, comprises a header generation module, an inner sealing module, a threshold time capsule module, a sealed frame construction and multi-path submission module, a unified reveal and batch verification module, a validity period alignment module and a fallback control module; The header generation module is used to generate a minimum visible header visible in the propagation phase; The inner sealing module is used to symmetrically encrypt the operation object and generate a ciphertext payload; The threshold timing encapsulation module is configured to perform -of- threshold cut; and sequentially work on each share to form a share-level time lock and a quickly verifiable proof; The sealed frame construction and multi-path submission module is used to sequentially splice the minimum visible header, the ciphertext payload and the threshold time capsule in a three-section structure to form a sealed data frame, and send the sealed data frame to multiple aggregation nodes via multiple different paths; The unified reveal and batch verification module is used to collect at least shares of valid shares and their order proofs, perform aggregated or parallel batch verification; recover the key and unseal the ciphertext payload after reaching the threshold condition; The validity period alignment module is used to time-align the reveal window with the validity period metadata of the operation object; The rollback control module is used to trigger retransmission, channel switching or degradation strategy according to a preset state machine when the threshold is not reached in the exposure window, any route fails or an exception occurs.

10. The system of claim 9, wherein, It also includes a parameter coordination unit for announcing and checking the sequential work difficulty, exposure window width and fee bucket width at the epoch level; and a frame level commitment or unique identification for route deduplication and integrity preliminary inspection, which is calculated based on the minimum visible header, ciphertext payload and threshold timing encapsulation and uses domain-separated truncated hash.

Images