WO2022010289A1 - Method for processing block data received in peer terminal in hyperledger fabric structure - Google Patents

Abstract

The present invention relates to a method for processing block data received in a peer terminal in a Hyperledger Fabric structure. The method for a peer terminal processing received block data, according to one embodiment of the present invention, comprises: a step in which first and second block data are received, and first and second payload blocks are stored in a buffer memory; a first temporary storage step in which a control unit decodes the first payload block and stores first decoding data associated with the first payload block in a cache memory; a first tasking step in which the first decoding data is read, and thus a task for the first block data is carried out; and a step in which the second payload block is decoded before the first tasking step ends, and second decoding data associated with the second payload block is stored in the cache memory, and the second decoding data is read after the first tasking step ends, and thus a task for the second block data is carried out, wherein a blockchain is stored in a storage unit, the blockchain having the first decoding data updated in the blockchain after the first tasking step ends, and, after the second tasking step ends, having the second decoding data updated by means of the second decoding data being connected to the blockchain.

Description

How to process block data received by peer terminals in Hyperledger Fabric architecture

The present invention relates to a method for processing block data received by a peer terminal in a Hyperledger Fabric architecture.

A block chain can be divided into a public block chain where anyone can participate in the network, and a private block chain where only authorized people can participate in the network.

Hyperledger Fabric has the form of a permissioned private blockchain, and unlike a public blockchain where anyone can freely participate, only users who have been downgraded by the authentication management system can participate in the blockchain network.

Therefore, Hyperledger Fabric can be more secure than other public blockchains, and nodes participating in the Hyperledger Fabric network can be seen as trusted nodes that have already been authorized by the system, and malicious malicious actors used in the public blockchain It does not require a complex consensus algorithm to verify the in-node, but it is sufficient to verify whether the user who wants to access the ledger is an authorized node, has such authority, and whether the transaction is properly structured.

In such a Hyperledger Fabric network structure, all nodes can share information with the same ledger stored in the form of a block chain, and it is also possible to create a separate ledger by creating a separate channel between nodes to be shared for business purposes. do.

Such a Hyperledger Fabric network may include a client terminal, a peer terminal, and an orderer terminal, and the peer terminals form each node of the network and are authenticated in the Hyperledger Fabric network, It may be a terminal that is allowed to participate.

The client terminal generates transaction information including the transaction details and transmits it to each peer terminal in the network. Each peer terminal generates signature information that authenticates the transaction information of the client terminal, and the client terminal receives each transaction information The signature information of the peer terminals may be combined and transmitted to the orderer terminal.

The orderer terminal may block a plurality of transaction information transmitted from the client terminal to generate block data, and transmit the generated block data to each peer terminal.

In each peer terminal, the block data transmitted from the orderer terminal can be committed and verified, and then stored in the storage unit in the form of a block chain.

An object of the present invention is to provide a method for processing block data received by a peer terminal in a Hyperledger Fabric architecture.

In a method for a peer terminal to process received block data according to an example of the present invention, at least one client terminal generating transaction information, generating signature information for authenticating transaction information, a communication unit, a buffer memory (buffer) memory), a cache memory, a storage unit and a control unit, and at least one of the transaction information and the signature information of the plurality of peer terminals to block the first and second block data. In a hyperledger fabric structure including a generating orderer terminal, in the plurality of peer terminals, the communication unit receives the first block data from the orderer terminal, a first receiving step of storing one payload block in the buffer memory; a second receiving step of the communication unit storing a second payload block of the second block data in the buffer memory; a first temporary storage step of the controller decoding a first payload block and storing first decoded data for the first payload block in the cache memory; a first tasking step in which the controller reads the first decoded data and performs at least one task on the first block data; a second temporary storage step in which the controller decodes the second payload block and stores second decoded data for the second payload block in the cache memory before the end of the first tasking step; and a second tasking step in which the controller reads the second decoded data and performs at least one task on the second block data after the end of the first tasking step, wherein the storage The block chain stores the block chain, and after the first tasking step is finished, the first decoded data is encoded and connected to the block chain and updated, and the block chain is updated when the second tasking step is completed After completion, the second decoded data is encoded and updated by being connected to the block chain.

At least one task for the first block data in the first tasking step includes a plurality of tasks including first and second tasks, and when the first task is performed in the first tasking step , the controller reads the first decoded data from the cache memory to perform the first task, and when performing the second task in the first tasking step, the controller is configured to perform the first decoding from the cache memory The second task may be performed by reading data.

At least one task for the first block data in the first tasking step includes a storage task, and when the storage task is performed, the first decoded data is marshaled and updated in the storage unit. can

The storage unit may be at least one of a solid state drive (SSD) and a hard disk drive (HDD).

Each of the first and second block data stored in the buffer memory may have a data type of a protocol buffer (Protobuf) type.

The at least one transaction information includes content about transaction information,

Before the first and second receiving steps,

receiving, by each of the plurality of peer terminals, an authentication request for each transaction information generated by at least one client terminal; and

The method may further include generating signature information for authenticating the received transaction information and transmitting the generated signature information to the at least one client terminal.

After the authentication information transmission step, the at least one client terminal combines a plurality of signature information transmitted from the plurality of peer terminals with respect to each of the transaction information and transmits the combination to the orderer terminal. ; may be further included.

After the orderer transmitting step and before the first and second receiving steps, the orderer terminal orders each transaction information in which the plurality of signature information transmitted from the at least one client terminal are combined to obtain the first block data creating a; and transmitting the first block data to the plurality of peer terminals.

In a peer terminal having a hyperledger fabric structure according to an example of the present invention, at least one transaction information transmitted from an orderer terminal and a plurality of signature information for authenticating each of the at least one transaction information are blocked first and second a communication unit for receiving block data; a buffer memory for storing first and second payload blocks of the received first and second blocks of data, respectively; a cache memory for temporarily storing first and second decoded data obtained by decoding the first and second payload blocks; and a controller for decoding the first and second payload blocks to convert the first and second decoded data into the first and second decoded data, and reading the first and second decoded data to perform at least one task on the first and second block data; wherein the control unit decodes the first payload block and stores the first decoded data for the first payload block in a cache memory, and then reads the first decoded data, A first tasking step of performing at least one task on the first block data is performed, and before the end of the first tasking step, by decoding the second payload block, the second payload Storing second decoded data for a block in the cache memory, and reading the second decoded data after completion of the first tasking step to perform at least one task on the second block data .

The storage unit further includes a storage unit storing a block chain, wherein after at least one task for the first block data is completed, the first decoded data is connected to the block chain of the storage unit is updated, and after at least one task for the second block data is completed, the second decoded data may be connected to the block chain of the storage unit and updated.

The at least one task for the first block data includes a plurality of tasks including first and second tasks, and when the controller performs the first task, the first task is performed by reading the cache memory and, when performing the second task, the second task may be performed by reading the cache memory.

The controller may unmarshal the first and second payload blocks stored in the buffer memory and store the first and second decoded data in the cache memory.

The control unit may marshal each of the first and second decoded data and connect them to the block chain of the storage unit to update them.

The storage unit may be at least one of a solid state drive (SSD) and a hard disk drive (HDD).

Each of the first and second block data stored in the buffer memory may have a data type of a protocol buffer (Protobuf) type.

The at least one transaction information includes the transaction information, and the control unit authenticates the authentication request for the transaction information generated and received by the client terminal before the first and second block data are received. signature information can be generated and transmitted to the client terminal.

In the method for processing block data received from a peer terminal in a hyperledger fabric structure according to an example of the present invention, before the previous tasking step is completed, the control unit decodes the current payload block in advance and stores it in the cache memory, When performing a commit to verify the payload block of , it is possible to further simplify the processing step of the commit by utilizing the payload stored in the cache memory, and to further improve the processing speed of the peer terminal.

1 is a diagram for explaining an example of a terminal constituting a hyperledger fabric structure according to an example of the present invention.

FIG. 2 is a diagram for explaining information flow between the client terminal 200, the peer terminal 100, and the orderer terminal 300 shown in FIG. 1 .

FIG. 3 is a diagram for explaining an example of each peer terminal 100 in FIG. 2 .

4 is a method in which each peer terminal 100 receives block data from the orderer terminal 300 in FIG. 2 and then performs a commit to store the received block data in the storage unit 150. It is a figure for demonstrating an example.

Hereinafter, embodiments of the present invention will be described in detail with reference to the accompanying drawings. In describing the present invention, if it is determined that adding a detailed description of a technique or configuration already known in the field may make the gist of the present invention unclear, some of it will be omitted from the detailed description. In addition, the terms used in this specification are terms used to properly express embodiments of the present invention, which may vary according to a person or custom in the relevant field. Accordingly, definitions of these terms should be made based on the content throughout this specification.

The terminology used herein is for the purpose of referring to specific embodiments only, and is not intended to limit the invention. As used herein, the singular forms also include the plural forms unless the phrases clearly indicate the opposite. As used herein, the meaning of 'comprising' specifies a particular characteristic, region, integer, step, operation, element and/or component, and other specific characteristic, region, integer, step, operation, element, component, and/or group. It does not exclude the existence or addition of

Hereinafter, the present invention will be described with reference to the accompanying drawings.

1 is a diagram for explaining an example of a terminal constituting a hyperledger fabric structure according to an example of the present invention, and FIG. 2 is a client terminal 200, a peer terminal 100, and an orderer terminal ( 300) is a diagram for explaining the flow of information.

1, the terminals constituting the Hyperledger fabric architecture according to an example of the present invention are a client terminal 200, a peer terminal 100, and an orderer (Orderer). ) may include a terminal 300 . Such a client terminal 200, peer terminal 100, orderer terminal 300 may configure each node of the Hyperledger Fabric network.

The client terminal 200 is a node required to access the Hyperledger Fabric network, and may generate transaction information Tx including the contents of the transaction information. Although FIG. 1 illustrates a case in which there are a plurality of client terminals 200 as an example, there may be at least one client terminal 200 , and a case in which there is one client terminal 200 is also possible.

When a smart contract is installed or invoked, the client terminal 200 provides transaction information ( Tx) can be created.

In this way, the client terminal 200 may generate the transaction information Tx and transmit it to each of the plurality of peer terminals 100 . When the client terminal 200 receives signature information that authenticates the transaction information Tx from the plurality of peer terminals 100 , each transaction information Tx and signature information may be combined and transmitted to the orderer terminal 300 .

Each of the plurality of peer terminals 100 is the most basic node in the Hyperledger Fabric structure, has a ledger in the peer terminal 100, and may include a chaincode (smart contract).

Each of the plurality of peer terminals 100 can verify and propagate the received transaction information Tx, and when receiving block data in which the transaction information Tx is blocked from the orderer terminal 300, the peer terminal ( 100) can update the stored ledger in the form of a block chain. Thereafter, when the block chain is updated, the peer terminal 100 may transmit information indicating that the block chain is updated to the client terminal 200 .

Although one orderer terminal 300 is illustrated in FIG. 1 as an example, the orderer terminal 300 is not necessarily limited thereto, and there may be at least one orderer terminal 300 .

If there are a plurality of orderer terminals 300 , the plurality of orderer terminals 300 may operate as if one service node. For example, the orderer terminal 300 may be provided in the form of an ordering service node (OSN).

The orderer terminal 300 may generate block data in which the transaction information Tx is blocked by using the verified transaction information Tx. That is, the orderer terminal 300 may generate block data by sequencing a plurality of transaction information Tx transmitted from clients. In this way, the block data generated by the orderer terminal 300 may be transmitted to each of the plurality of peer terminals 100 and updated in the block chain provided in each peer terminal 100 .

An example of a method in which at least one client terminal 200, a plurality of peer terminals 100 and at least one orderer terminal 300 are operated in a Hyperledger fabric architecture according to an example of the present invention The explanation is as follows.

First, at least one client terminal 200 generates transaction information Tx (S1), transmits the generated transaction information Tx to a plurality of peer terminals 100 (S2), and includes the transaction information Tx. You can request certification.

When each of the plurality of peer terminals 100 receives an authentication request for each transaction information Tx generated by at least one client terminal 200 , the plurality of peer terminals 100 receive at least one client terminal 200 . Check and verify the transaction information (Tx) transmitted from the terminal 200, generate signature information for authenticating the received transaction information (Tx) (S3), and at least one client terminal 200 for the authentication request As a response, signature information may be transmitted (S4).

Accordingly, the client terminal 200 may receive as many signature information as the number of the plurality of peer terminals 100 for each transaction information Tx.

The client terminal 200 combines the plurality of signature information received from the plurality of peer terminals 100 with each transaction information Tx (S5), and records the transaction information Tx together with the plurality of signature information into at least one false message. Some may be transmitted to the terminal 300 (S6).

At least one orderer terminal 300 receives a plurality of signature information and transaction information Tx received from the client terminal 200, and receives a predetermined number of transaction information Tx from the client terminal 200. , it is possible to sort and order the received plurality of transaction information (Tx), and block the received plurality of transaction information (Tx) by an algorithm agreed upon on the network of the Hyperledger Fabric structure to generate block data (S7) have. The orderer terminal 300 may transmit the generated block data to each of the plurality of peer terminals 100 (S8).

When each of the plurality of peer terminals 100 receives block data from at least one orderer terminal 300 , it performs a commit of confirming and verifying the block data ( S9 ), and blocks in the peer terminal 100 . The block chain can be updated by connecting to a ledger that is stored in the form of a chain, and the update of the block chain can be transmitted to the client terminal 200 .

In addition, thereafter, when a request for block data is received from the client terminal 200 ( S11 ), each of the plurality of peer terminals 100 may transmit the block data to the client terminal 200 ( S12 ).

Meanwhile, in the present invention, each of the plurality of peer terminals 100 performs a pre-processing step on the block data received from the orderer terminal 300 in advance and stores it in the cache memory, and then uses the block data stored in the cache memory to Commit can be performed.

This will be described in more detail with reference to FIGS. 3 and 4 below.

3 is a diagram for explaining an example of each peer terminal 100 in FIG. 2 , and FIG. 4 is a block data received after each peer terminal 100 receives block data from the orderer terminal 300 in FIG. 2 . It is a diagram for explaining an example of a method of performing a commit to store block data in the storage unit 150 .

As shown in FIG. 3 , each of the plurality of peer terminals 100 according to an example of the present invention includes a communication unit 110 , a control unit 120 , a buffer memory 130 , and a cache memory 140 . and a storage unit 150 .

The communication unit 110 may communicate with the client terminal 200 , the orderer terminal 300 , and other peer terminals 100 . Such a communication unit 110 may receive the transaction information (Tx) from the client terminal 200, and block data in which at least one transaction information (Tx) and a plurality of signature information are blocked from the orderer terminal 300 . If the ledger stored in the form of a block chain in the storage unit 150 of the peer is updated, the update event may be transmitted to the client terminal 200 .

The controller 120 may include an endor 121 and a committer 123 .

The endor 121 may generate signature information for each transaction information Tx by checking and authenticating each transaction information Tx generated in the client terminal 200 . For example, the endor 121 determines whether a transaction is appropriate through chain code simulation for each transaction information (Tx) transmitted from the client terminal 200, and when it is determined as a normal transaction, the corresponding transaction information (Tx) It is possible to generate signature information for authenticating the , and transmit it to the client terminal 200 through the communication unit 110 .

The committer 123 verifies the block data received from the orderer terminal 300, performs a plurality of tasks for determining validity, performs a commit, and when it is determined as valid block data , the block data may be updated by chaining the ledger provided in the form of a block chain in the storage unit 150 .

In addition, the control unit 120 receives a request from the client terminal 200 for specific block data or specific transaction information (Tx), accesses the block chain stored in the storage unit 150, reads the block chain, and the client It can be controlled to transmit to the terminal.

The buffer memory 130 may store a payload block of block data received by the communication unit 110 from the client terminal 200 . For example, the orderer terminal 300 may transmit block data in a protocol buffer (protobuf) type, which is serialized data in order to increase the transmission speed of the block data, and the buffer memory 130 is a protocol buffer (protobuf) type. A payload block in which a header and metadata are excluded from block data may be stored in a protocol buffer type.

The cache memory 140 may temporarily store decoded data obtained by decoding a payload block of block data. For example, the payload block received in the buffer memory 130 may be decoded by being unmarshalled, and unmarshalted decoded data may be temporarily stored in the cache memory 140 .

The committer 123 may perform a plurality of tasks of confirming and verifying each of a plurality of transaction information Tx included in each block by using the decoded data stored in the cache memory 140 as described above. .

When the verification of the decoded data for each block data stored in the cache memory 140 is completed and the block chain is updated, the decoded data temporarily stored in the cache memory 140 may be deleted.

The storage unit 150 may be provided in the form of at least one of a solid state drive (SSD) and a hard disk drive (HDD), and a ledger may be stored in the storage unit 150 in the form of a block chain. Accordingly, when the verification task for the decoded data stored in the cache memory 140 is completed, the decoded data is encoded and chain-connected to the block chain, so that the block chain can be updated. Here, as an example, the decoded data stored in the cache memory 140 may be encoded by being marshaled, and the decoded data in the storage unit 150 is chain-connected to the block chain in the form of marshaled data and updated. can be

As shown in FIG. 4 , each peer terminal 100 receives block data BL from the orderer terminal 300 and then commits to store the received block data BL in the storage unit 150 . The method of performing (commit) may include first and second receiving steps (S110A, S110B), first and second temporary storage steps (S120A, S120B), and first and second tasking steps (S130A, S130B). .

For example, each of the plurality of peer terminals 100 may receive the first and second block data BL1 and BL2 from the orderer terminal 300 .

When each of the plurality of peer terminals 100 receives the first and second block data BL1 and BL2, the communication unit 110 of each of the plurality of peer terminals 100 performs the first receiving step S110A, the orderer terminal. The first payload block PLB1 of the first block data BL1 received from 300 is stored in the buffer memory 130, and the first payload block PLB1 received from the orderer terminal 300 in the second receiving step S110B The second payload block PLB2 of the two-block data BL2 may be stored in the buffer memory 130 .

Each of the first and second block data BL1 and BL2 stored in the buffer memory 130 in the first and second receiving steps S110A and S110B may have a protocol buffer type data type.

For example, the orderer terminal 300 may transmit the first and second block data BL1 and BL2 to each of the plurality of peer terminals 100 in the form of protocol buffer (Protobuf) type data, and each peer terminal 100 ), the first and second payload blocks PLB1 and PLB2, which are actual data of the first and second block data BL1 and BL2, are removed by removing the header and metadata from the protocol buffer type data form. It may be stored in the buffer memory 130 .

In the first temporary storage step S120A, the controller 120 decodes the first payload block PLB1 and stores the first decoded data DD1 for the first payload block PLB1 in the cache memory 140 . can

The first temporary storage step S120A is not limited to storing the first decoded data DD1 from which the first payload block PLB1 is decoded in the cache memory 140 , but the first payload block It is also possible that (PLB1) is lightly encoded and stored in the cache memory 140 . In this case, the encoded level of the first payload block PLB1 stored in the cache memory 140 is the encoded level when the first payload block PLB1 is stored in the storage unit 150 in the form of a block chain. This first temporary storage step S120A may be a pre-processing process for the committer 123 to commit the first block data BL1, for example. , the first payload block PLB1 may be decoded by the controller 120 unmarshalling the first payload block PLB1 in the first temporary storage step S120A. However, the present invention is not necessarily limited to Unmarshal.

The first tasking step S130A may be performed after the decoding operation on the first payload block PLB1 in the cache memory 140 is completed, and in the first tasking step S130A, the controller 120 controls the cache At least one task on the first block data BL1 may be performed by reading the first decoded data DD1 stored in the memory 140 .

For example, at least one task for the first block data BL1 in the first tasking step S130A may include a plurality of tasks including first and second tasks Task 1 and Task2. . For example, the first and second tasks Task 1 and Task2 may include confirmation and verification tasks for each transaction information Tx included in the first block data BL1 . Such a first tasking step (S130A) may be performed by the committer 123 included in the control unit 120 .

When performing the first task Task1 in the first tasking step S130A, the controller 120 reads the first decoded data DD1 from the cache memory 140 to perform the first task Task1, When performing the second task Task2 in the first tasking step S130A, the controller 120 reads the first decoded data DD1 from the cache memory 140 to perform the second task Task1 have.

As such, when the plurality of tasks Task1 to Task5 are performed in the first tasking step S130A, the committer 123 reads the first decoded data DD1 from the cache memory 140 and reads the plurality of tasks Task1 ~ Task5) can be performed.

In the first tasking step S130A, at least one task for the first block data BL1 may include a storage task, and when the storage task is performed, the first decoded data DD1 is Marshal. ) and may be updated in the storage unit 150 . Such a storage task may be the last task that the committer 123 performs on the first block data BL1.

Accordingly, when the first tasking step S130A is finished, the first block data B1 in which the first decoded data DD1 stored in the cache memory 140 is encoded is connected to the existing block chain and updated. can be

In the second temporary storage step S120B, before the end of the first tasking step S130A, the control unit 120 decodes the second payload block PLB2 to obtain the second payload block PLB2 The decoded data DD2 may be stored in the cache memory 140 .

The second temporary storage step S120B is not limited to storing the second decoded data DD2 from which the second payload block PLB2 is decoded in the cache memory 140 , but the second payload block It is also possible that (PLB2) is lightly encoded and stored in the cache memory 140 . In this case, the encoded level of the second payload block PLB2 stored in the cache memory 140 is the encoded level when the second payload block PLB2 is stored in the storage unit 150 in the form of a block chain. It may be at a lower level.

That is, the second temporary storage step S120B may be a pre-processing process for the committer 123 to commit the second block data BL2, and the first tasking step S130A It may be executed by the control unit 120 in the middle of the execution. Also in this second temporary storage step (S120B), the controller 120 unmarshals the second payload block PLB2, so that the second payload block PLB2 is decoded, and the decoded second decoded data DD2 may be stored in the cache memory 140 .

For example, in the first tasking step ( S130A ), in the middle of the committer 123 performing the first tasks ( Task1 ) to the fifth tests ( Task 5 ), the controller 120 controls the second temporary storage step ( S120B). ) to perform pre-processing of the second payload block PLB2 of the second block data BL2 to decode the second decoded data ( DD2) may be stored in the cache memory 140 .

Accordingly, the second temporary storage step S120B may be performed in advance before the plurality of tasks Task1 to Task5 of the first tasking step S130A ends.

In the second tasking step S130B, the controller 120 sequentially reads the second decoded data DD2 stored in the cache memory 140 after the end of the first tasking step S130A, and the second block data ( At least one task for BL2) may be performed. 4 illustrates an example in which three tasks (Task1 to Task3) are performed in the second tasking step (S130B).

When the second tasking step S130B is finished, the second block data B2 in which the second decoded data DD2 is encoded is connected to the block chain including the first block data B1 and is in an updated state. have.

As described above, according to the present invention, whenever the committer 123 performs each of a plurality of tasks to perform a commit, the payload data is decoded from the buffer memory 130 and stored in the cache memory 140 each time (Pre-processing). -processing) process is not performed, but the entire payload block to be committed is decoded and stored in the cache memory 140 in advance and all pre-processing processes are performed in advance. By performing a plurality of tasks using the decoded data stored in 140), when the committer 123 performs a plurality of tasks of confirming or verifying the block data, there is no need to decode the payload block each time, so that the peer terminal The processing speed of (100) can be improved more.

The technical features disclosed in each embodiment of the present invention are not limited only to the embodiment, and unless they are mutually incompatible, the technical features disclosed in each embodiment may be combined and applied to different embodiments.

Accordingly, in each embodiment, each technical feature will be mainly described, but unless the technical features are incompatible with each other, they may be merged and applied.

The present invention is not limited to the above-described embodiments and the accompanying drawings, and various modifications and variations will be possible from the point of view of those of ordinary skill in the art to which the present invention pertains. Accordingly, the scope of the present invention should be defined not only by the claims of the present specification, but also by those claims and their equivalents.

Claims (16)

At least one client terminal that generates transaction information, generates signature information for authenticating transaction information, and includes a communication unit, a buffer memory, a cache memory, a storage unit, and a control unit. The peer terminal in a hyperledger fabric structure including a peer terminal and an orderer terminal for generating first and second block data by blocking the at least one piece of transaction information and the signature information of the plurality of peer terminals In the method of processing the received block data, A first reception in which the communication unit receives the first block data from the orderer terminal in the plurality of peer terminals and stores a first payload block of the first block data in the buffer memory step; a second receiving step of the communication unit storing a second payload block of the second block data in the buffer memory; a first temporary storage step of the controller decoding a first payload block and storing first decoded data for the first payload block in the cache memory; a first tasking step in which the controller reads the first decoded data and performs at least one task on the first block data; a second temporary storage step in which the controller decodes the second payload block and stores second decoded data for the second payload block in the cache memory before the end of the first tasking step; and a second tasking step in which the controller reads the second decoded data after the end of the first tasking step and performs at least one task on the second block data; The storage unit stores the block chain, In the block chain, after the first tasking step is finished, the first decoded data is encoded and connected to the block chain and updated; In the block chain, after the second tasking step is finished, the second decoded data is encoded and connected to the block chain to be updated. A method of processing block data received by a peer terminal in a Hyperledger Fabric architecture. According to claim 1, At least one task for the first block data in the first tasking step includes a plurality of tasks including first and second tasks, When performing the first task in the first tasking step, the control unit reads the first decoded data from the cache memory and performs the first task, When performing the second task in the first tasking step, the controller reads the first decoded data from the cache memory to perform the second task A method of processing block data received by a peer terminal in a Hyperledger Fabric architecture. According to claim 1, At least one task for the first block data in the first tasking step includes a storage task, When the storage task is performed, the first decoded data is marshaled and updated in the storage unit. A method of processing block data received by a peer terminal in a Hyperledger Fabric architecture. According to claim 1, The storage unit is at least one of a solid state drive (SSD) and a hard disk drive (HDD). A method of processing block data received by a peer terminal in a Hyperledger Fabric architecture. According to claim 1, Each of the first and second block data stored in the buffer memory has a data type of a protocol buffer (Protobuf) type. A method of processing block data received by a peer terminal in a Hyperledger Fabric architecture. According to claim 1, The at least one transaction information includes content about transaction information, Before the first and second receiving steps, receiving, by each of the plurality of peer terminals, an authentication request for each transaction information generated by at least one client terminal; and Generating signature information for authenticating the received transaction information and transmitting it to the at least one client terminal A method of processing block data received by a peer terminal in a Hyperledger Fabric architecture. 7. The method of claim 6, After the authentication information transmission step, the at least one client terminal combines a plurality of signature information transmitted from the plurality of peer terminals with respect to each of the transaction information and transmits the combination to the orderer terminal. further containing ; A method of processing block data received by a peer terminal in a Hyperledger Fabric architecture. According to claim 1, After the orderer transmission step and before the first and second reception steps, generating, by the orderer terminal, the first block data by sequencing each transaction information in which the plurality of signature information transmitted from the at least one client terminal are combined; and Transmitting the first block data to the plurality of peer terminals; further comprising A method of processing block data received by a peer terminal in a Hyperledger Fabric architecture. a communication unit configured to receive first and second block data in which at least one piece of transaction information transmitted from an orderer terminal and a plurality of signature information for authenticating each of the at least one transaction information are blocked; a buffer memory for storing first and second payload blocks of the received first and second blocks of data, respectively; a cache memory for temporarily storing first and second decoded data obtained by decoding the first and second payload blocks; and a control unit that decodes the first and second payload blocks, converts them into the first and second decoded data, reads the first and second decoded data, and performs at least one task on the first and second block data; including, the control unit After decoding the first payload block and storing the first decoded data for the first payload block in a cache memory, the first decoded data is read, at least for the first block data Perform a first tasking step of performing one task, before the end of the first tasking step, decoding the second payload block, and storing second decoded data for the second payload block in the cache memory; After completion of the first tasking step, reading the second decoded data to perform at least one task on the second block data Peer terminals with Hyperledger Fabric architecture. 10. The method of claim 9, A storage unit in which the block chain is stored; further including, In the storage After at least one task for the first block data is finished, the first decoded data is connected to the block chain of the storage unit and updated; After at least one task for the second block data is finished, the second decoded data is connected to the block chain of the storage unit and updated Peer terminals with Hyperledger Fabric architecture. 11. The method of claim 10, The at least one task for the first block data includes a plurality of tasks including first and second tasks, the control unit When performing the first task, the first task is performed by reading the cache memory; When performing the second task, reading the cache memory to perform the second task Peer terminals with Hyperledger Fabric architecture. 11. The method of claim 10, the control unit unmarshalling the first and second payload blocks stored in the buffer memory and storing the first and second decoded data in the cache memory; Peer terminals with Hyperledger Fabric architecture. 11. The method of claim 10, The control unit Marshals each of the first and second decoded data and connects to the block chain of the storage unit to update Peer terminals with Hyperledger Fabric architecture. 11. The method of claim 10, The storage unit is at least one of a solid state drive (SSD) and a hard disk drive (HDD). Peer terminals with Hyperledger Fabric architecture. 10. The method of claim 9, Each of the first and second block data stored in the buffer memory has a data type of a protocol buffer (Protobuf) type. Peer terminals with Hyperledger Fabric architecture. 10. The method of claim 9, The at least one transaction information includes content about transaction information, Before the first and second block data is received, the control unit It generates and transmits signature information to the client terminal to authenticate the authentication request for the transaction information generated and received in the client terminal. Peer terminals with Hyperledger Fabric architecture.

Images