Block chain state fragmentation method based on shadow state structure

Abstract

The invention discloses a shadow state-based block chain state fragmentation method. According to the method, a portal committee is established in each fragment and is responsible for transaction processing and state synchronization. A shadow state is created in a target fragment for a frequent cross-fragment interaction account, so that a relatively low cross-fragment transaction proportion is realized; according to the method, transaction types are distinguished through double-address state tree addressing, cross-slice transactions capable of achieving on-slice processing through shadow states are rapidly distinguished, asynchronous state synchronization and atomic cross-slice transaction protocols are adopted to assist cross-slice transaction processing, and the system throughput is improved while final consistency is guaranteed. According to the method, the problems of low node redistribution efficiency, high cross-chip transaction processing delay and high energy consumption in the existing dynamic fragmentation scheme are effectively solved, and the inter-chip communication efficiency and the overall transaction processing performance of the system are remarkably improved.

Description

TECHNICAL FIELD

[0001] The application belongs to the technical field of blockchains, and particularly relates to a method for optimizing transaction efficiency in a sharded blockchain system by introducing a shadow state mechanism. BACKGROUND

[0002] Blockchain has attracted widespread attention due to its decentralization and tamper resistance, but its scalability problem is the main bottleneck restricting its large-scale application. Sharding technology, which divides the network and state into multiple parallel processing shards, is considered the most promising solution to improve blockchain throughput.

[0003] However, existing dynamic sharding schemes still have many challenges in practical applications. On the one hand, as the network load changes, frequent redistribution of nodes and states between shards is required, which is usually inefficient, consumes a lot of computing resources, and may cause network instability. On the other hand, the processing of cross-shard transactions is still a bottleneck. Most schemes rely on complex cross-shard communication protocols, requiring multiple interactions between multiple shards to complete a transaction. This multi-step, synchronous communication mode results in high cross-shard transaction latency and high energy consumption, and as the network load increases, the communication overhead grows exponentially, severely restricting the full potential of sharding technology. Therefore, how to design a new mechanism that can both reduce cross-shard transaction rates and efficiently process cross-shard transactions while ensuring global state consistency has become a key problem in the field of sharded blockchains. SUMMARY

[0004] The application provides a blockchain state sharding method based on a shadow state structure, which fundamentally solves the core pain points of low cross-shard transaction efficiency in existing sharding technology through structural innovation and mechanism optimization.

[0005] A blockchain state sharding method based on a shadow state, characterized in that the method comprises the following steps: S1, dividing the blockchain network into multiple shards and selecting a number of nodes in each shard to form a committee; an account creates a main state in the state tree of the corresponding shard, and when the account interacts frequently with other shards, a corresponding shadow state is created for the account in the target shard; S2, after the committee within the shard receives a transaction, it addresses the transaction in the local state tree according to the addresses of the transaction parties, queries whether there is a corresponding main state or shadow state, and divides the transaction into an intra-shard transaction or a cross-shard transaction according to the addressing result; S3, for intra-shard transaction processing, directly execute state changes within the current shard; if the transaction involves shadow state updates, after the transaction is completed, the shard committee asynchronously completes the synchronization of the state involved in the main / shadow state of each shard to achieve the final consistency of the state between shards; S4, for cross-shard transaction processing, the portal committee designates an account as a transaction shadow transit party, and coordinates the execution of the cross-shard transaction through an atomicity guarantee protocol.

[0006] The beneficial effects of the present application are: The present application significantly improves the efficiency of cross-shard transactions and system throughput. By converting most cross-shard transactions into efficient intra-shard transactions, the redundant cross-shard transaction communication delay is eliminated. This greatly reduces the transaction confirmation time and enables the shard network to process more transactions in parallel, fundamentally solving the performance bottleneck of existing shard technology.

[0007] The present application effectively reduces network communication and computing overhead. Shadow state updates only need to send lightweight incremental update packages, rather than synchronizing the entire state tree across the network. At the same time, by using simple Merkle proof, the system only needs to perform limited local hash recalculation, greatly saving computing resources, making state synchronization more rapid and efficient. And by maintaining a lightweight cross-shard routing table, high-speed routing and fast inter-shard communication are achieved.

[0008] The present application provides strong transaction atomicity and security guarantees while maintaining decentralization, effectively improving the processing efficiency of cross-shard transactions. Through token locking and timeout rollback, the atomicity of cross-shard transactions is ensured, and the risk of asset loss is eliminated. The synchronization identifier and proof field in the account state work together to ensure the consistency of state data on all shards, further improving the reliability of the system. BRIEF DESCRIPTION OF DRAWINGS

[0009] Figure 1 System model diagram of the present application.

[0010] Figure 2 Cross-shard transaction successful processing diagram of the present application.

[0011] Figure 3 Cross-shard transaction failure processing case one diagram of the present application.

[0012] Figure 4 Cross-shard transaction failure processing case two diagram of the present application. DETAILED DESCRIPTION

[0013] The blockchain state sharding method based on shadow state structure of the present application systematically solves existing problems through the following design: (1) Effectively reduce cross-shard transaction rate and improve overall system throughput. In the existing shard scheme, any interaction of an account with other shards will inevitably generate cross-shard transactions, and the complex multi-step negotiation mechanism is the main bottleneck for system efficiency improvement. The present application allows accounts that interact frequently with a specific shard to create a shadow state within that shard. This allows transactions that would otherwise require cross-shard negotiation to be processed directly within a single shard and completed through consensus, thus converting a large number of complex cross-shard transactions into simple and fast intra-shard transactions, significantly reducing the heavy overhead of the system caused by processing cross-shard transactions, and fundamentally improving the transaction processing capacity of the system.

[0014] (2) Significantly reduce network overhead and communication delay caused by state synchronization. Traditional dynamic state migration or cross-shard transaction confirmation requires a large amount of real-time and synchronous communication between shards, which is very costly and can cause network congestion. The main / shadow states involved in the present application are independent of each other and use asynchronous state synchronization. After a transaction is executed and consensus is reached in the local shard, the proof of update to the main state or shadow state is sent asynchronously by the portal committee to other related shards in the background without blocking the consensus process. This mechanism uses the and fields for fast verification and eventual consistency synchronization, decoupling the communication overhead of state synchronization from core transaction processing and significantly reducing network load.

[0015] (3) Through an optimized atomicity protocol, necessary cross-shard transactions are efficiently and securely executed. For cross-shard transactions that cannot be avoided, the present application discards the complex multi-shard collaborative consensus mechanism. By designating a reliable shadow intermediary by the portal committee and constructing two associated sub-transactions, an efficient atomicity submission protocol is formed. The protocol clearly defines the execution, confirmation, and timeout rollback paths, significantly simplifying the cross-shard interaction process and reducing processing delay while ensuring atomicity (either all succeed or all rollback), providing an efficient and reliable solution for handling the remaining cross-shard transactions.

[0016] In order to make the content of the present application easier to be clearly understood, the following further detailed description of the present application is made according to specific embodiments and in conjunction with the accompanying drawings.

[0017] As shown in Figure 1 , a blockchain state sharding method based on shadow state, characterized in that the method comprises the following steps: S1, divide the blockchain network into multiple shards, and select a number of nodes in each shard to form a portal committee; an account creates a main state in the state tree of the shard to which it belongs, and when the account interacts frequently with other shards, a corresponding shadow state is created for the account in the target shard. The specific steps are as follows: S1-1: The entire blockchain network is divided into... Each segment, Each shard Select A node used for coordination and communication serves as the portal committee. exist, The portal committee is responsible for coordinating communication between fragments within and between fragments. Each fragment node stores a complete list of its fragment node's IP addresses for intra-fragment communication. For the intra-fragment portal committee, a lightweight cross-fragment routing table is maintained. In addition to recording the IP information of nodes within the chip for intra-chip broadcasting, each committee also records the routing information of other target committees to achieve efficient inter-chip communication.

[0018] S1-2: After a regular account is created, it is stored in the state tree and has the following fields: .in, This refers to the address of the account; all transaction address fields point to this address. Fields. The latter. This represents the source address of the account. For the primary state, its value is equal to its own address; for the shadow state, it points to the address of its corresponding primary state. This field indicates the number of transactions initiated by the current account. This field exists independently for different states of a single account and is mainly used to prevent double-spending attacks. This field represents the balance information of the current account in the current shard. This field exists independently for the account's corresponding master / shadow state. This represents the distributed balance key-value pair mapping of the current account in the sharding system. This is used to reflect the distribution of the master / shadow state of the current account, where the key is the shard identifier. The value is the balance allocated to the shadow state of this fragment. . Indicates the current account status type, divided into primary status. and shadow state . Record the last system era update ( This field is used to quickly verify the age of the status data and prevent status rollback. It is also used to ensure the atomicity of cross-shard transactions. The field stores the simple Merkle proof of the master state corresponding to this account, used to verify its consistency with the master state. The field enables rapid validation of state validity and consistency.

[0019] S1-3: Portal Committee Responsible for monitoring shards It manages the interaction between internal accounts and other shards, and is responsible for creating the shadow state of accounts within its own shard.

[0020] Fragments Portal Committee At Monitoring accounts With fragmentation Interaction sequence: The portal committee first maintains the current shard. Workload detection volume Then for the account Calculate its previous one To fragment Dynamic workload load value .

[0021] Portal Committee Updates Current Next account Dynamic workload is To conduct an inspection If this is not true, it indicates that the current account and shard are not compatible. The overall transaction frequency is normal. If not, it indicates that the cross-shard transaction frequency of this account relative to this shard needs further examination. Further, calculate the current account's... ,conduct If the comparison is successful, it indicates that the current cross-segment transaction frequency is too high for the account's own transaction volume, and the portal committee can remind the user to create a relevant shadow state.

[0022] Account The main state (fragmentation) First, proceed Initialize and assign values Then to the fragment Portal Committee Initiate a shadow state creation request The request includes the account. address As a shadow state Fields, and through hash function formulas The shadow state is calculated and stored in the partition. The address of the state tree. The field is used to validate the validity of the state; the main state contained in the request. The field is used to initialize the corresponding field of the shadow state, and the initial balance of the shadow state. The value is 0. After the state is created, the committee will perform asynchronous state synchronization between slices.

[0023] S2. After receiving a transaction, the committee within the shard performs addressing in the local state tree of the shard based on the addresses of both parties to the transaction, checks whether there is a corresponding main state or shadow state, and classifies the transaction into intra-shard transaction or cross-shard transaction based on the addressing result. The specific implementation steps of S2 are as follows: S2-1: Fragmentation Portal Committee Receive transaction .in These are the main state addresses of the initiator and the receiver, respectively. For the transaction amount, For both sides' status Fields, Sign for the initiator. Upon receiving the transaction, first query the main state addresses of both parties' accounts involved in the transaction in the current segment's state tree. If no corresponding state information is found, then calculate the shadow state address using the formula, i.e. and Query possible shadow states.

[0024] S2-2: If the query is successful, then verify. , And local balance, if a valid and sufficiently balanced primary / shadow state is found, i.e., the status field... or The transaction is then successfully packaged into the next block of this shard. This process is completed entirely within the shard, without any cross-shard communication, resulting in extremely low latency. After the transaction is completed and the state is updated, the portal committee performs asynchronous state synchronization between shards. S2-3: If the query fails, according to... Source fragments are calculated from the address. The portal committee is then responsible for designating intra-segment shadow intermediaries to handle cross-segment transactions. The shadow intermediary's status field must meet the following requirements. and That is, in the source fragment A shadow state exists, and the current target fragment... The balance is sufficient.

[0025] S3. For intra-shard transaction processing, the state change is executed directly within the current shard; if the transaction involves updating the shadow state, the shard committee asynchronously synchronizes the state with the main / shadow states involved in each shard after the transaction is completed, so as to achieve eventual consistency of the state between shards. The specific implementation steps of S3 are as follows: S3-1: For account owner status updates, when shards After a transaction is completed, the corresponding account status is not updated with the creation of a new block, but rather by the portal committee. According to the accounts involved The field initiates asynchronous / synchronous communication. For After the main state is updated and the portal committee verifies the information, the corresponding proof is packaged. The field sends a state proof packet to its shadow state fragment. ,in The root of the state tree for the current state, and a partial path hash. The fragment to which the shadow state belongs . These are the addresses of each shadow state. Shadow states are based on... Verified Afterwards, update and Field.

[0026] S3-2: If for Shadow state update, portal committee Read its Calculate the partition where the main state is located. Send a state proof packet to the main state. After the main state updates the corresponding state fields, it continues to publish update proof packages to other shadow states. The state proof package involves a simple Merkle proof, which only contains the set of hash values ​​of all sibling nodes on the path from the leaf node to the root node. This method updates the root hash of the state tree by locally recalculating the path hash, without needing to transmit the entire state tree or perform unnecessary I / O calls and hash operations.

[0027] S4. For cross-shard transaction processing, the committee designates an account as a shadow intermediary for the transaction and coordinates the execution of the cross-shard transaction through an atomicity guarantee protocol; the specific successful processing flow is as follows: Figure 2 As shown.

[0028] The specific implementation steps of S4 are as follows: S4-1: A user initiates a raw cross-shard transaction. The committee then designates an account as a shadow intermediary to begin processing the transaction.

[0029] Sender A (shard #1) creates an initial cross-shard transaction, transferring v to recipient B (shard #2). The portal committee corresponding to shard #1 of the sender... Upon receiving the transaction, designate shadow intermediary C to assemble the transaction: This transaction contains the sender's address. Shadow relay user address Transfer amount Recipient address Preset frozen window value Recipient The shadow relay party corresponds to the account in shard #2. And A's signature The window value field is designed primarily to prevent infinite waiting and to ensure transaction atomicity. The field is used to ensure the indivisibility of the cross-shard transaction execution, meaning that no other transactions will occur during the execution of the target shard #2. The portal committee broadcasts the transaction to the intra-shard network.

[0030] S4-2: The intermediary creates and signs two sub-transactions ( and Both were created simultaneously. Used to initially transfer funds from the initiating user and freeze them in a shadow account belonging to the same segment as the intermediary; This is an unassembled initial transaction, sent to the fragment where the recipient is located.

[0031] The relay C in the source fragment received Then, create and sign the first sub-transaction. The purpose of this transaction is to transfer tokens from the sender's account and initially freeze them in the intermediary's shadow account in the source shard. Includes the original transaction and the current state epoch marker of the shadow intermediary. and signature This epoch marker ensures the current state is up-to-date and should be consistent with the system epoch number. It is used to mark the start time and also to verify the validity of any subsequent failed proofs. .Will Broadcast within shard #1 (the source shard). After each node in the shard verifies the signature and account balance, it will... Added to the trading pool and awaiting packaging.

[0032] Within the same timeframe, create and sign the unassembled initial transaction of the second sub-transaction. . It also includes the original transaction and the current epoch and signature. The transaction is initiated and signed by the shadow intermediary, and then sent to the recipient's shard #2.

[0033] S4-3: Confirm After confirmation, To be packaged and assembled And confirmed.

[0034] In target shard #2, the shadow relay receives information from source shard #1 regarding... After confirming the submitted information, check the validity of the epoch and begin the transaction. The assembly, to obtain The purpose of this transaction is to complete the final token transfer. Includes the original transaction and the epoch number at which the transaction was initiated. The epoch number within the current segment And the signature of the shadow intermediary . Intra-shard broadcast is performed within the target shard. Nodes within the shard verify the validity of the epoch. After it becomes valid, check the status to confirm it is valid, and then... Added to shard #2 trading pool. Subsequently, the portal committee... Will Extract, package into a block, and perform the following operations: verify the validity of the submission information, and ensure the current shadow intermediary's... With the initial transaction inside After agreement, the balance of shadow relay C in target shard #2 decreases. Receiver B's balance increased The transfer point in the shadow The value increments by 1 to prevent double-spending. Simultaneously, the portal committee completes state synchronization, and the frozen balance in source shard #1 is restored. Unlock.

[0035] S4-4: Atomicity Guarantee for Cross-Shard Transactions: If any sub-transaction fails to be confirmed within the specified epoch, the system will trigger a transaction rollback. Specifically, if... time out, Will be marked as invalid or Unable to confirm after timeout; if If the timeout occurs, the frozen amount in shard #1 will be refunded to the initiator. The specific process is as follows: Figure 3 and Figure 4 As shown.

[0036] when or Failure to confirm within the specified epoch will trigger a failure handling process to ensure the atomicity of assets. This guarantees that either both processes will execute, or neither will execute.

[0037] when Not confirmed within the specified era. If time has expired. If the first subtransaction is not confirmed, the transaction will be identified as invalid by the shard in the transaction pool of shard #2 based on its epoch marker. This guarantees the atomicity of the transaction.

[0038] when Not confirmed within the specified era. If time has expired. Not received Confirmation and execution of transaction rollback: Unlock the balance of Shadow Intermediary C in source shard #1 and will The money is returned to sender A. Furthermore, even if the source fragment subsequently receives the result of the successful execution of the second sub-transaction, it will still be invalidated due to the expiration of the second sub-transaction epoch. The transaction is rolled back, thus terminating the shadow transfer and ensuring the atomicity of the transaction.

[0039] This invention discloses a blockchain state sharding method based on shadow states. The method establishes a portal committee in each shard, responsible for transaction processing and state synchronization. By creating shadow states for accounts with frequent cross-shard interactions in the target shard, a lower cross-shard transaction ratio is achieved. A dual-address state tree addressing is used to distinguish transaction types, quickly identifying cross-shard transactions that can be processed within the shard using shadow states. Asynchronous state synchronization and atomic cross-shard transaction protocols are employed to assist cross-shard transaction processing, improving system throughput while ensuring eventual consistency. This invention effectively solves the problems of low node reallocation efficiency, high cross-shard transaction processing latency, and high energy consumption in existing dynamic sharding schemes, significantly improving inter-shard communication efficiency and overall system transaction processing performance.

Claims

1. A blockchain state sharding method based on shadow states, characterized in that, The method includes the following steps: S1. Divide the blockchain network into multiple shards and select several nodes in each shard to form a portal committee; create a main state for an account in the state tree of its shard, and create a corresponding shadow state for the account in the target shard when the account interacts frequently with other shards. S2. After receiving a transaction, the committee within the shard performs addressing in the local state tree of the shard based on the addresses of both parties to the transaction, checks whether there is a corresponding main state or shadow state, and classifies the transaction into intra-shard transaction or cross-shard transaction based on the addressing result. S3. For intra-shard transaction processing, the state change is executed directly within the current shard; if the transaction involves updating the shadow state, the shard committee asynchronously synchronizes the state with the main / shadow states involved in each shard after the transaction is completed, so as to achieve eventual consistency of the state between shards. S4. For cross-shard transaction processing, the portal committee designates an account as a transaction shadow intermediary and coordinates the execution of the cross-shard transaction through an atomicity guarantee protocol.

2. The blockchain state sharding method based on shadow states according to claim 1, characterized in that, The specific steps of step S1 above are as follows: S1-1: The entire blockchain network is divided into... Each segment, Each shard Select A node used for coordination and communication serves as the portal committee. exist, The portal committee is responsible for coordinating communication between fragments within and between fragments; each fragment node stores a complete list of its fragment node's IP addresses for intra-fragment communication; and for each fragment portal committee, a lightweight cross-fragment routing table is maintained. In addition to recording the IP information of nodes within the slice for intra-slice broadcasting, each portal committee also records the routing information of other portal committees. S1-2: After a regular account is created, it is stored in the state tree and has the following fields: ;in, This refers to the address of the account; all transaction address fields point to this address. Field; the latter This represents the source address of the account. For the primary state, its value is equal to its own address; for the shadow state, it points to the address of its corresponding primary state. This field indicates the number of transactions initiated by the current account. This field exists independently for different states of a single account to prevent double-spending attacks. This field represents the balance information of the current account in the current shard. This field exists independently for the account's corresponding master / shadow state. This represents the distributed balance key-value pair mapping of the current account in the sharding system. This is used to reflect the distribution of the master / shadow state of the current account, where the key is the shard identifier. The value is the balance allocated to the shadow state of this fragment. ; Indicates the current account status type, divided into primary status. and shadow state ; Records the last updated system epoch, used to quickly verify the age of the state data and prevent state rollback. This field also ensures atomicity for cross-shard transactions. The field stores the simple Merkle proof of the master state corresponding to this account, used to verify its consistency with the master state. Fields enable rapid validation of state validity and consistency; S1-3: Portal Committee Responsible for monitoring shards The internal account is responsible for the interaction between other shards and the creation of the shadow state of its own shard account; Regarding how the portal committee monitors workload for sharded accounts: First, define sharding. Internal Accounts Other fragments At The dynamic workload is as follows ;in For sliding weighted values, It is responsible for adjusting whether the current monitoring focus is on newly initiated transactions or historical trends in initiated transactions; Indicates the current era Below, account To fragment Transaction count initiated; For the previous era Next account For fragments The dynamic load monitoring value; at the same time, the dynamic load threshold of the account is defined as... ;in, A constant factor, Secondly, the portal committee It will maintain a list of partitions for the current partition. Workload monitoring volume ;in This represents all other fragments excluding the current fragment. This represents the user space under the current fragment. Portal Committee Updates Current Next account Dynamic workload is To conduct an inspection If true, it indicates that the current account and shard are compatible. The overall transaction frequency is normal; otherwise, it indicates that the cross-shard transaction frequency of this account relative to this shard needs further examination; calculate the current account's ,conduct If the comparison is successful, it indicates that the current cross-segment transaction frequency is too frequent for the account's own transaction volume. Account Main state fragmentation First, proceed Initialize and assign values Then to the fragment Portal Committee Initiate a shadow state creation request The request contains an account. address As a shadow state Fields, and through hash function formulas The shadow state is calculated and stored in the partition. The address of the state tree; The field is used to validate the validity of the state; the main state contained in the request. The field is used to initialize the corresponding field of the shadow state, and the initial balance of the shadow state. The value is 0; after the state is created, the portal committee will perform asynchronous state synchronization between slices.

3. The blockchain state sharding method based on shadow states according to claim 2, characterized in that, The specific steps of step S2 above are as follows: S2-1: Fragmentation Portal Committee Receive transaction ;in These are the main state addresses of the initiator and the receiver, respectively. For the transaction amount, For both sides' status Fields, The initiator signs the transaction; upon receiving the transaction, it first queries the main state addresses of both parties' accounts in the current segment's state tree. If no corresponding state information is found, it calculates the shadow state address using the formula. and Query possible shadow states; S2-2: If the query is successful, then verify. , And local balance, if a valid and sufficiently balanced primary / shadow state is found, i.e., the status field... or The transaction is then successfully packaged into the next block of this shard; This process is completed entirely within a shard, without any cross-shard communication; after the transaction is completed and the status is updated, the portal committee performs asynchronous state synchronization between shards. S2-3: If the query fails, according to... Source fragments are calculated from the address. The portal committee is responsible for designating shadow intermediaries within the same shard to handle cross-shard transactions; the shadow intermediary's status field must meet the following requirements. and That is, in the source fragment A shadow state exists, and the current target fragment... The balance is sufficient.

4. The blockchain state sharding method based on shadow states according to claim 3, characterized in that, The specific steps of step S3 above are as follows: S3-1: For account owner status updates, when shards After a transaction is completed, the corresponding account status is not updated with the creation of a new block, but rather by the portal committee. According to the accounts involved The field initiates asynchronous / synchronous information; for After the main state is updated and the portal committee verifies the information, the corresponding proof is packaged. The field sends a state proof packet to its shadow state fragment. ,in The root of the state tree for the current state, and a partial path hash; The fragment to which the shadow state belongs ; For the addresses of each shadow state; shadow states are based on Verified Afterwards, update and Field; S3-2: If for Shadow state update, portal committee Read its Calculate the partition where the main state is located. ; Send a state proof packet to the main state After the main state updates the corresponding state fields, it continues to publish update proof packages to other shadow states; among them, the state proof package involves a simple Merkle proof, which only contains the set of hash values ​​of all sibling nodes on the path from the leaf node to the root node.

5. A blockchain state sharding method based on shadow states according to claim 4, characterized in that, The specific steps of step S4 above are as follows: S4-1: The user initiates a raw cross-shard transaction; then the portal committee designates an account as a shadow intermediary. The sender begins processing the transaction. Create a raw cross-shard transaction to transfer funds to the recipient. The source fragment where the sender is located Portal Committee Upon receiving the transaction, assemble the cross-shard transaction: ； This transaction contains the sender's address. Shadow relay address Transfer amount Recipient address Preset frozen window value Recipient Shadow transfer point Target fragment The account corresponding to as well as signature The window value field is designed primarily to prevent infinite waiting and to ensure transaction atomicity. The field is used to ensure the indivisibility of the cross-shard transaction execution, that is, no other transactions will interrupt the execution of the target shard; the portal committee broadcasts the transaction to the intra-shard network. S4-2: The intermediary creates and signs two sub-transactions. and Both are created simultaneously; Used to initially transfer funds from the initiating user and freeze them in a shadow account belonging to the same segment as the intermediary; This is an unassembled initial transaction, sent to the fragment where the recipient is located; Source Sharding Shadow transfer point receive Then, create and sign the first sub-transaction. The purpose of this transaction is to transfer tokens from the sender's account and initially freeze them in the intermediary's shadow account in the source shard. Includes the original transaction and the current state epoch marker of the shadow intermediary. and signature This epoch marker ensures the current state is up-to-date and should be consistent with the system epoch number. It is used to mark the start time and to verify the validity of any subsequent failed proofs. ;Will Broadcast within the source shard; after each shard node verifies the signature and account balance, Added to the trading pool and awaiting packaging; Within the same timeframe, create and sign the unassembled initial transaction of the second sub-transaction. ; It also includes the original transaction and the current epoch and signature; The transaction is initiated and signed by the shadow intermediary before being sent to the recipient. The target fragment ; S4-3: Confirm After confirmation, To be packaged and assembled And confirm; Target fragment In the middle, the shadow relay party receives information from the source shard. After confirming the submitted information, check the validity of the epoch and begin the transaction. The assembly, to obtain ; The purpose of this transaction is to complete the final token transfer; Includes the original transaction and the epoch number at which the transaction was initiated. The epoch number within the current segment And the signature of the shadow intermediary ; Intra-shard broadcast is performed within the target shard; nodes within the shard verify the validity of the epoch. After it becomes valid, check the status to confirm it is valid, and then... Join the trading pool; subsequently, the portal committee Will Extract, package into a block, and perform the following operations: verify the validity of the submission information, and ensure the current shadow intermediary's... With the initial transaction inside After agreement, the shadow relay party's balance in the target shard decreases. The recipient's balance increased The transfer point in the shadow The value increments by 1 to prevent double-spending; simultaneously, the portal committee completes state synchronization, freezing the balance in the source shard. Unlock; S4-4: Atomicity Guarantee for Cross-Shard Transactions: If any sub-transaction fails to be confirmed within the specified epoch, the system will trigger a transaction rollback; where, if time out, Will be marked as invalid or Unable to confirm after timeout; if If the timeout occurs, the frozen amount in the source shard will be refunded to the initiator; when or Failure to confirm within the specified epoch will trigger a failure handling process to ensure the atomicity of assets; Ensure that either both are executed, or neither is executed. when Not confirmed within the prescribed era; if time has exceeded If the first sub-transaction is not confirmed, the transaction will be identified as an invalid transaction by the shard in the target shard's transaction pool through its epoch marker; this guarantees the atomicity of the transaction. when Not confirmed within the prescribed era; if time has exceeded Not received Upon confirmation, execute the transaction rollback: unlock the shadow intermediary's balance in the source shard. and will The data is returned to the sender; furthermore, even if the subsequent source fragment receives the result of the successful execution of the second sub-transaction, it will be invalidated due to the expiration of the second sub-transaction epoch. The transaction is rolled back, thus terminating the shadow transfer and ensuring the atomicity of the transaction.

Images