Consensus building system

Abstract

To reduce an amount of data of a blockchain held by a light node.SOLUTION: A system comprises: a full node that divides data of a blockchain into block groups including a plurality of blocks and holds them; and a light node that creates a chain of block group headers using header information of a plurality of blocks included in a chain of block headers recorded on an own device and removes block headers included in the chain of block group headers from the chain of block headers.SELECTED DRAWING: Figure 4

Description

TECHNICAL FIELD

[0001] The present disclosure relates to a technology for reducing the data capacity of a blockchain. BACKGROUND ART

[0002] A blockchain is a technology in which transaction data determined to be valid within a certain period is grouped into units called blocks, and the hash values of these blocks are linked on a chain, enabling consensus among multiple nodes on a set of valid transaction data and the execution order thereof. Among nodes that store all data of a blockchain (hereinafter referred to as full nodes), a node selected by a random draw for which falsification is considered difficult, such as Proof of Work (PoW), generates a next block connected to the end of the blockchain that it has determined to be valid, and transmits said next block to the blockchain network. All full nodes connect the received block to the end of the blockchain. Therefore, as the length of a blockchain increases, it can be statistically guaranteed that a large number of full nodes regard the chain as valid, i.e., consensus has been formed among multiple nodes. In addition, since all full nodes retain the data of a blockchain, extremely high fault tolerance is achieved.

[0003] A full node is an important node that stably maintains a blockchain, and is a node that retains all block data from the genesis block of the blockchain to the latest block. Since a full node retains all blocks, it can determine the validity or invalidity of all transaction data (hereinafter referred to as transactions, abbreviated as Tx). By operating as a full node, the security of the blockchain network is guaranteed through Tx verification, and a user can obtain rewards by becoming a block creator. Therefore, operating as a full node has advantages for both all other nodes in the network and the user of the node itself.

[0004] Figure 1 shows an example of a block structure. For ease of understanding, the figure shows an example where the blockchain consists of two blocks, 11#101 and #102. Each block contains one or more transactions (Tx) and a block header. The block header stores the version, Nonce, Previous Hash, time, Merkle Root, and n Bits. The Nonce is information used in Proof of Work (PoW) and is an arbitrary bit sequence of a certain length. The Previous Hash is the hash value of the block header of the previous verified block (the top-level block in the main chain). Note that the Previous Hash of the first block group header may store the hash value of the block header of the first block in the blockchain (the genesis block) to explicitly indicate its correspondence with the blockchain.

[0005] Figure 2 shows an example of a Merkle root. The Merkle root is a value obtained using the hash values ​​of transactions. For example, if there are four transactions, the hash value of each is calculated, and two of these hash values ​​are used to calculate further hash values ​​(Hash0 and Hash1), and then the hash value of Hash0 and Hash1 (Top Hash) is calculated. In this way, the Merkle root can be calculated by calculating hash values ​​according to the tree structure.

[0006] Because storing all block data would result in an enormous amount of data, a light node is defined that only holds the block header information (Block Header) for each block and does not hold transaction data. Light nodes do not hold blockchain data, but they can issue transactions (Tx) and verify that the transactions have been incorporated into the blockchain by a full node.

[0007] Public blockchains like Ethereum and Bitcoin require the retention of all past transaction data. The number of users is increasing year by year, and the number of transactions issued per unit of time is also increasing significantly. As of June 11, 2021, a full Ethereum node held 821GB of blockchain data, an increase of approximately 445GB compared to June 11, 2020. While a light node holds only about 1 / 19th the size of the blockchain data (block headers), both types of nodes are likely to see a rapid increase in the amount of data they need to retain in the future. This increase in data volume will necessitate larger SSDs or HDDs for users operating full or light nodes.

[0008] In Kaneko et al.'s research, nodes belonging to a network were randomly clustered based on their IP addresses, and blocks were created in the order of the clusters. By having specific clusters sequentially hold each block, the amount of storage held by a full node was reduced to one-tenth of the cluster size (Non-Patent Literature 1). In Yibin Xu et al.'s research, the amount of storage held by a full node was reduced by dividing the blockchain into segments and storing them in a distributed manner (Non-Patent Literature 2). However, neither of these studies was able to reduce the amount of storage held by a light node. [Prior art documents] [Non-patent literature]

[0009] [Non-Patent Document 1] Yuta Kaneko, Takuya Asaka, "DHT Load Balancing Clustering Considering Storage in Blockchain," IEICE Technical Report, vol. 118, no. 371, NS2018-161, pp. 29-34, 2021.7.1 [Non-Patent Document 2] YIBIN XU,YANGYU HUAN,“Segment Blockchain: A Size Reduced Storage Mechanism for Blockchain”,IEEE,13.1.2020 [Overview of the project] [Problems that the invention aims to solve]

[0010] The purpose of this disclosure is to reduce the amount of blockchain data held by light nodes. [Means for solving the problem]

[0011] The data structure of the blockchain disclosed herein consists, firstly, a block containing block data composed of multiple transactions and a block header, similar to conventional technologies. Secondly, as a data structure unique to this disclosure, a block group containing block group data composed of multiple blocks and a block group header. Each of the aforementioned blocks stores transaction data.

[0012] The block header includes a Merkle root obtained using the hash value of the transaction included in the block, and the hash value of the block header connected before the block. It may also include the hash value of the block group header. The block group header includes a Merkle root of the block group obtained using the hash value of the transaction included in the plurality of blocks or the Merkle root stored in the block header of the block included in the block group, and the hash value of the block group header connected before the plurality of blocks.

[0013] The system of this disclosure comprises a full node and a write node. The full node and write node send and receive multiple blocks, each containing transaction data and forming a chain structure based on the hash value of the previous block header. The full node and write node further perform the method of this disclosure.

[0014] When the length of the blockchain reaches a certain number, the full node of this disclosure will form a group of blocks including the most recent block in the blockchain, corresponding to the said certain number of blocks. The Merkle root of the block group is calculated using the Merkle root stored in the block header of the block included in the block group. The hash value of the block group header of the block group immediately preceding the aforementioned block group, and the calculated Merkle root, are stored in the header of the aforementioned block group.

[0015] When a full node in this disclosure wins the lottery, it generates a block, and if that block is the block immediately after the creation of the block group header, it also stores the hash value of the block group header in the block header of that block. After generating a block, it forwards it to other full nodes and write nodes. When it receives a block from another node, it records that block within the node.

[0016] The light node in this disclosure is a light node that records a chain of block headers using block header information included in the blockchain, Using the header information of multiple blocks included in the block header chain, a chain of block group headers is created, which is the header information of a block group composed of multiple blocks. Remove any block headers included in the chain of block headers from the chain of block headers.

[0017] The light node in this disclosure is When verifying any transaction contained within any block, Send the hash value of the transaction to be verified to the full node, The full node receives the hash value of the block group header containing the transaction to be verified and the Merkle tree data of the block group. From the chain of block group headers stored in the device, read the block group header corresponding to the hash value of the received block group. Using the received Merkle tree data, calculate the Merkle root of the block group containing the transaction to be verified. It may be verified that the calculated Merkle root matches the Merkle root stored in the read block group header.

[0018] Note that the above disclosures can be combined as far as possible.

Effects of the Invention

[0019] According to the present disclosure, a light node only needs to hold block group headers, which are smaller in number and data amount than block headers. Therefore, the present disclosure can reduce the amount of blockchain data held by light nodes. Accordingly, the present disclosure can lower the economic barrier for blockchain nodes.

Brief Description of Drawings

[0020] [Figure 1] It is a configuration example of a blockchain. [Figure 2] An example of a Merkle root included in a block header is shown. [Figure 3] A system configuration example of the present disclosure is shown. [Figure 4] A configuration example of the blockchain according to the present disclosure is shown. [Figure 5] It is an example of a data structure of a block group. [Figure 6] An example of a Merkle root included in a block group header is shown. [Figure 7] An example of an operation when a light node verifies a transaction is shown. [Figure 8] An example of occurrence of a blockchain fork is shown. [Figure 9] An example of data amounts of a full node and a light node is shown.

Mode for Carrying Out the Invention

[0021] Embodiments of this disclosure will be described in detail below with reference to the drawings. However, this disclosure is not limited to the embodiments shown below. These examples are illustrative, and this disclosure can be implemented in various modified and improved forms based on the knowledge of those skilled in the art. In this specification and in the drawings, components with the same reference numerals refer to the same components.

[0022] Figure 3 shows an example of the system configuration of this disclosure. The consensus building system according to this disclosure has multiple nodes 91 connected via a P2P (peer-to-peer) network. Each node 91 is a computer and includes, for example, a processing unit 31, memory 32, and a transmitting / receiving unit 33. Each node 91 functions as a full node or a write node.

[0023] Figure 4 shows an example of the blockchain configuration described in this disclosure. In this disclosure, blockchain data is divided into a fixed number of consecutive blocks (hereinafter referred to as "block groups"). At this time, checkpoints are set at intervals that are integer multiples of N. That is, when the length of the blockchain reaches a checkpoint that is an integer multiple of N, a block group is formed containing N blocks, starting from the latest block located at the end of the blocks contained in the blockchain. In this way, the blockchain data that would normally be held by a full node is divided into multiple block groups.

[0024] The following example shows a scenario where block groups 12#1 to 12#110 already exist, and blocks 11#501 and later are connected to the blockchain. In this case, the block header of the first block in the block group, 11#501, contains the hash value of the block header of the previous block, 11#500, as well as the hash value of the block group header of the previous block group, 12#110. Similarly, the block header of 11#505 contains the hash value of the block header of the previous block, 11#504, as well as the hash value of the block group header of block group 12#111.

[0025] A full node sends and receives blockchains containing multiple blocks that store transactions and adds newly authenticated blocks to the blockchain. When the blockchain reaches a new checkpoint, the full node creates a block header for a new block group 12. For example, if the checkpoint is block 11#504, each full node, upon receiving block 11#504, creates a block header for a new block group 12#111 that includes N blocks starting from block 11#504, which is located at the end of the block.

[0026] Figure 5 shows an example of the data structure of a block group. The data of block group 12#111 consists of the data of all blocks 11#501 to 11#504 included in that block group, and a newly defined block group header 13. The block group header 13 includes a prior hash and a Merkle root. The prior hash stored in the block group header 13 is the hash value of the block header of the previous block group 12#110. Note that the prior hash of the first block group header may store the hash value of the block header of the first block (genesis block) of the blockchain to explicitly indicate its correspondence with the blockchain.

[0027] Figure 6 shows an example of a Merkle root included in the block group header 13. In this disclosure, a Merkle tree of block group 12 is constructed in order to verify that a transaction (Tx) is included in the blockchain with the smallest possible amount of data. The Merkle tree of block group 12 is calculated by using the hash values ​​of each transaction included in blocks 11#501 to 11#504 as leaf nodes, and is recorded in the block group header 13.

[0028] For example, if block 11#501 contains transactions #5011 to #5014, the Merkle tree of block group 12#111 is calculated using the hash values ​​of transactions #5011 to #5014, according to the tree structure of transactions #5011 to #5014. The block headers of blocks 11#501 to 11#504 store the Merkle root. Therefore, the full node calculates the Merkle root of block group 12#111 using the Merkle roots stored in the block headers of blocks 11#501 to 11#504.

[0029] Here, Merkle tree data is a set of log2n hash values ​​(where n is the number of transactions in the block) that can indicate that a particular transaction (Tx) is part of the block in question, and when n is large, it is significantly smaller than the size of the entire block. In this disclosure, the Merkle tree is extended from block 11 to block group 12. Therefore, when a full node calculates the Merkle root using the TxID, it calculates the data that becomes the Merkle root of the block group header in which the transaction is stored as the Merkle tree data. In this way, this disclosure newly defines a block group header 13 that aggregates the blocks that make up the block group.

[0030] When a full node wins the lottery, it generates a block. If the block is the block immediately following the creation of the block group header, for example, block 111#505 following checkpoint block 111#504, the hash value of the block group header of block group 12#111 is also stored in the block header of block 111#505. Once block 111#505 is generated, it is forwarded to other full nodes and write nodes. When a block is received from another node, that block is recorded within the node.

[0031] On the other hand, when a write node receives a block from another node, it records only the header of that block within the node. This creates a chain of block headers starting from the origin block, block 11#501, and is retained by the write node.

[0032] In the write node as well, a block group header 13 is created using block headers at intervals of N integer multiples, starting from the origin block, block 11#501. In this embodiment, the write node creates a block group header using the header information from block 11#501 to block 11#504 in the block header chain.

[0033] As mentioned above, the block group header 13 contains the prior hash and the Merkle root. The prior hash is the hash value of the block group header of the previous block group 12#110. In this embodiment, the write node can read it from the block header of the first block 11#501 in block group 12#111. The Merkle root may be updated using the Merkle root value contained in the block header of block 11 each time a block 11 constituting block group 12 is received, or it may be calculated using the Merkle roots of blocks 11#501 to 11#504 included in the block header chain after receiving all blocks 11#501 to 11#504.

[0034] In this embodiment, when a new block group 12#111 is formed, the write node holds the block group header 13 of block group 12#111. Then, as shown in Figure 4, it holds the chain of block group headers 13 from the first block group to the latest block group 12#111. For this reason, the write node does not need to hold all the block headers from the first block 11#001 to block 11#504; it only needs to hold the block group header 13.

[0035] Blockchains have a low probability of branching, but the main chain is determined when subsequent blocks are added to the longer chain, increasing its length. In the case of Bitcoin, the main chain is said to be almost certain when the chain length reaches about 6 to 8 levels. Therefore, the number of blocks M at which the main chain is almost certain is predetermined. When the length of the blockchain reaches an integer multiple of N + a certain number of M blocks, a light node discards the header of the block contained in the last block group 12#111. If there is a branch (secondary chain) within the last block group 12#111, the header is discarded after the difference in length between the end of the secondary chain and the end of the main chain reaches M. By making the size of M sufficiently large, the impact of blockchain branching can be prevented from affecting block group 12#111. As described above, this disclosure can reduce the amount of data held by one light node.

[0036] Furthermore, even full nodes are not required to hold all block data from the first block 11 to the latest block 11 of the blockchain. If a certain number is an integer multiple of N, a full node can discard the blocks included in the last block group 12#111 when the length of the blockchain reaches an integer multiple of N + a certain number M.

[0037] A full node that discards the aforementioned blocks is determined, for example, as follows: "When the total number of full nodes is S, the redundancy required to prevent block loss from the network is R, the number of a full node is I, and the hash value of the block group header is H, if the remainder when the hash values ​​of I and H are divided by S is R or greater, the full node may discard the blocks included in that block group." In this way, the disclosure can also reduce the amount of data that a single full node needs to hold.

[0038] Figure 7 shows an example of how a light node verifies a transaction. If a light node wants to verify that a certain transaction (Tx) is included in the blockchain, it sends the hash value (TxID) of that transaction to one of the full nodes (S101). The full node calculates the hash value (block group ID) of the block group header of block group 12 containing that transaction (S102) and the Merkle tree data, and returns them to the light node (S103).

[0039] The write node reads the block group header corresponding to the received block group ID from the chain of block group headers stored in its device. The write node uses the received Merkle tree data to calculate the Merkle root of block group 12 corresponding to the received block group ID (S104). The write node determines whether the calculated Merkle root value matches the Merkle root value held in the block group header 13 corresponding to the block group ID.

[0040] If they match, it means that the transaction in question is included in the block group 12. Therefore, the write node can confirm that any transaction is included in the block group 12 simply by holding the block group header 13 of the block group 12, without receiving the entire block.

[0041] In blockchain technology, if the latest block is created almost simultaneously by multiple nodes, a blockchain fork may occur, as shown in Figure 8. The next block will be connected to the longer chain, so the probability of the shorter chain extending is low, but in rare cases it may extend and cause a switch to the main chain. Therefore, if the checkpoint is block 11#503, the block group 12 up to block 11#503 is formed, but from block 11#504 onwards, which may trigger a switch, the blocks and block headers constituting the block group 12 are not discarded until a certain number of blocks 11 are connected. This certain number (M above) can be exemplified by 1000.

[0042] Furthermore, in the system disclosed herein, older blocks with a low probability of chain switching are distributed and held by multiple full nodes, while newer blocks within a certain number of stages that have a chance of switching are held by all full nodes. For example, in the example in Figure 4, block group 12#111 is held by all full nodes, but block group 12#1 is held by only some full nodes. Therefore, when a node becomes a full node, it downloads data from any number of block groups 12 (0 or more), all block group headers, and data from the previous checkpoint to the latest block (up to 1 block group's worth of blocks + M blocks) from other full nodes.

[0043] If the hash values ​​of the block headers and block headers from the genesis block to the latest block are consistent, and the end of the chain continues to grow, the full node can determine that the block headers and block header chain is a legitimate main chain. Furthermore, by calculating the Merkle tree of the received block data and comparing it to the Merkle root in the received block header, the validity of the received block data can be determined.

[0044] Similarly, when a node becomes a write node, it downloads all block group headers and block headers from the previous checkpoint to the latest block (up to one block group's worth of block headers + M block headers) from other full or write nodes. Furthermore, if the hash values ​​of the block group headers and block headers from the genesis block to the latest block are consistent, and the end of the chain continues to grow, the write node can determine that the chain of block group headers and block headers is the legitimate main chain.

[0045] Furthermore, as shown in Figure 8, if a blockchain fork occurs, when constructing block group 12 from block 11#504 onward, blocks 11#509 and 11#510 may also be included in block group 12.

[0046] Figure 9 shows an example of the data volume for full and light nodes. Conventional blockchain nodes needed to store all the data of the blockchain, which grew larger year by year. For example, as of December 2021, the number of blocks was 14 million. In this case, if the block size is 80kB and the header size is 500B, the amount of data required for a light node is 7GB, and the amount of data required for a full node is 1.1TB. Applying the Segment Blockchain described in Non-Patent Literature 2 under the same conditions, the amount of data that a full node needs to hold can be reduced to 7.1GB by configuring one block group with 1000 blocks.

[0047] On the other hand, this disclosure significantly reduces the amount of data a single node holds without erasing past transactions from the network. For example, if a block group consists of 1,000 blocks, as in Non-Patent Document 2, then 14 million blocks 11 are grouped into 14,000 block groups 12. In this case, this disclosure only needs to hold 14,000 block group headers 13, and the header information can be reduced to 8MB. Therefore, this disclosure significantly reduces the amount of data a single write node holds.

[0048] Furthermore, in this disclosure, a full node may retain the header information for each block 11, but it may also retain a block group header 13 instead of the header information for each block 11. In this case, the amount of data for the header information is reduced from 7GB to 8MB, so the amount of data that one full node must retain can be reduced to 88MB. Therefore, this disclosure can also significantly reduce the amount of data that one full node must retain.

[0049] Thus, this disclosure can reduce the amount of data, making it possible for lightweight devices that could not previously be used as full or light nodes to become nodes. Furthermore, it lowers the economic barrier to becoming a node, making it easier to participate in the blockchain network and resolving security concerns that may arise from a decrease in the number of full nodes.

[0050] The node 91 of this disclosure can also be realized by a computer and a program, and the program can be recorded on a recording medium or provided over a network. The program of this disclosure is a program for realizing a computer as each functional unit of the node 91 of this disclosure, and is a program for causing the computer to execute each step of the method executed by the node 91 of this disclosure. [Industrial applicability]

[0051] This disclosure can be applied to the information and communications industry. [Explanation of symbols]

[0052] 11: Block 12: Block Group 13: Block group header 31: Processing Unit 32: Memory 33: Transmitter / Receiver 91: Node

Claims

1. A light node that records the chain of block headers included in the blockchain, Using the multiple block headers included in the chain of block headers, a block group header is created, which is the header information for a block group composed of multiple blocks. The block header used in the aforementioned block group header is discarded from the chain of block headers recorded in the device. Light node.

2. The aforementioned block group header includes a Merkle root obtained using the hash values ​​of the transactions included in the block group, When verifying any transaction contained within any block, Send the hash value of the transaction to be verified to the full node, The full node receives Merkle tree data composed of the hash value of the block group header corresponding to the block group in which the transaction to be verified is stored and the hash value of the transaction included in the block group. Using the received Merkle tree data, the Merkle root of the block group header is calculated. The calculated Merkle root is verified to match the Merkle root of the block group header corresponding to the received hash value among the block group headers stored in the device. The light node according to claim 1.

3. A method performed by a light node to record the chain of block headers included in the blockchain, Using the multiple block headers included in the chain of block headers, a block group header is created, which is the header information for a block group composed of multiple blocks. The block header used in the aforementioned block group header is discarded from the chain of block headers recorded in the device. method.

4. A program for realizing a computer as a write node according to claim 1 or 2.

Images