Sharding methods to improve scalability in Byzantine environments

Abstract

This provides a sharding method for improving scalability in a Byzantine environment. [Solution] The method includes the steps of receiving forwarding transaction groups containing cross-shard transactions from a number of general shards, generating a global coordination sequence that specifies the execution order of the cross-shard transactions, and transmitting the global coordination sequence to a number of general shards. Each general shard independently generates a local execution sequence that determines the execution order of transactions, and the local execution sequence is determined autonomously. The execution order of cross-shard transactions is set to follow the execution order of the global coordination sequence, thereby increasing the transaction processing rate per second while ensuring atomicity and minimizing inter-shard communication in a Byzantine environment to reduce Byzantine consensus costs.

Description

[Technical Field]

[0001] The present invention relates to a sharding method, and more particularly to a sharding method for improving scalability in a Byzantine environment. [Background technology]

[0002] Sharding is a method of improving the scalability of a database or blockchain by partitioning data and distributing it into multiple shards, each of which executes transactions in parallel.

[0003] In sharding methods, transactions can be divided into single-shard transactions, which access only the data hosted by a single shard, and cross-shard transactions, which access data hosted by multiple shards. However, cross-shard transactions act as a major obstacle to the scalability of sharding.

[0004] Cross-shard transactions are relatively expensive to process because they access data handled by multiple shards. Furthermore, they have an atomicity requirement: all relevant shards must either commit or abort the transaction. If a cross-shard transaction is only committed in some shards and fails to satisfy atomicity, it violates system consistency. For example, if a transaction transfers 1 million won from account A to account B, and 1 million won is deducted from account A but not added to account B, atomicity is not met, resulting in a consistency violation.

[0005] Existing sharding methods primarily used the 2PC (two-phase commit) protocol to satisfy the atomicity of cross-shard transactions. The 2PC protocol uses four messages: "VoteRequest," "Vote," "Decision," and "Acknowledgement." A single server called the coordinator sends a VoteRequest message to the relevant participants. Each participant decides whether to commit or abort, records this in stable storage, and sends this as a Vote message to the coordinator. If all relevant participants respond with a commit, the coordinator sends a Decision message requesting a commit to all participants. If even one participant responds with an abort, the coordinator sends a Decision message requesting an abort to all participants. After committing or aborting the transaction according to the Decision message, participants transmit an Acknowledge message to the coordinator. Once the coordinator receives Acknowledge messages from all relevant participants, it begins processing the new cross-shard transaction.

[0006] In the 2PC protocol, to ensure atomicity even in the event of a crash failure, each participant and coordinator always records their decisions in stable storage before sending a message. If even one participant experiences a crash failure before sending a Vote message, the coordinator will decide to abort, and all participants will abort. If a participant experiences a crash failure after sending a Vote message, they will commit or abort immediately after recovery, according to the contents recorded in their stable storage or the coordinator's storage. Therefore, the 2PC protocol can guarantee atomicity against any crash error.

[0007] However, if a shard contains nodes that may experience Byzantine faults, the 2PC protocol inevitably introduces considerable overhead. Since no node belonging to a shard can be trusted, all messages sent from a shard must be verified through Byzantine Fault Tolerance (BFT) consensus. Messages that have not been agreed upon may contain false information, and if the coordinator makes a decision to commit or abort based on such a message, atomicity may not be guaranteed. Therefore, when applying 2PC to a Byzantine environment, a single cross-shard transaction requires at least four consensuses, which significantly degrades sharding performance (for example, the number of transactions processed per second).

[0008] Another method for ensuring atomicity is the deterministic database method. The deterministic database method predetermines the order in which transactions are executed, ensuring that all servers execute transactions in the same order. While existing deterministic database methods reduce the overhead that occurs in the 2PC method, they do not reduce the inter-shard communication that occurs when executing transactions. In a Byzantine environment, all inter-shard messages require BFT agreement, and such inter-shard communication also generates considerable overhead, which is a major factor hindering the scalability of sharding. [Overview of the project] [Problems that the invention aims to solve]

[0009] The present invention has been made in view of the problems of the prior art described above, and the object of the present invention is to provide a method for improving the scalability of sharding by increasing the transaction throughput per second and decreasing the processing time (latency) while ensuring atomicity.

[0010] Furthermore, an object of the present invention is to provide a method for improving the scalability of sharding by minimizing intersharded communication in a Byzantine environment and reducing Byzantine consensus costs. [Means for solving the problem]

[0011] A sharding method for improving scalability in a Byzantine environment according to one aspect of the present invention, made to achieve the above objective, is a method performed to improve scalability in a Byzantine environment in a system including a coordinator and a number of general shards, comprising the steps of: receiving a forwarding transaction group including cross-shard transactions of each general shard from each of the number of general shards; generating a global coordination sequence specifying the execution order of the cross-shard transactions included in the forwarding transaction group received from the number of general shards; and transmitting the global coordination sequence to the number of general shards, wherein each general shard that receives the global coordination sequence generates a local execution sequence that independently determines the execution order of transactions, and the local execution sequence is set such that the execution order of single-shard transactions is determined autonomously and the execution order of cross-shard transactions follows the execution order of the global coordination sequence.

[0012] The sharding method further includes the steps of: receiving a local snapshot from each of the general shards that aggregates the data necessary for executing cross-shard transactions of each general shard; a step of aggregating the local snapshots received from the numerous general shards to generate a global snapshot; and a step of transmitting the global snapshot to the general shards.

[0013] The aforementioned global coordination sequence is configured to assign a version number to each cross-shard transaction so that all cross-shard transactions are fully ordered.

[0014] The step of generating the global snapshot includes checking the version number assigned to the local snapshot to determine whether the data contained in the local snapshot is the latest version.

[0015] The general shard performs a write lock on the data included in the local snapshot to prevent modification of the data included in the local snapshot.

[0016] The step of generating the global snapshot includes checking the version number assigned to the local snapshot to determine whether the data contained in the local snapshot is the latest version.

[0017] Each of the aforementioned general shards uses the global snapshot to perform cross-shard transactions without communicating with other general shards.

[0018] Each of the numerous general shards determines whether there is a causally preceding cross-shard transaction (CPCT) for the cross-shard transaction (LCCT) that commits the data it is responsible for, and uses the global snapshot to execute the causally preceding cross-shard transaction (CPCT) together with the cross-shard transaction (LCCT) that commits the data.

[0019] Another aspect of the present invention for improving scalability in a Byzantine environment, which is made to achieve the above object, is a sharding method for improving scalability in a Byzantine environment in a system including a coordinator and a large number of general shards. The method includes receiving a local snapshot that summarizes data necessary for executing cross-shard transactions of each general shard from each of the large number of general shards, generating a global snapshot by aggregating the local snapshots received from the large number of general shards, and transmitting the global snapshot to the general shards. Each of the large number of general shards is characterized in that it executes cross-shard transactions using the global snapshot without communicating with other general shards.

Effects of the Invention

[0020] According to the present invention, it is possible to increase the transaction throughput per second while ensuring atomicity, reduce the processing time (latency), and improve the scalability of sharding.

[0021] In addition, it is possible to minimize inter-shard communication in a Byzantine environment and reduce the Byzantine consensus cost.

Brief Description of the Drawings

[0022] [Figure 1] It is a block diagram showing the structure of a sharding system for a sharding method for improving scalability in a Byzantine environment of the present invention. [Figure 2] It is a block diagram showing the structure of a general shard included in a general shard group according to an embodiment of the present invention. [Figure 3] It is a block diagram showing the structure of a coordinator according to an embodiment of the present invention. [Figure 4] It is a diagram showing the operation of a sharding method for improving scalability in a Byzantine environment according to an embodiment of the present invention. [Figure 5] This flowchart shows the preparation task procedure on a general shard according to one embodiment of the present invention. [Figure 6] This flowchart shows the procedure for executing a texture on a general shard according to one embodiment of the present invention. [Figure 7] This is a flowchart showing the preparation task procedure for a coordinator according to one embodiment of the present invention. [Figure 8] This is a flowchart showing the execution task procedure of a coordinator according to one embodiment of the present invention. [Modes for carrying out the invention]

[0023] Specific embodiments of the present invention will be described below with reference to the drawings. The following detailed description is provided to aid in a comprehensive understanding of the methods, apparatus, and / or systems described herein. However, this is illustrative and the present invention is not limited thereto.

[0024] In describing embodiments of the present invention, detailed explanations of known technologies related to the present invention will be omitted if it is determined that such explanations would unnecessarily obscure the gist of the embodiments. Furthermore, the terms described below are defined in consideration of the function of the present invention, and these may change depending on the intent or convention of the user or operator. Therefore, their definitions should be based on the content throughout this specification. The terms used in the detailed descriptions are solely for the purpose of describing one embodiment and should not be restrictive. Unless used clearly differently, singular expressions include the meaning of the plural form. Expressions such as “includes” or “equipped with” in this specification are intended to indicate some characteristic, number, stage, operation, element, part or combination thereof, and should not be construed as excluding the existence or possibility of one or more other characteristics, numbers, stages, operations, elements, part or combination thereof other than those described.

[0025] Figure 1 is a block diagram showing the structure of a sharding system for a sharding method for improving scalability in a Byzantine environment according to the present invention.

[0026] Referring to Figure 1, a sharding system according to one embodiment of the present invention includes a general shard group 110, a coordinator 120, and a client 130.

[0027] Client 130 generates a transaction and submits it to a shard included in the general shard group 110. The general shard group 110 contains multiple general shards, and Client 130 submits the transaction to the general shard responsible for the data that the requested transaction is approaching.

[0028] Transactions are divided into those that access data within a single shard and those that access data shared by multiple shards. In this embodiment, transactions that access data within a single shard are defined as single-shard transactions, and transactions that access data shared by multiple shards are defined as cross-shard transactions.

[0029] If the transaction submitted by client 130 is a single-shard transaction, client 130 submits the transaction to only one general shard. If the transaction submitted by client 130 is a cross-shard transaction, client 130 submits the transaction to multiple general shards responsible for the data adjacent to that transaction.

[0030] The transaction submitted by client 130 is processed by a general shard belonging to general shard group 110, and client 130 receives information about the transaction processing result as response information.

[0031] A general shard belonging to general shard group 110 executes the received transaction after receiving it from client 130. For single-shard transactions, a general shard executes it in the same way as the existing method. However, in the case of cross-shard transactions, the present invention performs a separate operation to minimize inter-shard communication. Specifically, each general shard collects only the cross-shard transactions from the received transactions to generate a forwarding transaction group (FTG), and transmits the generated forwarding transaction group to the coordinator 120.

[0032] Each general shard generates a forwarding transaction group and transmits it to the coordinator 120 when a predetermined number of cross-shard transactions accumulate. Alternatively, each general shard may generate a forwarding transaction group and transmit it to the coordinator 120 each time a timeout occurs.

[0033] Furthermore, each general shard generates a local snapshot (LS), which is the data necessary for executing cross-shard transactions included in the forwarding transaction group, and transmits the generated local snapshot to the coordinator 120.

[0034] Coordinator 120 is a special type of shard that receives forwarding transaction groups and local snapshots transmitted by each general shard. Coordinator 120 determines the execution order of cross-shard transactions received from all general shards. In this embodiment, the execution order of cross-shard transactions determined by Coordinator 120 is defined as the Global Coordination Sequence (GCS).

[0035] Furthermore, Coordinator 120 collects local snapshots received from each general shard to generate a global snapshot.

[0036] The global coordination sequence and global snapshot generated by the coordinator 120 are transmitted to the general shards of the general shard group 110, and the general shards use the global coordination sequence and global snapshot to determine the execution order of transactions and execute the transactions.

[0037] Figure 2 is a block diagram showing the structure of a general shard included in a general shard group according to one embodiment of the present invention.

[0038] Referring to Figure 2, a general shard according to one embodiment of the present invention includes a forwarding transaction group generation module 200, a local snapshot generation module 210, a local execution sequence generation module 220, a transaction execution module 230, and a communication module 240.

[0039] The forwarding transaction group generation module 200 generates a forwarding transaction group by collecting only cross-shard transactions from the transactions submitted by client 130. Transactions submitted by clients are classified into single-shard transactions and cross-shard transactions, and the forwarding transaction group generation module 200 selects only cross-shard transactions to generate a forwarding transaction group.

[0040] As described above, the forwarding transaction generation module 200 generates a forwarding transaction group for the cross-shard transactions that have accumulated during the specified time period, once a predetermined number of cross-shard transactions have been collected or a timeout has occurred.

[0041] The local snapshot generation module 210 generates a local snapshot after a forwarding transaction group has been created. When a cross-shard transaction of the forwarding transaction group is determined, the local snapshot generation module 210 acquires the data that the relevant cross-shard transaction is approaching, collects the acquired data, and generates a local snapshot. According to one embodiment of the present invention, the local snapshot generation module 210 generates a local snapshot consisting only of the latest values ​​of the data handled by the general shard.

[0042] On the other hand, the local snapshot generation module 210 performs write protection on the data contained in the generated local snapshot. Through write protection, it prevents other transactions running locally before a cross-shard transaction approaches from modifying the data in the local snapshot.

[0043] The local execution sequence generation module 220 generates a local execution sequence (LES), which is the execution order of transactions to be executed on a shard. According to a preferred embodiment of the present invention, each general shard independently determines the execution order of transactions. Each general shard is not constrained by the transaction execution order of other general shards and independently determines the execution order of transactions.

[0044] When generating a local execution sequence, a general shard autonomously determines the execution order of single-shard transactions it must execute. However, the execution order of cross-shard transactions is determined to follow the cross-shard transaction execution order of the global coordination sequence provided by the coordinator 120. In short, the local execution sequence generation module 220 generates local execution sequences by following the order of the global coordination sequence for cross-shard transactions and autonomously determining the order for single-shard transactions.

[0045] On the other hand, the local execution sequence generation module 220 generates a local execution sequence that executes both a cross-shard transaction (LCCT: Local-Commit Cross-shard Transaction) that commits the data it is responsible for, and a causally preceding cross-shard transaction (CPCT: CasuallyPreceding Cross-Shard Transaction) that precedes it.

[0046] CPCT is a transaction that must be executed before LCCT. Since the data obtained from the execution of CPCT must be used in LCCT, CPCT is a causally preceding transaction. If CPCT is a cross-shard transaction executed on another general shard, the execution of that CPCT must be waited for, and inter-shard communication must be performed to find the execution result of that CPCT.

[0047] In the present invention, in order to eliminate waiting and inter-shard communication, for a cross-shard transaction that must be executed, when it is an LCCT, the CPCT associated with the relevant LCCT is found from the global coordination sequence, and a local sequence is generated so that the CPCTs associated with the LCCT are executed together. With such a local sequence, the LCCT and the CPCT are directly executed together without waiting for the execution results of the CPCTs of other general shards. Eventually, each general shard can execute transactions at its own pace regardless of the operations of other general shards, so that performance degradation due to delays of other specific general shards can be prevented.

[0048] For the identification of LCCT and CPCT, a read / write set, which is a set of data IDs read and written by each transaction, is used. If the data handled by a specific general shard is included in the write set of transaction T k , then the corresponding transaction T k is determined to be the LCCT of the corresponding general shard. If there is a transaction T k that performs a write to the data belonging to the read set of T k and precedes T j in the global coordination sequence, then the transaction T j is regarded as the CPCT of the corresponding shard. This means that the read set of T k and the write set of T j have a non-empty intersection. In the same way, if there is a transaction T j that performs a write to the data belonging to the read set of T j and precedes T i which is determined to be a CPCT, then the transaction T i is also regarded as the CPCT of the corresponding shard.

[0049] Such a method for generating a local execution sequence of the present invention can simplify communication and reduce communication costs.

[0050] In existing deterministic database methods, a control server determines the execution order of all transactions and broadcasts it to the shards. Distributed shards exchange information with each other and share the execution order of all transactions, increasing the number of communications and thus requiring high Byzantine consensus costs. However, the present invention simplifies communication compared to deterministic database methods. In particular, since general shards autonomously determine the order of single-shard transactions, it is also effective in minimizing the performance impact of cross-shard transactions on single-shard transactions.

[0051] The transaction execution module 230 executes the transaction using the generated local execution sequence. Since transaction execution is a general process, a detailed explanation of the execution process will be omitted.

[0052] The communication module 240 is a module for communication between the general shard and the coordinator. Forward transaction groups and local snapshots generated in the general shard are transmitted to the coordinator through the communication module 240. In addition, global coordination sequences and global snapshots sent from the coordinator are received by the general shard through the communication module 240.

[0053] Figure 3 is a block diagram showing the structure of a coordinator according to one embodiment of the present invention.

[0054] Referring to Figure 3, a coordinator according to one embodiment of the present invention includes a global coordination sequence generation module 300, a global snapshot generation module 310, and a communication module 320.

[0055] The global coordination sequence generation module 300 receives forwarding transaction groups from general shards and generates a global coordination sequence that includes the execution order of cross-shard transactions. The execution order of cross-shard transactions can be determined in various ways. According to one embodiment of the present invention, the execution order of cross-shard transactions can be determined in the order in which the forwarding transaction groups are received. According to another embodiment of the present invention, the execution order of the received cross-shard transactions may be determined randomly.

[0056] Of course, it will be obvious to those skilled in the art that there are many other ways to determine the execution order of cross-shard transactions besides the methods described above.

[0057] The global coordination sequence generation module 300 assigns a version number to each cross-shard transaction of the generated global coordination sequence, ensuring that all cross-shard transactions are fully ordered. These version-numbered global coordination sequences are then transmitted to the general shards.

[0058] The global snapshot generation module 310 generates a global snapshot using local snapshots received from general shards. A global snapshot is defined as data that aggregates all local snapshots.

[0059] The global snapshot generation module 310 checks the version number assigned to the local snapshot and verifies whether the data included in the local snapshot is the latest value based on the version number. The global snapshot generation module 310 ensures that a global snapshot containing only the latest values ​​is generated, thereby guaranteeing system consistency.

[0060] The global snapshot generated by the global snapshot generation module 310 is transmitted to each general shard, allowing each general shard to use the global snapshot to perform cross-shard transactions.

[0061] When a common shard performs a cross-shard transaction via a global snapshot, additional inter-shard communication required to obtain data values ​​handled by other common shards is eliminated. This is because all the remote data values ​​that the cross-shard transaction approaches are included in the global snapshot.

[0062] The communication module 320 is a module for communication between the coordinator and the general shards. Forwarding transaction groups and local snapshots generated in the general shards are received through the communication module 320. In addition, global coordination sequences and global snapshots generated in the coordinator are transmitted to the general shards through the communication module 320.

[0063] For the sake of explanation, the above description states that general shards and coordinators are devices that operate independently of each other. However, it will be obvious to those skilled in the art that general shards and coordinators are mode shards, and that a single device may perform both roles concurrently.

[0064] Figure 4 shows the operation of a sharding method for improving scalability in a Byzantine environment according to one embodiment of the present invention.

[0065] Referring to Figure 4, client 130 transmits a request to each general shard (400). Here, a request means submitting a transaction. The client submits the transaction to the general shard associated with the requested transaction.

[0066] Each general shard determines whether an incoming transaction is a single-shard transaction or a cross-shard transaction, and then groups only the cross-shard transactions together to create a forwarding transaction group (FTG). Each general shard also generates a local snapshot (LS), which is the data necessary for executing cross-shard transactions (410).

[0067] The forwarding transaction groups and local snapshots generated in each general shard are transmitted to the coordinator (420).

[0068] The coordinator uses forwarding transaction groups and local snapshots to generate a global snapshot (GS) that combines the global coordination sequence (GCS), which includes the execution order of cross-shard transactions, and the local snapshots (430).

[0069] The global coordination sequence and global snapshot generated by the coordinator are transmitted to all general shards (440).

[0070] Each general shard that receives a global coordination sequence and a global snapshot generates a local execution sequence based on the global coordination sequence and executes transactions based on the generated local execution sequence (450).

[0071] As described above, local execution sequences are generated autonomously for each general shard. Local execution sequences are generated so that the execution order of cross-shard transactions follows the order of the global coordination sequence, but the execution order of general shard transactions is determined autonomously. Also, as described above, local execution sequences are generated so that causally preceding cross-shard transactions (CPCTs) are executed together with cross-shard transactions (LCCTs) that commit data.

[0072] The transaction execution results in each general shard are transmitted to the client (460).

[0073] As can be seen through Figure 4, in the sharding method of the present invention, inter-shard communication between general shards is not performed. Only communication takes place between the coordinator, which is a special type of shard, and general shards. Therefore, inter-shard communication is minimized, and the Byzantine agreement cost incurred each time inter-shard communication occurs is minimized, thereby improving the scalability of the shards.

[0074] In this invention, general shards and coordinators, which are special types of shards, each operate by dividing them into two tasks: preparation tasks and execution tasks.

[0075] Figure 5 is a flowchart showing the preparation task procedure in a general shard according to one embodiment of the present invention.

[0076] Referring to Figure 5, a typical shard is initially in a mode where it waits to receive transactions from clients (stage 500).

[0077] When a transaction is received, it is stored in the memory pool (step 502).

[0078] It is determined whether the quantity of incoming transactions reaches a predetermined threshold, or whether the transaction reception time reaches a predetermined timeout period (stage 504). Transaction reception continues until the threshold is reached or the timeout period is reached.

[0079] A forwarding transaction group (FTG) and a local snapshot (LS) are generated using transactions stored in the memory pool (step 506).

[0080] Once the forwarding transaction group and local snapshot are generated, the execution task is started (stage 508).

[0081] Figure 6 is a flowchart showing the execution procedure on a general shard according to one embodiment of the present invention.

[0082] Referring to Figure 6, a typical shard is initially in a waiting mode for execution tasks (stage 600).

[0083] Once execution begins, the general shards agree on a forwarding transaction group (FTG) and a local snapshot (LS) and transmit them to the coordinator (stage 602).

[0084] General shards receive Global Coordination Sequences (GCS) and Global Snapshots (GS) from the coordinator (stage 604).

[0085] Based on the global coordination sequence and global snapshot, a local execution sequence (LES) is generated, agreed upon, and executed (stage 606).

[0086] Figure 7 is a flowchart showing the preparation task procedure for a coordinator according to one embodiment of the present invention.

[0087] Referring to Figure 7, the coordinator is initially in a mode during the preparation task where it waits to receive forwarding transaction groups (FTGs) and local snapshots (LSs) from the general shard (stage 700).

[0088] Transactions and local snapshots received from general shards are stored in the coordinator's memory pool (stage 702).

[0089] It is determined whether the number of incoming transactions reaches a pre-set threshold, or whether the transaction reception time reaches a pre-set timeout (stage 704). Transaction reception continues until the threshold is reached or the timeout period is reached.

[0090] The coordinator generates a global coordination sequence (GCS) and a global snapshot (GS) based on the received transactions and snapshots (stage 706).

[0091] Once the global coordination sequence and global snapshot are generated, the system enters a mode to initiate the coordination task (stage 708).

[0092] Figure 8 is a flowchart showing the execution task procedure of a coordinator according to one embodiment of the present invention.

[0093] Referring to Figure 8, the coordinator is initially in a waiting mode for execution on the execution task (stage 800).

[0094] Once execution begins, the coordinator transmits the Global Coordination Sequence (GCS) and Global Snapshot (GS) to the general shards through agreement (stage 802).

[0095] Although the present invention has been described with reference to the embodiments illustrated in the drawings, these are merely illustrative examples, and a person with ordinary skill in the art will understand that a variety of modifications and equivalent other embodiments are possible. Therefore, the scope of the present invention should be defined by the technical idea of ​​the invention. [Explanation of Symbols]

[0096] 110 General Shard Groups 120 Coordinators 130 clients

Claims

1. A method performed to improve scalability in a Byzantine environment in a system including a coordinator and numerous general shards, The steps include receiving a forwarding transaction group from each of the aforementioned numerous general shards, which includes cross-shard transactions for each general shard, The steps include generating a global coordination sequence that specifies the execution order of cross-shard transactions included in the forwarding transaction group received from the aforementioned number of general shards, The step of transmitting the global coordination sequence to the numerous general shards is included, Each general shard that receives the aforementioned global coordination sequence independently generates a local execution sequence that determines the execution order of transactions. A sharding method for improving scalability in a Byzantine environment, characterized in that the local execution sequence autonomously determines the execution order of single-shard transactions, and the execution order of cross-shard transactions follows the execution order of the global coordination sequence.

2. The step of receiving a local snapshot from each of the aforementioned general shards, which contains the data necessary for executing cross-shard transactions for each general shard, The steps include: generating a global snapshot by aggregating local snapshots received from the aforementioned large number of general shards; A sharding method for improving scalability in a Byzantine environment according to claim 1, further comprising the step of transmitting the global snapshot to the general shard.

3. The sharding method for improving scalability in a Byzantine environment according to claim 1, characterized in that the global coordination sequence is configured so that all cross-shard transactions are fully ordered by assigning a version number to each cross-shard transaction.

4. The sharding method for improving scalability in a Byzantine environment according to claim 2, characterized in that the step of generating the global snapshot includes a step of checking the version number assigned to the local snapshot to confirm whether the data contained in the local snapshot is the latest value.

5. The sharding method for improving scalability in a Byzantine environment according to claim 2, characterized in that the general shard performs a write lock on the data included in the local snapshot to prevent modification of the data included in the local snapshot.

6. A sharding method for improving scalability in a Byzantine environment according to claim 2, characterized in that each of the aforementioned number of general shards uses the global snapshot to perform cross-shard transactions without communication with other general shards.

7. A sharding method for improving scalability in a Byzantine environment according to claim 6, characterized in that each of the numerous general shards determines whether there is a causally preceding cross-shard transaction (CPCT) for a cross-shard transaction (LCCT) that commits the data it is responsible for, and executes the causally preceding cross-shard transaction (CPCT) together with the cross-shard transaction (LCCT) that commits the data using the global snapshot.

8. A method performed to improve scalability in a Byzantine environment in a system including a coordinator and numerous general shards, The step of receiving a local snapshot from each of the aforementioned numerous general shards, which contains the data necessary for executing cross-shard transactions for each general shard, The steps include: generating a global snapshot by aggregating local snapshots received from the aforementioned large number of general shards; The step includes transmitting the global snapshot to the general shard, A sharding method for improving scalability in a Byzantine environment, characterized in that each of the aforementioned numerous general shards executes cross-shard transactions using the global snapshot without communication with other general shards.

9. The sharding method for improving scalability in a Byzantine environment according to claim 8, characterized in that the step of generating the global snapshot includes a step of checking the version number assigned to the local snapshot to confirm whether the data contained in the local snapshot is the latest value.

10. The sharding method for improving scalability in a Byzantine environment according to claim 8, characterized in that the general shard performs a write lock on the data included in the local snapshot to prevent modification of the data included in the local snapshot.

11. The sharding method for improving scalability in a Byzantine environment according to claim 8, characterized in that each of the numerous general shards determines whether there is a causally preceding cross-shard transaction (CPCT) for a cross-shard transaction (LCCT) that commits the data it is responsible for, and executes the causally preceding cross-shard transaction (CPCT) together with the cross-shard transaction (LCCT) that commits the data using the global snapshot.

12. The steps include receiving a forwarding transaction group from each of the aforementioned numerous general shards, which includes cross-shard transactions for each general shard, The steps include generating a global coordination sequence that specifies the execution order of cross-shard transactions included in the forwarding transaction group received from the aforementioned number of general shards, The process further includes the step of transmitting the global coordination sequence to the numerous general shards, Each general shard that receives the aforementioned global coordination sequence independently generates a local execution sequence that determines the execution order of transactions. The sharding method for improving scalability in a Byzantine environment according to claim 8, characterized in that the local execution sequence is set so that the execution order of single-shard transactions is determined autonomously, and the execution order of cross-shard transactions follows the execution order of the global coordination sequence.

13. The sharding method for improving scalability in a Byzantine environment according to claim 12, characterized in that the global coordination sequence is configured such that all cross-shard transactions are fully ordered by assigning a version number to each cross-shard transaction.

14. Processor and Includes a memory connected to the aforementioned processor, The aforementioned processor, A sharding apparatus for improving scalability in a Byzantine environment, characterized by performing the method described in claim 1 or claim 8.

Images