KR102346293B1 - Blockchain system and performance method for distributed processing of transaction using common keyset information - Google Patents

Abstract

The present invention relates to a blockchain system for distributed processing of transactions by using common keyset information, which comprises: a transaction packer generating a transaction proposal (Tx Proposal) which shows transaction information according to a transaction request from a user and adding key information corresponding to the transaction request to the generated Tx proposal; a transaction aggregator generating common keyset information corresponding to the Tx proposal and common transaction batch information according to the key information included in the Tx proposal delivered by the transaction packer and making classification by the generated common transaction batch information to transmit the same to a predetermined execution node group; and at least one transaction executor belonging to the execution node group and performing simulation of the Tx proposals included in the common transaction batch information transmitted by the transaction aggregator.

Description

Blockchain system and performance method for distributed processing of transaction using common keyset information}

The present invention relates to a blockchain distributed processing technology that enables distributed processing to be performed using common keyset information corresponding to a transaction request for efficient transaction distributed processing in a blockchain framework.

One of the big problems of concurrent computing is collisions due to references and changes to one variable. The most common method is a lock strategy for controlling exclusive access to a single variable, but since 1993, lock-free strategies such as STM (Software Transactional Memory) and RLU (Read-Log-Update) have been developed. STM, a representative lock-free strategy, is used in parallel processing completed within a single machine such as SMP (Shared Memory Multi-Processor), memory sharing model in distributed computing such as etcd, and collision detection between distributed transactions in blockchain. It is a parallel processing technique.

Due to its unique characteristic of being able to decentralize management entities, blockchain technology has been expected to have a very large ripple effect when applied to existing industries. However, the application of blockchain technology to existing industries has been delayed than expected, and one of the reasons is that the processing performance (throughput) is very low. Regarding the performance problems of these blockchains, we are trying to improve the overall processing performance of the platform by reducing the consensus time, increasing the processing capacity per block, and distributing transactions per chain through consensus algorithms and technologies such as multi-chain.

In general, mining refers to a total of four tasks: 1. Select transaction to be executed, 2. Transaction execution (Execution), 3. Transaction record ordering (Ordering), and 4. Hash & Nonce Finding.

In general, consensus algorithm development focuses on optimization and speeding up of the 3rd and 4th steps and the verification process. Since the early blockchain framework followed Bitcoin's PoW consensus method for public blockchains, safe and efficient consensus algorithms have been developed to speed up the 3rd and 4th steps. However, research on the existing consensus algorithm does not focus on the second step, speeding up transaction execution. As an approach different from the improvement of the consensus algorithm, there is also a multi-chain (multi-channel, side-chain) method that improves overall processing performance by processing different domains or types of transaction requests for each chain. By processing and generating blocks separately for each chain, overall throughput can be improved, but when different chains want to reference and change the same key, such as information shared between chains or variables for inter-chain interaction, a single key There is a performance degradation problem due to the block key collision problem. This means that if the process required by the existing industry, such as inventory management, is implemented on the blockchain as it is, it is difficult to process it efficiently.

Although the blockchain is composed of distributed nodes for mutual verification, it has a chronic problem that it is impossible to improve performance (scalability) according to the number of nodes. The most representative factor among the reasons why it is difficult to achieve scalability in a blockchain is the problem of single block key collision.

The single-block key conflict problem cannot be handled in one block at a time because the key conflicts between the transactions when a transaction running on two or more computational principals (the one executing the transaction request) references and changes the same key. none. This is because the consistency of the ledger record is broken if the values changed after reference by transactions referencing the same key are different (R/W Set conflicts). This is a process corresponding to the R/W set validation of STM. If the R/W set conflicts when a transaction is reflected like STM in the block chain, the processing result of the transaction is destroyed and re-executed, and reflected in the next block. should try As a result, in order to confirm mutually interfering transactions, as many blocks as the number of interfering transactions are required.

This problem can be solved if the changed values can be shared with each other, but since the blockchain is composed of distributed nodes, a distributed shared memory model should be used instead of shared memory, but since this means a greater performance degradation, different It is not desirable to share processing results between nodes.

As a result, the single-block key collision problem not only means degradation of the blockchain performance, but also decreases the block density (reduces the number of transactions contained in one block), and decreases the efficiency of transaction computation resources (by repeatedly re-executing the same transaction, valid transactions decrease in execution rate), etc.

In other words, in the case of early blockchain technology, there was no problem because the transaction was processed by distributing the transaction between nodes because one node calculated the transaction request to be processed and then verified it in the remaining nodes. However, due to hardware limitations such as I/O performance or CPU performance, there is a limit to the number of transactions that a single node can process in one block generation cycle. This means that if the number of transactions requesting processing per unit time increases, a given transaction cannot be processed by a single node, but has to be processed in multiple nodes.

In order to solve this problem, various techniques have been proposed in the past. Various technologies have been proposed, from methods to solve partial and special cases such as Riden/Lightening Network to methods to solve problems macroscopically such as sharding and multi-chain. However, since these technologies are directly or indirectly based on transaction processing and error recovery by STM (Software Transactional Memory) method, a single block key collision problem (within-block collision) inevitably occurs.

In a transactional system, the parallel processing performance of the STM method is higher than that of the lock strategy if the timing of the simultaneous execution of Tx in a transactional system, that is, the reflection period of the results does not match, and the probability of R/W set collision between each Tx is low. high. However, in the block chain, the reflection of the execution result of Tx is made only at the time of block creation. This is not a problem if only one Tx is executed in one block, but in case of parallel processing and further distributed processing, the time of reflection of the execution results of all Tx is always the same, so the R/W set collision of all Tx This occurs at once, and as a result, the probability of occurrence of STM retry inevitably increases compared to the general SMP environment, so the parallel processing performance of the blockchain system is very low. In other words, since it is inappropriate to apply the STM method to the blockchain as it is for the reasons described above, a method to solve this problem is required. Prior art literature: Korean Patent Publication No. 10-2018-0115778

The problem to be solved by the present invention relates to a blockchain system and a method for performing transaction distributed processing using common keyset information for efficient transaction distributed processing in a single ledger blockchain framework.

A blockchain system for distributed transaction processing using common keyset information according to the present invention for solving the above problems generates a transaction proposal (Tx Proposal) indicating transaction information according to a user's transaction request, and the generated transaction a transaction packer for adding key information corresponding to the transaction request to a proposal; According to the key information included in the transaction proposal received from the transaction packer, common keyset information and common transaction batch information corresponding to the transaction proposal are generated, and divided by the generated common transaction batch information in advance. a transaction aggregator that transmits to a specified execution nodegroup; and at least one or more transaction executors belonging to the execution node group and executing simulations for the transaction proposals included in the common transaction arrangement information transmitted from the transaction aggregator. do.

The key information is characterized in that it includes partial key information in an unconfirmed form including an array or composite key.

The common keyset information is characterized in that it indicates a key set for those having the same key among key information included in a plurality of transaction proposals.

The common transaction arrangement information is characterized in that it represents a set of transaction proposals respectively corresponding to key information included in the common keyset information.

The transaction aggregator is configured to designate the execution node group for calculation of the common transaction arrangement information according to reception of processing capability information of each of the execution nodes from a plurality of execution nodes, and to the designated execution node group. It is characterized in that the common transaction arrangement information is transmitted.

The transaction executor includes at least one cache memory, stores state information according to simulation execution of the transaction proposals in the cache memory, and uses the stored state information as a value for simulation for the next transaction proposal characterized in that

For the simulation of the transaction proposal, the transaction executor first accesses the cache memory to refer to the state information, and when the state information for the simulation of the transaction proposal does not exist in the cache memory, stored in the block chain It is characterized in that the ledger information is accessed and stored in the cache memory.

The transaction executor is characterized in that the ledger information stored in the block chain is stored in the cache memory in advance before the simulation of the transaction proposal.

The blockchain execution method for distributed transaction processing using common keyset information according to the present invention for solving the above problems is a transaction proposal (Tx Proposal) indicating transaction information according to a user's transaction request in a transaction packer. ) and adding key information corresponding to the transaction request to the generated transaction proposal; In a transaction aggregator, common keyset information and common transaction batch information corresponding to the transaction proposal are generated according to the key information included in the received transaction proposal, and the generated common transaction classifying each batch information and transmitting it to a pre-designated execution node group; and executing a simulation on the transaction proposals included in the transmitted common transaction arrangement information in at least one or more transaction executors belonging to the execution node group.

The key information is characterized in that it includes partial key information in an unconfirmed form including an array or composite key.

The common keyset information is characterized in that it indicates a key set for those having the same key among key information included in a plurality of transaction proposals.

The common transaction arrangement information is characterized in that it represents a set of transaction proposals respectively corresponding to key information included in the common keyset information.

The step of classifying the generated common transaction arrangement information and transmitting it to a pre-designated execution node group includes receiving processing capability information of each of the execution nodes from a plurality of execution nodes for calculation of the common transaction arrangement information. Designating the execution node group, and transmitting the common transaction arrangement information to the designated execution node group.

In the step of executing the simulation of the transaction proposals, state information according to the simulation of the transaction proposals is stored in a cache memory, and the stored state information is used as a value for the simulation of the next transaction proposal.

In the step of executing the simulation of the transaction proposals, for the simulation of the transaction proposal, first access the cache memory to refer to the state information, and the state information for the simulation of the transaction proposal does not exist in the cache memory If not, it is characterized in that it accesses the ledger information stored in the block chain and stores it in the cache memory.

The step of executing the simulation of the transaction proposals is characterized in that the ledger information stored in the block chain is stored in the cache memory in advance before the simulation of the transaction proposals.

According to the present invention, for a plurality of transaction requests, the existing multi-chain blockchain technology and Transaction Pre-Ordering technology and Otherwise, high transaction effective execution efficiency can be achieved.

In addition, when the transaction executor executes the simulation based on the common transaction batch information, the information stored in the cache memory is used primarily, but only when it is not stored in the cache memory, by executing the simulation on the transaction proposal by referring to the block chain. , it can significantly improve the simulation execution speed of transaction proposals.

Accordingly, it is possible to create a transaction group for each node group at a sufficiently high speed that guarantees an execution result without a single block key collision. By dividing and distributing common transaction arrangement information to a group of nodes on the blockchain and processing them sequentially or in parallel, it is possible to implement a blockchain framework technology that can achieve scalability according to an increase in the number of nodes.

1 is a block diagram of an embodiment for explaining a blockchain system for distributed transaction processing using common keyset information according to the present invention.
2 is a reference diagram illustrating transactions according to a user's request.
3 is a reference diagram illustrating an example of a process in which a transaction aggregator generates common keyset information and common transaction arrangement information.
4 is a reference diagram of another example for explaining a process in which the transaction aggregator generates common keyset information and common transaction arrangement information.
5 is a reference diagram of another example for explaining a process in which the transaction aggregator generates common keyset information and common transaction arrangement information.
6 is a reference diagram of another example for explaining a process in which the transaction aggregator generates common keyset information and common transaction arrangement information.
7 is a reference diagram of another example for explaining a process in which the transaction aggregator generates common keyset information and common transaction arrangement information.
8 is a reference diagram of another example for explaining a process in which the transaction aggregator generates common keyset information and common transaction arrangement information.
9 is a reference diagram of another example for explaining a process in which the transaction aggregator generates common keyset information and common transaction arrangement information.
10 is a reference diagram of another example for explaining a process in which the transaction aggregator generates common keyset information and common transaction arrangement information.
11 is a reference diagram of another example for explaining a process in which the transaction aggregator generates common keyset information and common transaction arrangement information.
12 is a reference diagram for another example for explaining a process in which the transaction aggregator generates common keyset information and common transaction arrangement information.
13 is a reference diagram of another example for explaining a process in which the transaction aggregator generates common keyset information and common transaction arrangement information.
14 is a reference diagram for explaining a process in which a transaction executor executes a simulation for each transaction proposal using common transaction arrangement information.
15 is a flowchart of an embodiment for explaining a block chain execution method for distributed transaction processing using common keyset information according to the present invention.

Hereinafter, preferred embodiments of the present invention will be described in detail with reference to the accompanying drawings.

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 following embodiments can be modified in various other forms, and the scope of the present invention is not limited It is not limited to the following examples. Rather, these examples are provided so that this disclosure will be more thorough and complete, and will fully convey the spirit of the invention to those skilled in the art.

The terminology used herein is used to describe specific embodiments, not to limit the present invention. As used herein, the singular form may include the plural form unless the context clearly dictates otherwise. Also, as used herein, the term “and/or” includes any one and all combinations of one or more of those listed items.

The technology proposed by the present invention applies the transaction parallel processing technology to the blockchain framework. By dividing the transaction request so that a single block key collision problem does not occur between transactions processed in different nodes, the parallel processing efficiency of the blockchain is method to increase it.

This method largely generates key information according to a transaction request, classifies transactions with common keyset information based on the generated key information (Transaction Proposal Aggregation: TPA), and cached that allows calculations between classified transactions to be executed. It is composed of Tx Executor. TPA classifies real-time transaction requests by node group so that there is no key duplication between groups. Cached Tx Executor executes the classified and assigned transactions in order.

First, the detailed contents of terms and data structures related to the present invention are summarized as follows.

Tx: Abbreviation for transaction. Tx means one processing, and it consists of information necessary for transaction processing required by the target blockchain architecture.

Tx Proposal: Includes transaction information according to a transaction request.

Tx Simulation: It means the execution result in the transaction executor for the transaction request.

Ledger Key: It means the key (variable name) of the value recorded in the ledger. It does not mean variables that are not recorded in the ledger or field names in structures.

Partial Ledger Key: Information composed of a part of the key of the value recorded in the ledger.

R/W Key Set (RWKS): It means a set of Ledger Key information of referenced and changed values when executing arbitrary Tx Proposal.

eTP (encapsulated Tx Proposal): This is a Tx Proposal with R/W Key Set Description information added to the existing Tx Proposal for transmission to the transaction aggregator.

The Tx Tree itself is a phenotype expressing the classification of one Tx type, and at the same time, a data structure expressing a set of classified Tx.

Tx Tree consists of two types of data. One is the RWKS of the Tx Tree, which is information expressing the type classification criteria of the corresponding Tx Tree. Another is Tx Set, which is a set of Tx that meets the type classification criteria of the corresponding Tx Tree.

eTPB: An ordered bundle of eTPs with mutual influence. The order within the eTPB is defined by the eTPID (TxID).

eTPBs (Forest, ForestContainer): A set of ordered eTPBs. The order of eTPBs within eTPBs is defined by the eTPBID (TreeID).

eTSBs: A bundle of Tx Simulations executed in the transaction executor in the order specified in the eTPBs.

eTPRBs: It is a bundle of Tx Proposal Responses executed in the order determined by eTPBs.

NodeInfoMap: Indicates the status information of all nodes participating in the blockchain.

Capacity: It means the Tx processing capacity capacity that each node group can process within one block generation cycle.

Arithmetic Load: refers to the time taken for Tx execution that does not include key reference and change operations on the ledger.

Key load: refers to the execution time required for key reference and change on the ledger.

eTP consists of the following information.

Kinds Contents EtpId (string) eTP identifier. In general, Tx ID of Tx Proposal is applied mutatis mutandis. TaskLoad(int32) The cost (≒ time) required to execute the corresponding Tx Proposal. Except for the time it takes to read or write a value to the ledger. ParKeys ([]string, or []([]string)) Array of Partial Ledger Keys of Ledger Keys that the Tx Proposal may refer to and change Keys([]string) Array of Ledger Keys that can be referenced or changed by the Tx Proposal Proposal (depending on the applied blockchain platform) Raw data of Tx Proposal of the applied blockchain platform (just insert Tx Proposal as it is) Receptor (string) Information of the Node (API Server) that received the Tx Proposal. Not covered in this document.

The eTPB consists of the following information.

Kinds Contents TreeId (string) identifier of the tree TreeCoreLoad(int32) Sum of TaskLoad of Tx Proposal contained in the tree ParKeys (map[string]bool, or map[[]string]bool) Array of Partial Ledger Keys of Ledger Keys that all Tx Proposals in the Tree can reference and change Keys (map[string]bool) Array of Ledger Keys that all Tx Proposals in the tree can reference and change Etps ([]ETP) Array of Tx Proposal in the Tree

eTPBs consist of the following information:

Kinds Contents Forest ([]eTPB) A set of all eTP trees processed by the node group of the transmission target
The order of loading data in the eTP Tree is not guaranteed, so the order is determined by the TreeID of the eTP Tree. ForestID (NodeGroupID:int32) Send destination Node Group ID of the eTPB ForestLoad(int32) Load value when running all the relevant eTPBs

dTPA (distributed TPA) communication protocol

dTPA is a TPA machine that exists distributedly on the network. dTPA receives eTP information exclusively or simultaneously from each API Server.

Each dTPA classifies eTPs using the same algorithm, but it is impossible to classify eTPs in the same way in all TPAs depending on the order and method of receiving a plurality of eTP information. To solve this problem, dTPAs selectively or non-selectively share information with each other, so that all TPAs classify eTPs in the same way, and the classification result must be transmitted to each Endorsing Peer node without overlapping.

For this, dTPA exchanges the following information with each other.

Kinds communication method Contents eTP_Charge Broadcast Signal that any eTP will be handled by a specific TPA
Configured with eTP and TPA_Id Charge_Negotiate P2P Communication to resolve the overlapping declaration of responsible TPA for any eTP
Data composition may vary depending on the negotiation algorithm eTPBs_Broadcast Broadcast A signal to inform other TPAs of the eTPBs that the TPA is currently in charge of at the time of origination
Share eTPBs or ΔeTPBs information RWKS_Broadcast Broadcast Signal to inform other TPA of RWKS of eTPBs that TPA is currently in charge of at the time of sending
Share eTPBs or ΔeTPBs information eTP_Toss P2P Communication to pass the eTP to the target TPA that the TPA cannot handle eTPB_Exchange_
Negotiation P2P Negotiation signal for exchanging eTPBs between TPAs eTPB_Exchange P2P Negotiation signal for exchanging eTPBs between TPAs

If the declaration of responsibility for a specific eTP is duplicated, the TPAs that have made the Charge Negotiation do not need to transmit the decision result to another TPA. This is because the TPA that has not declared the eTP does not classify the eTP and only needs to receive the result through eTPB_Broadcast. In any case, when the classification result is not yet delivered, the eTP and the eTP with overlapping variables are transmitted. If received, the TPA can deliver the eTP to all TPAs that have declared responsibility for the eTP through eTP_Toss. The data structure of dTPA is as follows.

Kinds data structure eTP_Charge eTP(ETP), TPA_Id(int32) Charge_Negotiate Ex) TPA_Id(int32), related_tx_count(int32), released_forest_count(int32) eTPBs_Broadcast ID of all eTPBs or eTPs included in the history of altered eTPBs, ΔeTPBs RWKS_Broadcast All eTPBs, or included in the history of altered eTPBs, ΔeTPBs
Ledger Key RWKS and Partial Key RWKS of eTPBS eTP_Toss eTP All eTPB_Exchange_
Negotiation

주고자 하는 eTPB의 ID, 받고자 하는 eTPB의 ID, 승낙 여부)ex) eTPB_IDs([]int32), eTPB_IDs([]int32), bool
(

ID of eTPB you want to give, ID of eTPB you want to receive, whether or not you agree) eTPB_Exchange []eTPB

The contents of the transaction executor with cache that can be distributed are as follows.

The present invention proposes a transaction executor structure for efficiently executing planned and classified Tx batch information for distributed computing through TPA. At the same time, we propose a transaction executor structure that improves execution speed by effectively reducing the I/O delay that occurs in the process of referencing values from the ledger.

First, the terminology for this is summarized as follows.

Block generation cycle: It means the time to execute all transactions in one block.

Global Cache: It refers to the cache memory that stores the referenced and changed values of all transaction proposals executed within one block generation cycle.

Read Entry: This is the key and value information read by the transaction proposal, and it is the type of information stored by the Read Set. Contains the key, the value, and the reference position of that value (the block number of that value and the Tx number within that block).

Write Entry: This is the key and value information written and changed by Tx, and it is the type of information stored by the Write Set. Includes keys, values, and whether to delete them.

The transaction executor proposed in the present invention has the following characteristics.

Global Cache is valid within one block generation cycle. A Local Cached R/W Set is valid during the execution of one transaction proposal. When a transaction proposal refers to a value, it is referred to in the order of Local Cached R/W Set -> Global Cache -> Ledger. When a transaction proposal records or changes a value, it is recorded only in the Local Cached R/W Set and is not reflected in the Global Cache. Only when the execution of the transaction proposal is normally completed, records and changes (ie, Local Cached R/W Set) of the transaction proposal are reflected in the Global Cache. Transaction proposals are executed sequentially in the order specified in the batch, and the result (R/W set) is also recorded sequentially.

The transaction executor has two new data structures.

Global Cache is a cache that temporarily stores the read/write values of all Tx executed within one block generation cycle.

Local Cached R/W Set is a cache that temporarily stores Read/Write values while executing one Tx.

Global Cache and Local Cached R/W Set store Read Entry in Read Set and Write Entry in Write Set based on Key.

The Read entry of Global Cache and Local Cached R/W Set consists of the following information.

Kinds Contents Key (string) The key and type of the value on the ledger can be changed according to the block chain structure Value (string) Values and types on the ledger can be changed depending on the structure of the block chain. Version(int, int) The location on the ledger where the value was recorded.
The first value is the block number, and the second value is the Tx number within the block.
Depending on what is being discussed, it may have only a block number.

Write entry of Global Cache and Local Cached R/W Set consists of the following information.

Kinds Contents Key (string) The key and type of the value on the ledger can be changed according to the block chain structure Value (string) Values and types on the ledger can be changed depending on the structure of the block chain. Is_Deleted(bool) Whether to delete the value.
It expresses whether the corresponding value has been deleted in the corresponding transaction (Local Cached R/W Set) or block generation cycle (Global Cache).

The transaction executor executes a transaction in Tx batch units instead of one Tx unit and returns the result.

1. The transaction executor receives _{batch P} , a batch of transaction requests.

2. Create _{batch Q} , which is a batch of empty transaction execution results.

3. Create an empty Global Cache, Cache _G.

4. When the block generation cycle starts, the received batch is executed.

5. If there is no remaining TxProp _A in the batch, proceed to the next step.

_{6. Create Cache L} , which is a Local Cached R/W Set of empty TxProp _A.

7. Execute TxProp _A.

8. If TxProp _A is executed normally, overwrite the Write Set of the Local Cached R/W Set of _{TxProp A to the Write Set of the Global Cache.}

9. Add TxProp _A and Cache _L to batch _Q.

10. When all transaction requests in Batch are executed, batch _Q is sent to the Committing Node as the execution result.

Global Cache, Cache _G , and Local Cached R/W Set Cache _L are changed in the following situations.

A. When executing arbitrary Tx, referencing the value of key X

First, the key X is referenced in Local Cached R/W Set(Cache _L ), and if there is, the corresponding value is returned.

If it is not in Cache _{L , it refers to the Global Cache (Cache G} ), returns the corresponding value if it exists, and adds _{the Read Entry to Cache L.}

If it is not in Cache _G , it refers to the ledger, returns the corresponding value, and adds _{the Read Entry to Cache G} and Cache _L.

B. When executing arbitrary Tx, if key X value is added, changed, or deleted, it is reflected only in _{Local Cached R/W Set (Cache L ).}

C. When the execution of a random Tx is normally completed (4.4 of the algorithm above), that is, when the value added, changed, or deleted by the corresponding Tx is reflected, the write set contents of _{Cache L are reflected in the Global Cache (Cache G} ) do.

By executing as above, it is possible to create a block without a single block key collision problem even if Tx that references/changes the value of one key multiple times within one block generation cycle is executed.

Prefetching by Read/Write Key Set

By introducing the Global Cache and Local Cached R/W Set structures proposed above, the single block key collision problem can be solved. In addition, execution performance can be improved by reducing I/O delay using RWKS information provided by Tx Proposal Batch.

RWKS contains the key of the value referenced or changed when executing all Tx of the Tx Proposal batch including the RWKS.

That is, if all the keys in the Read Key Set of RWKS are put in the Global Cache in advance, I/O Delay that occurs while waiting for references to be read from the ledger during Tx execution can be effectively removed.

Prefetching can be implemented efficiently enough by executing it as a thread independent of the existing Tx execution thread.

Prefetching can be performed in that order because the order of the required Read Key is also known in advance, but the reference order is not always constant due to branches such as if-then-else. To solve this problem, a method using a Prioritized Queue can be introduced.

The structure of the executor introduced in the present invention is described on the premise that all Tx are sequentially processed. However, parallel processing is also possible in this executor. For example, parallel processing in a tree unit or parallel processing by an order by a Tx dependency graph is possible.

The Tx batch received by the transaction executor is a Tx Forest, that is, a set of Tx Trees independent of each other. In other words, it is easy to create an executor thread in units of Tx Tree and execute them concurrently. At this time, since I/O load is a resource shared by all threads (Tx Tree), the key load calculation method of Tx batch for each node of TPA is almost the same.

However, the calculation method of Tx Execution Load of Tx batch may be different. If the memory I/O resource contention can be ignored, the Tx Execution Load should obtain the max value, not the sum of the Tx Execution loads of all Tx Trees in the Tx batch.

Hereinafter, a block chain system and execution method for transaction distributed processing using common keyset information according to the present invention will be described in detail.

1 is a block diagram of an embodiment for explaining a blockchain system (hereinafter referred to as a blockchain system) for distributed processing of transactions using common keyset information according to the present invention.

Referring to FIG. 1 , the blockchain system 100 includes a transaction packer 110 , a transaction aggregator 120 , and an execution node group 130 .

The transaction packer 110 generates a transaction proposal (Tx Proposal) indicating transaction information according to the user's transaction request (IN), and adds key information corresponding to the transaction request to the generated transaction proposal, It is passed to the Transaction Aggregator (120).

The transaction proposal includes transaction information corresponding to a user's transaction request, and indicates a data format of a transaction that can be used in the transaction aggregator 120 .

Key information means a Ledger Key in the above-mentioned term summary. In addition, the key information may include partial key information in an unconfirmed form including an array or a composite key. This means Partial Ledger Key in the above-mentioned glossary of terms.

In various cases, the Ledger Key to be referenced and changed is determined at the time the Tx is executed, or it is sometimes difficult to figure out all of them before executing the Tx. Partial Ledger Key is used in the following situations.

This is a case in which a subset of Ledger Keys that are referenced and changed in the corresponding Tx share certain characteristics. In the case of an array (accessing all or part of the values of the array abc ), when the leading string is the same, when the trailing string is the same, or when including some strings, etc. In addition, the Ledger Key referenced and changed in the corresponding Tx is generated or acquired during execution, and its characteristics are known in advance.

Array can be treated the same as in the case of the leading character string, and the trailing character string can be used in the same way if the character string is inverted, and some string matching methods can also be used if the data structure and algorithm are appropriately modified. However, when adding trailing string matching and partial string matching, you need to add one more dictionary layer. For the sake of explanation, the case where the leading character strings are the same is dealt with.

Prepare R/W Key Set (RWKS) not only for Ledger Key but also Partial Ledger Key and Ledger Key. For example, you can use Trie as a data structure of a Dictionary that stores Partial Ledger Keys and Ledger Keys. If it can be seen that the Tx of a certain Smart Contract mainly accesses a string starting with “APPLE” such as “APPLESEED” and “APPLEJUICE”, the Partial Key of this Tx is expressed as “APPLE*”.

In this way, when a Partial Ledger Key is given, with all the Partial Ledger Keys K of the newly given Partial Ledger Key RWKS of Tx A, K is retrieved from the RWKS for the Partial Ledger Keys of _{all Tx Tree B 1} ~ B _k. The same contents as these algorithms are performed for Partial Ledger Key K and RWKS of Partial Ledger Key.

If the Partial Ledger Key K is not found, by executing the above algorithm as it is, Tx including the Partial Ledger Key can also be classified as Tx through the above algorithm.

On the other hand, there are Tx that are difficult to classify even with the above Partial Key Tx Aggregation. This is a case where the Ledger Key referenced and changed in the relevant Tx is generated or acquired during execution, and its characteristics cannot be known in advance. In the case of a Ledger Key that is determined randomly, it is a case where the value on the ledger is used as the Ledger Key. In such a case, Tx including the Uncertain Key is classified as one Tx Tree, and if the size of the classified Uncertain Key Tx Tree is large, only an appropriate size is adopted, and the rest is reserved. Add Uncertain Key Tx Tree to all eTPBs classified by the above algorithm.

If the transaction executor executes this Uncertain Key Tx Tree first and then executes the rest of the Tx Tree on the execution result (Cache), even for Tx that cannot be classified due to the Uncertain Key, there is no conflict of R/W Set between Tx Trees. It is possible to process For example, if the value given as an argument to the Smart Contract is used as the leading string, the value “XYZ” is used to create something like “XYZ*”. Here, the ‘*’ character is considered a special character, not a regular character.

The transaction packer 110 converts a user's transaction request into a Tx proposal, adds additional information to generate an encapsulated Tx proposal (eTP), and transmits the generated eTP to the transaction aggregator 120 . Here, the eTP is a Tx Proposal in which additional information (R/W Key Set Description information) is added to be transmitted to the transaction aggregator 120 to the existing Tx Proposal.

2 is a reference diagram illustrating transactions (Tx 1 to Tx 11) according to a user's request. Referring to FIG. 2 , A, B, C, D, E, F, G, and H in transactions Tx 1 to Tx 11 may illustrate a sender and a receiver in a money transaction. For example, Tx 1: A -> C may be an example of a transaction in which person A remits a certain amount to person C.

The transaction packer 110 generates transaction proposals corresponding to the transactions Tx 1 to Tx 11, respectively, according to the transaction request of the users. Here, the transaction proposal is a data format of a transaction including the sender and the receiver corresponding to the requested transactions (Tx 1 to Tx 11), the direction and amount of the remittance, etc. In FIG. 2, A -> C, A - > D, A -> E, B -> F, B -> G, B -> H, A -> B, C -> D, E -> F, D -> H, G -> H indicated.

The transaction packer 110 adds key information corresponding to the transaction request to the generated transaction proposal. Here, the key information refers to a ledger key, for example, A, B, C, D, E, F, G, H constituting the transactions (Tx 1 to Tx 11) of FIG. 2 .

For example, the transaction packer 110 generates an encapsulated Tx Proposal (eTP) by adding key information A and C corresponding to the generated transaction proposal A -> C, and uses the generated eTP with the transaction aggregator 120 . forward to In addition, the transaction packer 110 generates an encapsulated Tx Proposal (eTP) to which key information A and D corresponding to the generated transaction proposal A -> D is added, and delivers the generated eTP to the transaction aggregator 120 . do. As described above, the transaction packer 110 sequentially generates eTPs for the transactions Tx 1 to Tx 11 for a transaction requested for a predetermined time and transmits the eTPs to the transaction aggregator 120 .

The transaction aggregator 120 generates common keyset information and common transaction batch information corresponding to the transaction proposal according to the key information included in the transaction proposal (eTP) received from the transaction packer 110 . Then, the generated transaction arrangement information is divided for each type and transmitted (OUT) to a pre-designated execution node group.

The common keyset information indicates a key set for those having the same key among key information included in a plurality of transaction proposals. Here, the common key set information means R/W Key Set (RWKS) information in the above-described terminology.

The transaction arrangement information indicates a set of transaction proposals respectively corresponding to key information included in the common keyset information. Here, the transaction arrangement information refers to the eTPB in the above term summary, and the order in the eTPB is defined by the eTPID (TxID).

FIG. 3 is a reference diagram for explaining a process of generating common keyset information and common transaction batch information performed in the transaction aggregator 120 .

3A illustrates a transaction proposal (eTP): A -> C received from the transaction packer 110 . Although not shown in (a) of FIG. 3 , the transaction proposal (eTP) A -> C includes information on A and C corresponding to key information.

3 (b) is a reference diagram showing that the first common keyset information A and C for the transaction proposal (eTP) were generated using key information A and C included in the transaction proposal (eTP): A -> C to be. Also, FIG. 3C is a reference diagram illustrating the first common transaction arrangement information A -> C corresponding to the common keyset information A and C. Referring to (b) and (c) of FIG. 3 , transaction proposal (eTP): first common keyset information (A, C) corresponding to A -> C and first common transaction arrangement information (A -> C) It can be seen that each is generated by the transaction aggregator 120 .

4 is a reference diagram of another example for explaining a process of generating common keyset information and common transaction arrangement information performed in the transaction aggregator 120 .

4A illustrates a transaction proposal (eTP) received from the transaction packer 110: A -> D. Although not shown in (a) of FIG. 4 , A -> D, which is a transaction proposal (eTP), includes information of A and D corresponding to key information.

Figure 4 (b) shows that the first common keyset information A, C, and D for the transaction proposal (eTP) was generated using key information A and D included in the transaction proposal (eTP): A -> D It is a reference diagram. The first common keyset information indicates A, C, and D corresponding to a set of key information common to transaction proposal (eTP): A -> C and A -> D. Also, FIG. 4C is a reference diagram illustrating first common transaction arrangement information A -> C, A -> D corresponding to first common keyset information A, C, and D. Referring to (b) and (c) of FIG. 4 , transaction proposal (eTP): first common keyset information (A, C, D) and first common transaction corresponding to each of A -> C, A -> D It can be seen that the batch information (A -> C, A -> D) is respectively generated by the transaction aggregator 120 .

5 is a reference diagram of another example for explaining a process of generating common keyset information and common transaction arrangement information performed in the transaction aggregator 120 .

5A illustrates a transaction proposal (eTP): A -> E received from the transaction packer 110 . Although not shown in (a) of FIG. 5 , A -> E, which is a transaction proposal (eTP), includes information on A and E corresponding to key information.

In Figure 5 (b), the first common keyset information for the transaction proposal (eTP), A, C, D, and E, was generated using key information A and E included in the transaction proposal (eTP): A -> E. It is a reference diagram showing The first common keyset information indicates A, C, D, and E corresponding to a set of key information common to transaction proposals (eTP): A -> C, A -> D and A -> E. In addition, (c) of FIG. 5 is a reference illustrating the first common transaction arrangement information A -> C, A -> D, A -> E corresponding to the first common keyset information A, C, D and E It is also Referring to (b) and (c) of Figure 5, transaction proposal (eTP): A -> C, A -> D and A -> first common keyset information corresponding to each of E (A, C, D, It can be seen that E) and the first common transaction arrangement information (A -> C, A -> D, and A -> E) are respectively generated by the transaction aggregator 120 .

6 is a reference diagram of another example for explaining a process of generating common keyset information and common transaction arrangement information performed in the transaction aggregator 120 .

6A illustrates a transaction proposal (eTP) received from the transaction packer 110: B -> F. Although not shown in (a) of FIG. 6 , the transaction proposal (eTP) B -> F includes information of B and F corresponding to key information.

6 (b) and 6 (c) correspond to FIGS. 5 (b) and 5 (c), respectively, and the transaction proposal (eTP) received from the transaction packer 110: B -> Since the key information of F corresponds to B and F, the first common keyset information and the first common transaction arrangement information do not change.

In contrast, in (d) of FIG. 6 , the second common keyset information for the transaction proposal (eTP), B and F, was newly created using key information B and F included in the transaction proposal (eTP): B -> F. It is a reference diagram showing

Also, FIG. 6E is a reference diagram illustrating the second common transaction arrangement information B -> F corresponding to the second common keyset information B and F. 6 (d) and (e), transaction proposal (eTP): second common keyset information (B, F) corresponding to B -> F and second common transaction arrangement information (B -> F) It can be seen that each is generated by the transaction aggregator 120 .

7 is a reference diagram of another example for explaining a process of generating common keyset information and common transaction arrangement information performed in the transaction aggregator 120 .

7A illustrates a transaction proposal (eTP) received from the transaction packer 110: B -> G. Although not shown in (a) of FIG. 7 , B -> G, which is a transaction proposal (eTP), includes information of B and G corresponding to key information.

7 (b) and 7 (c) correspond to FIGS. 6 (b) and 6 (c), respectively, and the transaction proposal (eTP) received from the transaction packer 110: B -> Since the key information of G corresponds to B and G, the first common keyset information and the first common transaction arrangement information do not change.

In contrast, in FIG. 7( d ), the second common keyset information for the transaction proposal (eTP), B, F, and G, is generated using key information B and G included in the transaction proposal (eTP): B -> G It is a reference diagram indicating that The second common keyset information indicates B, F, and G corresponding to a set of key information common to transaction proposal (eTP): B -> F and B -> G. In addition, FIG. 7E is a reference diagram illustrating second common transaction arrangement information B -> F and B -> G corresponding to the second common keyset information B, F, and G. Referring to (d) and (e) of FIG. 7 , transaction proposal (eTP): second common keyset information (B, F, G) and second common transaction corresponding to each of B -> F and B -> G It can be seen that the batch information (B -> F and B -> G) is generated by the transaction aggregator 120, respectively.

8 is a reference diagram of another example for explaining a process of generating common keyset information and common transaction arrangement information performed in the transaction aggregator 120 .

8A illustrates a transaction proposal (eTP) received from the transaction packer 110: B -> H. Although not shown in (a) of FIG. 8 , information of B and H corresponding to key information is included in the transaction proposal (eTP) B -> H.

8 (b) and 8 (c) correspond to FIGS. 7 (b) and 7 (c), respectively, and the transaction proposal (eTP) received from the transaction packer 110: B -> Since the key information of H corresponds to B and H, the first common keyset information and the first common transaction arrangement information do not change.

In comparison, (d) of FIG. 8 shows the second common keyset information B, F, G and H for the transaction proposal (eTP) using key information B and H included in the transaction proposal (eTP): B -> H. It is a reference diagram showing that a was created. The second common keyset information indicates B, F, G, and H corresponding to a set of key information common to transaction proposal (eTP): B -> F, B -> G, B -> H. In addition, (e) of FIG. 8 is a reference exemplifying the second common transaction arrangement information B -> F, B -> G, B -> H corresponding to the second common keyset information B, F, G, H It is also Referring to (d) and (e) of FIG. 8 , transaction proposal (eTP): B -> F, B -> G, B -> second common keyset information (B, F, G, It can be seen that H) and the second common transaction arrangement information (B -> F, B -> G, B -> H) are respectively generated by the transaction aggregator 120 .

9 is a reference diagram of another example for explaining a process of generating common keyset information and common transaction arrangement information performed in the transaction aggregator 120 .

FIG. 9A illustrates a transaction proposal (eTP) received from the transaction packer 110: A -> B. Although not shown in (a) of FIG. 9 , information of A and B corresponding to key information is included in A -> B, which is a transaction proposal (eTP).

Transaction proposal (eTP): A and B, which are key information included in A -> B, are first common keyset information (A, C, D, E) and second common keyset information (B, F, G, H), respectively included in each. Accordingly, transaction proposal (eTP): for A -> B, the first common keyset information (A, C, D, E) and the corresponding first common transaction arrangement information (A -> C, A -> D, and It cannot be classified to be included in A -> E), and in addition, the second common keyset information (B, F, G, H) and the corresponding second common transaction arrangement information (B -> F, B -> G, It cannot be classified to be included in B -> H).

Accordingly, when the key information intersects with a plurality of common keyset information, the transaction aggregator 120 generates common keyset information and common transaction arrangement information for a transaction proposal (eTP) including the corresponding key information. Instead, it is stored in a separate temporary storage space so that it can be processed at the time of blockchain execution of the next cycle.

As a result, FIGS. 9(b), 9(c), 9(d), and 9(e) are respectively shown in FIGS. 8(b), 8(c), and 8(d) ) and corresponding to (e) of FIG. 8 , the first and second common keyset information and the first and second common transaction arrangement information do not change. In addition, FIG. 9(f) shows a state in which the transaction proposal (eTP): A -> B is temporarily stored in a separate storage space to be executed at the next block chain processing time.

10 is a reference diagram of another example for explaining a process of generating common keyset information and common transaction arrangement information performed in the transaction aggregator 120 .

10A illustrates a transaction proposal (eTP) received from the transaction packer 110: C -> D. Although not shown in (a) of FIG. 10 , C -> D, which is a transaction proposal (eTP), includes information on C and D corresponding to key information.

FIG. 10 (b) corresponds to FIG. 9 (b), and since key information of the transaction proposal (eTP): C -> D received from the transaction packer 110 corresponds to C and D, the first common There is no change in keyset information. However, (c) of FIG. 10 shows the first common transaction arrangement information, which is the common transaction arrangement information to which C -> D, which is a transaction proposal (eTP), is added, A -> C, A -> D, A - It contains > E and C -> D.

In addition, FIGS. 10 (d) and 10 (e) correspond to FIGS. 9 (d) and 9 (e), respectively, and the transaction proposal (eTP) received from the transaction packer 110: C -> Since key information of D corresponds to C and D, there is no change in the second common keyset information and the second common transaction arrangement information. In addition, there is no change in (f) of FIG. 10 in that it corresponds to a temporarily stored transaction proposal (eTP): A -> B to be executed next time.

11 is a reference diagram of another example for explaining a process of generating common keyset information and common transaction arrangement information performed by the transaction aggregator 120 .

11A illustrates a transaction proposal (eTP) received from the transaction packer 110: E -> F. Although not shown in (a) of FIG. 11 , E -> F, which is a transaction proposal (eTP), includes information on E and F corresponding to key information.

Transaction proposal (eTP): E and F, which are key information included in E -> F, are first common keyset information (A, C, D, E) and second common keyset information (B, F, G, H), respectively included in each. Therefore, for transaction proposal (eTP): E -> F, the first common keyset information (A, C, D, E) and the corresponding first common transaction arrangement information (A -> C, A -> D, A) -> E and C -> D) cannot be classified, and also, the second common keyset information (B, F, G, H) and the corresponding second common transaction arrangement information (B -> F, B) -> G, B -> H) cannot be classified.

Accordingly, when the key information intersects with a plurality of common keyset information, the transaction aggregator 120 generates common keyset information and common transaction arrangement information for a transaction proposal (eTP) including the corresponding key information. Instead, it is stored in a separate temporary storage space so that it can be processed at the time of blockchain execution of the next cycle.

As a result, FIGS. 11 (b), 11 (c), 11 (d) and 11 (e) are shown in FIGS. 10 (b), 10 (c), and 10 (d), respectively. ) and FIG. 10 (e), the first and second common keyset information and the first and second common transaction arrangement information do not change.

In addition, FIG. 11(f) shows a state in which the transaction proposal (eTP): E -> F is temporarily stored in a separate storage space to be executed at the next block chain processing time. According to this, it can be confirmed that the previously stored transaction proposal (eTP): A -> B is additionally stored, and the transaction proposal (eTP): E -> F is stored.

12 is a reference diagram of another example for explaining a process of generating common keyset information and common transaction arrangement information performed by the transaction aggregator 120 .

12A illustrates a transaction proposal (eTP) received from the transaction packer 110: D -> H. Although not shown in (a) of FIG. 12 , D -> H, which is a transaction proposal (eTP), includes information on D and H corresponding to key information.

Transaction proposal (eTP): D and H, which are key information included in D -> H, are first common keyset information (A, C, D, E) and second common keyset information (B, F, G, H), respectively included in each. Therefore, for transaction proposal (eTP): D -> H, the first common keyset information (A, C, D, E) and the corresponding first common transaction arrangement information (A -> C, A -> D, A) -> E and C -> D) cannot be classified, and also, the second common keyset information (B, F, G, H) and the corresponding second common transaction arrangement information (B -> F, B) -> G, B -> H) cannot be classified.

Accordingly, when the key information intersects with a plurality of common keyset information, the transaction aggregator 120 generates common keyset information and common transaction arrangement information for a transaction proposal (eTP) including the corresponding key information. Instead, it is stored in a separate temporary storage space so that it can be processed at the time of blockchain execution of the next cycle.

As a result, FIGS. 12(b), 12(c), 12(d) and 12(e) are shown in FIGS. 11(b), 11(c), and 11(d), respectively. ) and FIG. 11 (e), the first and second common keyset information and the first and second common transaction arrangement information do not change.

In addition, FIG. 12(f) shows a state in which the transaction proposal (eTP): D -> H is temporarily stored in a separate storage space to be executed at the next block chain processing time. Accordingly, it can be confirmed that the transaction proposal (eTP): D -> H is stored in addition to the previously stored transaction proposal (eTP): A -> B, and E -> F.

13 is a reference diagram of another example for explaining a process of generating common keyset information and common transaction arrangement information performed in the transaction aggregator 120 .

13A illustrates a transaction proposal (eTP) received from the transaction packer 110: G -> H. Although not shown in (a) of FIG. 13 , G -> H, which is a transaction proposal (eTP), includes information on G and H corresponding to key information.

13 (b) and 13 (c) correspond to FIGS. 12 (b) and 12 (c), respectively, and the transaction proposal (eTP) received from the transaction packer 110: G -> Since the key information of H corresponds to G and H, the first common keyset information and the first common transaction arrangement information do not change.

In addition, (d) of FIG. 13 corresponds to (d) of FIG. 12 , and since the key information of the transaction proposal (eTP): G -> H received from the transaction packer 110 corresponds to G and H, the first 2 There is no change in common keyset information. However, (e) of FIG. 13 shows the second common transaction arrangement information, which is the common transaction arrangement information to which G -> H, which is a transaction proposal (eTP), is added, A -> C, A -> D, A - It contains > E and G -> H. In addition, there is no change in FIG. 13(f) in that it corresponds to the temporarily stored transaction proposals (eTPs) to be executed next time: A -> B, E -> F and D -> H.

The transaction aggregator 120 designates the execution node group 130 for calculation of the common transaction arrangement information according to the reception of processing capability information of each of the execution nodes from a plurality of execution nodes, and The common transaction arrangement information is transmitted to the execution node group 130 . The transaction aggregator 120 may receive processing capability information from a plurality of execution nodes at the time of generation of the common keyset information and the common transaction arrangement information, and may designate the execution node group 130 accordingly.

The execution node group 130 includes execution nodes for simulating at least one or more at least one transaction. A plurality of such execution node groups 130 may exist. Each execution node belonging to the execution node group 130 is called a transaction executor.

As shown in Figure 1, the execution node group 130 includes a plurality of transaction executors (130-1, 130-2, 130-3, ...). Each of the transaction executors 130-1, 130-2, 130-3, ... sequentially performs simulations for transaction proposals included in the transaction arrangement information transmitted from the transaction aggregator 120. run Meanwhile, each of the transaction executors 130-1, 130-2, 130-3, ... may execute a simulation in parallel with other transaction executors belonging to another execution node group.

Each of the transaction executors 130-1, 130-2, 130-3, ... has at least one or more cache memories. Here, the cache memory may include the aforementioned Global Cache and Local Cached R/W Set. In this case, the Global Cache may be referred to as a global cache memory, and the Local Cached R/W Set may be referred to as a local cache memory.

The global cache memory is a memory that temporarily stores the read/write values of all transactions executed within one block creation cycle. Also, the local cache memory is a memory that temporarily stores Read/Write values while executing one transaction.

14 is a reference diagram for explaining a process in which a transaction executor executes a simulation for each transaction proposal using common transaction arrangement information.

Referring to FIG. 14 , it is exemplified that the transaction executor includes a global cache memory (GCM) and a local cache memory (LCM).

Each of the transaction executors 130-1, 130-2, 130-3, ... stores state information according to the simulation of transaction proposals in the global cache memory (GCM) and the local cache memory (LCM), and the stored The state information is used as a value for the simulation of the next transaction proposal.

Each of the transaction executors 130-1, 130-2, 130-3, ..., accesses the cache memory to refer to the state information for simulation of the transaction proposal, When the state information for the simulation of the data does not exist, the ledger information stored in the block chain is accessed and stored in the cache memory.

A simulation execution process for each of the transaction executors 130-1, 130-2, 130-3, ... will be described with reference to FIG. 14.

For example, each of the transaction executors 130 - 1 , 130 - 2 , 130 - 3 , ... receives any common transaction arrangement information from the transaction aggregator 120 . In this case, the common transaction arrangement information includes transaction proposals (A -> B, A -> C) having key information corresponding to {A, B, C, D}, as shown in FIG. 14 . Transaction proposal: A -> B is a request signal to deduct the amount corresponding to 50 from the A account and deposit the deducted 50 to the B account. Also, transaction proposal: A -> C is a request signal to deduct the amount corresponding to D from account A and deposit the deducted amount D to account C.

Each of the transaction executors 130-1, 130-2, 130-3, ... sequentially executes simulations on transaction proposals included in the received common transaction arrangement information.

At this time, each of the transaction executors (130-1, 130-2, 130-3, ...) reads key information and key value information required for simulation from the ledger of the block chain and stores it in the global cache memory (GCM) in advance. can be put For example, as described in FIG. 14 , each of the transaction executors 130-1, 130-2, 130-3, ... has ledger information registered in the block chain in advance, that is, key information (A , B, C, D) and the corresponding key value information (100, 40, 30, 20) can be read from the block chain in advance and stored in the global cache memory (GCM).

Then, each of the transaction executors 130-1, 130-2, 130-3, ... executes a simulation for the transaction proposal corresponding to the first rank: A -> B. To this end, each of the transaction executors 130-1, 130-2, 130-3, ... is information for the simulation of the transaction proposal: A -> B, and the key value information "100 corresponding to the key information A" " and key value information "40" corresponding to key information B are read from the global cache memory (GCM).

Each of the transaction executors (130-1, 130-2, 130-3, ...) uses the key information read from the global cache memory (GCM) and the corresponding key value information to propose a transaction: A -> B , and the corresponding state information, A'=50 and B'=90, is stored in the local cache memory (LCM). Then, each of the transaction executors (130-1, 130-2, 130-3, ...) refers to the state information stored in the local cache memory (LCM), A' = 50 and B' = 90, Update key information and key value information in the cache memory (GCM).

Then, each of the transaction executors 130-1, 130-2, 130-3, ... is a transaction proposal corresponding to the second rank among the transaction proposals included in the common transaction arrangement information: A -> C Run the simulation. To this end, each of the transaction executors 130-1, 130-2, 130-3, ... is information for the simulation of the transaction proposal: A -> C, and the key value information "50 corresponding to the key information A " and key value information "30" corresponding to key information C are read from the global cache memory (GCM). On the other hand, as information for simulation of transaction proposal: A -> C, when key information D and corresponding key value information "20" are not stored in the global cache memory (GCM), transaction executors 130-1 , 130-2, 130-3, ...) each access the block chain, read the key information D included in the ledger information and the corresponding key value information 20, and store it in the global cache memory (GCM) A simulation corresponding to the transaction proposal can be executed using the stored information.

Each of the transaction executors (130-1, 130-2, 130-3, ...) uses key information read from the global cache memory (GCM) and corresponding key value information, transaction proposal: A -> C , and stores the corresponding state information A"=30 and C'=50 in the local cache memory (LCM). After that, the transaction executors 130-1, 130-2, 130-3, ...) each updates the key information and key value information of the global cache memory (GCM) with reference to A" = 30 and C' = 50, which are state information stored in the local cache memory (LCM).

After that, since each of the transaction executors 130-1, 130-2, 130-3, ... has completed simulation execution for all transaction proposals included in the common transaction arrangement information, state information according to the simulation It transmits the key information and key value information of the in-global cache memory (GCM) to the block chain so that it can be added to the ledger information of the block chain.

Then, each of the transaction executors (130-1, 130-2, 130-3, ...) transmits the response information that the simulation execution for all transaction proposals included in the common transaction arrangement information has been completed and the ledger information It is forwarded to the writing Committing Peer (not shown).

15 is a flowchart of an embodiment for explaining a block chain execution method for distributed transaction processing using common keyset information according to the present invention.

The transaction packer generates a transaction proposal (Tx Proposal) indicating transaction information according to a user's transaction request, and adds key information corresponding to the transaction request to the generated transaction proposal (step S200). The transaction proposal includes transaction information corresponding to a user's transaction request, and indicates a data format of a transaction that can be used in the transaction aggregator 120 .

Key information means a Ledger Key in the above-mentioned term summary. In addition, the key information may include partial key information in an unconfirmed form including an array or a composite key. This means Partial Ledger Key in the above-mentioned glossary of terms.

The transaction packer converts a user's transaction request into a Tx Proposal, adds additional information to create an encapsulated Tx Proposal (eTP), and delivers the generated eTP to the transaction aggregator. Here, the eTP is a Tx Proposal in which additional information (R/W Key Set Description information) is added to transmit to the transaction aggregator 120 to the existing Tx Proposal.

After step S200, common keyset information and common transaction batch information corresponding to the transaction proposal are generated according to the key information included in the transaction proposal received from the transaction packer, and the generated common transaction batch information It is divided by each and transmitted to a pre-designated execution node group (step S202).

The common keyset information indicates a key set for those having the same key among key information included in a plurality of transaction proposals. Here, the common key set information means R/W Key Set (RWKS) information in the above-described terminology.

The transaction arrangement information indicates a set of transaction proposals respectively corresponding to key information included in the common keyset information. Here, the transaction arrangement information refers to the eTPB in the above term summary, and the order in the eTPB is defined by the eTPID (TxID).

The step of dividing the generated common transaction arrangement information and transmitting it to a pre-designated execution node group includes receiving processing capability information of each of the execution nodes from a plurality of execution nodes for calculation of the common transaction arrangement information. The execution node group is designated, and the common transaction arrangement information is transmitted to the designated execution node group.

The transaction aggregator designates the execution node group for calculation of the common transaction arrangement information according to the reception of processing capability information of each of the execution nodes from a plurality of execution nodes, and assigns the common execution node group to the designated execution node group. Transmits transaction batch information. The transaction aggregator may receive processing capability information from a plurality of execution nodes at the time of generating common keyset information and common transaction arrangement information, and may designate an execution node group accordingly.

Each of the execution nodes transmits the simulation result to the transaction aggregator. Each of the execution nodes transmits a Tx Proposal Response to the corresponding transaction aggregator by referring to the information stored in the transaction proposal (information in the Receptor field for the transaction proposal).

After step S202, at least one transaction executor belonging to the execution node group executes a simulation on the transaction proposals included in the transmitted common transaction arrangement information (step S204).

In this case, the ledger information stored in the block chain may be stored in the cache memory in advance before the simulation of the transaction proposal. Also, in the step of executing the simulation of the transaction proposals, state information according to the simulation of the transaction proposals is stored in a cache memory, and the stored state information may be used as a value for the simulation of the next transaction proposal.

In addition, for the simulation of the transaction proposal, first access the cache memory to refer to the state information, and when the state information for the simulation of the transaction proposal does not exist in the cache memory, the ledger information stored in the block chain can be accessed and stored in the cache memory.

Up to now, the present invention has been mainly looked at with respect to the embodiments. Those of ordinary skill in the art to which the present invention pertains will understand that it can be implemented in a modified form without departing from the essential characteristics of the present invention. Therefore, the disclosed embodiments are to be considered in an illustrative rather than a restrictive sense. Therefore, the scope of the present invention is not limited to the above-described embodiments, and should be construed to include various embodiments within the scope of the claims and equivalents thereto.

100: Blockchain system
110: transaction packer
120: transaction aggregator
130: Execution node group

Claims (16)

a transaction packer that generates a transaction proposal indicating transaction information according to a user's transaction request, and adds key information corresponding to the transaction request to the generated transaction proposal;
According to the key information included in the transaction proposal received from the transaction packer, common keyset information and common transaction batch information corresponding to the transaction proposal are generated, and divided by the generated common transaction batch information in advance. a transaction aggregator that transmits to a specified execution nodegroup; and
It belongs to the execution node group and includes at least one or more transaction executors that execute simulations for the transaction proposals included in the common transaction arrangement information transmitted from the transaction aggregator,
The transaction packer,
adding partial key information in an unconfirmed form having the same leading string or trailing string corresponding to a part of the string composite key to the transaction proposal;
The transaction aggregator is
generating the common keyset information and the common transaction arrangement information using the partial key information;
The transaction executor is
At least one cache memory is provided, state information according to simulation execution of the transaction proposals is stored in the cache memory, and the stored state information is used as a value for simulation for the next transaction proposal, characterized in that A blockchain system for distributed processing of transactions using common keyset information. delete The method according to claim 1,
The common keyset information is
A blockchain system for distributed transaction processing using common keyset information, characterized in that it indicates a key set for those having the same key among key information included in a plurality of transaction proposals. The method according to claim 1,
The common transaction arrangement information is
A block chain system for distributed transaction processing using common keyset information, characterized in that it represents a set of transaction proposals respectively corresponding to the key information included in the common keyset information. The method according to claim 1,
The transaction aggregator is
Upon receipt of the processing capability information of each of the execution nodes from a plurality of execution nodes, the execution node group for calculating the common transaction configuration information is designated, and the common transaction configuration information is transmitted to the designated execution node group. A blockchain system for distributed processing of transactions using common keyset information, characterized in that delete The method according to claim 1,
The transaction executor is
For the simulation of the transaction proposal, first access the cache memory to refer to the state information, and when the state information for the simulation of the transaction proposal does not exist in the cache memory, access the ledger information stored in the block chain A blockchain system for distributed processing of transactions using common keyset information, characterized in that it is stored in the cache memory. 8. The method of claim 7,
The transaction executor is
A block chain system for distributed transaction processing using common keyset information, characterized in that the ledger information stored in the block chain is stored in the cache memory in advance before the simulation of the transaction proposal. generating, in a transaction packer, a transaction proposal indicating transaction information according to a user's transaction request, and adding key information corresponding to the transaction request to the generated transaction proposal;
In a transaction aggregator, common keyset information and common transaction batch information corresponding to the transaction proposal are generated according to the key information included in the transaction proposal, and the generated common transaction batch information separating them by each and transmitting them to a pre-designated execution node group; and
In at least one transaction executor belonging to the execution node group, executing a simulation on the transaction proposals included in the transmitted common transaction arrangement information;
The transaction packer,
adding partial key information in an unconfirmed form having the same leading string or trailing string corresponding to a part of the string composite key to the transaction proposal;
The transaction aggregator is
generating the common keyset information and the common transaction arrangement information using the partial key information;
The transaction executor is
At least one cache memory is provided, state information according to simulation execution of the transaction proposals is stored in the cache memory, and the stored state information is used as a value for simulation for the next transaction proposal, characterized in that A blockchain implementation method for distributed transaction processing using common keyset information. delete 10. The method of claim 9,
The common keyset information is
A method of performing a blockchain for distributed transaction processing using common keyset information, characterized in that it indicates a key set for those having the same key among key information included in a plurality of transaction proposals. 10. The method of claim 9,
The common transaction arrangement information is
A block chain execution method for distributed transaction processing using common keyset information, characterized in that it represents a set of transaction proposals respectively corresponding to the key information included in the common keyset information. 10. The method of claim 9,
The step of classifying the generated common transaction arrangement information and transmitting it to a pre-designated execution node group includes:
Upon receipt of the processing capability information of each of the execution nodes from a plurality of execution nodes, the execution node group for calculating the common transaction configuration information is designated, and the common transaction configuration information is transmitted to the designated execution node group. A block chain execution method for distributed processing of transactions using common keyset information, characterized in that delete 10. The method of claim 9,
The step of executing the simulation of the transaction proposals,
For the simulation of the transaction proposal, first access the cache memory to refer to the state information, and when the state information for the simulation of the transaction proposal does not exist in the cache memory, access the ledger information stored in the block chain and a block chain execution method for transaction distribution processing using common keyset information, characterized in that it is stored in the cache memory. 16. The method of claim 15,
The step of executing the simulation of the transaction proposals,
A block chain execution method for distributed transaction processing using common keyset information, characterized in that the ledger information stored in the block chain is stored in the cache memory in advance before the simulation of the transaction proposal.

Images