KR102315226B1 - Block chain system based on consensus algorithm of proof-of-rule and method thereof - Google Patents

Abstract

A blockchain system based on a consensus algorithm of a proof-of-rule method and a method thereof are provided. A block chain system based on a consensus algorithm of a rule proof method according to an embodiment of the present invention is a block chain system including a plurality of determinant nodes that communicate with each other and communicate with a user node, and each of the plurality of determinant nodes is Processes the transaction issued by the user node, bundles the processed transaction into chunks for a certain time unit, performs the corresponding round for consensus, and requests and receives the chunk corresponding to the round from other round-synchronized decision maker nodes , generates a hypothesis by rearranging the received chunk and the transactions included in the own chunk based on the standard timestamp included in each transaction, and computes the hash of each transaction to obtain the hash information calculated by the transaction and the If the hash information matches, the hypothesis is pre-confirmed as the block of the corresponding round, the state of the block is changed, and the pre-confirmed block is stored.

Description

A block chain system based on consensus algorithm of proof-of-rule and method thereof

The present invention relates to a blockchain system based on a consensus algorithm of a rule proof method and a method therefor.

In general, blockchain is a data transmission/storage technology that stores network records, etc. in the form of blocks that cannot be forged or tampered with. In this blockchain system, all information is verified by random network participants, and data is also periodically synchronized and stored by a number of distributed nodes, so it is safe from forgery and destruction of data.

However, the proof-of-work (PoW) method, which is mostly used in blockchain systems, is slow and uses too much computing power. Therefore, the greater the number of nodes participating in the network, the longer it takes to confirm and store the block.

US 2019-0092483 A

In order to solve the problems of the prior art as described above, an embodiment of the present invention is to provide a block chain system based on a consensus algorithm of a rule proof method that can quickly confirm a block agreement by a simple process and a method thereof do.

However, the problems to be solved by the present invention are not limited to the problems mentioned above, and other problems not mentioned will be clearly understood by those skilled in the art from the following description.

According to one aspect of the present invention for solving the above problems, as a block chain system including a plurality of decision-making nodes that communicate with each other and communicate with a user node, each of the plurality of decision-maker nodes is a user It processes the transaction issued by the node, bundles the processed transaction into chunks for a certain time unit, performs the corresponding round for consensus, and requests and receives the chunk corresponding to the round from other decision maker nodes that are round-synchronized. , generate a hypothesis by rearranging the received chunk and the transaction included in its own chunk based on the standard timestamp included in each transaction, and calculating the hash of each transaction to obtain the hash information calculated by the transaction and the corresponding transaction. If the hash information matches, the hypothesis is pre-confirmed as the block of the corresponding round, the state of the block is changed, and the consensus algorithm-based block chain system of the rule proof method is provided to store the pre-confirmed block.

In an embodiment, each of the plurality of decision maker nodes may request the latest round information from the other decision maker node, and may synchronize with the block of the decision maker node in the most advanced round state among the plurality of decision maker nodes.

In an embodiment, each of the plurality of decision maker nodes may proceed with the round for consensus when there is no decision maker node in a round state prior to its own round.

In one embodiment, each of the plurality of decision maker nodes may block the decision maker node of the corresponding transaction if the hash calculated for the transaction and the hash included in the transaction do not match.

In one embodiment, the transaction may include type, timestamp and contract information.

In an embodiment, the contract information may include code defined as a function for checking the structure of a transaction, checking the validity of a transaction, setting a state of a block, and determining an acceptance.

According to another aspect of the present invention, as a consensus method of a blockchain system including a plurality of decision maker nodes that communicate with each other and communicate with a user node, a transaction issued by a user node is processed and the transaction processed performing a corresponding rounding for consensus by tying them into chunks in a predetermined time unit; requesting and receiving a chunk corresponding to the round from another decision maker node synchronized with the round; A hypothesis is generated by rearranging the received chunk and the transactions included in its own chunk based on the standard timestamp included in each transaction, and calculating the hash of each transaction to obtain the hash information calculated by itself and the hash of the transaction if the information matches, pre-confirming the hypothesis as a block of the corresponding round; and changing the state of the block and storing the pre-confirmed block; is provided a consensus method of the rule proof method of the block chain system, including.

In one embodiment, the consensus method of the rule proof method of the block chain system further includes the steps of requesting the latest round information from the other decision maker node, and synchronizing with the block of the decision maker node in the most advanced round state among the plurality of decision maker nodes. may include

In an embodiment, in the step of synchronizing, when there is no decision maker node in a round state prior to its own round, the round for consensus may be performed.

In an embodiment, the determining may block the decision maker node of the transaction if the hash calculated for the transaction and the hash included in the transaction do not match.

In one embodiment, the transaction may include type, timestamp and contract information.

In an embodiment, the contract information may include code defined as a function for checking the structure of a transaction, checking the validity of a transaction, setting a state of a block, and determining an acceptance.

In accordance with an embodiment of the present invention, a block chain system based on a consensus algorithm of a rule proof method and a method thereof pools the transactions generated in all the decision nodes for each decision node, rearranges them according to a standard timestamp, and calculates a hash to generate the original transaction By confirming the block by comparing it with the hash of

1 is a schematic configuration diagram of a block chain system based on a consensus algorithm of a rule proof method according to an embodiment of the present invention;
2 is a diagram showing a data structure of a block chain system based on a consensus algorithm of a rule proof method according to an embodiment of the present invention;
3 is a view showing a transaction structure of a block chain system based on a consensus algorithm of a rule proof method according to an embodiment of the present invention;
4 is a diagram showing the structure and processing sequence of a smart contract of a block chain system based on a consensus algorithm of a rule proof method according to an embodiment of the present invention;
5 is a diagram showing the structure of block data stored in a block chain system based on a consensus algorithm of a rule proof method according to an embodiment of the present invention;
6 is a flowchart illustrating a method of consensus of a rule proof method according to an embodiment of the present invention;
7 is a diagram for explaining round synchronization in a method of agreement of a rule proof method according to an embodiment of the present invention;
8 is a diagram for explaining a pre-commit in a method of agreement of a rule proof method according to an embodiment of the present invention;
FIG. 9 is a diagram for explaining blocking of a specific node in a method for agreeing a rule proof method according to an embodiment of the present invention.

Hereinafter, with reference to the accompanying drawings, the embodiments of the present invention will be described in detail so that those of ordinary skill in the art to which the present invention pertains can easily implement them. The present invention may be embodied in many different forms and is not limited to the embodiments described herein. In order to clearly explain the present invention in the drawings, parts irrelevant to the description are omitted, and the same reference numerals are assigned to the same or similar components throughout the specification.

The embodiments of the present invention are provided to more completely explain the present invention to those of ordinary skill in the art, and the embodiments described below may be modified in various other forms, The scope is not limited to the following examples. Rather, these examples are provided so as to more fully and complete the present invention, and to fully convey the spirit of the present invention to those skilled in the art.

1 is a schematic configuration diagram of a block chain system based on a consensus algorithm of a rule proof method according to an embodiment of the present invention.

Referring to FIG. 1 , a block chain system 10 based on a consensus algorithm of a rule proof method according to an embodiment of the present invention includes a plurality of determinant nodes V1 to V5.

The blockchain system 10 according to an embodiment of the present invention is based on a consensus algorithm of a Proof-of-Rule (PoR) using a smart contract. The consensus algorithm proposed in this specification is named HAP (Hypothesis Acceptance Protocol). In addition, the Blockchain Engine based on the HAP algorithm is named SASEUL.

Here, the block chain system 10 may be used as a variety of infrastructure, not as a simple monetary system or platform. That is, the transaction Tr issued by the user nodes L11 to L52 connected to the consensus algorithm-based blockchain system 10 is not limited to transaction information such as remittance. For example, the transaction Tr may be shared record information. In this case, the transaction Tr may be defined by a smart contract as described below.

In addition, the blockchain system 10 based on the consensus algorithm of the rule proof method can form a private network and a public network. Here, the public network may be a network having a structure in which anyone can create validator nodes (V1 to V5) based on the public rules of the network itself. The decision maker node that creates the network for the first time can set the rules of the network. The set rule may be shared by all decision maker nodes V1 to V5 and user nodes L11 to L52.

The private network is a network with a structure in which decision-making nodes (V1 to V5) can be created based on the rules determined by the service operator. A service operator may own all decision maker nodes (V1~V5), and some may be converted to participate in general users.

At this time, in the case of a public network, the node that first establishes the network and commits the genesis block becomes the determinant nodes V1 to V5. In the case of a private network, the node designated by the network manager (service operating subject) becomes the decision maker node (V1 to V5).

Here, the contract and state necessary for HAP processing are defined as system contract and system state, and the system contract consists of network creation (Genesis, Genesis), code registration (RegisterCode), and code modification (ModifyCode). In addition, the system state consists of a block (Block), authority (Authority), and a tracker (Tracker).

The decision maker node that declared Genesis has the authority of the network manager and can register and modify code. At this time, the decision maker node registers a custom contract for operating the network. Other decision maker nodes first decide which decision maker node to recognize as Genesis, and from then on, they define the customized contract created in the network as their own rule and receive block data from the network.

The decision maker nodes V1 to V5 perform accept/reject agreements and block generation procedures for the transaction Tr generated by the user nodes L11 to L52.

In this case, all transactions issued by the user nodes L11 to L52 may be processed by the corresponding decision maker nodes V1 to V5. At this time, the decision maker nodes V1 to V5 process the transaction Tr issued by the contract defined in advance, and the processing result is determined as acceptance/rejection. The accepted transaction (Tr) changes the status, and the rejected transaction (Tr) does not change the status.

In addition, each determinant node V1 to V5 may include a processor and a memory. Here, the processor may execute a consensus algorithm performed by each determinant node V1 to V5. The memory may store inputs or processing results required by a consensus algorithm running in the processor.

The user nodes L11 to L52 are nodes without a separate network contribution to the network and may be referred to as light nodes. User nodes (L11 to L52) have their own private key and tracker, and it is possible to create and request a transaction (Tr), and to inquire the result.

In FIG. 1 , user nodes L11 to L13 may request a transaction Tr connected to a decision maker node V1. The user nodes L21 to L23 may be connected to the decision maker node V2 to request a transaction Tr. The user nodes L31 to L33 may be connected to the decision maker node V3 to request a transaction Tr. The user nodes L41 to L42 are connected to the decision maker node V4. The user nodes L51 to L52 may be connected to the decision maker node V5.

On the other hand, in the embodiment of the present invention, the core of the HAP algorithm is that all decision maker nodes in SASEUL are very selfish decision makers who focus on making their own blocks. Each determinant node (V1~V5) collects and merges all transactions (Tr) from other determinant nodes, rearranges them by timestamp, and creates a virtual block (hypothesis). Determining nodes (V1 to V5) can compute and compare hashes of these virtual blocks, and finally decide selfishly to connect and disconnect.

In this case, each decision-making node (V1 to V5) processes the virtual blocks in order according to a set contract, and if the result is the same as itself, the corresponding block can be determined.

Here, the plurality of decision maker nodes V1 to V5 generate a consensus on acceptance and rejection of the transaction Tr based on the HAP algorithm. The plurality of decision maker nodes V1 to V5 independently determine whether to accept or reject each transaction Tr, and then collect a certain number of transactions Tr and compare the decision result with other decision maker nodes. That is, instead of sharing and synchronizing judgment results for all individual transaction (Tr) requests, transactions (Tr) of a unit determined by the network are compared at once. A bundle of such transactions Tr is called a chunk, and comparison of the chunks is performed through hash value comparison. Here, when the hash value is different, it means that the transaction Tr is different or the processing result is different.

2 is a diagram illustrating a data structure of a block chain system based on a consensus algorithm of a rule proof method according to an embodiment of the present invention.

Referring to FIG. 2 , in the consensus algorithm-based blockchain system 10, data is divided into two types: state and transaction. The consensus algorithm-based blockchain system 10 can change the state by a transaction (Tr). The time at which the state changes is the same as the time at which the block is confirmed. At this time, the transactions Tr in the block are arranged in chronological order.

Here, a set of transactions Tr that have not yet been approved constitutes an unconfirmed block (pseudoblock), which is called a hypothesis. With respect to this hypothesis, if a hash is calculated for each determinant node (V1 to V5) and matched, the corresponding block is confirmed. That is, if the operation results match, the unapproved hypothesis may be stored as a complete block.

3 is a diagram illustrating a transaction structure of a block chain system based on a consensus algorithm of a rule proof method according to an embodiment of the present invention.

Referring to FIG. 3 , a transaction Tr includes a type and a timestamp. Here, the type is for designating a contract to be processed in the transaction (Tr), and the timestamp is for processing or rearranging the transaction (Tr) in chronological order.

At this time, each user node (L11 ~ L52) hashes the transaction (Tr) to prove that it is the transaction (Tr) that it has generated, and then generates a signature using the private key. and provide the public key and signature together. Here, the public key can check forgery of the signature created by the private key. Since all user nodes L11 to L52 generate addresses based on the public key, the public key can be trusted based on the addresses of the user nodes L11 to L52 that have generated and transmitted the transaction Tr.

In addition, the information (other) other than the type and timestamp is information to be used in the contract. Here, the other information may include a specification of an operation to be performed by the transaction. For example, in the case of a remittance transaction, the transaction data may include an account to be sent, an account to receive, an amount, and the like.

On the other hand, accurate visual synchronization of each determinant node (V1 ~ V5) is not easy due to geographic differences or the like. Therefore, as will be described later, a standard timestamp used in the block confirmation process is defined. Here, the standard timestamp may be a reference time at which a block is generated. In this case, the standard timestamp is a divisor of the unit time (Interval), and the unit time is the minimum time for block confirmation. That is, the unit time may be a multiple of a standard timestamp.

Each determinant node (V1 ~ V5) may define a reference time period for generating a hypothesis to generate a block as a standard timestamp. That is, each determinant node (V1 ~ V5) processes the timestamp in the transaction (Tr) as a standard timestamp. In this case, the standard timestamp may be a time when the corresponding transaction (Tr) request is generated.

4 is a diagram illustrating the structure and processing sequence of a smart contract of a block chain system based on a consensus algorithm of a rule proof method according to an embodiment of the present invention.

In the contract, the structure (Structure) of the transaction (Tr), the validity (Validity), the state of the block, and the acceptance decision (Make Decision) are defined. Therefore, as shown in Fig. 4, the program code included in the contract is to be defined as a function that performs the structure check of the transaction, validation check, status designation (Get Status), acceptance decision, and status setting by acceptance (Set Status). can In other words, the function defined in the contract can be performed by the program code included in the contract.

5 is a diagram illustrating the structure of block data stored in a block chain system based on a consensus algorithm of a rule proof method according to an embodiment of the present invention.

As shown in FIG. 5 , block data that is confirmed and stored may include a block header and a transaction. Here, the transaction included in the block data may additionally include a decision result in addition to the type, timestamp, public key, and signature included in the original transaction.

Hereinafter, a consensus method of the rule proof method of the present invention will be described with reference to FIGS. 6 to 9 .

6 is a flowchart illustrating a method of agreement of a rule proof method according to an embodiment of the present invention, and FIG. 7 is a diagram for explaining round synchronization in a method of agreement of a rule proof method according to an embodiment of the present invention, FIG. 8 is a diagram for explaining pre-commit in the method of agreement of the rule proof method according to an embodiment of the present invention, and FIG. 9 is a block of a specific node in the method of agreement of the rule proof method according to an embodiment of the present invention. It is a drawing for explanation.

The consensus method 20 of the rule proof method includes the steps of performing rounding for consensus on the block (S21), pooling chunks from other determinant nodes (S22), rearranging the pooled chunks to generate a hypothesis and hash It includes a step of pre-determining through comparison (S23) and a step of changing and storing the state of the block (S24).

Here, since such a consensus method is performed at each determinant node (V1 to V5), for convenience of explanation, any one determinant node is exemplarily described, but of course, the same may be performed in other determinant nodes as well. am.

More specifically, as shown in FIG. 6 , first, in the consensus algorithm-based blockchain system 10, each determinant node (V1 to V5) performs rounding for consensus on the block (step S21). At this time, each determinant node (V1 to V5) periodically collects information on the state of other determinant nodes. In this process, information can be collected through regular pings.

Each decision maker node (V1~V5) defines its next action from the previous block information. Here, the process for determining the next block is called rounding.

First, the decision maker node V1 monitors the states of other decision maker nodes V2 to V5. At this time, the decision maker node V1 requests the latest round information from other decision maker nodes V2 to V5.

Each determinant node (V1 ~ V5) stores the current length of the block chain it is operating on, and it is called a round. That is, each determinant node (V1 to V5) stores the state indicating the number of blocks from the start of the corresponding chain lifecycle in which the operation is being performed as a round. Each determinant node (V1 to V5) checks how many rounds each other is operating in order to agree with other determinant nodes. Confirmation does not currently broadcast its own round, but requests a round of decision-making nodes other than itself.

Here, the round information may include previous block information, next standard timestamp information, a public key, and a signature. At this time, since the response from the decision maker node providing the round is not reliable, a signature procedure is necessarily included. In addition, the standard timestamp is larger than the standard timestamp of the previous block among the suggested values, is a divisor of the unit time, and the smallest value is selected.

As a result of monitoring, when the decision maker node V3 is in the most advanced round state, as shown in FIG. 7A , the decision maker node V1 requests the decision maker node V3 for round synchronization. Of course, the other decision maker nodes V2 and V4 in a round state following the decision maker node V3 also perform round synchronization.

Here, since the informational/temporal distance on the network cannot be ignored, perfect real-time synchronization of all the decision maker nodes V1 to V5 is impossible. In such a network situation, if the decision maker nodes V1 to V5 broadcast round information at the end of each round, the decision point nodes V1 to V5 must all recognize each other's round completion at different times, and as a result, a specific round It will be impossible to specify the time and round to agree on. The fact that the decision-making nodes (V1~V5) do not achieve real-time synchronization in the consensus of the round means that the time for all the decision-making nodes (V1~V5) to generate consensus cannot be specified.

In order to solve this problem, the embodiment of the present invention confirms the situation of each other decision maker node and acknowledges the decision maker nodes V1 ~ V5) takes the form of following-up.

Each decision maker node (V1 ~ V5) requests the round information of other decision maker nodes instead of broadcasting its own round information. Determines whether or not to remain on the same network. Here, the first block must include the genesis block, and there are register and modify contracts in subsequent blocks. Therefore, if the blocks are calculated in order, a smart contract recognized in the network is obtained, and it can be determined whether the processing result of the subsequent transaction is appropriate by the contract.

In addition, each decision-making node (V1-V5) determines whether or not to remain on the same network by checking whether opinions are the same when agreeing on the same step. Therefore, if a decision maker node (V1 ~ V5) makes an incorrect result that is not based on the contract, other decision maker nodes (V1 ~ V5) will not accept the data, so it is naturally blocked from the network.

At this time, as shown in (b) of FIG. 7 , the decision maker node V1 may perform round synchronization by the block data of the decision maker node V3.

The decision maker node V1 proceeds a round for confirmation of the next block by the round synchronization or when it is in the latest round state.

During the corresponding round, each decision maker node (V1 ~ V5) can process the transaction issued by the user nodes (L11 ~ L52) connected to each.

At this time, each decision maker node V1 to V5 individually decides whether to accept or reject the transaction Tr to generate a processing result for consensus. Here, since the transaction Tr includes the signature generated by the private key, it is possible to check whether the signature is forged or falsified by using the public key. Whether the public key is trustworthy can be confirmed from the addresses of the user nodes (L11 to L52) that generate and request the corresponding transaction (Tr). Through this process, each decision maker node (V1 ~ V5) can check whether the transaction (Tr) it created is correct.

Next, each determinant node (V1 ~ V5) verifies whether the transaction (Tr) is valid when the transaction (Tr) created by it is correct. At this time, each decision maker node (V1 ~ V5) may verify the validity of the transaction (Tr) through the contract. For example, in the case of a transaction (Tr) in the most general cryptocurrency (Cryptocurrency network), it is possible to check whether the sender's balance is sufficient to perform the transaction, and whether the recipient's wallet address is valid.

At this time, each determinant node (V1 ~ V5) bundles transactions processed in a predetermined time unit into chunks.

Next, each decision maker node V1 to V5 requests and receives a chunk corresponding to the corresponding round from another decision maker node (step S22). In this case, the other decision maker node may be a round-synchronized decision maker node. Here, since each determinant node (V1 to V5) brings data from other determinant nodes, this process is called data pulling.

At this time, each decision maker node V1 to V5 may collect and hash signatures of transactions provided to other decision maker nodes and re-sign them. Here, such a signature is defined as a chunk signature. If one decision maker node provides two or more signatures in the same round, the signature with the smaller value may be selected.

Referring to FIG. 8 , a decision maker node V3 may receive a chunk from a decision maker node V1 and a decision maker node V2 . As an example, the determinant node V1 may provide a chunk including three transactions (a, d, e), and the determinant node V2 may provide a chunk including two transactions (b, f). .

At this time, the decision maker node V3 rearranges the chunk including its own transaction c and the chunks pooled from the decision maker node V1 and the decision maker node V2 based on the standard timestamp. Here, a to f mean standard timestamps. As a result, the decision maker node V3 can sequentially rearrange from the transaction (a) to the transaction (f).

Next, the decision maker node V3 processes each transaction according to a set contract and generates a block hash. Finally, the hash information includes chunk signature information, standard timestamp, block hash, public key, and signature information. Here, the block hash is a hashed value of the previous block, and is the sum of the transaction hash and the processing result.

At this time, when the hash information calculated by the decision maker node V3 matches the hash information of the transaction, the block of the corresponding round is pre-determined (step S23). This process is called pre-commit.

On the other hand, if the hash information calculated by each decision maker node V1 to V5 does not match the hash information of the transaction, the decision maker node corresponding to the transaction may be blocked.

Referring to FIG. 9 , if the hash information calculated by the decision maker node V3 does not match the hash information of the transaction, the decision maker node V5 providing the transaction may be regarded as an illegal participant. The decision maker node V3 may block the decision maker node V5.

Similarly, each determinant node V1 to V4 may block the determinant node V5. Therefore, the decision maker node V5, which is an illegal participant, can be isolated and blocked from the consensus algorithm-based blockchain system 10 .

In this way, each decision maker node (V1 ~ V5) does not apply pressure or punishment to other decision maker nodes to gather each other's opinions, but blocks itself and other decision maker nodes from their network. If this method is used, even if there are few good determinant nodes, the determinant node can survive.

Conventional consensus methods (for example, PoS (Proof-of-Stake), PoW) judged right and wrong depending on the number (or stake) of decision maker nodes participating in the consensus. Therefore, the conventional consensus method was equivalent to the Byzantine generals' problem, and there was no suitable countermeasure for the 51% attack.

However, the consensus method of the embodiment of the present invention has a logical scheme different from the Byzantine problem in which data must be synchronized at a single moment by taking the form of verifying each other determinant node rather than making one consensus. Therefore, in the HAP-based network according to the embodiment of the present invention, each non-evil determinant node can survive even if it becomes a minority group of 51% or less. In addition, the user nodes L11 to L52 may follow up a small number of non-malicious determinant nodes V1 to V5 through hash comparison or the like.

Optionally, each of the decision maker nodes V1 to V4 may re-perform the corresponding round except for the decision maker node V5.

Next, each decision maker node V1 to V4 finally determines and stores the block of the corresponding round (step S24). This process is called commit.

In this case, each of the decision maker nodes V1 to V4 may change the state of the block, store the confirmed block, and return to the rounding step.

The above methods may be implemented by the consensus algorithm-based blockchain system 10 of the rule proof method as shown in FIG. 1, and in particular, may be implemented as a software program performing these steps, in this case, These programs may be stored in a computer-readable recording medium or transmitted by a computer data signal combined with a carrier wave in a transmission medium or a communication network. In this case, the computer-readable recording medium may include any type of recording device in which data readable by a computer system is stored.

Although one embodiment of the present invention has been described above, the spirit of the present invention is not limited to the embodiments presented herein, and those skilled in the art who understand the spirit of the present invention can add components within the scope of the same spirit. , changes, deletions, additions, etc. may easily suggest other embodiments, but this will also fall within the scope of the present invention.

10 : Consensus Algorithm-based Blockchain System of Proof-of-Rule Method
V1~V5 : Determinant node L11~L52 : User node

Claims (12)

A blockchain system comprising a plurality of decision maker nodes that communicate with each other and communicate with user nodes,
Each of the plurality of decision maker nodes,
The transaction issued by the user node is processed and the processed transaction is bundled into chunks in a certain time unit to perform the corresponding rounding for consensus,
Each of the plurality of decision maker nodes requests the latest round information from another decision maker node, checks the standard timestamp of the latest round information, and synchronizes it with the block of the decision maker node that is in the most advanced round state among the plurality of decision maker nodes, Validate and synchronize only when it is valid, and block the network connection if not valid,
Request and receive chunks corresponding to the round from other decision maker nodes synchronized with the round,
A hypothesis is generated by rearranging the received chunk and the transactions included in the own chunk based on the standard timestamp included in each transaction, and calculating the hash of each transaction to obtain the hash information calculated by the user and the hash of the transaction. If the information matches, the hypothesis is pre-confirmed as a block of the round,
A blockchain system based on a consensus algorithm with a proof-of-rule method that changes the state of a block and stores a pre-confirmed block. delete According to claim 1,
Each of the plurality of decision maker nodes is a block chain system based on a consensus algorithm of a rule proof method that proceeds the round for the consensus when there is no decision maker node in a round state prior to its own round. According to claim 1,
In each of the plurality of decision maker nodes, if the hash calculated for the transaction and the hash included in the transaction do not match, the rule proof method consensus algorithm-based blockchain system that blocks the decision maker node of the transaction. According to claim 1,
The transaction is a rule proof-based consensus algorithm-based blockchain system that includes type, timestamp, and contract information. 6. The method of claim 5,
The contract information is a block chain system based on a consensus algorithm of a proof-of-rule method that includes a code defined as a function to check the structure of a transaction, check the validity of the transaction, set the state of the block, and decide to accept it. delete delete delete delete delete delete

Images