Server constituting sealer node of blockchain network, consensus execution method, and software program thereof

Abstract

[Problem] To provide a system capable of dynamically changing a block generation period in accordance with the number of sealer nodes using a simpler method. [Solution] Provided is a server characterized by comprising: a snapshot management module that acquires the number of sealer nodes in a blockchain network, and updates the number of sealer nodes and a configuration file index of a snapshot if the number of sealer nodes has increased or decreased; a server configuration management module that, on the basis of the fact that the configuration file index of the snapshot has been updated, compares the updated number of sealer nodes and a reference number of sealer nodes included in the configuration file to identify a corresponding server configuration, and sets a block generation period included in the identified server configuration in the server; and a block generation module that generates a block on the basis of the block generation period included in the server configuration set in the server configuration management module.

Description

Server constituting a Sealer node of a blockchain network, consensus execution method, and software program therefor

[0001] The present invention relates to blockchain technology, and in particular to a server constituting a Sealer node (approval node) of a blockchain that uses a Proof of Authority (PoA) type consensus algorithm, a consensus execution method, and a software program therefor.

[0002] In blockchain technology, consensus algorithms are used to guarantee the validity of data in a decentralized network and prevent tampering. A consensus algorithm defines rules whereby nodes on a network confirm the validity of transactions and add new blocks.

[0003] Representative consensus algorithms include Proof of Work (PoW), Proof of Stake (PoS), and Proof of Authority (PoA). Among these, unlike PoW and PoS, PoA is a system in which only pre-trusted nodes (Sealers) generate blocks, so it enables high-speed transaction processing, has low energy consumption, and high throughput. For this reason, it is widely adopted in private blockchains and enterprise blockchains.

[0004] By the way, PoA is highly convenient from the viewpoint of stability and efficiency of block generation speed, but due to the fixation of the block generation period, there is a problem that adjustment cannot be performed according to the network environment and increases or decreases in the number of Sealer nodes. For example, when the number of Sealer nodes increases, the opportunity for each node to generate blocks decreases, which may reduce the throughput (TPS) of the entire network. On the other hand, when the number of Sealer nodes decreases, an excessive load is applied to existing Sealer nodes, creating a risk of delayed block generation.

[0005] Furthermore, changing the block generation period typically requires a hard fork (a major network update). Performing a hard fork requires preparing software that defines the new block generation period and applying it to all nodes in the network. The system then transitions to the new configuration at a certain block height, but this process presents several challenges. First, since not all nodes are updated simultaneously, a mix of old and new versions of the node system can occur, potentially causing temporary network instability. Second, the need to prompt all node operators to update incurs significant human and time costs, making rapid response difficult. The difficulty in real-time adjustments in response to market changes and fluctuations in transaction volume is also a major challenge for traditional PoA systems.

[0006] In response to this, several methods have been proposed using conventional technologies. For example, some blockchain projects introduce on-chain governance and provide a mechanism to change the block generation period through voting by Sealer nodes. However, the voting process is time-consuming, making real-time adjustments difficult. Another approach is to keep the block generation period of the main chain fixed and use sidechains or Layer 2 to process transactions at high speed. However, this approach requires additional network infrastructure, resulting in high implementation costs.

[0007] This invention was made in view of the above-mentioned problems, and aims to provide a system in a PoA-type blockchain that can dynamically change the block generation period according to the number of Sealer nodes in a simpler way.

[0008] To solve the above problems, the following invention is provided according to this invention.

[0009] (1) A server comprising a server that constitutes a Sealer node of a blockchain network, wherein the server configuration file defines network settings and includes a plurality of server settings with different reference Sealer node counts, and each server setting defines at least a block generation period corresponding to the reference Sealer node count; a snapshot management module that obtains the number of Sealer nodes in the network and updates the snapshot Sealer node count and configuration file index if the number of Sealer nodes has been added or decreased; a server configuration management module that, based on the fact that the snapshot configuration file index has been updated, compares the updated number of Sealer nodes with the reference Sealer node count included in the configuration file to identify a corresponding server setting and sets the block generation period included in the identified server setting on the server; and a block generation module that generates blocks based on the block generation period included in the server setting set in the server configuration management module.

[0010] (2) The server in (1) above, characterized in that the blockchain network is a Proof of Authority (PoA) type network.

[0011] (3) A server in which the block generation period is set to be shorter as the number of reference Sealer nodes increases.

[0012] (4) A server in which each server setting further includes a block generation reward amount corresponding to the number of reference Sealer nodes, and the server setting management module sets the block generation reward amount included in the server setting to the server.

[0013] (5) A server in which the block generation reward is set to be higher the larger the number of reference Sealer nodes is.

[0014] (6) A consensus formation method to be performed on a server constituting a Sealer node of a blockchain network, the method using a server configuration file that defines network settings, the server configuration file containing a plurality of server settings with different reference number of Sealer nodes, each server setting defining at least a block generation period corresponding to the reference number of Sealer nodes, the method comprising: a snapshot management step in which a computer obtains the number of Sealer nodes in the network and updates the number of Sealer nodes and the configuration file index of the snapshot if the number of Sealer nodes has been added or decreased; a server configuration management step in which the computer, based on the fact that the configuration file index of the snapshot has been updated, compares the updated number of Sealer nodes with the reference number of Sealer nodes included in the configuration file to identify a corresponding server setting and sets the block generation period included in the identified server setting on the server; and a block generation step in which the computer generates a block based on the block generation period included in the server setting set in the server configuration management module.

[0015] (7) The method according to (6) above, characterized in that the blockchain network is a Proof of Authority (PoA) type network.

[0016] (8) The method of (6) above, characterized in that the block generation period is set to be shorter as the number of reference Sealer nodes increases.

[0017] (9) The method of (6) above, wherein each server setting further includes a block generation reward amount corresponding to the number of reference Sealer nodes, and the server setting management step is to set the block generation reward amount included in the server setting on the server.

[0018] (10) The method of (9) above, characterized in that the block generation reward is set to be higher the larger the number of reference Sealer nodes.

[0019] (11) A server software program installed on a computer and constituting a Sealer node of a blockchain network, which uses a server configuration file that defines network settings, which includes a plurality of server settings with different reference Sealer node numbers, and each server setting defines at least a block generation period corresponding to the reference Sealer node number, wherein the software program causes the computer to execute: a snapshot management step of obtaining the number of Sealer nodes in the network and updating the number of Sealer nodes in the snapshot and the configuration file index if the number of Sealer nodes has been added or decreased; a server configuration management step of comparing the updated number of Sealer nodes with the reference Sealer node number included in the configuration file based on the fact that the configuration file index of the snapshot has been updated to identify the corresponding server setting and set the block generation period included in the identified server setting on the server; and a block generation step of generating blocks based on the block generation period included in the server setting set in the server configuration management module.

[0020] (12) The software program of (11) wherein the blockchain network is a Proof of Authority (PoA) type network.

[0021] (13) The software program of (11) wherein the block generation period is set to be shorter as the number of reference Sealer nodes increases.

[0022] (14) The software program of (11) wherein each server setting further includes a block generation reward amount corresponding to the number of reference Sealer nodes, and the server setting management step sets the block generation reward amount included in the server setting on the server.

[0023] (15) The software program of (14) wherein the block generation reward is set to be higher the larger the number of reference Sealer nodes.

[0024] This configuration solves the problems of conventional technology and provides a Sealer node server that can dynamically change the block generation period without hard forks. The server of this invention dynamically acquires the number of Sealers using snapshots and reflects the latest network state. Furthermore, by updating the server configuration index, it is possible to adjust the block generation period in real time. This allows for flexible adaptation to fluctuations in the number of nodes, maintains efficient block generation, eliminates the cumbersome work of conventional hard forks, and provides a new PoA mechanism that ensures stability and scalability while reducing the management burden.

[0025] Figure 1 is a schematic diagram showing a server configuration file according to one embodiment of this invention. Figure 2 is a schematic diagram showing a server configuration file. Figure 3 is a schematic diagram showing a snapshot. Figure 4 is a schematic configuration diagram showing the server configuration. Figure 5 is a flowchart showing the processing steps.

[0026] One embodiment of the present invention will be described below with reference to the attached drawings.

[0027] (Overall Configuration) Figure 1 is a conceptual diagram showing this embodiment.

[0028] In Figure 1, 1 represents the PoA blockchain network, and 2 represents a Sealer node participating in that network. Specifically, this Sealer node 2 is PoA-compatible server software installed on a computer that performs transaction verification and block generation. It is loaded into the computer's memory and executed to realize each component of the present invention. Although only one Sealer node 2 is shown in this figure, in this embodiment, the blockchain network 1 has multiple Sealer nodes 2, all of which have the same configuration.

[0029] Furthermore, Figure 3 shows the server configuration file (Config) used in this embodiment. This server configuration file 3 is a file or database containing configuration information that controls the operation of the blockchain network 1. In this embodiment, it is stored in a specific block or management node on the blockchain 1 and can be downloaded to the local memory of the Sealer node as needed for reference.

[0030] (Server configuration file - Config) Figure 1 is a conceptual diagram of the server configuration file 3 used in the present invention.

[0031] The server configuration file 3 of this embodiment contains multiple server configurations (in this example, a first server configuration 4a and a second server configuration 4b) in an array, and one of them can be appropriately selected according to the number of Sealer nodes participating in the network. In this embodiment, it includes two server configurations, namely a first server configuration 4a and a second server configuration 4b, but the number of server configurations may be three or more. Each server configuration 4a, 4b includes at least a reference node count 5a, 5b that serves as the basis for determining which server configuration to apply, and block generation periods 6a, 6b and block generation rewards 7a, 7b for each reference node count 5a, 5b.

[0032] Figure 2 shows an example of server configuration file 3. In this example, the definitions of the reference node counts 5a and 5b for the first and second server configurations 4a and 4b are specified by "maxSealerCount". The intention is that if the number of nodes is less than or equal to the number specified here, the server configurations 4a and 4b, including the maxSealerCount, will be used as the server configuration (Config) for the entire network. In this example, if maxSealerCount is 8760 nodes or less, the first server configuration 4a will be applied. If it exceeds 8760 nodes, the second server configuration 4b with maxSealerCount = 14600 will be applied to the entire network. In other words, when the number of nodes participating in the network increases or decreases, the server configuration applied will be switched accordingly based on the value of maxSealerCount.

[0033] In this example, the first block generation period 6a in the first server configuration 4a (maxSealerCount = 8760) is period = 300, which means 300 seconds, or 5 minutes. The second block generation period 6b in the second server configuration 4b (maxSealerCount = 14600) is period = 180, which means 3 minutes. In other words, when operating the network with the server configuration file in this example, the block generation interval is 5 minutes up to 8760 nodes, and 3 minutes for nodes exceeding 8760 but 14600 or less. Also, in this example, the first block generation reward 7a and the second block generation reward 7b are set to the same amount.

[0034] (Configuration of Sealer Node Servers) Next, we will describe the servers that make up Sealer Node 2.

[0035] As shown in Figure 4, the server is implemented by installing the various functional units that realize / execute the server as software programs or data areas on a general computer system in which a software storage unit 12 and a data storage unit 13 are connected to a bus 11 to which a CPU 8, memory 9, and input / output unit 10 are connected. First, the software storage unit 12 stores, only the components relevant to the present invention, a snapshot management unit 15, a server configuration management unit 16, and a block generation unit 17. The data storage unit 13 stores snapshots 18 and a server configuration file 19. These various functional units and data areas 15 to 19 are called and executed on the memory 9 by the CPU 8 of the server, thereby functioning and operating as the components of the present invention.

[0036] The server configuration management unit 16 includes a server configuration reading unit 23 that acquires the latest server configuration (config) based on the current configuration index, and a block generation period setting unit 24 and a block generation reward setting unit 25 that set an appropriate block generation period and its reward by referring to the server configuration (the first server configuration or the second server configuration) corresponding to the current number of Sealer nodes according to the updated configuration index.

[0037] The block generation unit 17 performs consensus by generating blocks within the block generation period set by the server configuration management unit 16.

[0038] (Processing Steps) The configuration of this embodiment will be further explained below by describing the consensus execution process according to this embodiment.

[0039] As shown in Figure 5, the processing steps in this embodiment consist of a Sealer node number monitoring step S1, a block generation period setting step S2 that utilizes the monitoring results, and a block generation step S3.

[0040] (Sealer node count monitoring process) In the Sealer node count monitoring process, the snapshot update unit 21 first verifies whether a new block is valid when it is added to the network and updates the snapshot 18. Figure 3 shows an example of a snapshot 18. (1) records the currently selected server configuration (Config), and (2) records the current configuration index (Config Index).

[0041] In the example server configuration shown in Figure 2, if the number of reference Sealer nodes, maxSealerCount, is 8760 or less, the first server configuration 4a is applied. If the number exceeds 8760 nodes, the second server configuration 4b with maxSealerCount = 14600 is applied to the entire network. On the other hand, if the number of nodes participating in the network increases or decreases, the server configuration applied is switched accordingly based on the value of maxSealerCount.

[0042] In this example, the first block generation period 6a in the first server configuration 4a (maxSealerCount = 8760) is period = 300, which means 300 seconds, or 5 minutes. The second block generation period 6b in the second server configuration 4b (maxSealerCount = 14600) is period = 180, which means 3 minutes. In other words, when operating the network with the server configuration file in this example, the block generation interval is 5 minutes up to 8760 nodes, and 3 minutes for the number of nodes exceeding 8760 but 14600 or less. Also, in this example, the first block generation reward 7a and the second block generation reward 7b are set to the same amount.

[0043] (Block generation process) Next, the block generation unit 17 executes the consensus algorithm at intervals set above for block generation and generates new blocks.

[0044] Furthermore, in this embodiment, the server configuration file 3 is stored in a specific block on the blockchain 1 or a management node in this embodiment, and is appropriately downloaded to a data storage unit of the Sealer node 3 so as to be referable. However, the present invention is not limited to this, and content stored in a specific block on the blockchain 1 or a management node may be directly referenced.

[0045] (Effects of Embodiment) According to such a configuration, the following effects can be obtained.

[0046] That is, in the Proof of Authority (hereinafter referred to as PoA) consensus algorithm, a block generation interval is set as a configuration at startup in server software for operating a blockchain. Therefore, once the server software has been operated and the network has been constructed, this cannot be easily changed.

[0047] In this state, the number of Sealer nodes constituting the blockchain may increase or decrease over time. When the number of nodes increases, the timing for one node to contribute to block generation becomes longer, and opportunities to validate blocks decrease. For example, when rewards are provided for contributing to block generation, this leads to the situation that as the number of nodes participating in the network increases, it becomes more difficult to obtain rewards. Such characteristics of PoA are considered to be a disadvantage in services that convert blockchain rewards into points or the like.

[0048] Furthermore, changing the block generation period in PoA-compatible server software requires a hard fork (specification change) for the network that the server joins. For example, to change the 10-minute timing to 5 minutes, after preparing server software that defines a 5-minute block generation interval with new server configurations, it is necessary to schedule a hard fork and urge all nodes joining the network to update their servers before the hard fork. Since updates are performed by the administrator operating each server, they are not necessarily performed, and the timing of implementation also varies for each, so it is necessary to set a relatively long period for the hard fork to respond, and it takes a considerable amount of time for the entire network to operate with the new 5-minute block generation interval.

[0049] In contrast, according to the configuration of the present embodiment, the interval of block generation timing can be dynamically adjusted according to the number of participating users (nodes), so rewards can be obtained at a certain interval, and there is no need to perform complicated network migration caused by a hard fork.

[0050] Such a function of appropriately switching between a plurality of server configurations makes it possible to dynamically change the block generation timing according to the number of nodes, and in this embodiment, the amount of reward is further adjusted according to the number of nodes.

[0051] In this way, the system of the present invention can flexibly respond to network changes and improve the scalability of the PoA-type blockchain.

[0052] It should be noted that the present invention is not limited to the above embodiment, and various modifications can be made without changing the gist of the invention.

[0053] For example, in the above embodiment, the description has been given assuming that only one server is installed in one computer, but the present invention is not limited thereto, and two or more servers may be installed in one computer.

[0054] Furthermore, in the above embodiment, the server settings were recorded in an array within a single server configuration file, but this is not limited to this, and they may be stored in multiple configuration files.

[0055] Furthermore, in the above embodiment, the first block generation reward 7a and the second block generation reward 7b are set to the same amount, but they may be different amounts. In this case, the reward amount may be set to be higher as the block generation period lengthens.

[0056] 1…Blockchain network 1…Blockchain 2…Layer 3…Server configuration file 4a…First server configuration 4b…Second server configuration 5a…First reference number of Sealer nodes 5b…Second reference number of Sealer nodes 6a…First block generation period 6b…Second block generation period 7a…First block generation reward 7b…Second block generation reward 8…CPU 9…Memory 10…Input / Output unit 11…Bus 12…Software storage unit 13…Data storage unit 15…Snapshot management unit 16…Server configuration management unit 17…Block generation unit 18…Snapshot 19…Server configuration file 21…Snapshot update unit 22…Node count confirmation unit 23…Server configuration reading unit 24…Block generation period setting unit 25…Block generation reward setting unit

Claims

1. A server comprising: a server that constitutes a Sealer node of a blockchain network, wherein the server configuration file defines network settings and includes multiple server settings with different reference Sealer node counts, and each server setting defines at least a block generation period corresponding to the reference Sealer node count; a snapshot management module that obtains the number of Sealer nodes in the network and updates the snapshot Sealer node count and configuration file index if the number of Sealer nodes has been added or decreased; a server configuration management module that, based on the fact that the snapshot configuration file index has been updated, compares the updated number of Sealer nodes with the reference Sealer node count included in the configuration file to identify a corresponding server setting and sets the block generation period included in the identified server setting on the server; and a block generation module that generates blocks based on the block generation period included in the server setting set in the server configuration management module.

2. The server according to claim 1, characterized in that the blockchain network is a Proof of Authority (PoA) type network.

3. A server according to claim 1, characterized in that the block generation period is set to be shorter as the number of reference Sealer nodes increases.

4. The server according to claim 1, wherein each server setting further includes a block generation reward amount corresponding to the number of reference Sealer nodes, and the server setting management module sets the block generation reward amount included in the server setting to the server.

5. A server according to claim 4, characterized in that the block generation reward is set to be higher the larger the number of reference Sealer nodes.

6. A consensus formation method executed on servers constituting Sealer nodes of a blockchain network, the method using a server configuration file that defines network settings, the server configuration file containing multiple server settings with different reference number of Sealer nodes, each server setting defining at least a block generation period corresponding to the reference number of Sealer nodes, the method comprising: a snapshot management step in which a computer obtains the number of Sealer nodes in the network and updates the number of Sealer nodes and the configuration file index of a snapshot if the number of Sealer nodes has been added or decreased; a server configuration management step in which the computer, based on the fact that the configuration file index of the snapshot has been updated, compares the updated number of Sealer nodes with the reference number of Sealer nodes contained in the configuration file to identify a corresponding server setting and sets the block generation period included in the identified server setting on the server; and a block generation step in which the computer generates a block based on the block generation period included in the server setting set in the server configuration management module.

7. The method according to claim 6, characterized in that the blockchain network is a Proof of Authority (PoA) type network.

8. The method according to claim 6, characterized in that the block generation period is set to be shorter as the number of reference Sealer nodes increases.

9. The method according to claim 6, wherein each server setting further includes a block generation reward amount corresponding to the number of reference Sealer nodes, and the server setting management step is to set the block generation reward amount included in the server setting on the server.

10. The method according to claim 9, characterized in that the block generation reward is set to be higher the larger the number of reference Sealer nodes.

11. A server software program installed on a computer and constituting a Sealer node of a blockchain network, wherein the server configuration file defines network settings and includes multiple server settings with different reference Sealer node counts, each server setting defining at least a block generation period corresponding to the reference Sealer node count, and the software program uses this server configuration file, and is characterized by causing the computer to execute: a snapshot management step which obtains the number of Sealer nodes in the network and updates the snapshot's Sealer node count and configuration file index if the number of Sealer nodes has been added or decreased; a server configuration management step which, based on the fact that the snapshot's configuration file index has been updated, compares the updated number of Sealer nodes with the reference Sealer node count included in the configuration file to identify the corresponding server setting and sets the block generation period included in the identified server setting on the server; and a block generation step which generates a block based on the block generation period included in the server setting set in the server configuration management module.

12. The software program according to claim 11, characterized in that the blockchain network is a Proof of Authority (PoA) type network.

13. The software program according to claim 11, characterized in that the block generation period is set to be shorter as the number of reference Sealer nodes increases.

14. The software program according to claim 11, wherein each server setting further includes a block generation reward amount corresponding to the number of reference Sealer nodes, and the server setting management step is to set the block generation reward amount included in the server setting on the server.

15. A software program according to claim 14, characterized in that the block generation reward is set to be higher the larger the number of reference Sealer nodes.

Images