Verifiable Inter-Shard Transaction System and Method in a Blockchain Network

Abstract

The present invention relates to an inter-shard transaction system and method capable of verifying the validity of a corresponding transaction during an inter-shard transaction between accounts belonging to different shards (working shards) in a blockchain network to which a dynamic sharding technique is applied. According to an embodiment of the present invention, in a verifiable inter-shard transaction system in a node that manages a first sending account that performs a first transaction between a first sending account and a first receiving account, the node includes a transaction generation unit that generates the first transaction, a transaction request unit that requests the first transaction from a receiving node that manages the first receiving account, a transaction information calculation unit that calculates transaction information for verifying the first transaction in a world round state chain including the first transaction information, and a transaction verification information transmission unit that sends the first transaction verification information to the receiving node.

Description

Technical Field

[0001] The present invention relates to a verifiable inter-shard transaction stem and method in a blockchain network, and more specifically, to an inter-shard transaction system and method capable of verifying the validity of a transaction when performing an inter-shard transaction between accounts belonging to different shards (working shards) in a blockchain network applying dynamic sharding technology. Nshi

Background Art

[0002] Blockchain is a decentralized distributed transaction management technology that emerged in an attempt to break away from the centralized method in which a conventional centralized institution stores transaction details at a single point. Blockchain is a distributed ledger system that makes it impossible to forge and modify records by having all participants hold a shared ledger determined through a consensus algorithm on a P2P (Peer-to-Peer) communication network. That is, the distributed ledger system is a system in which each node synchronizes and maintains a database called a ledger in a distributed environment without the control of a central administrator.

[0003] In a blockchain, in order for all nodes to maintain a synchronized ledger, it is necessary to store all transactions and blocks generated within the network. Therefore, conventionally, all messages have been propagated to all nodes in a blockchain network by a flooding method. However, this method has a problem that all nodes must receive and store all messages, that is, a scalability problem.

[0004] To solve the scalability problem, in the recent blockchain field, a sharding technique has been proposed that distributes multiple nodes into multiple shard groups and divides multiple transactions into each distributed shard for parallel processing. Sharding divides the transactions and blocks generated in the blockchain network into shards, which are small groups. Nodes belonging to each shard do not need to process transactions and blocks of different shards, but only process the transactions and blocks of the shard they belong to, thereby reducing the transaction processing volume of the entire network and the size of the distributed ledger.

[0005] However, when introducing the sharding technique, the number of nodes for verifying transactions decreases according to the number of shards. As a result, there is a problem that the risk of data being tampered with by a malicious node's consensus attack increases. The consensus attack is the most dangerous type of attack against the blockchain. In the blockchain, a verification committee containing multiple nodes basically verifies blocks through the consensus of the majority of the committee, and blocks that do not reach a consensus are excluded from the selection and separated from the chain.

[0006] In a general blockchain, since tens of thousands to hundreds of thousands of nodes are included in the verification committee, it is realistically impossible for the number of malicious nodes to exceed more than half. However, when the sharding technique is introduced, there are differences in the frequency of transactions, the number of nodes, and the ratio of validators for each shard. As time passes, imbalance occurs between shards, and there may be a problem that the stability of some shards becomes vulnerable. That is, there may be a case where the number of malicious nodes in some shards exceeds more than half. When the number of malicious nodes exceeds more than half in this way, there is a risk that a fake block will be incorporated into the chain. That is, when the sharding technique is applied, the number of nodes that the attacker has to control decreases, and it becomes easier to control more than half of the nodes, thereby increasing the risk that a fake block will be connected to the chain.

[0007] To solve such problems, even after the shards are once determined, it is necessary to re - arrange the constituent members (nodes) of the shards to adjust the balance between the shards. Also, when the overall traffic of the blockchain network increases, it is necessary to increase the number of shards. The applicant of the present invention proposes the technology of re - balancing the constituent members of the shards and increasing the number of shards as the dynamic sharding technology.

[0008] Generally, in a blockchain network applying sharding technology, the validity of a transaction can be confirmed by verifying the transaction block (ledger) of the sending account that has reached consensus and been shared within the shard. When conducting in-shard transaction communication between accounts belonging to the same shard, since the receiving account belongs to the same shard as the sending account, it can share the transaction block of the sending account and verify the validity of the transaction based on this. However, when conducting cross-shard transaction communication between accounts belonging to different shards, since the receiving account belongs to a different shard from the sending account, it does not share the transaction block of the sending account, and thus there is a problem that the validity of the transaction cannot be verified.

Summary of the Invention

Problems to be Solved by the Invention

[0009] The object of the present invention is to solve the above problems, and to provide an inter-shard transaction system and method in a blockchain network to which sharding technology is applied, such that when conducting cross-shard transaction communication between accounts belonging to different shards, the receiving account can verify the validity of the transaction.

Means for Solving the Problems

[0010] The present invention can be realized in various ways, including an apparatus (system), a method, a computer program stored in a computer-readable medium, or a computer-readable medium storing a computer program.

[0011] In a verifiable shard - to - shard transaction system for managing a first sending account that performs a first transaction between a first sending account and a first receiving account according to an embodiment of the present invention, a node includes a transaction generation unit that generates a first transaction, a transaction request unit that requests the first transaction from a receiving node that manages the first receiving account, a transaction transmission list management unit that records and manages the first transaction information in a transaction transmission list, a transaction verification information calculation unit that calculates first transaction verification information for verifying the first transaction in a world round state chain including the first transaction information, and a transaction verification information transmission unit that transmits the first transaction verification information to a node belonging to the receiving shard of the first transaction.

[0012] More preferably, the node further includes a transaction completion receiving unit that receives a transaction completion message for the first transaction.

[0013] More preferably, based on the transaction completion message for the first transaction, the transaction transmission list management unit performs a completion process on the first transaction in the transaction transmission list.

[0014] More preferably, the transaction request unit acquires the home shard information of the first receiving account, acquires the working shard information of the first receiving account from a node belonging to the home shard of the first receiving account, and requests the first transaction from the receiving node based on the working shard information of the first receiving account.

[0015] More preferably, the node is a verification confirmation node for a second transaction between a second transmission account and a second reception account. The node further includes a transaction transmission list management unit that records and manages second transaction information in the transaction transmission list, a transaction verification request reception unit that receives a verification request for the second transaction from a node belonging to the reception shard of the second transaction, a transaction verification information calculation unit that calculates second transaction verification information for verifying the second transaction in the world round state chain including information related to the second transaction, and a transaction verification information transmission unit that transmits the second transaction verification information to a node belonging to the reception shard of the second transaction.

[0016] More preferably, the node further includes a transaction request transmission unit that transmits the second transaction.

[0017] More preferably, the node further includes a transaction completion reception unit that receives a transaction completion message for the second transaction.

[0018] More preferably, based on the transaction completion message for the second transaction, the transaction transmission list management unit performs a completion process on the second transaction in the transaction transmission list.

[0019] More preferably, the node is a receiving node that manages a third receiving account for performing a third transaction between a third sending account and the third receiving account. The node includes a transaction request receiving unit that receives a third transaction request from a sending node that manages the third sending account, a transaction receiving list management unit that records and manages the third transaction information in a transaction receiving list, a transaction verification information receiving unit that receives verification information for the third transaction from a node belonging to the sending shard of the third transaction, a transaction verification unit that applies the verification information for the third transaction to a world round state chain to verify the third transaction, a transaction processing unit that registers the verified third transaction in the transaction chain of the third receiving account, and a transaction completion sending unit that sends a third transaction completion message to a node belonging to the sending shard of the third transaction for the third transaction registered in the transaction chain.

[0020] More preferably, when the third transaction is verified and completed by the transaction verification unit or the third transaction is registered in the transaction chain by the transaction processing unit, the transaction receiving list management unit changes the state information of the third transaction recorded in the transaction receiving list.

[0021] More preferably, the node is a verification request node for a fourth transaction between a fourth sending account and a fourth receiving account, and the node further includes a transaction receiving list management unit that records and manages fourth transaction information in a transaction receiving list, a transaction verification request sending unit that sends a verification request for the fourth transaction to a node belonging to the sending shard of the fourth transaction, a transaction verification information receiving unit that receives verification information for the fourth transaction from a node belonging to the sending shard of the fourth transaction, and a transaction verification unit that applies the verification information for the fourth transaction to a world round state chain to verify the fourth transaction.

[0022] More preferably, the node further includes a transaction request transmission unit that transmits the fourth transaction.

[0023] More preferably, the node further includes a transaction completion transmission unit that receives a fourth transaction completion message from a receiving node of the fourth transaction and transmits it to a node belonging to the sending shard of the fourth transaction.

[0024] More preferably, when the fourth transaction is verified and completed in the transaction verification unit or the fourth transaction completion message is received in the transaction completion transmission unit, the transaction receiving list management unit changes the state information of the fourth transaction recorded in the transaction receiving list.

[0025] In a node that manages a first sending account for performing a first transaction between a first sending account and a first receiving account according to an embodiment of the present invention, in a verifiable shard - to - shard transaction method implemented by at least one processor, the method includes: the step of the node generating a first transaction; the step of the node requesting the first transaction from a receiving node that manages the first receiving account; the step of the node recording and managing the first transaction information in a transaction sending list; the step of the node calculating first transaction verification information for verifying the first transaction in a world - round state chain including the first transaction information; and the step of the node sending the first transaction verification information to a node belonging to the receiving shard of the first transaction.

[0026] More preferably, the method further includes the step of the node receiving a transaction completion message for the first transaction.

[0027] More preferably, the method further includes the step of the node performing a completion process on the first transaction in the transaction sending list based on the transaction completion message for the first transaction.

[0028] More preferably, the method includes the steps of obtaining home shard information of the first receiving account, obtaining working shard information of the first receiving account from a node belonging to the home shard of the first receiving account, and requesting the first transaction from the receiving node based on the working shard information of the first receiving account.

[0029] More preferably, the node is a verification confirmation node for a second transaction between a second sending account and a second receiving account, and further includes steps of: the node records and manages second transaction information in the transaction sending list; the node receives a verification request for the second transaction from a node belonging to the receiving shard of the second transaction; the node calculates second transaction verification information for verifying the second transaction in the world round state chain including information related to the second transaction; and the node sends the second transaction verification information to a node belonging to the receiving shard of the second transaction.

[0030] More preferably, the node further includes a step of transmitting the second transaction.

[0031] More preferably, the node further includes a step of receiving a transaction completion message for the second transaction.

[0032] More preferably, the node further includes a step of completing the second transaction in the transaction sending list based on the transaction completion message for the second transaction.

[0033] More preferably, the node is a receiving node that manages a third receiving account for performing a third transaction between a third sending account and the third receiving account, and the steps include: the node receiving a third transaction request from a sending node that manages the third sending account; the node recording and managing third transaction information in a transaction receiving list; the node receiving verification information for the third transaction from a node belonging to the sending shard of the third transaction; the node applying the verification information for the third transaction to a world round state chain to verify the third transaction; the node registering the verified third transaction in the transaction chain of the third receiving account; and the node sending a third transaction completion message for the third transaction registered in the transaction chain to a node belonging to the sending shard of the third transaction.

[0034] More preferably, when the third transaction is verified or the third transaction is registered in the transaction chain, the node further includes the step of changing the status information of the third transaction recorded in the transaction receiving list.

[0035] More preferably, the node is a verification request node for a fourth transaction between a fourth sending account and a fourth receiving account, and the steps include: the node recording and managing fourth transaction information in a transaction receiving list; the node sending a verification request for the fourth transaction to a node belonging to the sending shard of the fourth transaction; the node receiving verification information for the fourth transaction from a node belonging to the sending shard of the fourth transaction; and the node applying the verification information for the fourth transaction to a world round state chain to verify the fourth transaction.

[0036] More preferably, the node further includes the step of transmitting the fourth transaction.

[0037] More preferably, the method further comprises a step in which the node receives a fourth transaction completion message from the receiving node of the fourth transaction and transmits the message to a node belonging to the sending shard of the fourth transaction.

[0038] More preferably, the method further comprises a step in which when the fourth transaction is verified and completed or a fourth transaction completion message is received, the node changes the state information of the fourth transaction recorded in the transaction reception list.

Advantages of the Invention

[0039] According to the present invention, the following effects can be obtained.

[0040] By dividing the blockchain network into shards and processing transactions and blocks, the present invention can reduce the transaction processing volume and the size of the distributed ledger, and improve the scalability of the blockchain network.

[0041] The present invention introduces the concepts of a home shard and a working shard, enables the derivation of home shard information of any account through calculation, stores the working shard information, which is the shard to which the account currently belongs, in the home shard of the account, and updates the working shard information after the change in the home shard of the account when any account changes its working shard, so that the working shard of the account can be tracked even when the account moves its working shard.

[0042] The present invention can support cross-shard transactions between any two accounts by having the transaction sending-side account obtain the working shard information of the receiving-side account via the home shard of the receiving-side account.

[0043] In the present invention, during a shard - to - shard transaction between any two accounts, the receiving account management node can verify the legitimacy of the transaction, and the sending account management node can verify that the transaction has been successfully registered with the receiving account.

[0044] The effects of the present invention are not limited to the effects mentioned above, and other effects not mentioned can be clearly understood by those with ordinary knowledge in the technical field to which the present invention belongs (referred to as "ordinary technicians") from the description of the claims.

Brief Description of the Drawings

[0045] Embodiments of the present invention will be described with reference to the accompanying drawings described below. Similar reference numerals indicate similar elements, but are not limited thereto.

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6

Figure 7

Figure 8

Figure 9

Figure 10

Figure 11

[0046] Embodiments of the present invention will be described with reference to the accompanying drawings described below. Similar reference numerals indicate similar elements, but are not limited thereto.

Mode for Carrying Out the Invention

[0047] Hereinafter, specific contents for carrying out the present invention will be described in detail with reference to the accompanying drawings. However, in the following description, when there is a risk of unnecessarily obscuring the gist of the present invention, specific descriptions of generally known functions and configurations will be omitted.

[0048] In the accompanying drawings, the same or corresponding components are given the same reference numerals. In the following description of the embodiments, duplicate descriptions of the same or corresponding components may be omitted. However, even when the description of a component is omitted, it is not intended that the component is not included in any embodiment.

[0049] The advantages and features of the embodiments disclosed in this specification, and the methods for achieving them, will become apparent by referring to the embodiments described later together with the accompanying drawings. However, the present invention is not limited to the embodiments disclosed below, and can be realized in various different forms. These embodiments are merely provided to enable those skilled in the art related to the present invention to fully understand the scope of the invention.

[0050] Unless otherwise defined, all terms (including technical and scientific terms) used herein shall be construed in a sense that is commonly understood by those of ordinary skill in the art to which this invention belongs. Also, terms defined in commonly used dictionaries shall not be idealized or interpreted overly unless specifically defined otherwise.

[0051] For example, the term "technique" can refer to a system, method, computer-readable instructions, module, algorithm, hardware logic, and / or be permitted by the foregoing context and refer to operations throughout the document.

[0052] The terms used herein are briefly described, and the disclosed embodiments are specifically described. The terms used herein are, to the extent possible, general terms that are currently widely used while considering the functions in the present invention, but this may change due to the intentions of those skilled in the relevant field, case law, or the emergence of new technologies. Also, in certain cases, there are terms arbitrarily selected by the applicant, and in such cases, the meaning will be described in detail in the description part of the invention. Therefore, the terms used in the present invention should be defined not simply by the name of the term, but based on the meaning the term has and the overall content of the present invention.

[0053] In this specification, singular expressions include plural expressions unless specifically specified as singular in the context. Also, plural expressions include singular expressions unless specifically specified as plural in the context. Throughout the specification, when a part is said to include a certain component, this means that, unless otherwise stated to the contrary, it may further include other components rather than excluding other components.

[0054] In the present invention, terms such as "comprising" and "including" can indicate the presence of features, steps, operations, elements, and / or components, but such terms do not exclude the addition of one or more other functions, steps, operations, elements, components, and / or combinations thereof.

[0055] In the present invention, when a particular component is referred to as being "coupled", "combined", "connected", "associated" or "reacting" with any other component, the particular component can be directly coupled, combined, connected and / or associated or reacted with the other component, but is not limited thereto. For example, one or more intermediate components can exist between the particular component and the other component. Further, "and / or" in the present invention can include each of one or more of the listed items, or a combination of at least some of the one or more items.

[0056] In the present invention, terms such as "first", "second", etc. are used to distinguish a particular component from other components, and the foregoing components are not limited by such terms. For example, the "first" component can be used to refer to an element that is the same as or similar in form to the "second" component.

[0057] In the present invention, a "blockchain network" is an aggregate of a plurality of computers (nodes) that participate in a blockchain system and perform peer-to-peer communication with each other via the Internet or the like. In the present invention, a "node" can be a computer that participates in a blockchain network. Here, the computer includes all devices having CPU, memory, communication, and input / output functions, and specifically can include a server computer, a personal computer (PC), a mobile phone terminal, a small household electrical appliance, and the like.

[0058] Nodes can execute information sharing and dissemination via a blockchain network. Nodes manage user accounts. The accounts managed by nodes can include the account of the node owner (hereinafter referred to as the host account) and accounts entrusted with management by other users (hereinafter referred to as guest accounts). Nodes store all information regarding the host accounts and guest accounts they manage, send it to other nodes on the blockchain network, and can receive the latest information regarding the host accounts and guest accounts managed by each node from other nodes.

[0059] In the present invention, "account" can be a data structure representing a single user as a user account participating in the blockchain. An account can add information to the blockchain system by issuing a transaction and can be a linked list of transactions issued by the user. A transaction can be a unit of data added to the system by the user. An account can own a node and directly manage its own transaction information, and such an account can be regarded as a host account. Also, an account can entrust the management of transaction information to a node of another user, and such an account can be regarded as a guest account, and the node that receives the entrustment of account management can be regarded as the entrusted node. Identity verification of the node and the account can be performed using a cryptographic key, and the same cryptographic key can be used to sign transactions. A guest account can also operate its own node to become a host account, can change the entrusted node, and a host account can also select an entrusted node to become a guest account.

[0060] In the present invention, a "transaction" can be issued independently by one account as a unit of information added to the blockchain. The content of a transaction is nominally any information provided by a user and can actually be a meaningful message within the system. For example, a transaction can include messages such as "Account A sent 100 coins to Account B" and "Account B received 100 coins from Account A". In the present invention, the serial number of a transaction is a positive integer starting from 0, increasing by 1 for each transaction, and an account-wise transaction chain (AWTC) that manages a ledger for each account is used. The technology of the account-wise transaction chain (AWTC) can be understood by referring to the content described in Korean Patent Publication No. 2021-0015196.

[0061] In the present invention, an account that requests a transaction can be referred to as a sending account, and an account that is the target of the transaction request can be referred to as a receiving account. A node that manages the sending account can be referred to as a sending node, and a node that manages the receiving account can be referred to as a receiving node. In the present invention, "transaction request" means a request regarding transaction communication. That is, the transmitting node sends a transaction reception request to the receiving node, and the receiving node receives the transaction reception request from the transmitting node.

[0062] A "block" in the present invention can be a signed list of transactions added to a shard or a blockchain network during a specific period. A block can be generated by signing the generated transactions to the list via a consensus algorithm. Only one block can be generated at a time, and a blockchain can be formed by adding a new block to an existing block list.

[0063] In the present invention, a "shard" can be a subset of nodes participating in a blockchain network. The entire blockchain network is generally divided into multiple shards. If not divided, all nodes are considered to participate in one shard, and each shard has a unique address. Generally, in a blockchain network applying sharding technology, nodes belonging to the same shard communicate with each other peer-to-peer and share the account-wise transaction chain (AWTC) of all accounts belonging to the same shard.

[0064] In the present invention, all accounts can have one working shard and one home shard. The working shard and the home shard of any account may be the same or different. In the present invention, the "home shard" of an account can be calculated based on a function with the account address and the total number of shards as parameters. The "working shard" of an account in the present invention is currently the shard to which the account belongs and operates, and can be a general shard. That is, in the present invention, nodes with the same working shard can communicate with each other peer-to-peer and share the account-wise transaction chain (AWTC) of all accounts belonging to the same working shard.

[0065] In the present invention, an "intra-shard transaction" can mean a transaction between nodes in the same working shard. That is, the sending node and the receiving node of an intra-shard transaction may belong to the same working shard. In the present invention, an "inter-shard transaction" may mean a transaction between nodes belonging to different working shards. That is, the sending node and the receiving node of an inter-shard transaction belong to different working shards.

[0066] Each shard can have a set of accounts for which the shard is the home shard, and a set of nodes and accounts for which the shard is the working shard. The nodes and accounts that make up the blockchain network must belong to one working shard.

[0067] A node can move from one working shard to another. When a node moves working shards, the host accounts and guest accounts it manages can also move working shards at the same time. Any account can move from one working shard to another separately from the node.

[0068] In the present invention, "peer-to-peer communication" in the blockchain network and shards means that when any node receives predetermined information, it replicates the received information and transmits it to other nodes, and the nodes that receive the information also replicate the information and transmit it to other nodes. After sufficient time has passed, all nodes belonging to the blockchain network and shards share the information.

[0069] In the present invention, the "adjacent shard" of any shard can be a shard having an address with a bit distance of 1 from the address of the said shard. A bit distance of 1 means that when any two binary values (binary numbers) are compared digit by digit, only the value of one digit is different. For example, for the binary value "0101", the binary value that differs only in the first digit is "0100", the binary value that differs only in the second digit is "0111", the binary value that differs only in the third digit is "0001", and the binary value that differs only in the fourth digit is "1101". Therefore, for the binary value "0101", the binary values "0100", "0111", "0001", and "1101" are all binary values that differ only in one digit value. Thus, in the present invention, a binary value that differs only in one digit value from any binary value is defined as having a bit distance of 1, and a shard having an address with a bit distance of 1 from the address of any shard is defined as an adjacent shard.

[0070] The operating system described below constitutes one embodiment and does not limit the claims to any one operating environment. It can be used in other environments without departing from the technical idea and scope of the claimed gist.

[0071] FIG. 1 is a diagram showing a conceptual diagram of a blockchain network divided into three shards of the present invention.

[0072] A plurality of nodes constituting the blockchain network can be divided into three shards 110, 120, and 130, but it is not limited thereto. The number of shards can be increased as the number of nodes and accounts constituting the blockchain network increases, and at this time, one shard can be divided into two. Each of the shards 110, 120, and 130 can be the working shard of the nodes currently belonging to that shard. Nodes belonging to the current working shard can all share the same information.

[0073] Each node can include a list of in - shard communication nodes that store peer - to - peer communication target (in - shard communication nodes) information among the nodes within the working shard, and a list of inter - shard communication nodes that store peer - to - peer communication target (inter - shard communication nodes) information among the nodes outside the working shard.

[0074] The in - shard communication nodes that are communication targets within the working shard of each node can be determined according to the Kademlia rule. The inter - shard communication nodes that are communication targets outside the working shard of each node can be randomly determined from among some of the nodes belonging to adjacent shards.

[0075] Based on the in - shard communication node list and the inter - shard communication node list determined in this way, information sharing via peer - to - peer communication within and outside the working shard becomes possible. Information shared with inter - shard communication nodes may be different from information shared with in - shard communication nodes. That is, the information shared with inter - shard communication nodes may be more restricted than the information shared with in - shard communication nodes. The in - shard communication nodes and inter - shard communication nodes included in the in - shard communication node list and the inter - shard communication node list assigned to each node can be randomly reconfigured.

[0076] In FIG. 1, the nodes 111, 121, 131 that communicate with the nodes within the working shard are shown as non - hatched circles, and the nodes 112, 122, 132 that communicate with the nodes outside the working shard are shown as hatched circles. The nodes 112, 122, 132 that communicate with the nodes outside the working shard can communicate with the nodes belonging to adjacent shards based on the inter - shard communication node list. Here, an adjacent shard can be a shard with a bit distance of 1 in the shard address. A bit distance of 1 means that the addresses of the shards differ by only one digit of bit value. That is, the addresses with a bit distance of 1 from the address "00" can be "01" and "10".

[0077] In the example of FIG. 1, when the address of the first shard 110 is "00", the address of the second shard 120 is "01", and the address of the third shard 130 is "10", the addresses of the first shard 110 and the second shard 120 are "00" and "01" respectively, and the bit distance is 1. The addresses of the first shard 110 and the third shard 130 are "00" and "10" respectively, and the bit distance is 1. However, the addresses of the second shard 120 and the third shard 130 are "01" and "10" respectively. Since the two digit values are different, the bit distance is not 1.

[0078] Therefore, the first shard and the second shard are adjacent shards, and the first shard and the third shard can directly communicate as adjacent shards. However, since the second shard and the third shard are not adjacent shards, they cannot directly communicate and can communicate through the first shard which is their respective adjacent shard.

[0079] Each node in FIG. 1 includes a shard rebalancing algorithm, and the shard rebalancing algorithm can be executed according to preset conditions. The shard rebalancing algorithm can use, but is not limited to, the Bounded Cuckoo algorithm. The Bounded Cuckoo algorithm is described in detail in the introduction material of rapidchain (RapidChain: Scaling Blockchain via Full Sharding, see https: / / eprint.iacr.org / 2018 / 460.pdf). The present invention can calculate the health index of shards based on the Bounded Cuckoo algorithm, classify them into strong shards and weak shards, and periodically randomly extract some nodes from the strong shards and move them to the weak shards.

[0080] When the shard balancing algorithm is executed, a node that changes the working shard is randomly selected, and the working shard of the node may be reassigned and changed. When the working shard of a node is changed, the node can execute the working shard change procedure for all host accounts and guest accounts it manages.

[0081] Furthermore, the node can execute an individual working shard change procedure for the host accounts and guest accounts it manages. For example, when the guest account entrusted by the node changes the entrusted node, and the changed entrusted node belongs to another working shard, the node can execute the working shard change procedure for the guest account. Alternatively, when newly entrusting the management of a third account that was previously managed by a node belonging to another working shard, the node can perform the working shard change procedure for the third account.

[0082] FIG. 2 is a block diagram showing an exemplary configuration of node 200 including the account transaction system of the present invention. Each node can be implemented as a computer device.

[0083] In some examples, the various devices and / or components of node 200 can include distributed computer resources 250 that can communicate with each other and with external devices via one or more networks 260.

[0084] In various embodiments, the distributed computer resources 250 can include devices 250(1) to 250(N).

[0085] Embodiments of the present invention support scenarios where the distributed computer resources 250 can operate in a clustered or other grouped configuration to share resources, distribute load, improve performance, or for other purposes and include one or more computer devices.

[0086] The distributed computer resource 250 can fall into various categories such as a conventional server-type device, a desktop computer-type device, a mobile device, a special-purpose device, an implanted device, and / or a wearable device. Thus, although described as desktop and laptop computers, the distributed computer resource 250 can include various types of devices and is not limited to a specific type of device. The distributed computer resource 250 can be a desktop computer, a server computer, a web server computer, a personal computer, a mobile computer, a laptop computer, a tablet computer, a wearable computer, an implant computer, a communication device, an automotive computer, a network-assisted television, a thin client, a terminal, a PDA, a game console, a game device, a workstation, a media player, a personal video recorder (PVR), a set-top box, a camera, and an integrated component for inclusion in a computer device.

[0087] The node 200 can be one computer device that is the distributed computer resource 250. The node 200 can include any type of computer device having one or more processing units 202 operably connected to a computer-readable medium (CRM) 204 via a bus 240, and in some cases, can include one or more of these. Such a bus 240 can include a system bus, a data bus, an address bus, a PCI bus, a mini-PCI bus, and various local, peripheral device, and / or independent buses.

[0088] In the node 200, the processing unit 202 can include a processing unit 202 representing, for example, a CPU-type processing unit, a GPU-type processing unit, a field-programmable gate array (FPGA), a digital signal processor (DSP), or other hardware logic components that can be driven by a CPU.

[0089] For example, such hardware logic components can include Application-Specific Integrated Circuits (ASICs), Application-Specific Standard Products (ASPs), System-On-a-Chip (SOC) systems, Complex Programmable Logic Devices (CPLDs), and the like. Specifically, CRM204 can store executable instructions that can be executed by external processing units such as an external CPU-type processing unit 206 and an external GPU-type processing unit 208, and / or external accelerators 210 such as an FPGA-type accelerator 210(1), a DSP-type accelerator 210(2), or other accelerators 210(N).

[0090] The CRM204 described herein may include a computer storage medium and / or a communication medium.

[0091] A computer storage medium can include a storage unit of a type such as volatile memory, non-volatile memory, and / or other permanent or auxiliary computer storage media implemented by any method or technology for storing information such as computer-readable instructions, data structures, program modules, or other data, removable and non-removable computer storage media.

[0092] The computer storage medium can be, for example, RAM, static RAM (SRAM), dynamic RAM (DRAM), phase change memory (PRAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), flash memory, DVD, optical storage media, magnetic cassette, magnetic tape, solid state drive (SSD), and the like.

[0093] The executable instruction words stored in CRM204 can include an operating system 220 and other modules, programs, or applications that can be loaded and executed by the processing unit 202.

[0094] Additionally or alternatively, what is functionally described herein may be performed at least in part by one or more hardware logic components such as an accelerator.

[0095] For example, exemplary hardware logic components that may be used include FPGA (Field-Programmable Gate Array), ASIC (Application-Specific Integrated Circuits), ASSP (Application-Specific Standard Products), System-On-a-Chip system (SOC), Complex Programmable Logic Device (CPLD), and the like. Additionally, the accelerator may be a hybrid device from XILINX or ALTERA that includes a CPU embedded in the FPGA fabric.

[0096] In the illustrated embodiment, CRM204 may also include a data store 212. In some embodiments, data store 212 may include a data store such as a database, a data warehouse, or other types of structured or unstructured data stores.

[0097] In some embodiments, data store 212 may include a corpus and / or a relational database having one or more tables, indexes, stored procedures, etc. that enable data access, such as web tables including one or more Hypertext Markup Language (HTML) tables, Resource Description Framework (RDF) tables, Web Ontology Language (OWL) tables, and / or XML (Extensible Markup Language) tables.

[0098] For example, the data store 212 can store data and / or instruction words for the operation of processes, applications, components, and / or modules stored in the CRM 204 and executed by the processing unit 202.

[0099] The node 200 can further include one or more input / output (I / O) interfaces 216, and the input / output (I / O) interface 216 can be an I / O interface that enables the node 200 to communicate with a user input device including a peripheral input device (e.g., keyboard, mouse, pen, game controller, voice input device, touch input device, gesture input device, camera, etc.) and a peripheral output device (e.g., display, printer, etc.).

[0100] Furthermore, the node 200 can further include one or more input / output (I / O) network interfaces 218 that enable the node 200, which can be a node of the blockchain network, to communicate with other nodes of the blockchain network via the network 260.

[0101] Such input / output (I / O) network interfaces 218 can include one or more network interface controllers (NICs) or other types of transceiver devices for transmitting and receiving communications via the network 260.

[0102] Network 260 can include a shared network such as the Internet, a private network such as an institutional and / or personal intranet, or a combination of parts of private and shared networks. Network 260 can include any type of wired and / or wireless network including, but not limited to, a local area network (LAN), a wide area network (WAN), a satellite network, a cable network, a Wi-Fi network, a WiMax network. It can include a mobile communication network (e.g., 3G, 4G, 5G, etc.) or any combination thereof. Network 260 can utilize a communication protocol including packet-based and / or datagram-based protocols such as Internet Protocol (IP), Transmission Control Protocol (TCP), User Datagram Protocol (UDP), or other types of protocols.

[0103] Furthermore, Network 260 can include a plurality of devices that facilitate network communication or form a hardware basis for the network such as switches, routers, gateways, access points, firewalls, base stations, repeaters, backbone devices, etc.

[0104] In some embodiments, Network 260 can further include a device that enables connection to a wireless network such as a wireless access point (WAP). Embodiments according to the present invention can support a WAP that supports the IEEE (Institute of Electrical and Electronical Engineers) 802.11 standard (e.g., 802.11g, 802.11n, etc.) and support connections via a WAP that transmits and receives data via various electromagnetic frequencies (e.g., radio frequencies).

[0105] In the illustrated embodiment, CRM204 may include an operating system 220 and an inter-shard transaction system 222. The inter-shard transaction system 222 may include one or more modules and / or APIs shown by blocks 224, 226, 228, 230, 232, and 234, but this is merely an illustration and the number may be more or less. The functions described for each block 224, 226, 228, 230, 232, and 234 may be combined to be executed by a smaller number of modules and / or APIs, or may be divided and executed by a larger number of modules and / or APIs.

[0106] Alternatively, part or all of the operating system, the data stored in the data store, and the account transaction system may be stored in separate memories 234 such as memory 214 on process unit 202, memory 234(1) on CPU type processing unit 206, memory 234(2) on GPU type processing unit 208, memory 234(3) on FPGA type accelerator 210(1), memory 234(4) on DSP type accelerator 210(2), and / or memory 234(M) on other accelerators 210(N).

[0107] The inter-shard transaction system 222 may include an account management module 224, a peer-to-peer communication module 226, a transaction consensus module 228, a home shard calculation module 230, a transaction processing module 232, and a transaction verification module 234.

[0108] The account management module 224 can manage host accounts and guest accounts. The account management module 224 can input and store an account-specific transaction chain (AWTC) for all accounts belonging to the same working shard.

[0109] The peer-to-peer communication module 226 can transmit messages to other nodes within the working shard and nodes outside the working shard via peer-to-peer communication for any message generated within the working shard, based on the in-shard communication node list and the inter-shard communication node list. The peer-to-peer communication module 226 can receive and process messages generated by the node itself or shared by other nodes, or share them with other nodes. Although such message sharing can span multiple nodes, for the sake of simplicity, the procedure for sharing messages is omitted.

[0110] The transaction consensus module 228 can select the consensus target transactions from the account-specific transaction chains (AWTC) of all accounts belonging to the same working shard, combine the selected consensus target transactions as round state blocks, perform consensus on the combined round state blocks based on the Byzantine Fault Tolerance (BFT) consensus algorithm, and manage the consensus round state blocks as a round state chain. The transaction consensus module 228 shares the consensus round state blocks with the nodes belonging to the same working shard so that all nodes belonging to the corresponding working shard hold the same round state chain. The technology by which the transaction consensus module 228 selects the consensus target transactions from the account-specific transaction chains of accounts and performs consensus on the selected consensus target transaction blocks can be understood with reference to the content described in Korean Patent Publication No. 10-2021-0015196.

[0111] In addition, the transaction consensus module 228 can combine all round state blocks agreed upon in all working shards of the blockchain network into a world round state block, agree on the combined world round state block based on the Byzantine fault tolerance consensus algorithm, and manage the agreed world round state block as a world round state chain. The transaction consensus module 228 shares the agreed world round state block with all nodes of the blockchain network, so that all nodes belonging to the corresponding blockchain network hold the same world round state chain.

[0112] In summary, the world round state chain is shared by all nodes of the blockchain network. The world round state chain contains a plurality of world round state blocks agreed upon in all working shards. Each world round state block contains round state blocks agreed upon in their respective working shards. Each round state block contains the transaction chains of all accounts within the corresponding working shard. Each account's transaction chain contains transaction information executed in each account. Therefore, whether any transaction of any account is legitimate can be verified by all nodes of the blockchain network based on the information contained in the world round state chain. In the present invention, by providing the receiving node with information for verifying the transaction information to be verified in the world round state chain at the sending node, the receiving node can verify the legitimacy of the transaction to be verified from the world round state chain.

[0113] The home shard calculation module 230 can calculate the home shard address of any account based on the account address and the total number of shards information. The home shard calculation module 230 can be driven by the transaction processing module 232. When the transaction processing module 232 requests the home shard information of the received account, it can apply the function with the address of the corresponding received account and the total number of shards information as parameters to calculate the home shard address of the corresponding received account.

[0114] The transaction processing module 232 can process a transaction between any two accounts. The transaction processing module 232 can process an in-shard transaction when any two accounts belong to the same working shard and an inter-shard transaction when any two accounts belong to different working shards. At this time, the account that requests the transaction is called the sending account, the account that receives the transaction request is called the receiving account, the node that manages the sending account is called the sending node, and the node that manages the receiving account is called the receiving node. Also, the node with the home shard of the receiving account as the working shard may be named the node belonging to the home shard. In addition, the working shard to which the sending node (i.e., the sending account) belongs may be named the sending shard, and the working shard to which the receiving node (i.e., the receiving account) belongs may be named the receiving shard.

[0115] The transaction verification module 234 can verify whether a transaction processed by the transaction processing module 232 is a legitimate transaction in the receiving node and the nodes belonging to the same working shard as the receiving node (hereinafter referred to as "nodes belonging to the receiving shard"), and can verify whether the transaction is being processed normally at the receiving node in the sending node and the nodes belonging to the same working shard as the sending node (hereinafter referred to as "nodes belonging to the sending shard"). For in-shard transactions where the sending node and the receiving node belong to the same working shard, the transaction verification module 234 can verify the legitimacy of the transaction based on the round state chain. For cross-shard transactions where the sending node and the receiving node do not belong to the same working shard, the transaction verification module 234 can verify the legitimacy of the transaction based on the world round state chain.

[0116] FIG. 3 is a diagram showing information stored in the data store 300 of each node in order to implement the verifiable cross-shard transaction system of the present invention.

[0117] The node's data store 300 stores the account - specific transaction chains (AWTC) 302, 304, 306, 308 of all accounts belonging to the node's working shard, the account directory 310 that stores the working shard history information of the account with the node's working shard as the home shard, the round state chain 312 that combines the account - specific transactions of all accounts belonging to the working shard and stores the round state blocks agreed upon among the nodes belonging to the working shard as a chain, the world round state chain 314 that combines all round state blocks belonging to the blockchain network and stores the agreed - upon world round state block as a chain, the in - shard communication node list 316 that stores the information of the communication target nodes within the node's working shard, the inter - shard communication node list 318 that stores the information of the communication target nodes outside the node's working shard, the transaction transmission list 320 that stores the transaction information sent by the node, and the transaction reception list 322 that stores the transaction information received by the node can be stored.

[0118] The account directory 310 stores the working shard history information of the accounts with the working shards of the nodes being the home shards. In this example, for the sake of convenience, it is assumed that each node is managed by only one account, that is, the host account. Therefore, in this example, a node can be regarded as the same concept as an account. For example, in the example of FIG. 1, when the home shard of the account to which node 111 belongs is the second shard 120, the information of the first shard 110 is stored as the working shard information of the account to which node 111 belongs on the account directories of nodes 121 and 122 with the second shard 120 as the working shard. On the other hand, in the example of FIG. 1, when the home shard of the account to which node 112 belongs is the third shard 130, the information of the first shard 110 is stored as the working shard information of the account to which node 112 belongs in the account directories of nodes 131 and 132 with the third shard as the working shard.

[0119] As described above, a node and an account can change the working shard. When the working shard is changed in this way, the node belonging to the home shard of the corresponding account can update the changed working shard information. In the present invention, it is desirable that the latest working shard address of the corresponding account be updated in the account directory of the node with the home shard of any account as the working shard.

[0120] In the round state chain 312, round state blocks are stored as a chain. The transaction consensus module 228 selects the consensus target transactions from the account - specific transaction chains (AWTC) of all accounts belonging to the same working shard, combines the selected consensus target transactions as round state blocks, reaches a consensus on the combined round state blocks based on the Byzantine Fault Tolerance (BFT) consensus algorithm, and can store the consensus - reached round state blocks in the round state chain 312. Such consensus - reached round state blocks are shared among the nodes belonging to the same working shard. Here, the consensus target transactions may be new transactions that have not been created in the round state blocks up to the previous round.

[0121] In the world round state chain 314, world round state blocks are stored as a chain. The transaction consensus module 228 selects the consensus target round state blocks from all the round state blocks that have reached a consensus in all the working shards of the blockchain network, combines the selected consensus target round state blocks as world round state blocks, reaches a consensus on the combined world round state blocks based on the Byzantine Fault Tolerance consensus algorithm, and can manage the consensus - reached world round state blocks as the world round state chain 314. Such consensus - reached world round state blocks are shared among all the nodes of the blockchain network. Here, the consensus target round state blocks may be new round state blocks that have not been created in the world round state blocks up to the previous round.

[0122] In the World Round State Chain 314, a plurality of world round state blocks agreed upon in all working shards are linked and managed. Each world round state block contains round state blocks agreed upon in their respective working shards. Each round state block contains the transaction chains of all accounts within the working shard agreed upon in any one working shard, and each account's transaction chain contains transaction information executed in each account.

[0123] The transaction sending list 320 is managed by the sending node and the nodes belonging to the sending shard, and the transaction sending list 320 stores the tracked transaction information sent by the sending node. The transaction receiving list 322 is managed by the receiving node and the nodes belonging to the receiving shard, and the transaction receiving list 322 stores the transaction information received by the receiving node.

[0124] FIG. 4 is a diagram showing an example of a blockchain network in which verifiable inter-shard transactions of the present invention are realized.

[0125] In the present invention, a "transaction" is a unit of information added to the blockchain, which can be issued independently by one account, and the content of the transaction can be any information or meaningful message provided by the user. An inter-shard transaction means a transaction between a sending account and a receiving account when the sending account and the receiving account belong to different working shards.

[0126] That is, an inter-shard transaction is a transaction in which the sending shard 410 to which the sending node 411 managing the sending account belongs and the receiving shard 420 to which the receiving node 421 managing the receiving account belongs are different from each other.

[0127] Transactions generated in the sending shard 410 are transmitted to the receiving node 421 via nodes 412, 413, 414 belonging to the sending shard and nodes 422, 423, 424 belonging to the receiving shard. At this time, the sending node 411 and nodes 412, 413, 414 belonging to the sending shard can each add and manage the corresponding transaction in the transaction sending list, and the receiving node 421 and nodes 422, 423, 424 belonging to the receiving shard can each add and manage the corresponding transaction in the transaction receiving list. At least one of the nodes 412, 413, 414 belonging to the sending shard can function as a verification confirmation node, and at least one of the nodes 422, 423, 424 belonging to the receiving shard can function as a verification request node.

[0128] The corresponding transaction is included in the round state block and shared by the sending node 411 and nodes 412, 413, 414 belonging to the sending shard, and is included in the world round state block and shared not only by the sending node 411 and nodes 412, 413, 414 belonging to the sending shard, but also by the receiving node 421 and nodes 422, 423, 424 belonging to the receiving shard.

[0129] The sending node 411 can generate information for verifying the corresponding transaction in the world round state block and transmit it to the receiving node 421 and nodes 422, 423, 424 belonging to the receiving shard via nodes 412, 413, 414 belonging to the sending shard. Then, the receiving node 421 and nodes 422, 423, 424 belonging to the receiving shard can each verify the corresponding transaction based on the received verification information.

[0130] However, if the verification information for the corresponding transaction is not received from the sending node 411, any verification request node (e.g., 424) among the nodes 422, 423, 424 belonging to the receiving shard can request verification of the corresponding transaction from the inter-shard communication nodes 413, 414 of the sending shard 410 via the inter-shard communication nodes 422, 423 within the receiving shard 420. Then, any verification confirmation node (e.g., 413, 414) within the sending shard 410 can generate information for verifying the corresponding transaction in the world round state block and send it to the receiving node 421 and the nodes 422, 423, 424 belonging to the receiving shard. At this time, the verification confirmation nodes 413, 414 of the sending shard 410 may be inter-shard communication nodes capable of communicating with the receiving shard 420.

[0131] When the verification information for the corresponding transaction is received from the verification confirmation nodes 413, 414 of the sending shard 410, the receiving node 421 and the nodes 422, 423, 424 belonging to the receiving shard can each verify the corresponding transaction based on the received verification information.

[0132] FIG. 5 is a configuration diagram showing a verifiable inter-shard transaction system according to an embodiment of the present invention. Such a verifiable inter-shard transaction system can be realized by a computer system of nodes.

[0133] In a verifiable cross-shard transaction, each node can operate as a sending node or a receiving node in some cases, and can also operate as a verification request node or a verification confirmation node. If a node belongs to a sending shard, it operates as a sending node or a verification confirmation node. If a node belongs to a receiving shard, it can operate as a receiving node and a verification request node. The sending node requests the receiving node to process the transaction. The verification request node in the receiving shard can request verification for the corresponding transaction, and the verification confirmation node in the sending shard can generate verification information for the corresponding transaction and send it to the receiving shard.

[0134] Among the nodes belonging to the sending shard that are not sending nodes or verification confirmation nodes, each can manage a transaction sending list based on the data shared for the corresponding transaction. Among the nodes belonging to the receiving shard that are not receiving nodes or verification request nodes, each can verify the received transaction based on the data shared for the corresponding transaction and manage a transaction receiving list.

[0135] To implement the verifiable cross-shard transaction system of the present invention, the data store of the node may include a world round state chain 501 in which a plurality of world round state blocks agreed upon in all working shards are chained together, a transaction sending list 502 in which a sending node or a node belonging to a sending shard stores transaction sending information, and a transaction receiving list 503 in which a receiving node or a node belonging to a receiving shard stores transaction receiving information.

[0136] The verifiable shard - to - shard transaction system 500 for each node may include a driving module 510 as a sending node, a driving module 520 as a verification confirmation node, a driving module 530 as a receiving node, and a driving module 540 as a verification request node. Assume that the node processes a first transaction between a first sending account and a first receiving account, a second transaction between a second sending account and a second receiving account, a third transaction between a third sending account and a third receiving account, and a fourth transaction between a fourth sending account and a fourth receiving account.

[0137] That is, assume that in the first transaction process, the node functions as a sending node (the driving module 510 as the sending node operates), in the second transaction process, the node functions as a verification confirmation node (the driving module 520 as the verification confirmation node operates), in the third transaction process, the node functions as a receiving node (the driving module 530 as the receiving node operates), and in the fourth transaction process, the node functions as a verification request node (the driving module 540 as the verification request node operates).

[0138] FIG. 6 is a configuration block diagram showing the driving module as the sending node of the present invention. 600 Here, the node may be the same as the sending node 411 in FIG. 4.

[0139] The drive module 600 as a sending node includes a transaction generation unit 601 that generates a first transaction between a first sending account and a first receiving account, a transaction request unit 602 that requests the first receiving node that manages the first receiving account to perform the first transaction, a transaction sending list management unit 603 that records and manages the first transaction information in the transaction sending list 502, a transaction verification information calculation unit 604 that calculates transaction verification information for verifying the first transaction in the world round state chain 501 including information related to the first transaction, a transaction verification information sending unit 605 that sends the calculated first transaction verification information to the nodes belonging to the receiving shard of the first transaction, and a transaction completion receiving unit 606 that receives a first transaction completion message from the nodes belonging to the receiving shard of the first transaction.

[0140] Based on the first transaction completion message, the transaction sending list management unit 603 can complete the process of the first transaction in the transaction sending list 502.

[0141] The transaction request unit 602 can obtain the home shard information of the first receiving account through the home shard calculation module, obtain the working shard information of the first receiving account from the nodes belonging to the home shard of the first receiving account, and request the first receiving node to perform the first transaction based on the working shard information of the first receiving account. The home shard calculation module can calculate the home shard information of the first receiving account based on the address information and the total number of shards information of the first receiving account.

[0142] The nodes belonging to the home shard of the first receiving account can store the working shard information of the first receiving account in the account directory and provide the working shard information of the first receiving account to the transaction request unit 602.

[0143] FIG. 7 is a configuration block diagram showing a drive module 700 as a verification confirmation node of the present invention. Here, the node may be any one of the nodes 412, 413, and 414 belonging to the transmission shard of FIG. 4.

[0144] The drive module 700 as a verification confirmation node includes a transaction transmission list management unit 702 that records and manages second transaction information in the transaction transmission list 502, a transaction verification request receiving unit 703 that receives a verification request for the second transaction from a node belonging to the receiving shard of the second transaction, a transaction verification information calculation unit 704 that calculates transaction verification information for verifying the second transaction in the world round state chain 501 including information related to the second transaction, a transaction verification information transmission unit 705 that sends the calculated second transaction verification information to a node belonging to the second transaction receiving shard, and a transaction completion receiving unit 706 that receives a second transaction completion message from a node belonging to the receiving shard of the second transaction.

[0145] The drive module 700 as a verification confirmation node may further include a transaction request transmission unit 701 that transmits the second transaction. The second transaction can be transmitted via the verification confirmation node, or can be transmitted via another node in the transmission shard without passing through the verification confirmation node.

[0146] The transaction transmission list management unit 702 can complete the process of the second transaction in the transaction transmission list 502 based on the second transaction completion message.

[0147] The transaction verification information calculation unit 60 of FIG. 6 4and the transaction verification information calculation unit 704 in FIG. 7 can be the same component. Since the sending node and the verification confirmation node belong to the same shard and share all transaction information, the verification confirmation node can calculate the verification information for the transactions of the sending node. The transaction verification information sending unit 60 in FIG. 6 5 and the transaction verification information sending unit 70 in FIG. 7 5 can be the same component. Also, the transaction completion receiving unit 60 in FIG. 6 6 and the transaction completion receiving unit 706 in FIG. 7 are the same components, and the transaction transmission list management unit 603 in FIG. 6 and the transaction transmission list management unit 702 in FIG. 7 can be the same components.

[0148] Also, nodes among the nodes belonging to the sending shard that are not the sending node and the verification confirmation node may include a transaction request transmission unit, a transaction completion receiving unit, and a transaction transmission list management unit. While transmitting the corresponding transaction via the transaction request transmission unit, the corresponding transaction information is added to the transaction transmission list, and when the corresponding transaction completion message is received via the transaction completion receiving unit, the corresponding transaction is completed in the transaction transmission list.

[0149] FIG. 8 is a configuration block diagram showing a drive module 800 as a receiving node of the present invention. Here, the node may be the receiving node 421 in FIG. 4.

[0150] The drive module 800 as a receiving node includes a transaction request receiving unit 801 that receives a third transaction request between a third sending account and a third receiving account, a transaction receiving list management unit 802 that records and manages the third transaction information in the transaction receiving list 503, a transaction verification information receiving unit 803 that receives verification information for the third transaction from a node belonging to the sending shard of the third transaction, a transaction verification unit 804 that applies the verification information for the third transaction to the world round state chain 501 to verify the third transaction, a transaction processing unit 805 that registers the verified third transaction in the transaction chain of the third receiving account, and a transaction completion sending unit 806 that sends a third transaction completion message to a node belonging to the sending shard of the third transaction for the third transaction registered in the transaction chain.

[0151] When the third transaction is verified by the transaction verification unit 804 or registered in the transaction chain by the transaction processing unit 805, the transaction receiving list management unit 802 changes the status information of the third transaction recorded in the transaction receiving list 503. For example, when the third transaction is requested, the transaction receiving list management unit 802 marks the status of the third transaction as "arrived" while recording the third transaction information in the transaction receiving list. When the verification is completed by the transaction verification unit 804, the status of the third transaction is changed to "confirmed", and when the chain registration is completed by the transaction processing unit 805, the status of the third transaction is changed to "active".

[0152] The verification information for the third transaction received by the transaction verification information receiving unit 803 can also be received via the sending node that manages the third sending account, or can be received via the verification confirmation node of the third sending shard.

[0153] FIG. 9 is a configuration block diagram showing the drive module 900 as the verification request node of the present invention. Here, the node may be any one of the nodes 422, 423, and 424 belonging to the receiving shard in FIG. 4.

[0154] The drive module 900 as the verification request node includes a transaction reception list management unit 902 that records and manages the fourth transaction information in the transaction reception list 503, a transaction verification request transmission unit 903 that sends a verification request for the fourth transaction to the node belonging to the sending shard of the fourth transaction if the verification information for the fourth transaction is not received, a transaction verification information receiving unit 904 that receives the verification information for the fourth transaction from the node belonging to the sending shard of the fourth transaction, a transaction verification unit 905 that applies the verification information for the fourth transaction to the world round state chain 501 to verify the fourth transaction, and a transaction completion transmission unit 906 that receives the fourth transaction completion message from the receiving node and sends it to the node belonging to the sending shard of the fourth transaction.

[0155] The drive module 900 as the verification request node may further include a transaction request transmission unit 901 that transmits the fourth transaction between the fourth sending account and the fourth receiving account. The fourth transaction can also be transmitted via the verification request node, or can be transmitted via other nodes in the receiving shard without passing through the verification request node.

[0156] When the fourth transaction is verified by the transaction verification unit 905 or the fourth transaction completion message is received by the transaction completion transmission unit 906, the transaction reception list management unit 902 changes the status information of the fourth transaction recorded in the transaction reception list 503. For example, when transmitting a fourth transaction request, the transaction reception list management unit 902 records the fourth transaction information in the transaction reception list, marks the status of the fourth transaction as "arrived", and when the verification is completed in the transaction verification unit 905, changes the status of the fourth transaction to "confirmed", and when the fourth transaction completion message is received by the transaction completion transmission unit 906, changes the status of the fourth transaction to "activate".

[0157] The transaction verification information reception unit 803 in FIG. 8 and the transaction verification information reception unit 904 in FIG. 9 may be the same component. The transaction verification unit 804 in FIG. 8 and the transaction verification unit 905 in FIG. 9 may be the same component. Since all the receiving nodes and verification request nodes share the same world round state chain, all the nodes belonging to the receiving shard can verify transactions using their respective world round state chains. Also, the transaction reception list management unit 802 in FIG. 8 and the transaction reception list management unit 902 in FIG. 9 may be the same component.

[0158] Also, among the nodes belonging to the receiving shard, nodes that are neither the receiving node nor the verification request node may include a transaction request transmission unit, a transaction verification information receiving unit, a transaction verification unit, a transaction completion transmission unit, and a transaction reception list management unit. While transmitting the transaction by the transaction request transmission unit, the transaction information is added to the transaction reception list, and the status of the transaction is displayed as "arrival". When the transaction is verified by the transaction verification unit, the status of the transaction is changed to "verified". When the transaction completion message is received by the transaction completion transmission unit, the status of the transaction is changed to "activated".

[0159] For the first transaction between the first sending account and the first receiving account, if the node is a sending node that manages the first sending account, the node drives the driving modules 510 and 600 as the sending node for verifiable transaction processing. Hereinafter, the operations of the respective components of the driving module 600 as the sending node will be described.

[0160] The transaction generation unit 601 generates a first transaction between the first sending account and the first receiving account. Here, the first sending account and the first receiving account belong to different working shards, and the first transaction may be an inter-shard transaction.

[0161] The transaction request unit 602 requests the first receiving node of the first transaction to send the first transaction, and the transaction transmission list management unit 603 records the first transaction information in the transaction transmission list 502. The request for the first transaction is transmitted to the first receiving node through peer-to-peer communication via nodes belonging to a large number of shards in the blockchain network. Since the sending node managing the first sending account and the first receiving node managing the first receiving account do not share the account-specific transaction chain (AWTC) of the account, the first receiving node cannot immediately determine whether the first transaction is a legitimate transaction. If the first transaction is not a legitimate transaction and the first receiving node processes the first transaction, the reliability of transactions in the blockchain network will be compromised. Therefore, in the present invention, a process of verifying the legitimacy of the first transaction is performed.

[0162] As described above, in the world round state chain 501, a plurality of world round state blocks agreed upon in all working shards are linked and managed. Each world round state block contains round state blocks agreed upon in their respective working shards. Each round state block contains the transaction chains of all accounts within each working shard, and each account's transaction chain contains transaction information executed in that account. Also, the world round state chain is shared by all nodes constituting the blockchain network. Therefore, the transaction chain of the sending account containing the first transaction information is included in the round state block, the corresponding round state block is included in the world round state block, and the corresponding world round state block is included in and shared by the world round state chain. In this case, the first transaction information can be verified via the world round state block, the round state block, and the transaction chain of the sending account from the world round state chain.

[0163] As described above, when the first transaction is registered in the world round state chain, the transaction verification information calculation unit 604 calculates transaction verification information for verifying the first transaction in the world round state chain 501 that contains information regarding the first transaction, and the transaction verification information transmission unit 605 transmits the calculated first transaction verification information to the first receiving node.

[0164] Transaction Nkan When the transaction receiving unit 606 receives the first transaction completion message from the first receiving node, the transaction transmission list management unit 603 performs completion processing on the first transaction in the transaction transmission list 502.

[0165] After the transaction verification information transmission unit 605 sends the first transaction verification information to the first receiving node, if the first transaction completion message is not received from the first receiving node until a certain period of time has elapsed, the first transaction verification information can be resent.

[0166] The transaction request unit 602 can obtain the home shard information of the first receiving account via the home shard calculation module, obtain the working shard information of the first receiving account from the node belonging to the home shard of the first receiving account, and request the first receiving node to perform the first transaction based on the working shard information of the first receiving account.

[0167] For the second transaction between the second sending account and the second receiving account, if the node is the verification confirmation node belonging to the sending shard, the node drives the driving modules 520 and 700 as the verification confirmation node for verifiable transaction processing. Hereinafter, the operations of the respective components of the driving module 700 as the verification confirmation node will be described.

[0168] The transaction request transmission unit 701 can transmit the second transaction between the second sending account and the second receiving account. In some cases, the transaction request transmission unit 701 may receive the second transaction and not transmit it. The transaction transmission list management unit 702 records the second transaction information in the transaction transmission list 502. The node belonging to the receiving shard of the second transaction requests the verification information for the second transaction if the verification information for the second transaction is not received for a certain period of time.

[0169] At this time, the transaction verification request receiving unit 703 calculates second transaction verification information for verifying the second transaction in the world round state chain 501 including information related to the second transaction, and the transaction verification information transmitting unit 705 transmits the calculated second transaction verification information to the nodes belonging to the receiving shard of the second transaction.

[0170] Transaction Nkan When the receiving unit 706 receives a second transaction completion message from the nodes belonging to the receiving shard of the second transaction, the transaction transmission list management unit 702 performs completion processing on the second transaction in the transaction transmission list 502.

[0171] After the transaction verification information transmitting unit 705 sends the second transaction verification information to the nodes belonging to the receiving shard of the second transaction, if the second transaction completion message is not received until a certain period of time has elapsed, the second transaction verification information can be resent.

[0172] For a third transaction between a third sending account and a third receiving account, if the node is a receiving node that manages the third receiving account, the node drives the driving modules 530 and 800 as the receiving node for verifiable transaction processing. Hereinafter, the operations of the respective components of the driving module 800 as the receiving node will be described.

[0173] The transaction request receiving unit 801 receives a third transaction request between the third sending account and the third receiving account. The transaction reception list management unit 802 adds the third transaction information to the transaction reception list and displays the status of the third transaction as "arrived". The third sending node may be a node that manages the third sending account. This third transaction request can be transmitted via peer-to-peer communication through nodes belonging to a number of shards in the blockchain network. The third sending account and the third receiving account belong to different working shards, and the third transaction may be an inter-shard transaction.

[0174] The transaction verification information receiving unit 803 receives the third transaction verification information from the third sending node. This third transaction verification information may be information that enables the verification of the third transaction information from the world round state chain 501. Therefore, before the third transaction verification information is received, it is preferable that the world round state block including the third transaction information is shared and stored in the world round state chain 501.

[0175] The transaction verification unit 804 applies the third transaction verification information to the world round state chain 501 to verify the third transaction. When the verification of the third transaction is completed, the transaction reception list management unit 802 changes the status of the third transaction in the transaction reception list to "verified".

[0176] The transaction processing unit 805 registers the verified third transaction in the transaction chain of the third receiving account, and the transaction reception list management unit 802 changes the status of the third transaction in the transaction reception list to "activated".

[0177] Transaction NkanOnce the verification is completed and the third transaction has been successfully registered on the transaction chain, the sending unit 806 generates a third transaction completion message for the third transaction and sends it to the third sending node.

[0178] For the fourth transaction between the fourth sending account and the fourth receiving account, if the node is a verification request node belonging to the receiving shard, the node drives the driving modules 540 and 900 as the verification request node for processing the verifiable transaction. Hereinafter, the operations of each component of the driving module 900 as the verification request node will be described.

[0179] The transaction request transmission unit 901 can transmit the fourth transaction between the fourth sending account and the fourth receiving account. In some cases, the transaction request transmission unit 901 may receive the fourth transaction but not transmit it. The transaction reception list management unit 902 records the fourth transaction information in the transaction reception list 503 and records the status of the fourth transaction as "arrived".

[0180] If no verification information for the fourth transaction is received within a certain period, the transaction verification request sending unit 903 requests the verification information for the fourth transaction from the nodes belonging to the sending shard of the fourth transaction.

[0181] The transaction verification information receiving unit 904 receives the verification information for the fourth transaction from the nodes belonging to the sending shard of the fourth transaction. This fourth transaction verification information may be information that enables the fourth transaction to be verified from the world round state chain 501.

[0182] The transaction verification unit 905 applies the verification information for the fourth transaction to the world round state chain 501 to verify the fourth transaction. When the fourth transaction is verified, the transaction reception list management unit 902 changes the state of the fourth transaction in the transaction reception list to "verified".

[0183] After that, when the fourth transaction is registered in the transaction chain from the receiving node of the fourth transaction and a transaction completion message is sent, the transaction completion transmission unit 906 transmits the transaction completion message to the nodes belonging to the sending shard of the fourth transaction, and the transaction reception list management unit 902 changes the state of the fourth transaction in the transaction reception list to "activated".

[0184] In the inter-shard transaction verification method of the present invention, the transaction verification information calculated at the sending node can be transmitted to the receiving node and the nodes belonging to the receiving shard, and the transaction verification information calculated at the verification confirmation node by the request of the verification request node can be transmitted to the receiving node and the nodes belonging to the receiving shard.

[0185] FIG. 10 is an operation flowchart showing the verifiable inter-shard transaction method according to the first embodiment of the present invention. In the inter-shard transaction method of the first embodiment of the present invention, the transaction verification information calculated at the sending node is transmitted to the receiving node and the nodes belonging to the receiving shard. The inter-shard transaction method according to the first embodiment of the present invention does not require a separate verification request node and verification confirmation node.

[0186] The operations of the exemplary process are illustrated in individual blocks and are described with reference to these blocks. The process is illustrated as a logical flow of blocks, where each block represents one or more operations that can be implemented in hardware, software, or a combination thereof. In the context of software, the operations represent computer-executable instructions stored on one or more computer-readable media that enable one or more processors to perform the operations recited when executed by the one or more processors. Generally, computer-executable instructions include routines, programs, objects, modules, components, data structures, performing particular functions or implementing particular abstract data types. The order in which the operations are described should not be construed as limiting, and the number of described operations can be subdivided into a number of sub-operations in any order or executed in parallel.

[0187] The sending node generates an inter-shard transaction between the sending account and the receiving account (S1001).

[0188] The sending node requests the receiving node that manages the receiving account to perform the transaction, and records the transaction information in the transaction sending list 502 (S1002). To request the receiving node to perform the transaction, the sending node can obtain the home shard information of the receiving account and the working shard information of the receiving account from the node belonging to the home shard of the receiving account. The sending node transmits a transaction request message to the communication target node based on the in-shard communication node list and the inter-shard communication node list through peer-to-peer communication. The node that receives the transaction request message shares the transaction request message with its in-shard communication nodes and inter-shard communication nodes through peer-to-peer communication. In this way, the transaction request message can be transmitted to the receiving node through peer-to-peer communication.

[0189] That is, the transaction request of the sending node is transmitted to the nodes belonging to the sending shard, and the nodes belonging to the sending shard transmit the transaction request to other nodes and record the transaction information in the transaction sending list (S1003).

[0190] Through the inter-shard communication between the sending shard and the receiving shard, the transaction request is transmitted to the nodes belonging to the receiving shard.

[0191] The nodes belonging to the receiving shard transmit the transaction request to the receiving node, add the transaction information to the transaction receiving list, and record the transaction status as "arrived" (S1004).

[0192] The receiving node receives the transaction request message to receive the transaction request, adds the transaction information to the transaction receiving list, and records the transaction status as "arrived" (S1005).

[0193] The sending node registers the transaction generated in the sending account as a transaction chain, generates a round state block including the transaction chain and links it to the round state chain, and generates a world round state block including the round state block and links it to the world round state chain. As a result, the world round state chain including the transaction information generated in the sending account can be shared by all nodes in the blockchain network.

[0194] After that, the sending node calculates the transaction verification information for verifying the transaction in the world round state chain including the information related to the transaction (S1006), and sends the calculated transaction verification information to the receiving node by peer-to-peer communication (S1007).

[0195] At this time, the nodes belonging to the sending shard transmit the transaction verification information to the nodes belonging to the receiving shard via peer-to-peer communication (S1008).

[0196] The nodes belonging to the receiving shard receive the transaction verification information, transmit it to the receiving nodes, apply the transaction verification information to the world round state chain to verify the transaction, and when the verification is completed, change the transaction state to "verified" in the transaction reception list (S1009).

[0197] The receiving nodes receive the transaction verification information, apply the transaction verification information to the world round state chain to verify the transaction, and when the verification is completed, change the transaction state to "verified" in the transaction reception list (S1010).

[0198] The transaction verification information can be information that enables the verification of transaction information from the world round state chain. Therefore, before the transaction verification information is received by the receiving nodes and the nodes belonging to the receiving shard, it is preferable that the world round state block containing the transaction information is shared with the receiving nodes and the nodes belonging to the receiving shard, and the world round state chain of the receiving nodes and the nodes belonging to the receiving shard is updated.

[0199] The receiving node registers the verified transaction in the transaction chain of the receiving account (S1011), sends a transaction completion message, and changes the transaction state to "activated" in the transaction reception list (S1012).

[0200] The receiving node generates a transaction completion message for the transaction whose verification and chain registration are completed and sends it to the sending node via peer-to-peer communication.

[0201] The nodes belonging to the receiving shard transmit the transaction completion message to the nodes belonging to the sending shard, and change the transaction state to "activated" in the transaction reception list (S1013).

[0202] The nodes belonging to the sending shard transmit the transaction completion message to the sending node, and complete the transaction in the transaction transmission list (S1014).

[0203] The sending node receives the transaction completion message, and completes the transaction in the transaction transmission list (S1015).

[0204] FIG. 11 is an operation flowchart showing a verifiable inter-shard transaction method according to a second embodiment of the present invention. In the inter-shard transaction method of the second embodiment of the present invention, the transaction verification information calculated at the verification confirmation node is transmitted to the receiving node and the nodes belonging to the receiving shard.

[0205] The operations of the exemplary process are shown as individual blocks and are described with reference to these blocks. The process is shown as a logical flow of blocks, and each block can represent one or more operations that can be implemented in hardware, software, or a combination thereof. With respect to software, the operations represent computer-executable instruction words stored in one or more computer-readable media that enable one or more processors to execute the operations cited by the one or more processors when executed by the one or more processors. Generally, computer-executable instruction words include performing routines, programs, objects, modules, components, data structures, executing specific functions, or implementing specific abstract data types. The order in which the operations are described should not be construed as limiting, and the number of operations described can be subdivided into a plurality of sub-operations or executed in parallel in any order.

[0206] The sending node generates an inter-shard transaction between the sending account and the receiving account (S1101).

[0207] The sending node requests the receiving node that manages the receiving account to perform the transaction, and records the transaction information in the transaction sending list 502 (S1102). To request the receiving node to perform the transaction, the sending node can obtain the home shard information of the receiving account and obtain the working shard information of the receiving account from the node belonging to the home shard of the receiving account. The sending node transmits a transaction request message to the communication target node based on the in-shard communication node list and the inter-shard communication node list through peer-to-peer communication. The nodes that receive the transaction request message share the transaction request message with their respective in-shard communication nodes and inter-shard communication nodes through peer-to-peer communication. In this way, the transaction request message can be transmitted to the receiving node through peer-to-peer communication.

[0208] That is, the transaction request of the sending node is transmitted to the nodes belonging to the sending shard including the verification confirmation node. The nodes belonging to the sending shard make the transaction request be shared with the nodes belonging to the sending shard and the nodes belonging to the receiving shard through P2P communication. The verification confirmation node receives the transaction request and records the transaction information in the transaction sending list (S1103). Each of the nodes belonging to the sending shard records the corresponding transaction information in the transaction sending list while receiving the transaction request.

[0209] Through the inter-shard communication between the sending shard and the receiving shard, the transaction request is transmitted to the nodes belonging to the receiving shard including the verification request node.

[0210] The nodes belonging to the receiving shard transmit the transaction request to the receiving node or the nodes belonging to other receiving shards via peer-to-peer communication so that it is shared among the nodes belonging to the receiving shard. The verification request node receives the transaction request, records the transaction information in the transaction reception list, and records the transaction state as "arrived" (S1104). The nodes belonging to the receiving shard each add the corresponding transaction information to the transaction reception list while transmitting the transaction request, and record the transaction state as "arrived".

[0211] The receiving node receives the transaction request message, receives the transaction request, adds the transaction information to the transaction reception list, and records the transaction state as "arrived" (S1105).

[0212] The sending node registers the transaction generated at the sending account as a transaction chain, generates a round state block including the transaction chain and concatenates it to the round state chain, and generates a world round state block including the round state block and concatenates it to the world round state chain. As a result, the world round state chain including the transaction information generated at the sending account can be shared among all the nodes in the blockchain network.

[0213] If the transaction verification information is not received from the sending node until a certain period has elapsed since the transaction was requested, any verification request node among the nodes belonging to the receiving shard requests the transaction verification information from the node belonging to the sending shard (S1106).

[0214] Among the nodes belonging to the sending shard that has been requested for transaction verification information, the verification confirmation node receives the transaction verification request (S1107), calculates the transaction verification information for verifying the transaction in the world round state chain containing the information about the transaction, and sends the calculated transaction verification information to the verification request node via peer-to-peer communication (S1108).

[0215] The verification request node receives the transaction verification information, transmits it to the receiving node or the nodes belonging to the receiving shard, applies the transaction verification information to the world round state chain to verify the transaction, and when the verification is completed, changes the transaction state to "verified" in the transaction reception list (S1109). Although not shown, the nodes belonging to the receiving shard transmit the transaction verification information via peer-to-peer communication, apply the transaction verification information to the world round state chain to verify the transaction, and when the verification is completed, change the transaction state to "verified" in their respective transaction reception lists.

[0216] The receiving node receives the transaction verification information, applies the transaction verification information to the world round state chain to verify the transaction, and when the verification is completed, changes the transaction state to "verified" in the transaction reception list (S1110).

[0217] The transaction verification information can be information that enables the verification of the transaction information from the world round state chain. Therefore, before the transaction verification information is received by the receiving node and the nodes belonging to the receiving shard, it is preferable that the world round state block containing the transaction information is shared with the receiving node and the nodes belonging to the receiving shard, and the world round state chain of the receiving node and the nodes belonging to the receiving shard is updated.

[0218] The receiving node registers the verified transaction in the transaction chain of the receiving account (S1111), sends a transaction completion message, and changes the transaction status to "activated" in the transaction reception list (S1112). The receiving node generates a transaction completion message for the transaction for which verification and chain registration are complete and sends it to the sending node via peer-to-peer communication.

[0219] The nodes belonging to the receiving shard including the verification request node transmit the transaction completion message to the nodes belonging to the sending shard and change the transaction status to "activated" in the transaction reception list (S1113).

[0220] The nodes belonging to the sending shard including the verification confirmation node transmit the transaction completion message to the sending node and complete the transaction in the transaction transmission list (S1114).

[0221] The sending node receives the transaction completion message and completes the transaction in the transaction transmission list (S1115).

[0222] All of the above methods and processes can be realized by software code modules executed by one or more general-purpose computers or processors and fully automated. The code modules can be stored in any type of computer-readable storage medium or other computer storage device. Some or all of the methods can be realized by special computer hardware.

[0223] Any routine description, element, or block of a flowchart described herein and / or shown in the accompanying drawings should be understood as potentially representing code, a module, a segment, or a portion that includes one or more executable instructions for implementing a particular logical function or element. Routine, alternative examples are included within the scope of the examples described herein, and elements or functions may be substantially, synchronously, or sequentially removed and executed in order from what is illustrated or discussed herein according to the functions understood herein.

[0224] Numerous modifications and variations can be made to the foregoing embodiments, and it should be understood that the elements thereof are one of other acceptable examples. All such modifications and variations are intended to be included within the scope of the present disclosure and protected by the following claims. The embodiments of the present invention described above can be implemented in the form of program instruction words executed via various computer components and can be recorded on a computer-readable recording medium. The computer-readable recording medium can include program instruction words, data files, data structures, etc. alone or in combination. The program instruction words recorded on the computer-readable recording medium may be those specially designed and configured for the present invention or those known and usable by those skilled in the field of computer software. Examples of computer-readable recording media include magnetic media such as hard disks, floppy disks, magnetic tapes, optical recording media such as CD-ROMs, DVDs, magneto-optical media such as floptical disks, and hardware devices specially configured to store and execute program instruction words such as ROMs, RAMs, flash memories, etc. Examples of program instruction words include not only machine language code created by a compiler but also high-level language code that can be executed by a computer using an interpreter or the like. The hardware device can be configured to operate as one or more software modules for executing the processes according to the present invention, and vice versa.

[0225] As described above, the present invention has been described with reference to the embodiments and drawings that specify specific matters such as specific components. However, this is provided to assist in a more overall understanding of the present invention, and the present invention is not limited to the above-described embodiments. Those having ordinary knowledge in the technical field to which the present invention pertains can make various modifications and variations from such descriptions.

[0226] Therefore, the idea of the present invention should not be limited to the described embodiments, and not only the scope of the following claims, but all things equivalently or equivalently modified from this scope of claims should be regarded as belonging to the category of the idea of the present invention.

Explanation of Reference Numerals

[0227] 222: Inter-shard Transaction System 224: Account Management Module 226: Peer-to-Peer Communication Module 228: Transaction Consensus Module 230: Home Shard Calculation Module 232: Transaction Processing Module 234: Transaction Verification Module

Claims

1. In a verifiable shard - to - shard transaction system in a node that manages a first sending account before performing a first transaction between the first sending account and a first receiving account, the node includes: a transaction generation unit that generates the first transaction; a transaction request unit that requests the first transaction to a receiving node that manages the first receiving account; a transaction sending list management unit that records and manages first transaction information in a transaction sending list; a transaction verification information calculation unit that calculates first transaction verification information for verifying the first transaction in a world - round state chain including the first transaction information; and a transaction verification information sending unit that sends the first transaction verification information to a node belonging to a receiving shard of the first transaction. A verifiable shard - to - shard transaction system in a blockchain network.

2. The node further includes: a transaction completion receiving unit that receives a transaction completion message for the first transaction. The verifiable shard - to - shard transaction system in a blockchain network according to Claim 1.

3. The transaction sending list management unit performs a completion process on the first transaction in the transaction sending list based on a transaction completion message for the first transaction. The verifiable shard - to - shard transaction system in a blockchain network according to Claim 2.

4. The transaction request unit: obtains home shard information of the first receiving account, obtains working shard information of the first receiving account from a node belonging to the home shard of the first receiving account, and requests the first transaction to the receiving node based on the working shard information of the first receiving account. The verifiable shard - to - shard transaction system in a blockchain network according to Claim 1.

5. The node is a verification confirmation node for a second transaction between a second sending account and a second receiving account. The node includes: The transaction transmission list management unit that records and manages the second transaction information in the transaction transmission list. The transaction verification request receiving unit that receives a verification request for the second transaction from a node belonging to the receiving shard of the second transaction. The transaction verification information calculation unit that calculates second transaction verification information for verifying the second transaction in the world round state chain including information related to the second transaction. Further including the transaction verification information transmission unit that sends the second transaction verification information to a node belonging to the receiving shard of the second transaction. The verifiable inter-shard transaction system in the blockchain network according to claim 1.

6. The node Further includes a transaction request transmission unit that transmits the second transaction. The verifiable inter-shard transaction system in the blockchain network according to claim 5.

7. The node Further includes a transaction completion receiving unit that receives a transaction completion message for the second transaction. The verifiable inter-shard transaction system in the blockchain network according to claim 5.

8. The transaction transmission list management unit performs completion processing of the second transaction in the transaction transmission list based on a transaction completion message for the second transaction. The verifiable inter-shard transaction system in the blockchain network according to claim 7.

9. The node is a receiving node that performs a third transaction between a third sending account and a third receiving account, and manages the third receiving account. The node A transaction request receiving unit that receives a third transaction request from a sending node that manages the third sending account; A transaction receiving list management unit that records and manages third transaction information in a transaction receiving list; A transaction verification information receiving unit that receives verification information for the third transaction from a node belonging to the sending shard of the third transaction. A transaction verification unit that applies verification information for the third transaction to the world round state chain to verify the third transaction; A transaction processing unit that registers the verified third transaction in the transaction chain of the third receiving account; and Further includes a transaction completion transmitter that sends a third transaction completion message to a node belonging to the sending shard of the third transaction for the third transaction registered in the transaction chain. The verifiable inter-shard transaction system in the blockchain network according to claim 1.

10. When the third transaction is verified in the transaction verification unit or the third transaction is registered in the transaction chain in the transaction processing unit, the transaction reception list management unit changes the status information of the third transaction recorded in the transaction reception list. The verifiable inter-shard transaction system in the blockchain network according to claim 9.

11. The node is a verification request node for a fourth transaction between a fourth sending account and a fourth receiving account. The node is A transaction reception list management unit that records and manages fourth transaction information in the transaction reception list. A transaction verification request transmitter that sends a verification request for the fourth transaction to a node belonging to the sending shard of the fourth transaction. A transaction verification information receiver that receives verification information for the fourth transaction from a node belonging to the sending shard of the fourth transaction. And Further includes a transaction verification unit that applies the verification information for the fourth transaction to the world round state chain to verify the fourth transaction. The verifiable inter-shard transaction system in the blockchain network according to claim 9.

12. The node is Further includes a transaction request transmitter that transmits the fourth transaction. The verifiable inter-shard transaction system in the blockchain network according to claim 11.

13. The transaction completion transmission unit further includes receiving a fourth transaction completion message from the receiving node of the fourth transaction and transmitting it to the nodes belonging to the transmission shard of the fourth transaction. The verifiable inter-shard transaction system in the blockchain network according to claim 11.

14. When the fourth transaction is verified by the transaction verification unit or the fourth transaction completion message is received from the transaction completion transmission unit, the transaction reception list management unit changes the state information of the fourth transaction recorded in the transaction reception list. The verifiable inter-shard transaction system in the blockchain network according to claim 13.

15. In a node that manages the first sending account that performs the first transaction between the first sending account and the first receiving account, in a verifiable inter-shard transaction method realized by at least one processor, The method includes: The step of the node generating a first transaction; The step of the node requesting the first transaction from the receiving node that manages the first receiving account; The step of the node recording and managing the first transaction information in the transaction transmission list; The step of the node calculating first transaction verification information for verifying the first transaction in the world round state chain including the first transaction information; and The step of the node sending the first transaction verification information to the nodes belonging to the receiving shard of the first transaction. The verifiable inter-shard transaction method in the blockchain network.

16. The method further includes the step of the node receiving a transaction completion message for the first transaction. The verifiable inter-shard transaction method in the blockchain network according to claim 15.

17. The method further includes the step of the node completing the first transaction in the transaction transmission list based on the transaction completion message for the first transaction. A method for verifiable cross-shard transactions in a blockchain network according to claim 16.

18. The step of the node requesting the first transaction from the receiving node that manages the first receiving account includes: obtaining the home shard information of the first receiving account, obtaining the working shard information of the first receiving account from a node belonging to the home shard of the first receiving account, and requesting the first transaction from the receiving node based on the working shard information of the first receiving account. A method for verifiable cross-shard transactions in a blockchain network according to claim 15.

19. The node is a verification confirmation node for a second transaction between a second sending account and a second receiving account. The method includes: the step of the node recording and managing the second transaction information in the transaction sending list; the step of the node receiving a verification request for the second transaction from a node belonging to the receiving shard of the second transaction; the step of the node calculating second transaction verification information for verifying the second transaction in the world round state chain including information related to the second transaction; further including the step of the node sending the second transaction verification information to a node belonging to the receiving shard of the second transaction. A method for verifiable cross-shard transactions in a blockchain network according to claim 15.

20. The method further includes the step of the node transmitting the second transaction. A method for verifiable cross-shard transactions in a blockchain network according to claim 19.

21. The method further includes the step of the node receiving a transaction completion message for the second transaction. A method for verifiable cross-shard transactions in a blockchain network according to claim 19.

22. The method further includes the step of the node completing the second transaction in the transaction sending list based on the transaction completion message for the second transaction. A method for verifiable cross-shard transactions in a blockchain network according to claim 21.

23. The node is a receiving node that manages the third receiving account for performing a third transaction between a third sending account and the third receiving account, The method includes: The step of the node receiving the third transaction request from a sending node that manages the third sending account; The step of the node recording and managing the third transaction information in a transaction reception list; The step of the node receiving verification information for the third transaction from a node belonging to the sending shard of the third transaction; The step of the node applying the verification information for the third transaction to a world round state chain to verify the third transaction; The step of the node registering the third transaction that has been verified in the transaction chain of the third receiving account; and, The method further includes the step of the node sending a third transaction completion message to a node belonging to the sending shard of the third transaction for the third transaction registered in the transaction chain. A method for verifiable cross-shard transactions in a blockchain network according to claim 15.

24. The method further includes the step of the node changing the state information of the third transaction recorded in the transaction reception list when the third transaction is verified or when the third transaction is registered in the transaction chain. A method for verifiable cross-shard transactions in a blockchain network according to claim 23.

25. The node is a verification request node for a fourth transaction between a fourth sending account and a fourth receiving account, The method includes: The step of the node recording and managing the fourth transaction information in a transaction reception list, The step of the node requesting verification for the fourth transaction from a node belonging to the sending shard of the fourth transaction, The step of the node receiving verification information for the fourth transaction from a node belonging to the sending shard of the fourth transaction, and, The step of the node applying verification information for the fourth transaction to the world round state chain to verify the fourth transaction is further included. The method for verifiable inter-shard transactions in a blockchain network according to claim 15.

26. The step of the node further transmitting the fourth transaction is included. The method for verifiable inter-shard transactions in a blockchain network according to claim 25.

27. The step of the node further receiving a fourth transaction completion message from the receiving node of the fourth transaction and transmitting it to the node belonging to the sending shard of the fourth transaction is included. The method for verifiable inter-shard transactions in a blockchain network according to claim 26.

28. The step of the node further changing the state information of the fourth transaction recorded in the transaction reception list when the fourth transaction is verified or the fourth transaction completion message is received is included. The method for verifiable inter-shard transactions in a blockchain network according to claim 27.

Images