KR20240055447A - Blockchain network system based on shared log and method of processing user transaction of blockchain network - Google Patents

Abstract

A blockchain network system according to an embodiment to achieve the purpose of the present invention is a service user that provides information necessary for user transaction creation, which is transmitted via a client-side software interface that creates a user transaction based on user information. A plurality of smart contract execution nodes that receive user transactions and execute user transactions; and at least one shared log storage that receives a commit record generated as a result of the execution of a user transaction executed by a plurality of smart contract execution nodes and stores the commit record as a shared log.

Description

Shared log-based blockchain network system and user transaction processing method of blockchain network {BLOCKCHAIN NETWORK SYSTEM BASED ON SHARED LOG AND METHOD OF PROCESSING USER TRANSACTION OF BLOCKCHAIN NETWORK}

The present invention relates to a method of processing user transactions in a blockchain network that provides blockchain services, a blockchain network system based on a shared log environment that can process user transactions in parallel, and user transactions in the blockchain network. It's about processing technology.

Blockchain is a distributed ledger system that guarantees decentralization, integrity, and transparency based on a P2P network. Users participating in the network store all transaction details in the same data structure called a block and create new blocks according to the consensus protocol. In other words, blockchain is a data structure in which a block composed of a set of transactions contains the hash value of the previous block and connects all blocks in a chain format, and all nodes participating in the blockchain network are Keep the data structure the same. In order for a new block to be reflected in the blockchain, agreement between nodes is required, and the consensus algorithm used in each blockchain network is different. Even if the block data of a specific node is arbitrarily manipulated, blockchain can be validated because it has the hash value of the previous block, and the manipulated data is not reflected in the blockchain. In this way, blockchain makes it impossible to arbitrarily forge or falsify data, thereby ensuring data integrity and transparency.

Blockchain is divided into permissionless blockchain and permissioned blockchain. A permissionless blockchain is a blockchain that allows users and nodes to participate in the blockchain network without any restrictions. Representative permissionless blockchains include Bitcoin and Ethereum. Permissioned blockchain or consortium blockchain is a blockchain suitable for use in a business environment where only authorized users and nodes can participate in the blockchain network. A representative permissioned blockchain is Hyperledger Fabric. Hyperledger Fabric is a blockchain that follows the Execute-Order-Validate (EOV) execution model, and was introduced to complement the shortcomings of the blockchain system that followed the existing Order-Execute (O-X) execution model.

Smart contract refers to a distributed application that concludes and implements various types of contracts, such as notarization and real estate contracts, based on blockchain. A smart contract is a program that is executed through the consensus of nodes, which allows nodes to perform specified operations under the same conditions, allowing transactions to be carried out normally without a third party trust agency. You can develop and operate a distributed application (DApp) by configuring business logic through smart contracts.

Even with the above prior art, in order for blockchain-based decentralized applications to process user-requested transactions, blocks must be added to the ledger through a complex distributed consensus process, so there is still the problem of long transaction processing delays.

Additionally, the blockchain system has a structure in which each node receives blocks and is managed independently, so space overhead increases proportionally to the number of nodes, and there is also a significant problem with the overhead for world state updates.

Various efforts are being attempted to meet the performance scalability requirements of blockchain-based decentralized applications (DApps). In particular, consortium blockchain or permissioned blockchain systems were introduced to complement the performance limitations of existing permissionless blockchain platforms, but there are still performance limitations that make it difficult to apply them to actual applications for the reasons explained above.

The purpose of the present invention to solve the above problems is to develop a new blockchain network system that executes smart contracts in parallel on multiple nodes by utilizing a shared log, a service that maintains application consistency in a distributed environment. It proposes a method for processing user transactions in a blockchain network.

In addition, the purpose of the present invention is to support performance scalability through a new blockchain network system by expanding the number of nodes, reduce storage space overhead by recording blockchain information in a shared log service, and effectively support state information maintenance at the same time. It is done.

At this time, the shared log can easily support status information agreement between multiple nodes by basically adopting an append-only storage structure.

A shared log-based blockchain network system according to an embodiment to achieve the purpose of the present invention is provided by a service user who provides information necessary for user transaction creation through a client-side software interface that creates a user transaction based on user information. A plurality of smart contract execution nodes that receive user transactions transmitted and execute user transactions; and at least one shared log storage that receives a commit record generated as a result of the execution (endorsement) of a user transaction executed by a plurality of smart contract execution nodes and stores the commit record as a shared log.

Each of the plurality of smart contract execution nodes can process user transactions assigned to each of the plurality of smart contract execution nodes in parallel.

The shared log-based blockchain network system according to an embodiment of the present invention receives commit records from a plurality of smart contract execution nodes, verifies the validity of the commit records, and provides shared log storage if the commit records are determined to be valid. It may further include a sequencer node that generates an address token and transmits it to a plurality of smart contract execution nodes.

The sequencer node can perform validation checks between user transactions executed in parallel by a plurality of smart contract execution nodes, and generates a shared log storage address token containing a writable address to at least one shared log storage, thereby generating a plurality of shared log storage address tokens. It can support agreement on the order of user transaction execution between smart contract execution nodes.

To verify the validity of a commit record, the sequencer node compares the key-version pair for each object against the read set in the commit record and the version information of the objects included in the read set. Multi-version conflict check (MVCC) check) can be performed.

The shared log-based blockchain network system according to an embodiment of the present invention reads log data including user transaction commit records recorded in at least one shared log storage through the shared log interface, and uses the log data to block It may further include a block generation node that generates.

When creating blocks, block generation nodes can create new blocks that are compatible with existing blockchains and can propagate blocks.

The block generation node can generate blocks using the order already agreed upon during the sequential recording of user transactions related to log data and the execution of smart contracts.

A plurality of smart contract execution nodes may include a shared log interface.

Log data including commit records generated by a plurality of smart contract execution nodes may be transmitted to at least one shared log storage via a shared log interface.

Log data including commit records may be stored in at least one shared log storage.

A plurality of smart contract execution nodes can read the latest log data from at least one shared log storage via the shared log interface to obtain the latest status information necessary to create a commit record when executing a user transaction.

At least one shared log storage can store log data including commit records as multiple attributes. At this time, the plurality of properties may include at least one of transaction type, client ID, transaction ID, Java program information, transfer parameters, and execution results.

A user transaction processing method in a shared log-based blockchain network according to an embodiment of the present invention involves receiving a user transaction created based on user information from a service user providing the information necessary for user transaction creation through a client-side software interface. Transmitting to at least some of a plurality of smart contract execution nodes; At least some of the plurality of smart contract execution nodes execute a user transaction; At least some of the plurality of smart contract execution nodes generate a commit record as a result of executing a user transaction; and at least one shared log storage storing the commit record as a shared log.

Transmitting the user transaction to at least some of the plurality of smart contract execution nodes may include the client-side software interface assigning the plurality of user transactions to the plurality of smart contract execution nodes.

In the step of executing a user transaction, each of the plurality of smart contract execution nodes may process a plurality of user transactions assigned to each of the plurality of smart contract execution nodes in parallel.

In the user transaction processing method of a shared log-based blockchain network according to an embodiment of the present invention, after the step of creating a commit record and before the step of storing the commit record as a shared log, the sequencer node executes a plurality of smart contracts. Receiving commit records from at least some of the execution nodes; The sequencer node validates the commit record; If the commit record is determined to be valid, the sequencer node generates a shared log storage address token; and the sequencer node transmitting the shared log storage address token to at least some of the plurality of smart contract execution nodes.

At the stage where the sequencer node verifies the validity of the commit record, validation can be performed between user transactions executed in parallel by a plurality of smart contract execution nodes.

In the step of generating a shared log storage address token, a shared log address token containing a writable address in at least one shared log storage is generated, so that consensus on the order of user transaction execution between a plurality of smart contract execution nodes can be supported. there is.

In the step where the sequencer node verifies the validity of the commit record, the sequencer node collects the key-version pair for each object and the version information of the objects included in the read set for the read set in the commit record to verify the validity of the commit record. You can perform a multi-version conflict check (MVCC) to compare.

A user transaction processing method in a shared log-based blockchain network according to an embodiment of the present invention involves a block generation node reading log data including user transaction commit records recorded in at least one shared log storage through a shared log interface. step of putting in; A block generation node uses log data to create a new block compatible with existing blockchains; And it may further include propagating the block.

At the stage where the block generation node creates a new block, the block generation node can generate blocks using the order already agreed upon during the sequential recording of user transactions related to log data and the execution of smart contracts.

In the step where at least one shared log storage stores a commit record as a shared log, at least one shared log storage may store log data including the commit record as a plurality of attributes. At this time, the plurality of properties may include at least one of transaction type, client ID, transaction ID, Java program information, transfer parameters, and execution results.

According to an embodiment of the present invention, when processing large amounts of user transactions in an environment where shared logs are introduced into the blockchain system, the blockchain network system is configured to distribute user transactions to a plurality of nodes and execute smart contracts in parallel. By doing so, blockchain performance scalability can be supported.

Additionally, according to an embodiment of the present invention, unlike existing blockchain systems, when a user transaction is recorded as a shared log, it means that processing has been completed, so faster processing decisions can be supported compared to existing blockchain systems.

Figure 1 is a conceptual diagram illustrating a shared log-based blockchain network system according to an embodiment of the present invention.
FIG. 2 is a conceptual diagram illustrating in detail the structure of the smart contract execution node of FIG. 1.
FIG. 3 is a conceptual diagram illustrating in detail the structure of the block generator node of FIG. 1.
Figure 4 is a conceptual diagram illustrating an example of a commit record attribute structure used in a shared log-based blockchain network system according to an embodiment of the present invention.
Figure 5 is an operational flowchart illustrating an outline of a user transaction processing method in a shared log-based blockchain network according to an embodiment of the present invention.
FIG. 6 is an operation flowchart illustrating a process related to determining the order of creating a shared log and recording a user transaction in a shared log-based blockchain network according to an embodiment of the present invention.
FIG. 7 is a conceptual diagram illustrating part of a process of a user transaction processing method performed around a smart contract execution node of a shared log-based blockchain network system according to an embodiment of the present invention.
FIG. 8 is a conceptual diagram illustrating part of a process of a user transaction processing method performed around a block generator node.
Figure 9 is a block diagram illustrating a node or computing system in a generalized blockchain network according to an embodiment of the present invention.

Since the present invention can make various changes and have various embodiments, specific embodiments will be described in detail by illustrating them in the drawings. However, this is not intended to limit the present invention to specific embodiments, and should be understood to include all changes, equivalents, and substitutes included in the spirit and technical scope of the present invention. While describing each drawing, similar reference numerals are used for similar components.

Terms such as first, second, A, B, etc. may be used to describe various components, but the components should not be limited by the terms. The above terms are used only for the purpose of distinguishing one component from another. For example, a first component may be named a second component without departing from the scope of the present invention, and similarly, the second component may also be named a first component. The term “and/or” includes any of a plurality of related stated items or a combination of a plurality of related stated items.

When a component is said to be "connected" or "connected" to another component, it is understood that it may be directly connected to or connected to the other component, but that other components may exist in between. It should be. On the other hand, when it is mentioned that a component is “directly connected” or “directly connected” to another component, it should be understood that there are no other components in between.

The terms used in this application are only used to describe specific embodiments and are not intended to limit the invention. Singular expressions include plural expressions unless the context clearly dictates otherwise. In this application, terms such as “comprise” or “have” are intended to designate the presence of features, numbers, steps, operations, components, parts, or combinations thereof described in the specification, but are not intended to indicate the presence of one or more other features. It should be understood that this does not exclude in advance the possibility of the existence or addition of elements, numbers, steps, operations, components, parts, or combinations thereof.

Unless otherwise defined, all terms used herein, including technical or scientific terms, have the same meaning as generally understood by a person of ordinary skill in the technical field to which the present invention pertains. Terms defined in commonly used dictionaries should be interpreted as having a meaning consistent with the meaning in the context of the related technology, and unless explicitly defined in the present application, should not be interpreted in an ideal or excessively formal sense. No.

Matters disclosed before the filing date of the present invention as prior art may be included as part or all of the structure of the present invention within the scope that meets the purpose of the present invention. Those skilled in the art will be able to clearly infer the connection between the purpose and configuration of the present invention from the contents of prior art documents, and therefore excessively detailed descriptions that may obscure the purpose of the present invention will be omitted.

Hereinafter, preferred embodiments of the present invention will be described in more detail with reference to the attached drawings. In order to facilitate overall understanding when describing the present invention, the same reference numerals are used for the same components in the drawings, and duplicate descriptions of the same components are omitted.

Figure 1 is a conceptual diagram illustrating a shared log-based blockchain network system according to an embodiment of the present invention.

As shown in Figure 1, the entire system includes a service user 100 and a shared log-based blockchain network system 300.

The service user 100 represents a terminal that receives services from the shared log-based blockchain network system 300 and may include a smartphone, personal computer (PC), etc. The service user 100 can transmit transactions to the smart contract execution nodes 310 in the shared log-based blockchain network system 300 through the client SDK 200 for smart contract execution (endorsement).

The shared log-based blockchain network system 300 according to an embodiment of the present invention is a client-side software interface that creates a user transaction based on user information from the service user 100, which provides information necessary for user transaction creation. A plurality of smart contract execution nodes 310 that receive user transactions transmitted via the client SDK 200 and execute user transactions; and at least one shared log storage 341 that receives a commit record generated as a result of the execution of a user transaction executed by a plurality of smart contract execution nodes 310 and stores the commit record as a shared log.

Each of the plurality of smart contract execution nodes 310 may process user transactions assigned to each of the plurality of smart contract execution nodes 310 in parallel.

The shared log-based blockchain network system 300 according to an embodiment of the present invention receives a commit record from a plurality of smart contract execution nodes 310, verifies the validity of the commit record, and determines that the commit record is valid. If determined, it may further include a sequencer node 320 that generates a shared log storage address token and transmits it to a plurality of smart contract execution nodes 310.

The sequencer node 320 can perform validation checks between user transactions executed in parallel by a plurality of smart contract execution nodes 310, and has a shared log storage address including a writable address in at least one shared log storage. By generating a token, it is possible to support agreement on the order of user transaction execution between a plurality of smart contract execution nodes 310.

To verify the validity of the commit record, the sequencer node 320 performs a multi-version conflict check (MVCC) that compares the key-version pair for each object with the read set in the commit record and the version information of the objects included in the read set. -version conflict check) can be performed.

The shared log-based blockchain network system 300 according to an embodiment of the present invention provides log data including user transaction commit records recorded in at least one shared log storage 341 through a shared log interface/shared log API ( 333) and may further include a block generation node 330 that generates a block using log data.

When creating a block, the block generation node 330 can create a new block that is compatible with existing blockchains and can propagate the block. At this time, the block generation node 330 can deliver the new block to the outside of the shared log-based blockchain network 300.

The block generation node 330 may generate blocks using an order already agreed upon during sequential recording of user transactions related to log data and execution of smart contracts.

A plurality of smart contract execution nodes 310 may include a shared log interface/shared log API 314.

Log data including commit records generated by a plurality of smart contract execution nodes 310 may be transmitted to at least one shared log storage 341 via the shared log interface/shared log API 314.

Log data including commit records may be stored in at least one shared log storage 341.

A plurality of smart contract execution nodes 310 connect to at least one shared log storage via the shared log interface/shared log API 314 to obtain the latest status information required to create a commit record when executing a user transaction. The latest log data can be read from (341).

At least one shared log storage 341 may store log data including commit records as a plurality of attributes. At this time, the plurality of properties may include at least one of transaction type, client ID, transaction ID, Java program information, transfer parameters, and execution results.

The shared log-based blockchain network system 300 may include smart contract execution nodes 310, a sequencer node 320, a block generator node 330, and a shared log service execution node 340. The smart contract execution nodes 310 process transactions received from the client SDK 200 by executing (endorsement) the pre-installed smart contract 315 in a shared log environment, and generate a commit record including the results. , commit records can be recorded in the form of a shared log.

The client SDK 200 may be software installed on the service user 100, that is, the client side. The client SDK 200 may allocate and transmit user transactions to a plurality of smart contract execution nodes 310. In other words, the client SDK 200 can automatically load balance a plurality of user transactions.

The smart contracts 315 held by the smart contract execution nodes 310 may be identical to each other if they provide the same blockchain application service. However, user transactions processed by smart contracts 315 of different nodes may be different. When multiple service users 100 request different transactions, these transactions are divided and allocated to a plurality of smart contract execution nodes 310 so that user transactions can be processed in parallel. That is, transactions of different users and/or transactions with different content may be executed in parallel between different smart contract execution nodes 310.

The sequencer node 320 is a node that issues a shared log storage address token to control conflicts that occur when a plurality of smart contract execution nodes 310 record transactions to the same log location. The sequencer node 320 may hold a counter that stores the last log address of the shared log and a key-version pair for each entity. At this time, the key may refer to the key of the object, and the version may refer to the shared log address information where the object was last updated. The sequencer node 320 performs the following functions based on these two data structures. First, the sequencer node 320 can perform an MVCC read conflict check on the read set of commit records submitted by the smart contract execution nodes 310. Second, a shared log storage address token can be issued for commit records that have no conflicts for the read set.

The sequencer node 320 is a node that determines the order in which transactions are stored in the shared log after execution. That is, the order in which transaction information and execution result data are stored in the shared log may be determined by the sequencer node 320. Depending on the situation, user transaction execution may proceed normally even if the sequencer node 320 is not configured, and the sequencer node 320 may increase the transaction execution success rate, ultimately affecting performance.

According to an embodiment of the present invention, the sequencer node 320 may perform an integrity check of stored data (shared log). At this time, the sequencer node 320 can perform the role of integrity check of the shared log by performing MVCC.

The block generator node 330 can refer to the transaction log data recorded in the shared log storage/storage 341 of the shared log service execution unit 340, generate a block including this, and record it in blockchain form. Blockchain information can be linked to external nodes.

In the blockchain network system 300 according to an embodiment of the present invention, the distribution and execution of the smart contract 315, the processing results of user transactions, etc. are recorded in the shared log storage/storage 341 according to the execution order, By creating a blockchain in the form of blocks for external linkage, it can be considered a high-performance blockchain network with a kind of lightweight consensus process.

The block generator node 330 can use the shared log 342 to generate blocks and form a blockchain. Information formed through blockchain is difficult to change and can be discovered in the event of non-agreed upon changes.

In an embodiment of the present invention, block generator node 330 can only communicate with shared log storage 341. Block generator node 330 may operate independently from other entities/objects/nodes.

There is no need to necessarily check or verify the validity of the block at the block generator node 330.

Log data of the shared log service execution unit 340 may be shared by all smart contract execution unit nodes 310. Since the shared log service executing unit 340 determines the order of logs, consistency of transaction order can be maintained. Therefore, transaction information of the smart contract 315 executed by the smart contract execution nodes 310 can be recorded as a log.

The shared log storage 341 may be implemented as an independent server or in the form of a cloud server.

The shared log storage 341 may be implemented by combining one or more servers and a cloud server.

When the shared log is stored in the shared log storage 341, the data integrity check can be considered to have been performed. The sequencer node 320 may share part of the role of data integrity check and support it indirectly.

Since the shared log 342 exists, even if the state of objects in the smart contract 315 changes, these changes can be shared and updated between each smart contract execution node 310 by the shared log 342, can be synchronized.

In one embodiment of the present invention, the smart contract 315 itself does not change in the processing/execution of the transaction, and the usage status of objects may change. Changes in the usage status of these objects can be shared by multiple nodes through the shared log 342.

In another embodiment of the present invention, the smart contract 315 itself may change depending on the processing/execution of the transaction. In this case as well, the change history of the smart contract 315 can be shared between multiple nodes through the shared log 342.

At this time, changes in the smart contract 315 according to the execution of the transaction are shared with entities in the blockchain network 300 through the shared log 342, and changes in the smart contract 315 itself are shared with each execution node 310. It may be updated by .

The two main challenges of a general blockchain system are consistency of smart contract execution (endorsement/execution) results, which are distributed applications running on nodes that individually store the state, and performance scalability. Blockchain systems can often consist of multiple nodes that share application state. However, in a structure where each node maintains independent storage that is updated through blocks, it is difficult to maintain the state of the nodes consistently and achieve performance scalability. In particular, the user transaction processing performance of blockchain systems is significantly lower than that of centralized services. Therefore, in order to apply it to actual business applications, the blockchain system also needs to meet performance requirements equivalent to centralized services.

As user interest in not only decentralized exchange services, but also blockchain games such as Metaverse and non-fungible token NFT linkage, decentralized finance (Decentralized Finance DeFi), and P2E (Play-to-Earn) has increased, Block The importance of chain performance scalability continues to increase. In other words, the demand for a blockchain system designed to allow expansion of performance by adding blockchain nodes while maintaining the characteristics and advantages of a blockchain system is increasing.

According to an embodiment of the present invention, a shared log-based highly scalable blockchain network system and a method for processing user transactions within the network are disclosed. According to an embodiment of the present invention, blockchain performance scalability can be supported by processing transactions in parallel by a plurality of nodes in a shared log environment.

The shared log method was used in distributed data storage to provide high fault tolerance while maintaining application consistency in a distributed environment, and is a protocol that has since been utilized in various distributed systems. The shared log method provides the ability for multiple clients within one system to access and record logs at the same time. In some cases, the shared log 342 may need to be permanently stored for analysis or disaster recovery, and the way the shared log 342 is implemented to ensure smooth operation of the system may vary depending on system requirements.

The shared log 342 provides an API that can internally process fault-tolerant consensus in the shared log service execution unit 340, which can reduce the burden of fault-tolerant consensus processing when applied to distributed applications. there is.

The shared log service executing unit 340 can add or remove storage servers according to the requirements of distributed applications and maintain the order of all logs stored in each server. Therefore, the shared log method is simple to use, but is a protocol that supports the efficient construction of a fault-tolerant system.

The structure of the shared log-based highly scalable blockchain network system 300 according to an embodiment of the present invention includes a service user 100 that generates a user transaction, and a smart contract execution unit (Smart Contract) on the service user 100 side. Client SDK 200 that provides an interface to communicate with Executor nodes 310, smart contract execution nodes 310 that receive and process user transactions, and a share that records user transaction processing results in log form. The log service execution unit (Shared-log Service) 340, and the smart contract 315 accessed from the plurality of smart contract execution node nodes 310 corresponding to the plurality of smart contracts 315 running in parallel. Sequencer node 320, which performs consensus on state information consistency for objects and transaction execution order, and is shared for compatibility with existing blockchains (e.g. Ethereum, Hyperledger Fabric, etc.) It may include a total of six components, including a block generator node 330 that generates and propagates blocks based on transaction information recorded in the log storage 341. The shared log-based highly scalable blockchain system according to an embodiment of the present invention may include various methods for executing smart contracts in parallel and generating blocks in a distributed environment.

In addition, the sequencer node 320 is a node that issues a shared log storage address token to control conflicts that occur when a plurality of smart contract execution nodes 310 record transactions to the same shared log location. am. The shared log service execution unit 340 records user transaction processing results in a log and may serve as an object storage. More specifically, instead of maintaining an independent local state storage for each smart contract execution node 310, the shared log 342 is used as a distributed object storage to provide the same state to all smart contract execution nodes 310. An object state view (in-memory view) can be provided. The service user 100 may communicate with the smart contract execution nodes 310 through the client SDK 200 to use the blockchain service.

The object storage is a repository (storage) that stores the state information of an object, and the state information of the object may include the version and update state information of the object related to the smart contract.

According to an embodiment of the present invention, a technique for ensuring performance scalability is disclosed by recording and managing transactions transmitted by a service user 100 as a shared log. A method of supporting a shared log-based highly scalable blockchain includes the steps of a service user 100 transmitting a transaction to smart contract execution nodes 310, and the smart contract execution nodes 310 transmitting the transaction. Executing in a shared log environment, verifying the results of the transaction execution at the sequencer node 320 and issuing a token, and recording information about the transaction execution in the shared log service execution unit 340. A step of generating a block at the block generator node 330 based on log data recorded in the shared log service execution unit 340 may be included.

Additionally, the properties of the commit record recorded in the shared log may include transaction type, client ID, transaction ID, Java program information, transfer parameters, and execution results. According to another embodiment, the properties of the commit record may include additional properties defined as needed.

FIG. 2 is a conceptual diagram illustrating in detail the structure of the smart contract execution unit node 310 of FIG. 1.

As shown in Figure 2, the smart contract execution node 310 includes an API gateway 311, a smart contract execution module 312, a smart contract stub 313, a shared log API 314, and a smart contract 315. ) and may support the smart contract 315 to run in a shared log environment.

The smart contract execution node 310 can process user transactions. The smart contract execution node 310 may include five sub-modules, and the five sub-modules provide a single endpoint to the service users 100 and provide an API gateway (API gateway) that routes appropriate services according to requests. 311), a smart contract execution module 312 that executes a smart contract transaction, a smart contract 315 containing application logic, so that the smart contract 315 can communicate with the shared log service execution unit 340 A supported smart contract stub (313), a shared log API (shared -log API) (314).

The API gateway 311 may receive a transaction request from the service user 100 and process the service according to the request. The API gateway 311 provides a single endpoint to the service user 100 and upon receiving a request from the service user 100, validates the request, routes it to the appropriate service, and returns a response to the request to the service user 100. can do.

When the smart contract execution module 312 receives a request from the API gateway 311, it executes the logic for the smart contract 315 requested by the service user 100, and executes the execution result (read-write set) and transaction information (transaction You can create a commit record (log entry) including ID, service user (100) ID, etc.) and transmit it to the sequencer node 320 to request issuance of a shared log storage address token. If a token is successfully issued from the sequencer node 320, a commit record can be recorded in the shared log service execution unit 340 through the shared log API 314.

The smart contract stub 313 is a module that supports access and update requests for object state on the smart contract 315 side, and may include an interface for communicating with the shared log service execution unit 340. In the smart contract 315, object state reading and updating operations can be supported through the storage 341 maintained in the shared log service execution unit 340. The smart contract 315 does not maintain a local state within the program code and can only refer to the entity state stored in the shared log service execution unit 340. The smart contract stub 313 can access the object state of the shared log service execution unit 340 through the shared log API 314 and create a read set. At this time, in the case of an update request, a write set may be created simply for object update.

The shared log API 314 may refer to a set of APIs that provide an interface so that a shared log client (smart contract execution unit node 310) can communicate with the shared log service execution unit 340. Accordingly, the smart contract executor node 310 may load the shared log API 314 to interact with the shared log service executor 340 as an object store. The shared log API 314 can provide an in-memory local view of the object state to each smart contract execution node 310, and the provided in-memory local view of the object state is a shared log. It can be synchronized between a plurality of smart contract execution unit nodes 310 through the service execution unit 340.

The smart contract 315 is a program code that implements application logic, and is one of the most important components in the embodiment of the present invention because all business logic is inside the smart contract 315. The service user 100 can interact with the smart contract 315 through the smart contract execution node 310. Therefore, it is assumed that the same smart contract 315 is installed in all smart contract execution nodes 310 that perform transactions.

FIG. 3 is a conceptual diagram illustrating the structure of the block generator node 330 of FIG. 1 in detail.

Additionally, the block generator node 330 may include three sub-modules, and the three sub-modules read the transaction log from the shared log service execution unit 340 and convert it into a transaction entry form included in the block to generate a block. A reader module 331 that transmits the data to the module 332, a block generation module 332 that generates blocks from the transaction entries received from the reader module 331, and finally a shared log service execution unit. It may include a shared log API 333, which is an interface for referencing shared log data from 340.

The block generator node 330 may further include a block storage 334 in addition to a reader module 331, a block creation module 332, and a shared log API 333. The reader module 331 may read the transaction log recorded in the shared log service execution unit 340, convert it into a transaction entry form to be included in a block, and transmit it to the block generation module 332. The block creation module 332 may generate transaction entries received from the leader module 331 into blocks. Since the log data recorded in the shared log service execution unit 340 during the block creation process has already sequentially recorded transactions occurring in the smart contract execution unit node 310, it can be interpreted that an agreement on the order has been reached. The block generator node 330 is not involved in the execution of the smart contract 315 and only requires log data containing the execution results of the transaction. More specifically, the shared log API 333 in the block generator node 330 is required to refer to log data recorded in the shared log service execution unit 340.

Figure 4 is a conceptual diagram illustrating an example of a commit record attribute structure used in a shared log-based blockchain network system according to an embodiment of the present invention.

A commit record is a log entry that records all changes that occur in one transaction and is ultimately recorded in the shared log service execution unit 340. Since the commit record represents the order of transactions that occurred in the system, atomicity must be guaranteed. To provide this atomicity, the commit record must include transaction metadata and execution results (read-write set). In addition to atomicity, ACID, including consistency, isolation, and durability, can be considered essential properties for database transactions to be performed safely. Depending on the embodiment of the shared log service executing unit 340, the basic properties included in the commit record may be different. In order to create a block by referring to the log data of the shared log service execution unit 340 in the shared log-based blockchain network 300, the properties required for block creation must be recorded in the commit record. Therefore, the shared log-based blockchain network 300 can define the properties of the commit record. As shown in Figure 4, the properties of the commit record include at least a shared log address, transaction type, client ID, transaction ID, smart contract name and version, smart contract function and its argument information, timestamp, and read-write set. It may contain more than one.

FIG. 5 is an operational flowchart illustrating an outline of a user transaction processing method of the shared log-based blockchain network 300 according to an embodiment of the present invention.

The user transaction processing method according to an embodiment of the present invention can be executed by nodes that share each function within the shared log-based blockchain network 300. Each node may be implemented as a computing system that includes a processor that is electronically connected to internal components and a memory that stores instructions. The user transaction processing method may be executed by a computing system including such memory and processor.

The user transaction processing method of the shared log-based blockchain network 300 according to an embodiment of the present invention provides a user transaction generated based on user information from a service user 100 that provides information necessary for user transaction creation to a client. Transmitting to at least some of the plurality of smart contract execution nodes 310 via a side software interface (S510); At least some of the plurality of smart contract execution nodes 310 execute a user transaction (S530); At least some of the plurality of smart contract execution nodes 310 generate a commit record as a result of executing a user transaction (S550); And at least one shared log storage 341 stores the commit record as a shared log 342 (S570).

The step of transmitting the user transaction to at least some of the smart contract execution nodes 310 (S510) includes the client-side software interface assigning the plurality of user transactions to the plurality of smart contract execution nodes 310. can do.

In the step of executing a user transaction (S530), each of the plurality of smart contract execution nodes 310 may process a plurality of user transactions assigned to each of the plurality of smart contract execution nodes 310 in parallel.

The user transaction processing method of the shared log-based blockchain network 300 according to an embodiment of the present invention includes the step of generating a commit record (S550) and the step of storing the commit record as a shared log 342 (S570). ), the sequencer node 320 receiving a commit record from at least some of the plurality of smart contract execution nodes 310; The sequencer node 320 verifies the validity of the commit record; If the commit record is determined to be valid, the sequencer node 320 generates a shared log storage address token; And the sequencer node 320 may further include transmitting the shared log storage address token to at least some of the plurality of smart contract execution nodes 310.

In the step where the sequencer node 320 verifies the validity of the commit record, validation between user transactions executed in parallel by a plurality of smart contract execution nodes 310 may be performed.

In the step of generating a shared log storage address token, a shared log address token containing a writable address in at least one shared log storage is generated, thereby establishing an agreement on the user transaction execution order among the plurality of smart contract execution nodes 310. Can be supported.

In the step where the sequencer node 320 verifies the validity of the commit record, the sequencer node 320 includes a key-version pair for each object and a read set in the commit record in the read set to verify the validity of the commit record. You can perform a multi-version conflict check (MVCC) that compares the version information of existing objects.

The user transaction processing method of the shared log-based blockchain network 300 according to an embodiment of the present invention includes the block generation node 330 including a user transaction commit record recorded in at least one shared log storage 341. Reading log data through the shared log interface 333; A block generation node 330 generating a new block compatible with existing blockchains using log data; And it may further include propagating the block. At this time, the block generation node 330 can deliver the new block to the outside of the shared log-based blockchain network 300.

In the step where the block generation node 330 creates a new block, the block generation node 330 creates blocks using the order already agreed upon during the sequential recording of user transactions related to log data and the execution of smart contracts. You can.

In the step where the at least one shared log storage 341 stores the commit record as a shared log, the at least one shared log storage 341 may store log data including the commit record as a plurality of attributes. At this time, the plurality of properties may include at least one of transaction type, client ID, transaction ID, Java program information, transfer parameters, and execution results.

FIG. 6 is an operation flowchart illustrating a process related to determining the order of creating a shared log and recording a user transaction in a shared log-based blockchain network according to an embodiment of the present invention.

When smart contract execution is completed in the smart contract execution module 312 of the smart contract execution unit node 310, a commit record can be created (S550). The smart contract execution module 312 may transmit the commit record to the sequencer node 320 and request issuance of a shared log token (S610). When the sequencer node 320 receives a shared log token issuance request from the smart contract execution module 312 (S610), it can check/verify MVCC (Multi-version conflict check) read conflicts for the read set in the commit record ( S620). In step S620, the sequencer node 320 has a key-version pair for each entity and can check/verify whether there is a conflict by comparing the key-version pair with the version information of the entities included in the read set. Once the object state conflict check for the read set is completed (S620), the sequencer node 320 may issue a shared log storage address token for the commit record (S630). If a conflict occurs, the transaction may be aborted without issuing a token. Through this process, the order in which the shared log 342 is created can be determined by the sequence node 320.

Finally, the smart contract execution module 312, which has received the token (S630), sends a request to record a commit record (S640) or a request to add a transaction log (S642) to the shared log location of the token to the shared log service execution unit. It can be sent to (340). The shared log service executing unit 340, which has received the request (S640, S642), can record a commit record at the address location written on the token (S570) or record an added transaction log (S572) without a separate verification process. When the commit record or additional transaction log is completed (S570, S572), the commit record record is completed (S650) or the transaction log is added (S652) from the shared log service execution unit 340 to the smart contract execution node 310. The response indicated may be delivered. According to an embodiment of the present invention, the order in which the shared log 342 is created, which is determined by the sequence node 320 through this process, is the recording order of adding the commit record, shared log 342, and transaction log. In addition to affecting, it may also affect the execution order of the smart contract 315 and the processing order of user transactions.

FIG. 7 is a conceptual diagram illustrating a portion of a user transaction processing method performed around the smart contract execution node 310 of the shared log-based blockchain network system 300 according to an embodiment of the present invention.

The service user 100 may request/submit a transaction to the smart contract execution node 310 via the client SDK 200 (S510). In the smart contract execution node 310, the API gateway 311 may transmit a transaction request to the smart contract execution module 312 (S710). The smart contract execution module 312 can call the designated smart contract 315 and request execution of the smart contract 315 to execute a transaction in conjunction with the shared log service execution unit 340 (S720).

The process in which the execution of the smart contract 315 is performed in conjunction with the shared log service execution unit 340 is performed by the smart contract stub 313 through the shared log API 314 of the transaction or object related to the smart contract 315. This can be performed by requesting the state (S730), receiving the state of the object from the shared log storage 341, and responding with the state of the object to the smart contract stub 313 via the shared log API 314 (S732).

A read-write set may be created as a result of executing the smart contract 315. The read set may include all object state information referenced by the smart contract 315, and the write set may include all object state update information created during execution. You can. The smart contract 315 execution result may be transmitted to the smart contract execution module 312 (S740).

The smart contract execution module 312 may create a commit record containing transaction information and a read-write set and request a shared log token from the sequencer node 320 (S610). At this time, the commit record may be transmitted together to the sequencer node 320. When receiving a commit record, the sequencer node 320 can check whether an object included in the read set has been updated and issue/response a shared log storage address token to the smart contract execution module 312 that submitted it (S630). . The smart contract execution module 312 that receives the token can add a commit record to the address recorded in the token.

The process of adding a commit record to the address recorded in the token is that a log record is requested from the smart contract execution module 312 to the shared log API 314 (S750), and shared log storage is sent via the shared log API 314. When log recording is requested at (341) (S640) and the shared log (342) is successfully recorded/updated (S570, S572), the shared log storage (341) responds to the shared log API (314) that log recording is complete. (S650). At this time, step S640 may include step S642 of FIG. 6, and step S650 may include step S652 of FIG. 6.

When the smart contract execution module 312 responds that the log recording/addition has been completed by the shared log API 314 (S752), the smart contract execution module 312 recognizes that the log has been successfully recorded or added (updated). You can. When it is recognized that the log has been successfully recorded/added, the smart contract execution module 312 responds the transaction execution result to the API gateway 311 (S760), and the smart contract execution node 310 sends the API gateway 311. The transaction execution result can be returned to the service user 100 who requested the transaction (S762).

FIG. 8 is a conceptual diagram illustrating part of a process of a user transaction processing method performed around the block generator node 330.

After the transaction processing result is returned to the service user 100 (S762), the leader module 331 of the block generator 330 sends the transaction log added to the shared log service execution unit 340 through the shared log API 333. By making an inquiry request (S810, S820) and reading the log in response (S830, S840) via the shared log API (333), the data required for block creation can be extracted and converted into a transaction entry contained in the block. . The converted transaction entry may be transmitted to the block creation module 332 (S850). The block generation module 332 can generate a block by storing transactions in a block (S860).

Since the smart contract execution unit node 310 executes transactions in synchronization with the shared log service execution unit 340, the plurality of smart contract execution unit nodes 310 perform the same transaction for the objects stored in the shared log service execution unit 340. Status information can be shared. Accordingly, the smart contract execution node 310 can execute different transactions in parallel. This can ensure the scalability of the smart contract execution node 310, and can allow for faster commit decisions compared to existing blockchain systems because once a transaction is recorded in the log, it means it has been completed.

In contrast to the embodiment of the present invention, it is generally known that parallel distributed execution of transactions is difficult in the conventional permissioned/unpermissioned blockchain network system.

In contrast, in the embodiment of the present invention, the shared log 342 supports a lightweight consensus process instead of a complete blockchain, and can also provide transaction processing history, version history, etc., making commit decisions faster than existing blockchain systems. possible. Additionally, by determining the storage order of the shared log 342, the sequence node 320 can ensure that commit results are sequentially stored as the shared log 342 when processing parallel transactions.

Figure 9 is a block diagram illustrating a node or computing system in a generalized blockchain network according to an embodiment of the present invention. A node capable of performing at least part of the processes of FIGS. 1 to 8 according to an embodiment of the present invention may be implemented as a computing system.

In the embodiments of FIGS. 1 to 8 , although omitted in the drawings, a processor and a memory are electronically connected to each component, and the operation of each component can be controlled or managed by the processor.

At least some processes of the blockchain user transaction processing method according to an embodiment of the present invention may be executed by the computing system 1000 of FIG. 9.

Referring to FIG. 9, the computing system 1000 according to an embodiment of the present invention includes a processor 1100, a memory 1200, a communication interface 1300, a storage device 1400, an input interface 1500, and an output. It may be configured to include an interface 1600 and a bus 1700.

The computing system 1000 according to an embodiment of the present invention includes at least one processor 1100 and instructions instructing the at least one processor 1100 to perform at least one step. It may include a memory 1200 for storing. At least some steps of the method according to an embodiment of the present invention may be performed by the at least one processor 1100 loading instructions from the memory 1200 and executing them.

The processor 1100 may refer to a central processing unit (CPU), a graphics processing unit (GPU), or a dedicated processor on which methods according to embodiments of the present invention are performed.

Each of the memory 1200 and the storage device 1400 may be comprised of at least one of a volatile storage medium and a non-volatile storage medium. For example, the memory 1200 may be comprised of at least one of read only memory (ROM) and random access memory (RAM).

Additionally, the computing system 1000 may include a communication interface 1300 that performs communication through a wireless network.

Additionally, the computing system 1000 may further include a storage device 1400, an input interface 1500, an output interface 1600, etc.

Additionally, each component included in the computing system 1000 may be connected by a bus 1700 and communicate with each other.

Examples of the computing system 1000 of the present invention include a communication capable desktop computer, laptop computer, laptop, smart phone, tablet PC, and mobile phone. (mobile phone), smart watch, smart glass, e-book reader, PMP (portable multimedia player), portable game console, navigation device, digital camera, DMB (digital) It may be a multimedia broadcasting player, digital audio recorder, digital audio player, digital video recorder, digital video player, PDA (Personal Digital Assistant), etc. .

The operation of the method according to the embodiment of the present invention can be implemented as a computer-readable program or code on a computer-readable recording medium. Computer-readable recording media include all types of recording devices that store information that can be read by a computer system. Additionally, computer-readable recording media can be distributed across networked computer systems so that computer-readable programs or codes can be stored and executed in a distributed manner.

Additionally, computer-readable recording media may include hardware devices specially configured to store and execute program instructions, such as ROM, RAM, flash memory, etc. Program instructions may include not only machine language code such as that created by a compiler, but also high-level language code that can be executed by a computer using an interpreter, etc.

Although some aspects of the invention have been described in the context of an apparatus, it may also refer to a corresponding method description, where a block or device corresponds to a method step or feature of a method step. Similarly, aspects described in the context of a method may also be represented by corresponding blocks or items or features of a corresponding device. Some or all of the method steps may be performed by (or using) a hardware device, such as a microprocessor, programmable computer, or electronic circuit, for example. In some embodiments, at least one or more of the most important method steps may be performed by such an apparatus.

In embodiments, a programmable logic device (e.g., a field programmable gate array) may be used to perform some or all of the functionality of the methods described herein. In embodiments, a field-programmable gate array may operate in conjunction with a microprocessor to perform one of the methods described herein. In general, the methods are preferably performed by some hardware device.

Although the present invention has been described with reference to preferred embodiments of the present invention, those skilled in the art may make various modifications and changes to the present invention without departing from the spirit and scope of the present invention as set forth in the claims below. You will understand that it is possible.

Claims (19)

A plurality of smart contract execution nodes that receive user transactions transmitted from service users through a client-side software interface that creates user transactions based on user information, and execute the user transactions. field; and
At least one shared log storage that receives a commit record generated as a result of execution of the user transaction executed by the plurality of smart contract execution nodes and stores the commit record as a shared log;
A shared log-based blockchain network system that includes. According to paragraph 1,
Each of the plurality of smart contract execution nodes processes user transactions assigned to each of the plurality of smart contract execution nodes in parallel,
A shared log-based blockchain network system. According to paragraph 1,
Receives the commit record from the plurality of smart contract execution nodes, verifies the validity of the commit record, and generates a shared log storage address token when the commit record is determined to be valid to the plurality of smart contract execution nodes. Sequencer node sending to;
Containing more,
A shared log-based blockchain network system. According to paragraph 3,
The sequencer node performs validation checks between user transactions executed in parallel by the plurality of smart contract execution nodes, and generates the shared log storage address token including a writable address in the at least one shared log storage. By doing so, it supports agreement on the order of user transaction execution between the plurality of smart contract execution nodes,
A shared log-based blockchain network system. According to paragraph 3,
The sequencer node compares the key-version pair for each entity with the read set in the commit record and the version information of the entities included in the read set to verify the validity of the commit record. Performing multi-version conflict check,
A shared log-based blockchain network system. According to paragraph 1,
a block generation node that reads log data including user transaction commit records recorded in the at least one shared log storage through a shared log interface and generates a block using the log data;
A shared log-based blockchain network system further comprising: According to clause 6,
When generating the block, the block generation node creates a new block compatible with existing blockchains and propagates the block.
A shared log-based blockchain network system. According to clause 6,
The block generation node generates the block using an order already agreed upon during sequential recording of user transactions related to the log data and smart contract execution.
A shared log-based blockchain network system. According to paragraph 1,
The plurality of smart contract execution nodes include a shared log interface,
Log data including the commit record generated by the plurality of smart contract execution nodes is transmitted to the at least one shared log storage via the shared log interface,
Log data including the commit record is stored in the at least one shared log storage,
A shared log-based blockchain network system. According to paragraph 1,
The plurality of smart contract execution nodes include a shared log interface,
The plurality of smart contract execution nodes read the latest log data from the at least one shared log storage via the shared log interface to obtain the latest status information necessary to create the commit record when executing the user transaction. Is,
A shared log-based blockchain network system. According to paragraph 1,
The at least one shared log storage stores log data including the commit record as a plurality of properties, and the plurality of properties include at least one of transaction type, client ID, transaction ID, Java program information, transfer parameters, and execution result. containing one or more,
A shared log-based blockchain network system. Transmitting a user transaction generated based on user information from a service user providing information necessary for creating a user transaction to at least some of a plurality of smart contract execution nodes via a client-side software interface;
At least some of the plurality of smart contract execution nodes executing the user transaction;
generating a commit record as a result of executing the user transaction by at least some of the plurality of smart contract execution nodes; and
at least one shared log storage storing the commit record as a shared log;
Including,
How to process user transactions in a shared log-based blockchain network. According to clause 12,
The step of transmitting the user transaction to at least some of the plurality of smart contract execution nodes
the client-side software interface assigning the plurality of user transactions to the plurality of smart contract execution nodes;
Including,
The step of executing the user transaction is
Each of the plurality of smart contract execution nodes parallelly processes the plurality of user transactions assigned to each of the plurality of smart contract execution nodes,
How to process user transactions in a shared log-based blockchain network. According to clause 12,
After the step of creating the commit record and before the step of storing the commit record as the shared log,
A sequencer node receiving the commit record from at least some of the plurality of smart contract execution nodes;
the sequencer node verifying the validity of the commit record;
generating, by the sequencer node, a shared log storage address token when the commit record is determined to be valid; and
the sequencer node transmitting the shared log storage address token to at least some of the plurality of smart contract execution nodes;
Containing more,
How to process user transactions in a shared log-based blockchain network. According to clause 14,
In the step where the sequencer node verifies the validity of the commit record,
Validation is performed between user transactions executed in parallel by the plurality of smart contract execution nodes,
In the step of generating the shared log storage address token,
By generating the shared log address token containing a writable address in the at least one shared log storage, agreement on the order of user transaction execution between the plurality of smart contract execution nodes is supported,
How to process user transactions in a shared log-based blockchain network. According to clause 14,
In the step where the sequencer node verifies the validity of the commit record,
The sequencer node compares the key-version pair for each entity with the read set in the commit record and the version information of the entities included in the read set to verify the validity of the commit record. Performing multi-version conflict check,
How to process user transactions in a shared log-based blockchain network. According to clause 12,
A block generation node reading log data including user transaction commit records recorded in the at least one shared log storage through a shared log interface;
The block generation node generating a new block compatible with existing blockchains using the log data; and
propagating the block;
Containing more,
How to process user transactions in a shared log-based blockchain network. According to clause 17,
In the step where the block generation node generates the new block,
The block generation node generates the block using an order already agreed upon during the sequential recording of user transactions related to the log data and smart contract execution,
How to process user transactions in a shared log-based blockchain network. According to clause 12,
In the step of the at least one shared log storage storing the commit record as a shared log,
The at least one shared log storage stores log data including the commit record as a plurality of properties, and the plurality of properties include at least one of transaction type, client ID, transaction ID, Java program information, transfer parameters, and execution result. containing one or more,
How to process user transactions in a shared log-based blockchain network.