KR102294048B1 - Method and system for replicating blockchain application service - Google Patents

Abstract

Disclosed are a method for replicating a blockchain application service to recover a service state and a system thereof. According to one embodiment of the present invention, the method comprises the following steps: checking whether a value related to any one of a server state change, server state maintenance, and log record is included in a header of a user request when the user request related to a blockchain application service is received from a client; when the value is included, confirming that the user request satisfies a storage condition; reading a log size for the total number of stored log entries from a first key-value distributed repository connected to a reader server among key-value distributed repository connected to a plurality of servers executing block chain application services, respectively; calculating a storage location of the user request by using the log size; storing the user request in the first key-value distributed repository by associating the user request to the storage location as a log entry; and responding to the client by processing the user request stored in the first key-value distributed repository through the reader server.

Description

The replication execution method of the blockchain application service and the replication execution system of the blockchain application service

The present invention is related to the replication execution technique of the blockchain application service, and more specifically, it is related to the improvement of the safety of the blockchain service in a disaster situation through the continuous synchronization and recovery function between the replicated blockchain application services.

Blockchain technology started as a basic technology for electronic money such as Bitcoin, but now it is rapidly expanded to industries where data reliability is important, such as public institutions, finance, medicine, and administration.

On the other hand, when a service failure occurs due to the destruction of blockchain-based application services due to various disasters such as earthquakes, floods, and terrorism or hacking attacks, it is difficult to predict the side effects and it may cost a lot to recover.

However, until now, systematic research for the robust execution of blockchain application services and recovery of service failures has not been conducted.

Accordingly, there is an urgent need for a service replication technique to ensure the robust execution of blockchain application services so that continuous service can be provided even in the face of failures or defects.

An embodiment of the present invention is to perform continuous synchronization between replicated blockchain application services distributed and executed on a plurality of servers through a key-value distributed storage, thereby stably executing the blockchain application service even in a disaster situation. do.

The embodiment of the present invention manages service information in the block chain through a service registry designed using smart contracts of the Ethereum block chain, and provides a service access location and recovery request function, thereby providing a duplicated block chain application service It aims to ensure a more robust implementation of

In the method for executing replication of a blockchain application service according to an embodiment of the present invention, as a user request related to a blockchain application service is received from a client, in the header of the user request, the state of the server is changed, and the state of the server is maintained. and checking whether a value related to any one of the log records is included. If the value is included, confirming that the user request satisfies the storage condition; reading a log size for the total number of stored log entries from a first key-value distributed storage connected to a reader server among key-value distributed storages respectively connected to servers of calculating a storage location of a user request; storing the user request in the first key-value distributed repository by associating the user request with the storage location as a log entry; and storing the user request in the first key-value distributed repository. and responding to the client by processing the user request through the reader server.

In addition, the replication execution system of the block chain application service according to the embodiment of the present invention, as a user request related to the block chain application service is received from the client, in the header of the user request, the state of the server changes, the state of the server A judging unit that checks whether a value related to any one of maintenance and log records is included, and if the value is included, a determination unit that confirms that the user request satisfies the storage condition; reads the log size for the total number of stored log entries from the first key-value distributed storage connected to the reader server among the key-value distributed storages connected to the servers of a storage unit that calculates a storage location of may include a processing unit that processes the data through the reader server and responds to the client.

According to one embodiment of the present invention, the user request from the client is stored in the key-value distributed storage and then processed by the reader server, and when the reader server providing the current service is not running due to a disaster state, A new leader server is elected through a key-value distributed storage among multiple servers that are synchronizing status, and the new leader server continues the service. , even if all servers lose the service state, the service state can be restored by reading the log entry stored in the key-value distributed storage.

According to an embodiment of the present invention, using a service registry designed through a smart contract, a function to manage service information in a block chain, modify the access location of the service, or check the access location of the modified service By providing this, when the disaster state is restored and the service is resumed, the user request whose processing was interrupted can be continuously processed by the new leader server.

1 is a diagram illustrating a replication technique of a block chain application service in a system for executing replication of a block chain application service according to an embodiment of the present invention.
2 is a diagram showing the structure of a service registry in the replication execution system of the block chain application service according to an embodiment of the present invention.
FIG. 3 is a diagram illustrating a replication technique of a blockchain application service using the service registry shown in FIG. 2 .
4 is a diagram illustrating an environment in which the duplicated blockchain application service operates in the system for executing the replication of the blockchain application service according to an embodiment of the present invention.
5 is a block diagram showing the configuration of a replication execution system of a block chain application service according to an embodiment of the present invention.
6 to 9 are flowcharts illustrating a sequence of a method for executing replication of a block chain application service according to an embodiment of the present invention.

Hereinafter, embodiments will be described in detail with reference to the accompanying drawings. However, since various changes may be made to the embodiments, the scope of the patent application is not limited or limited by these embodiments. It should be understood that all modifications, equivalents and substitutes for the embodiments are included in the scope of the rights.

The terms used in the examples are used for description purposes only, and should not be construed as limiting. The singular expression includes the plural expression unless the context clearly dictates otherwise. In the present specification, terms such as “comprise” or “have” are intended to designate that a feature, number, step, operation, component, part, or combination thereof described in the specification exists, but one or more other features It should be understood that this does not preclude the existence or addition of 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 commonly understood by one of ordinary skill in the art to which the embodiment belongs. Terms such as those defined in commonly used dictionaries should be interpreted as having a meaning consistent with the meaning in the context of the related art, and should not be interpreted in an ideal or excessively formal meaning unless explicitly defined in the present application. does not

In addition, in the description with reference to the accompanying drawings, the same components are given the same reference numerals regardless of the reference numerals, and the overlapping description thereof will be omitted. In the description of the embodiment, if it is determined that a detailed description of a related known technology may unnecessarily obscure the gist of the embodiment, the detailed description thereof will be omitted.

The execution system of the blockchain application service according to the present invention can implement a service replication technique that can ensure the robust execution of the application service produced based on the blockchain.

According to this service replication technique, ETCD, a distributed storage using the Raft consensus protocol, can be used to replicate application services in a distributed environment. The necessary service registry can be designed using a smart contract that runs on the Ethereum blockchain.

Here, the service registry may perform a function of storing important information of a service and providing an access location of the service and a function of requesting a recovery.

Raft is a consensus algorithm for easily managing replication logs even in situations such as collision errors between server nodes participating in a distributed environment. Until a majority of nodes participating in the consensus group fail, server nodes belonging to the consensus group operate normally. It can be used to ensure that In the present invention, when a collision error occurs in a distributed environment by using Raft, which has the same performance as Paxos, which has been used to solve the consensus problem occurring in the existing distributed environment, but has the advantage of being simpler and easier to understand You can manage the replication log more efficiently.

ETCD is a Raft-based key-value distributed storage that can stably store data in a distributed system or system cluster. By using ETCD, which provides automatic TLS, more secure execution of blockchain application services replicated on each server can be ensured.

A smart contract is an executable code that is automatically executed according to conditions on a blockchain, out of the existing contract method that real people face. In the present invention, when designing a service registry, a smart contract executed on the Ethereum blockchain is used Therefore, it is easy to ensure integrity and prevent manipulation.

For example, if the user sends a transaction to use the deployed smart contract, the function can be provided according to the contents defined in the smart contract. Through the event function stored in the log format, functions can be performed safely and in various forms.

Here, the Ethereum block chain is a block chain platform designed to provide smart contract functions as a second-generation block chain. It has the advantage of being able to create decentralized applications in the form of

In the service replication technique proposed in the present invention, the blockchain application service is replicated in a distributed environment composed of at least three server nodes, and the replicated blockchain application service is executed in each server node, and the Raft consensus protocol is used. It can be connected to each ETCD.

As such, in this service replication technique, a strong leader is selected from among ETCDs to match the logs recorded in the ETCD connected to each server in a distributed environment where the blockchain application service runs on multiple servers, and the leader ETCD is created. As a standard, ETCDs in a distribution group can have the same logarithm.

In addition, in this service replication technique, a server connected to the ETCD elected as the leader is selected as a leader server that provides a service to the client, and before processing the user request from the client by the leader server, the user request is read as a leader. By storing as log entries in the ETCD connected to the server, it is possible to synchronize the state of the application service in each server to the latest state according to the log matching operation between each ETCD.

According to the present invention, a new leader server is selected through a key-value distributed storage among a plurality of servers that are synchronizing the status, and the new leader server continues the service, thereby coping with the copied server even in the event of a failure or defect. Even if the service is resumed with , or all servers lose the service state, the service state can be restored by reading the log entry stored in the key-value distributed storage. A block chain application service to which such a service replication technique is applied is shown in FIG. 1 .

1 is a diagram illustrating a replication technique of a block chain application service in a system for executing replication of a block chain application service according to an embodiment of the present invention.

Referring to FIG. 1, the system for executing the replication of the blockchain application service of the present invention configures a distributed group by installing a program (App) that replicates the blockchain application service on at least three server nodes (Node1, Node2, Node3). and ETCD (ETCD-A, ETCD-B, ETCD-C) for recording logs according to the execution of the App can be connected to each server node.

ETCD is a distributed storage that operates based on a consensus algorithm (Raft), and log matching of ETCD-B and ETCD-C can be performed based on ETCD-A, which is elected as a leader.

In each ETCD, a log entry (Request Log Entry) is stored in association with an index, and also, a log size related to the total number of stored log entries, and a recent processing related to the index of the most recently processed log entry An index (Latest Processed Index) and whether a stored user request (log entry) is processed (Response state) may also be stored.

As any one of these values is changed in ETCD-A, the leader, the remaining ETCDs also store (change) the values based on Raft, and an event notifying the change of values may occur internally in the ETCD. Accordingly, other servers (follow servers) other than the leader server may subscribe to the event and recognize the changed value.

The replication execution system of the blockchain application service selects the server node (Node1) connected to the leader ETCD-A as the leader server of the distributed group, and responds to the user request received from the client, the ETCD connected to the leader server -A can be saved as a new log entry (Request Log Entry). This allows user requests to be logged for log purposes.

In the replication execution system of the blockchain application service, when the total number of log entries in ETCD-A increases by one and the response state related to the index of the log entry is also created, the log size of ETCD-A ( Log Size) is increased by the increased number, and when the log size modification in the ETCD is completed, an update event of the log size occurs.

Accordingly, in the ETCD, user requests are copied to ETCD-B and ETCD-C by the Raft consensus algorithm, and the log size of ETCD-B and ETCD-C may be increased according to the copy.

Whenever the log size update event occurs, when the user request stored in ETCD-A is processed by the reader server, the replication execution system of the blockchain application service transmits the processing result to the client and triggers the user request processing completion event. By modifying the value of 0 (stored in the ETCD) of the response state, a processing completion event can be generated to another server node, and the latest processing index (Latest) that records the storage location (index) of the most recently processed request before the user request Processed Index) may be updated with a storage location (index) of the processed user request.

The server nodes (Node2, Node3) that have subscribed to the processing completion event for the user request process the user request stored in ETCD-B and ETCD-C, and update the latest processing index to the storage location of the user request, It can be synchronized with the reader server.

As described above, the present invention selects a new leader server from among the plurality of servers that are synchronizing the state through the key-value distributed storage and allows the new leader server to continue the service. Even if the service is continuously resumed or all servers lose the service state, the service state can be restored by reading the log entry stored in the key-value distributed storage.

The service replication scheme proposed in the present invention performs storage and state synchronization of user requests.

First, the storage of user request is the operation of the reader application service to store the user request of the blockchain application service in the ETCD. When the reader application service receives a user request, it suspends processing and response, and immediately stores the user request in the ETCD. The process for the reader application service to save the user request to the ETCD is the same.

(i) In order to perform a response to a user request in the synchronization operation, the unique identification value of the current reader application service is stored in the request sent by the user, and the request connection is stored in the connection pool to hold the response.

(ii) Serialize and compress user requests into a form that can be stored in ETCD.

(iii) Set the index of the Request Log Entry to store the user request (the value of the current log size + 1) and save the user request in the ETCD.

(iv) Response State indicating the stored user request processing state is stored with the index of the stored Request Log Entry as the key and code 0 indicating the unprocessed state as the value.

When the storage operation for the user request is completed by the reader application service, a log size update event occurs in the ETCD, and the reader application service detects this and processes the unprocessed user request in the ETCD. The process of processing a user request that is not processed by the reader application service is as follows.

(1) Read the Log Size value and the Latest processed index value of the reader application service in the ETCD.

(2) If the values of Latest processed index and Log Size are the same, the corresponding job is terminated. Otherwise, go to step 3).

(3) (Leaded Latest processed index value +1) is set as the current processing index in the application service, and the Request Log Entry corresponding to the current processing index is read

(4) If the requested Request Log Entry is for logging, go to (5). Otherwise, it processes the Request Log Entry and records the processing result in the Response state corresponding to the current index.

(5) The reader application service updates the value of the response state whose index is 0 to generate an event for the completion of user request processing in the ETCD.

(6) Modify the latest processed index value to the current processed index and proceed to step 2).

An update event for the completion of user request processing stored by the reader application service occurs, and the follower (except the leader) application services that detect this event perform a task to synchronize the status of the reader application service. The process of performing the processing is as follows.

(1) Read the Log Size value and the Latest processed index value of the reader application service in the ETCD.

(2) If the values of Latest processed index and Log Size are the same, the corresponding job is terminated. Otherwise, go to step 3).

(3) (Leaded Latest processed index value +1) is set as the current processing index in the application service, and the response state corresponding to the current processing index is read

(4) If the value of the read response state is 1, which is an integer value indicating successful processing by the reader application service, the process of (5) is performed. If not, go to step (6).

(5) Read the value of the request log entry corresponding to the current processing index and change the status of the corresponding application service.

(6) Modify the latest processed index value to the current processed index and proceed to step 2).

In addition, state synchronization is a task that synchronizes application services to keep up with the latest state when restarting or changing the reader server due to failure or failure, and the specific process is the same.

(i) When the log size update event occurs in the ETCD and the application service detects it or the application service restarts, the current log size value is read from the ETCD.

(ii) If synchronization is not currently being performed within the application service and the value of the Latest Processed Index of the application service is smaller than the value of the imported log size, the process of (1)~(9) is performed.

(1) The current Log Size value and the Latest Processed Index value are read to the corresponding application service.

(2) If the value of Latest processed Index is smaller than Log Size, perform the process of 3). If the two values are the same, the whole process is terminated.

(3) The value corresponding to (Value of the Latest processed Index+1) is set as the current processing index in the application service, and the Response state value of the corresponding index stored in the ETCD is read to the corresponding application service.

(4) If the user request in which the response state value read in (3) is stored is -1, an integer value indicating failure by the reader, or 9 indicating an unprocessed state, proceed to step (8).

(5) If the value of the response state read in (3) is an integer value 1 indicating that the stored user request has been successfully processed by the reader, the Request Log Entry corresponding to the current processing index is fetched from the ETCD and processed by the application service (8 ) to the process.

(6) If the value of the response state read in (3) is an integer value 0 corresponding to unprocessed, it is checked whether the state of the corresponding application service is the leader. If it is a leader, go to step (7), otherwise go to step (8).

(7) Modify all Response State values within the range of [Current Processing Index, Log Size] to 9 indicating simple log use within the ETCD,

After changing the value of the Latest processed index of the corresponding application service to the value of Log size, proceed to step 9).

(8) Update the Latest Processed Index value of the application service to the current index and return to the process of 2).

(9) Terminate the work.

In order to support the robust execution of the blockchain application service to which the service replication technique proposed in the present invention is applied, by designing a service registry using an Ethereum smart contract, the blockchain application service is stable even in hacking and various disaster situations in a distributed environment. can be made to run as The structure of a service registry designed with such an Ethereum smart contract is shown in FIG. 2 .

2 is a diagram showing the structure of a service registry in a system for executing replication of a block chain application service according to an embodiment of the present invention.

Referring to FIG. 2 , "register()" in the service registry is a function that allows the service manager to store important service information in the service registry.

The service information is stored in the form of a service struct, service ID (service id), access location (service current location), provider (company) name, service managers, managers contact), service state ( service state) and the like. This information is mapped to a unique service ID and key-value form, and is stored in a service list in which service information is stored in the service registry.

In addition, "Update_*()" in the service registry is a function that changes the information of the service that is already stored. do.

Functions in the service registry can only be used by a service administrator who has registered service information in the service registry, and a service replication technique using such a service registry is shown in FIG. 3 .

FIG. 3 is a diagram illustrating a replication technique of a blockchain application service using the service registry shown in FIG. 2 .

A user (Client) of the blockchain application service to which the service replication technique proposed in the present invention is applied can check the access location of the service even in a disaster state by using the service registry shown in FIG. 2 .

If this is described in detail with reference to FIG. 3, when the existing leader application service (Old leader) is stopped for reasons such as failure or defect, a new leader who will provide a service to the user among the remaining application services is elected and , the new reader application service modifies the access location of the corresponding service registered in the service registry of FIG. 2 to its own location.

When the modification of the access location of the service is completed, the service registry transmits a NewLocation event that notifies the service ID and location of the changed service access location to the service user.

The service user can check the new service access location through the event, and in the case of the service user who has not received the event, the new service access location can be obtained by using the getServiceLocation() function in the service registry.

If all application services fail or if the service is not continuously provided at the current service access location, the service user requests recovery of the failed service through the sendClaim() function that sends a recovery request to the service managers in FIG. can be transmitted.

When the sendClaim() function is executed in the service registry, a Claim event containing the service ID and current failed service access location information occurs. be able to

4 is a diagram illustrating an environment in which the duplicated blockchain application service operates in the system for executing the replication of the blockchain application service according to an embodiment of the present invention.

As shown in FIG. 4, the execution system of the blockchain application service of the present invention provides an ETCD to each node in a distributed environment composed of six independent nodes (N1 to N6), thereby applying an Ethereum blockchain application. Duplicate the service. As shown, the Ethereum blockchain can be a private chain consisting of 6 nodes.

At this time, the service registry deployed on the Ethereum blockchain can be used to provide a new service access location by sending a NewLocation event to the client.

According to the present invention, it is possible to successfully synchronize the status of all application services even in the event of a network failure, and to provide services again through the election of a new leader and the service registry even when the leader application service providing the service fails. , it can ensure the robust execution of blockchain application services.

In other words, the execution system of the blockchain application service according to the present invention proposes a service replication technique and a service registry to support the robust execution of the blockchain application service.

Specifically, the execution system of the blockchain application service uses the key-value distributed storage to duplicate and execute the blockchain application service, and service information even in a disaster situation using the service registry developed with the smart contract of the Ethereum blockchain management, useful information about services, and support for recovery request functions. In this way, even in the event of a service failure due to a failure or defect, information on a new node that can provide a service can be restored so that the service can be continuously provided.

In this specification, "blockchain application service" refers to a decentralized application service based on the smart contract of the second-generation blockchain Ethereum, and the framework for providing the Ethereum blockchain application service can be composed of a client and a server. .

Here, the client plays a role in providing information and interfaces for users to call and execute smart contracts on the blockchain, and the server serves to deliver the client to the user and provide services in the form of a conventional centralized server. do.

In this framework, the server is replicated using ETCD, a distributed storage operating based on Raft, to ensure more robust execution than the existing blockchain application service.

ETCD is an open source distributed key-value key-value distributed repository that can reliably store data in a distributed system or cluster of systems. Based on Raft, a consensus algorithm, a strong leader is elected and distributed Allow groups to have the same log.

Through the function provided above, data can be stored in the ETCD in the form of a key-value log entry, and the types of key-value entries stored in the ETCD in this system are: There are four key-value entries such as log size, response state, and latest processed indexes.

- Request log entry: A user request stored in the ETCD in the form of an index

- Log size: Total number of request log entries in ETCD

- Response state: processing result of Request log entry

- Latest processed indexes: A key-value list that records the index of the request log entry that each server recently processed.

Next, a function of subscribing to an event that occurs whenever the value of the Key-Value entry stored in the ETCD is changed can be used. For example, each server in this system subscribes to the update event of Response State with Log size and Key "RS/0".

In addition, a function to check the member status information constituting the ETCD can be used.

The running server elects a leader server to serve users and store user requests in the ETCD. At this time, the server continuously checks whether the status of the ETCD connected to itself is a leader through the function to check the status information of members provided by the ETCD, and if the status of the ETCD connected to the server is the leader, the server becomes the leader .

The replication execution system of the blockchain application service can ensure stable execution in preparation for disaster conditions by first storing the user request from the client in the key-value distributed storage and then processing it.

To this end, the replication execution system of the blockchain application service replicates the blockchain application service in a distributed environment using a key-value distributed storage that performs log matching, and uses a service registry designed using a smart contract. Thus, it is possible to modify the access location of the service or to check the access location of the modified service, so that even if the leader server is changed when the service is resumed, the blockchain application service can be provided stably.

In addition, when the service is resumed, the replication execution system of the blockchain application service is a key-value distributed storage system so that it can be determined whether there is an unprocessed user request due to a service failure among pre-stored user requests by logging into the key-value distributed storage. The log size (N) regarding the total number of log entries currently stored in . may be compared with the recent processing index (M) regarding the storage location of the recently processed user request.

If the log size and the recent processing index do not match (M<N), the replication execution system of the blockchain application service considers the user request stored in the next index (M+1) of the most recent processing index (M) as an unprocessed request. It is processed by extracting from the ETCD, and according to the processing, the recent processing index (M) may be increased by 1.

When the increased recent processing index matches the log size (M+1=N), the replication execution system of the blockchain application service can determine that the status of the leader server is up to date.

Therefore, according to the present invention, through continuous synchronization using ETCD, which is an example of a key-value distributed storage, the servers running the replicated application service can be restored to the latest state, so even if a disaster situation such as a network failure occurs, there is no side effect. service can be provided stably by minimizing

5 is a block diagram showing the configuration of a replication execution system of a block chain application service according to an embodiment of the present invention.

Referring to FIG. 5 , the replication execution system 500 of the block chain application service according to an embodiment of the present invention may include a determination unit 510 , a storage unit 520 , and a processing unit 530 . The replication execution system 500 of the block chain application service according to an embodiment of the present invention may be configured by adding a recognition unit 540 , a registration unit 550 , and an update unit 560 , respectively.

The determination unit 510 includes, in the header of the user request, a value associated with any one of server status change, server status maintenance, and log recording as a user request related to the block chain application service is received from the client. is checked, and if the value is included, it is confirmed that the user request satisfies the storage condition.

If none of the values is included, the determination unit 510 may determine that the user request does not satisfy the storage condition, and reject the processing of the user request by the reader server.

According to an embodiment, the replication execution system 500 of the blockchain application service further includes a recognition unit 540 and a registration unit 550 .

The recognition unit 540 reads a reader ID registered in the block chain 502 by the registration unit 550, and identifies a server identified by the reader ID, a plurality of servers 571 executing the block chain application service. , 572) as a representative leader server.

At this time, the determination unit 510 checks whether the server identified by the reader ID matches the server to which the user request is transmitted, and if not, the recognition unit 540 determines the server to which the user request is transmitted, It can be recognized as a new leader server representing a plurality of servers. In this case, the registration unit 550 may update the reader ID registered in the block chain 502 .

According to an embodiment, the recognition unit 540 recognizes the server to which the user request is transmitted as a leader server representing the plurality of servers, and the registration unit 550 may update the leader ID registered in the block chain. (Registration of a new leader server).

The storage unit 520 includes a first key-value distributed storage ( 581), read the log size in terms of the total number of stored log entries, use the log size to calculate the storage location of the user request, and associate the user request with the storage location as a log entry. It is stored in the first key-value distributed storage 581 .

According to an embodiment, the replication execution system 500 of the blockchain application service further includes an update unit 560 .

The update unit 560 increases the log size recorded in the first key-value distributed storage 581 as the user request is stored in the first key-value distributed storage 581, and the plurality of An update event notifying an increase in the log size is generated among the servers 571 and 572 except for the reader server.

The storage unit 520 copies the user request to a second key-value distributed storage 582 connected to a server that has detected the update event, and the first and second key-value distributed storage 581 and 582 ) can be matched.

The processing unit 530 processes the user request stored in the first key-value distributed storage 581 through the reader server, and responds to the client.

For example, the processing unit 530 may process the user request stored in the first key-value distributed storage 581 through the reader server according to the occurrence of the update event.

In addition, when the processing result of the user request is transmitted to the client, the processing unit 530 processes the user request copied to the second key-value distribution storage 582 through a server other than the reader server, State synchronization between the plurality of servers 571 and 572 may be performed.

According to an embodiment, the processing unit 530 may determine and switch the status of the reader server through the determination unit 510 so that the user request is processed by the reader server in the latest state.

Specifically, the determination unit 510 reads a recent processing index that records a storage location of a user request recently processed by the reader server, from the first key-value distribution storage, and the log size (N) is the latest processing index. If it is greater than the index (M), it is determined that the reader server is not up-to-date, and from the first key-value distributed storage, the user request stored after the latest processing index (M) is extracted, and the extracted user During the request, a user request that has not been processed by the reader server is converted to a log, or a user request that has not been processed by the reader server is reflected to the reader server, and the recent processing index is incremented by '1' , when the increased recent processing index coincides with the log size, it is possible to determine the reader server as the latest state.

As described above, according to the present invention, the user request from the client is stored in the key-value distributed storage and then processed by the reader server, and when the reader server providing the current service is not running due to a disaster state, the status is synchronized A new leader server is selected from among the plurality of servers in operation through the key-value distributed storage, and the new leader server continues the service, so that even in the event of a failure or defect, the copied server responds to a duplicate server and resumes service continuously, or all servers Even if the service state is lost, the service state can be restored by reading the log entry stored in the key-value distributed storage.

Hereinafter, the workflow of the replication execution system 500 of the block chain application service according to embodiments of the present invention will be described in detail with reference to FIGS. 6 to 10 .

6 to 10 are flowcharts illustrating a sequence of a method for executing replication of a block chain application service according to an embodiment of the present invention.

The replication execution method of the block chain application service according to the present embodiments may be performed by the above-described block chain application service replication execution system 500 .

In FIG. 6, the user request received from the client is stored in the distributed storage (ETCD) before processing by the reader server, the storage location (N+1) of the user request, and the log size (N) of the distributed storage (ETCD) ), an example of calculating using ) is shown.

In this embodiment, once received user requests are logged and stored sequentially in a distributed storage, and then processed by the reader server, stable provision of blockchain application services becomes possible.

When the processing of a user request fails and the service is resumed, the unprocessed user request can be stored for a simple log in the new reader server (set the value of the latests processed index related to the index of the user request to 9 [for log ]).

Referring to FIG. 6 , in steps 610 to 620, the block chain application service replication execution system 500 receives a user request related to the block chain application service from the client, and the user request satisfies the storage condition. make sure you do

If the storage condition is satisfied, the block chain application service replication execution system 500 in steps 630 to 640 logs the total number of stored log entries from the first key-value distributed storage connected to the reader server. Read the size (N), use the log size to calculate a storage location (N+1) of the log entry to be added to the first key-value distributed storage, and send the user request to the log entry to be added. is stored in the first key-value distributed storage in association with the storage location (N+1) as .

In steps 650 to 660, the block chain application service replication execution system 500 processes the user request stored in the first key-value distributed storage through the reader server, and responds to the client.

In FIG. 7 , when hacking or a disaster occurs while processing a user request, when the reader server that provides the current service fails due to a disaster, when the service is resumed by a new reader service, the existing reader from the distributed storage An embodiment is shown in which the status of the current reader is reflected by using the user request processed by , and the status of the unprocessed user request is converted to a log so that the reader is updated.

To this end, in this embodiment, the reader server processes all user requests stored in the distributed storage (ETCD) by comparing the storage location (recent processing index) of the recently processed user requests and the log size (N) of the distributed storage (ETCD). You can check if it is up-to-date, and if it is not, you can change and maintain it up-to-date by processing unprocessed user requests in the distributed storage (ETCD).

Referring to FIG. 7 , in step 710 , it is checked whether a failure of the reader server currently providing a service occurs due to a disaster.

As a result of the check in step 710, if there is no failure, the replication execution system 500 of the block chain application service moves to step 660 of FIG. 6 and transmits the processing result to the client.

Or, if it fails as a result of the check in step 710, the replication execution system 500 of the block chain application service in steps 720 to 730 according to the resume command, the latest processing index (M) and log in the leader server Read the size (N) and compare the two. The replication execution system 500 of the blockchain application service compares whether the recent processing index (M) is smaller than the log size (N).

As a result of the check in step 730, if the recent processing index (M) is smaller than the log size (N), the replication execution system 500 of the block chain application service in steps 740 to 750 indicates that the reader server is up-to-date. is not determined, extracts the user request stored in the index [M+1] from the ETCD of the reader server, and checks whether the extracted user request is in an unprocessed state.

If the unprocessed state is confirmed in step 750, the replication execution system 500 of the block chain application service in steps 760 and 780 changes the state of the unprocessed user request to log, and the latest processing index (M) ) is increased by '1'.

Alternatively, if it is confirmed that it is not in the unprocessed state in the step 750, the replication execution system 500 of the block chain application service in the steps 770 and 780 reflects the processed user request to the status of the current leader server, The recent processing index (M) is increased by '1'.

The replication execution system 500 of the blockchain application service moves back to step 730 and checks whether the recent processing index (M) increased in step 780 is still smaller than the log size (N).

As a result of checking in step 730, if the increased recent processing index M is still smaller than the log size N, the block chain application service replication execution system 500 performs steps 740 to 780 again. do.

Or, as a result of checking in step 730, if the increased recent processing index (M) matches the log size (N), the replication execution system 500 of the blockchain application service moves to step 790, The reader server is judged to be up-to-date.

Thereafter, the replication execution system 500 of the blockchain application service moves to the starting stage of FIG. 6 .

In FIG. 8, as a user request is stored in a distributed storage (ETCD) connected to the reader server, the log size is updated through an update event, and as the user request is processed by the reader server, the status of the reader server is changed. As a reminder, an embodiment of performing log matching between distributed repositories and state synchronization between servers is shown.

As such, in this embodiment, periodic state synchronization using a distributed storage (ETCD) that performs log matching is performed, so that distributed servers that replicate block chain application services can always be maintained and restored in the latest state, It is possible to provide stable service even in a disaster situation.

Referring to FIG. 8 , as the user request is stored in the first ETCD connected to the reader server in step 640 of FIG. 6 , the user request is connected to the follow server according to the Raft algorithm in the ETCD in step 810 . It is copied to the second ETCD. This step may represent a process in which a log matching operation is automatically performed internally in the ETCD based on a log entry in the first ETCD, which is the leader.

In step 820, the block chain application service replication execution system 500 increases the total number of log entries of each of the first ETCD and the second ETCD by one according to the storage and copying of the user request, the ETCD log Update the size from N to N+1.

In step 830, the replication execution system 500 of the blockchain application service notifies the follow server of the updated log size value (N+1) through the occurrence of an update event.

In step 840, the replication execution system 500 of the block chain application service checks whether the user request is processed by the reader server, that is, whether the result of processing the user request is responded to the client.

If it is confirmed that the user request has been processed in step 840, the replication execution system 500 of the block chain application service in steps 850 to 860 processes the copied user request also through the follow server to obtain the latest version of the leader server. Synchronize with the state, and increase the recent processing index (M) in the follow server by '1'.

As described above, according to the present invention, by periodically synchronizing the status of the follow server to follow the status of the leader server, it is possible to keep the follow server up to date like the leader server.

FIG. 9 is a detailed diagram of an embodiment of confirming whether a user request received from a client satisfies a predetermined storage condition in step 620 of FIG. 6 .

In this embodiment, by selecting the storage condition of the user request that the server receiving the user request is a leader server, any one of 'Stateful', 'Stateless' and 'Successful_TX' is present in the header of the received user request. , user requests related to server state changes, server state maintenance, or log records are stored in the distributed storage (ETCD), and user requests not related to these are processed immediately without storing in the distributed storage (ETCD). .

As described above, according to this embodiment, user requests with high importance affecting data reliability of blockchain application services are selectively stored, thereby preventing the distributed storage (ETCD) from growing defenselessly.

Referring to FIG. 9 , in step 910 , when a user request is received from a client, the block chain application service replication execution system 500 extracts a header from the user request.

In steps 920 to 940, the replication execution system 500 of the blockchain application service, in the extracted header, a value related to the server's state change ('Stateful'), a value related to maintaining the server's state ('Stateless'), and If any one of the log record value ('Successful_TX') and 'Successful_TX' is included, the process moves to step 630 of FIG. 6 to calculate the storage location of the user request.

If none of the values is in the header, in step 950 , the replication execution system 500 of the block chain application service rejects the processing of the user request by the reader server.

The method according to the embodiment may be implemented in the form of program instructions that can be executed through various computer means and recorded in a computer-readable medium. The computer-readable medium may include program instructions, data files, data structures, etc. alone or in combination. The program instructions recorded on the medium may be specially designed and configured for the embodiment, or may be known and available to those skilled in the art of computer software. Examples of the computer-readable recording medium include magnetic media such as hard disks, floppy disks and magnetic tapes, optical media such as CD-ROMs and DVDs, and magnetic such as floppy disks. - includes magneto-optical media, and hardware devices specially configured to store and carry out program instructions, such as ROM, RAM, flash memory, and the like. Examples of program instructions include not only machine language codes such as those generated by a compiler, but also high-level language codes that can be executed by a computer using an interpreter or the like. The hardware devices described above may be configured to operate as one or more software modules to perform the operations of the embodiments, and vice versa.

The software may comprise a computer program, code, instructions, or a combination of one or more thereof, which configures a processing device to operate as desired or is independently or collectively processed You can command the device. The software and/or data may be any kind of machine, component, physical device, virtual equipment, computer storage medium or device, to be interpreted by or to provide instructions or data to the processing device. , or may be permanently or temporarily embody in a transmitted signal wave. The software may be distributed over networked computer systems, and stored or executed in a distributed manner. Software and data may be stored in one or more computer-readable recording media.

As described above, although the embodiments have been described with reference to the limited drawings, those skilled in the art may apply various technical modifications and variations based on the above. For example, the described techniques are performed in a different order than the described method, and/or the described components of the system, structure, apparatus, circuit, etc. are combined or combined in a different form than the described method, or other components Or substituted or substituted by equivalents may achieve an appropriate result.

Therefore, other implementations, other embodiments, and equivalents to the claims are also within the scope of the following claims.

500: Replication execution system of blockchain application service
501: client
502: Blockchain
510: judgment unit
520: storage
530: processing unit
540: recognition unit
550: register
560: update
571, 572: server
581, 582: key-value distributed storage

Claims (15)

As a user request related to the blockchain application service is received from the client,
checking whether the header of the user request includes a value associated with any one of server status change, server status maintenance, and log recording;
if the value is included, confirming that the user request satisfies a storage condition;
The log size (N) for the total number of stored log entries is read from the first key-value distributed storage connected to the reader server among the key-value distributed storage connected to the plurality of servers running the blockchain application service. to do;
reading a recent processing index (M) in which a storage location of a user request recently processed by the reader server is recorded, from the first key-value distributed storage;
determining that the reader server is not up-to-date when the log size (N) is larger than the recent processing index (M);
extracting, from the first key-value distributed storage, a user request stored after the recent processing index (M);
Among the extracted user requests, a user request that has not been processed by the reader server is converted to a log, or a user request that has not been processed by the reader server is reflected to the reader server, and the latest processing index (M) incrementing by '1';
determining the reader server as the latest state when the increased recent processing index coincides with the log size (N);
As the leader server is determined to be up-to-date,
calculating a storage location of the user request by using the log size (N);
storing the user request in the first key-value distributed repository associating the user request to the storage location as a log entry; and
responding to the client by processing the user request stored in the first key-value distributed storage through the up-to-date reader server
A method for executing replication of blockchain application services, including According to claim 1,
As the user request is stored in the first key-value distributed storage,
increasing the log size recorded in the first key-value distributed storage;
generating an update event notifying an increase in the log size to a server other than the reader server among the plurality of servers; and
Copying the user request to a second key-value distributed storage connected to a server that has detected the update event, and performing a matching operation between the first and second key-value distributed storage
A replication execution method of the blockchain application service further comprising a. 3. The method of claim 2,
processing the user request stored in the first key-value distributed storage through the reader server according to the occurrence of the update event; and
When the processing result of the user request is transmitted to the client,
performing state synchronization between the plurality of servers by processing the user request copied to the second key-value distributed storage through a server other than the reader server
A replication execution method of the blockchain application service further comprising a. According to claim 1,
reading the leader ID registered in the block chain; and
Recognizing the server identified by the reader ID as a reader server representing the plurality of servers
A replication execution method of the blockchain application service further comprising a. According to claim 1,
recognizing the server to which the user request is transmitted as a reader server representing the plurality of servers; and
Steps to renew the leader ID registered in the blockchain
A replication execution method of the blockchain application service further comprising a. delete According to claim 1,
if the value is not included, confirming that the user request does not satisfy the storage condition; and
Rejecting the processing of the user request by the reader server
A replication execution method of the blockchain application service further comprising a. A computer-readable recording medium in which a program for executing the method of any one of claims 1 to 5 and 7 is recorded. As a user request related to the blockchain application service is received from the client, it is checked whether a value associated with any one of server status change, server status maintenance, and log record is included in the header of the user request, and the a determination unit that confirms that the user request satisfies a storage condition if the value is included;
The log size (N) for the total number of stored log entries is read from the first key-value distributed storage connected to the reader server among the key-value distributed storage connected to the plurality of servers running the blockchain application service. a storage unit for calculating a storage location of the user request by using the log size (N) and storing the user request in the first key-value distributed storage by associating the user request with the storage location as a log entry; and
A processing unit responding to the client by processing the user request stored in the first key-value distributed storage through the reader server
including,
The judging unit,
Reading a recent processing index (M) recording a storage location of a user request recently processed by the reader server, from the first key-value distributed storage,
When the log size (N) is larger than the recent processing index (M), it is determined that the reader server is not up-to-date, and from the first key-value distribution storage, after the latest processing index (M) extract the user request stored in
Among the extracted user requests, a user request that has not been processed by the reader server is converted to a log, or a user request that has not been processed by the reader server is reflected to the reader server, and the latest processing index (M) Incremented by '1', and when the incremented latest processing index matches the log size (N), it is determined that the reader server is up-to-date;
As the leader server is determined to be up-to-date,
The storage unit,
associating the user request with a storage location of the user request calculated using the log size N, and storing it in the first key-value distributed storage as a log entry;
The processing unit,
processing the user request stored in the first key-value distributed storage through the up-to-date reader server
A replication execution system of blockchain application services. 10. The method of claim 9,
The replication execution system of the blockchain application service is,
As the user request is stored in the first key-value distributed storage,
An update unit that increases the log size recorded in the first key-value distributed storage and generates an update event for notifying an increase in the log size to a server other than the leader server among the plurality of servers
further comprising,
The storage unit,
Copying the user request to a second key-value distributed storage connected to a server that has detected the update event, and performing a matching operation between the first and second key-value distributed storage
A replication execution system of blockchain application services. 11. The method of claim 10,
The processing unit,
processing the user request stored in the first key-value distributed storage through the reader server according to the occurrence of the update event;
When the processing result of the user request is transmitted to the client,
Process the user request copied to the second key-value distributed storage through a server other than the reader server to perform state synchronization between the plurality of servers
A replication execution system of blockchain application services. 10. The method of claim 9,
The replication execution system of the blockchain application service is,
A recognition unit that reads a reader ID registered in the block chain by the registration unit, and recognizes a server identified by the reader ID as a leader server representing the plurality of servers
A replication execution system of the blockchain application service further comprising a. 10. The method of claim 9,
The replication execution system of the blockchain application service is,
A recognition unit that recognizes the server to which the user request is transmitted as a leader server representing the plurality of servers, and updates the leader ID registered in the block chain through the registration unit
A replication execution system of the blockchain application service further comprising a. delete 10. The method of claim 9,
The judging unit,
If the value is not included, confirming that the user request does not satisfy the storage condition, and rejecting the processing of the user request by the reader server
A replication execution system of blockchain application services.

Images