WO2022010297A1 - Procédé pour transmettre, par un terminal homologue, des données de bloc à un terminal client dans une structure hyperledger fabric - Google Patents

Procédé pour transmettre, par un terminal homologue, des données de bloc à un terminal client dans une structure hyperledger fabric Download PDF

Info

Publication number
WO2022010297A1
WO2022010297A1 PCT/KR2021/008762 KR2021008762W WO2022010297A1 WO 2022010297 A1 WO2022010297 A1 WO 2022010297A1 KR 2021008762 W KR2021008762 W KR 2021008762W WO 2022010297 A1 WO2022010297 A1 WO 2022010297A1
Authority
WO
WIPO (PCT)
Prior art keywords
block data
terminal
cache memory
stored
transmission
Prior art date
Application number
PCT/KR2021/008762
Other languages
English (en)
Korean (ko)
Inventor
김판종
박규남
Original Assignee
주식회사 미디움
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from KR1020200127064A external-priority patent/KR102392150B1/ko
Application filed by 주식회사 미디움 filed Critical 주식회사 미디움
Publication of WO2022010297A1 publication Critical patent/WO2022010297A1/fr

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02—Addressing or allocation; Relocation
    • G06F12/08—Addressing or allocation; Relocation in hierarchically structured memory systems, e.g. virtual memory systems
    • G06F12/0802—Addressing of a memory level in which the access to the desired data or data block requires associative addressing means, e.g. caches
    • G06F12/0806—Multiuser, multiprocessor or multiprocessing cache systems
    • G06F12/0842—Multiuser, multiprocessor or multiprocessing cache systems for multiprocessing or multitasking
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02—Addressing or allocation; Relocation
    • G06F12/08—Addressing or allocation; Relocation in hierarchically structured memory systems, e.g. virtual memory systems
    • G06F12/0802—Addressing of a memory level in which the access to the desired data or data block requires associative addressing means, e.g. caches
    • G06F12/0866—Addressing of a memory level in which the access to the desired data or data block requires associative addressing means, e.g. caches for peripheral storage systems, e.g. disk cache
    • G06F12/0868—Data transfer between cache memory and other subsystems, e.g. storage devices or host systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/22—Payment schemes or models
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof

Definitions

  • the present invention relates to a method for a peer terminal to transmit block data to a client 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.
  • 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.
  • 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.
  • 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 a peer terminal to transmit block data to a client terminal in a Hyperledger Fabric architecture.
  • the control unit transmits first block data from each of the first and second client terminals a request information storage step of storing first and second request information for ; an update step of receiving the first and second block data from the orderer terminal and storing the first and second block data in the storage unit in the form of the block chain; a first temporary storage step of reading the first block data from the storage unit and storing the first block data in the cache memory in response to the first and second request information; a first transmission step of reading the first block data from the cache memory, encoding the first block data into transmission data of a transmission type, and transmitting the first block data to the first client terminal; and a second transmission step of reading the first block data from the cache memory, encoding the first block data into the transmission data, and transmitting the first block data to the second client terminal.
  • the control unit stores the third information request information for the second block data from the third client terminal, and before the end of the second transmission step, in response to the third request information, the storage a second temporary storage step of reading second block data from the unit and storing the second block data in the cache memory; and a third transmission step of reading the second block data from the cache memory, encoding the second block data into transmission type transmission data, and transmitting the data to the third client terminal after the second transmission step is completed.
  • each of the first and second block data may be decoded and stored in the cache memory.
  • Each of the first and second block data stored in the cache memory may have a binary data form.
  • each of the first and second block data may be unmarshalted and stored in the cache memory.
  • each of the first and second block data may be encoded and stored in the cache memory.
  • the transmission data may have a protocol buffer type data type.
  • the first and second block data stored in the storage unit may be stored in a marshaled state.
  • the storage unit may be at least one of a solid state drive (SSD) and a hard disk drive (HDD).
  • SSD solid state drive
  • HDD hard disk drive
  • a peer terminal having a hyperledger fabric structure includes a request information storage module for storing first, second, and third request information for block data requested from each of first, second, and third client terminals; a storage unit in which the first and second block data are stored in the form of a block chain; a cache memory in which the first and second block data read from the storage unit are temporarily stored to transmit the first and second block data; a buffer memory in which the first and second block data stored in the cache memory are encoded and stored in an encoded transmission type transmission data form; and in response to the plurality of first, second, and third request information, read the storage unit, store the first and second block data in the cache memory, and transmit the first and second block data stored in the cache memory to a transmission type a control unit for converting and transmitting the transmission data of read the first block data, encode it into transmission data of a transmission type, transmit it to the first client terminal, read the first block data from the cache memory, encode the first block data into the transmission data, and control to transmit it to
  • the control unit controls to read the second block data from the storage unit and store it in the cache memory in response to the third request information; After the transmission of the first block data to the second client terminal is completed, the control unit reads the second block data from the cache memory, encodes the second block data into transmission type transmission data, and transmits it to the third client terminal. can be controlled
  • the storage unit may be at least one of a solid state drive (SSD) and a hard disk drive (HDD).
  • SSD solid state drive
  • HDD hard disk drive
  • a peer terminal to transmit block data to a client terminal in a hyperledger fabric structure according to an example of the present invention
  • the block data is stored in the cache memory in advance, and the transmission performance of the peer terminal can be further improved.
  • FIG. 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 .
  • 3 to 6 are diagrams for explaining an example of a method in which each peer terminal 100 receives block data from the orderer terminal 300 in FIG. 2 and then transmits block data requested from a plurality of client terminals to be.
  • FIG. 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 client terminal 200, a peer terminal 100, and an orderer terminal ( 300) is a diagram for explaining the flow of information.
  • the terminals constituting the Hyperledger fabric architecture are a client terminal 200, a peer terminal 100, and an orderer (Orderer). ) may include a terminal 300 .
  • the client terminal 200 , the peer terminal 100 , and the 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.
  • 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.
  • the client terminal 200 When a smart contract is installed or invoked, the client terminal 200 provides transaction information ( Tx) can be created.
  • the client terminal 200 may generate the transaction information Tx and transmit it to each of 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 .
  • 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 .
  • the plurality of orderer terminals 300 may operate as if one service node.
  • the orderer terminal 300 may be provided in the form of an ordering service node (OSN).
  • OSN ordering service node
  • 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 .
  • the plurality of client terminals 200 generate transaction information Tx (S1), and transmit the generated transaction information Tx to the plurality of peer terminals 100 (S2) for transaction information Tx. You can request authentication.
  • each of the plurality of peer terminals 100 receives an authentication request for each transaction information Tx generated by the plurality of client terminals 200 , the plurality of peer terminals 100 transmits the plurality of client terminals ( 200 ), by verifying and verifying the transmitted transaction information Tx, generating signature information for authenticating the received transaction information Tx ( S3 ), and responding to the authentication request of the plurality of client terminals 200 . ), it is possible to transmit the signature information (S4).
  • 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).
  • the client terminal 200 may request that the peer terminal 100 transmit block data received from the orderer terminal 300 to each peer terminal 100 .
  • 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).
  • each of the plurality of peer terminals 100 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 .
  • each of the plurality of peer terminals 100 may transmit (S12) newly updated block data in the block chain to each client terminal 200 to respond.
  • the corresponding block data is stored in the cache memory in advance. , it is possible to read the cache memory, convert it into a transmission type data form, and transmit it to each of the plurality of client terminals.
  • FIG. 3 to 6 show a method of transmitting block data requested from a plurality of client terminals 200a, 200b, and 200c after each peer terminal 100 receives block data from the orderer terminal 300 in FIG. 3 is a diagram for explaining an example of the peer terminal 100 according to an example of the present invention
  • FIG. 4 is a view for explaining an example of a plurality of client terminals 200a, 200b, and 200c of each peer terminal. This is an example for explaining the concept of requesting block data to (100), and each peer terminal 100 transmitting block data to a plurality of client terminals 200a, 200b, and 200c to respond.
  • An example in which block request storage information is stored in the request information storage module 160 of each peer terminal 100 when a plurality of client terminals 200a, 200b, and 200c requests block data from each peer terminal 100 6 is a diagram for explaining an example of a method in which each peer terminal 100 transmits block data stored in the block chain of the storage unit 150 to each client terminal 200a, 200b, and 200c to be.
  • each of a plurality of peer terminals 100 includes a communication unit 110 , a control unit 120 , a buffer memory 130 , and a cache memory 140 .
  • cache memory, 140 and may include a storage unit (150).
  • the communication unit 110 may communicate with the client terminals 200a , 200b , and 200c , the orderer terminal 300 , and other peer terminals 100 .
  • the communication unit 110 may receive the transaction information Tx from the client terminals 200a, 200b, and 200c, and at least one transaction information Tx and a plurality of signature information are blocked from the orderer terminal 300 .
  • block data can be received, and when the ledger stored in the block chain form in the storage unit 150 of the peer terminal 100 is updated, the control unit 120 sends an update event to the client terminals 200a and 200b , 200c).
  • the control unit 120 may serve to authenticate the transaction information generated by the client terminals 200a, 200b, and 200c, verify the block data received from the orderer terminal 300, and store it in the block chain, To this end, it may include an endorser (121) and a committer (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 terminals 200a, 200b, and 200c 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 .
  • 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. have. Block data stored in the block chain of the storage unit 150 may be stored in a marshaled state.
  • SSD solid state drive
  • HDD hard disk drive
  • control unit 120 accesses the block chain stored in the storage unit 150 and stores the block chain. It can be read and controlled to be transmitted to the client terminals 200a, 200b, and 200c.
  • the controller 120 reads the storage unit 150 and stores the block data in the cache memory 140 in response to the request information for the block data received from the client terminals 200a, 200b, and 200c, and caches the block data. It is possible to control block data stored in the memory 140 to be transmitted by converting it into transmission type transmission data.
  • each peer terminal 100 may receive a request for first block data from the first and second client terminals 200a, 200b, and 200c, and may receive a second block data request from the third client terminal. Data may be requested.
  • request information for block data requested from the plurality of client terminals 200a, 200b, and 200c may be stored in the request information storage module 160 .
  • the request information storage module 160 is provided in each peer terminal 100, and when each peer terminal 100 receives a request for block data, it transmits the block requested by each of the client terminals 200a, 200b, and 200c therein.
  • the request can be saved.
  • the request information storage module 160 provides the first and second client terminals 200a, The first block transmission request information of 200b) and the second block transmission request information of the third client terminal 200c may be stored.
  • the request information storage module 160 includes a RAM memory, a buffer memory (which may be a buffer memory different from a buffer memory in which block data is temporarily stored), a cache memory (block data) provided in each peer terminal 100 . may be a cache memory different from the cache memory in which it is temporarily stored) or the storage unit 150 .
  • the controller 120 may read block data stored in the block chain of the storage 150 and store it in the cache memory 140 according to the request information stored in the request information storage module 160 .
  • the cache memory 140 may temporarily store block data by the controller 120 in order to transmit the block data stored in the storage unit 150 to the client terminal 200 .
  • the block data temporarily stored in the cache memory 140 may be stored in a marshaled or unmarshalled state, and may be temporarily stored in the form of binary data.
  • the level of security is weaker than that of block data stored in a marshaled state in the storage unit 150 , but the level of security is higher than that of block data stored in the buffer memory 130 . It is also possible to be encoded and stored as a state.
  • block data stored in the cache memory 140 may be encoded and stored in the form of encoded transmission type transmission data. As described above, the block data stored in the transmission type transmission data form stored in the buffer memory 130 may be transmitted to each of the plurality of client terminals 200a, 200b, and 200c by the communication unit.
  • the transmission data type stored in the buffer memory 130 may have a protocol buffer type data type advantageous for transmission, different from the data type stored in the cache memory 140 .
  • the control unit 120 reads the storage unit 150 in response to the block data transmission request information for each client stored in the request information storage module 160 , stores the block data in the cache memory 140 , and stores the block data in the cache memory 140 .
  • the communication unit may control the transmission to the plurality of client terminals 200a, 200b, and 200c.
  • the controller 120 reads the corresponding block data from the storage 150 for each client terminal 200a and 200b each time and caches it. Rather than storing the block data stored in the memory 140 and converting the block data stored in the cache memory 140 into transmission data form and transmitting the same block data, the block data is read from the storage unit 150 only once for the same block data to be transmitted to the cache memory 140 . and may be transmitted to each of the client terminals 200a and 200b using the corresponding block data stored in the cache memory 140 .
  • the transmission performance of the peer terminal 100 can be further improved. This will be described with reference to FIG. 6 as follows.
  • the method in which the peer terminal 100 transmits block data stored in the storage unit 150 in the form of a block chain to the plurality of client terminals 200a, 200b, and 200c according to an example of the present invention includes a request information storage step (not shown) , update step (S10 in Fig. 2), first temporary storage step (S110A), first transmission step (S120A1), second temporary storage step (S110B), second transmission step (S120A2) and third transmission step (S120B1) ) may be included.
  • the first block data B1 transmitted from each of the first and second client terminals 200a and 200b , 2 request information 161, 162 may be stored. That is, when the block chain is updated to the peer terminal 100 in the plurality of client terminals 200a, 200b, and 200c, as in step S11 of FIG. 2 , the peer terminal 100 blocks information about the updated block data. Data can be requested in advance before updating to the blockchain.
  • the first and second client terminals 200a and 200b may request the first block data B1 and the third client terminal 200c may request the second block data B2 from the peer terminal 100 .
  • the first client terminal 200a may be the first client terminal 200a to transmit the first block data B1 among the plurality of client terminals 200a, 200b, and 200c
  • the second client terminal 200b It may be the last client terminal 200b to transmit the first block data B1 among the plurality of client terminals 200a, 200b, and 200c
  • the third client terminal 200c is the first client terminal 200c to transmit the second block data B2 after the transmission of the first block data B1 is completed among the plurality of client terminals 200a, 200b, and 200c.
  • the peer terminal 100 performs the first, second, 3
  • a transmission request for block data requested to be transmitted from the client terminals 200a, 200b, and 200c may be stored in the request information storage module 160 .
  • the first client terminal 200a receives information for requesting the first block data B1
  • the first request information 161 receives information for requesting the first block data B1
  • the second client terminal 200b receives information for requesting the first block data B1.
  • the second request information 162 and information that the third client terminal 200c requests the second block data B2 may be referred to as third request information 163 .
  • the peer terminal 100 receives the first and second block data B1 and B2 from the orderer terminal 300 and updates the storage unit 150 in the form of a block chain. Accordingly, the first and second block data B1 and B2 may be marshaled and stored in the storage unit 150 .
  • the control unit 120 first and second request information for the first block data B1 of the first and second client terminals 200a and 200b stored in the block fairy storage module According to steps 161 and 162 , the first block data B1 may be read from the storage 150 and stored in the cache memory 140 .
  • the first block data B1 stored in the cache memory 140 may be in a marshaled state or an unmarshalled state, and may be temporarily stored in the form of binary data.
  • the level of security is weaker than that of block data stored in a marshaled state in the storage unit 150 , but the level of security is higher than that of block data stored in the buffer memory 130 . It is also possible to be encoded and stored as a state.
  • the controller 120 reads the first block data B1 from the cache memory 140 and encodes the first block data B1 into transmission type transmission data, and the first block data PB1 in the transmission data form. may be controlled to be transmitted to the first client terminal 200a.
  • the controller 120 reads the first block data B1 from the cache memory 140 and encodes the first block data B1 into transmission type transmission data, and the first block data PB1 in the transmission data form. may be controlled to be transmitted to the second client terminal 200b.
  • the first block data B1 is converted into a protocol buffer (Protobuf) type data type, which is a transmission data type, and temporarily stored in the buffer memory 130 , and then the first and second block data B1 are temporarily stored in the buffer memory 130 It may be transmitted to a plurality of client terminals 200a to 200b including the client terminal.
  • a protocol buffer Protobuf
  • the controller 120 controls the first block data B1 after storing in the cache memory 140 , the plurality of client terminals 200a to 200b including the first and second client terminals 200a and 200b using the first block data B1 stored in the cache memory 140 . ), the block data transmission speed of the peer terminal 100 can be further improved.
  • the controller 120 controls the third client terminal 200c )
  • the third request information 163 for the second block data B2 may be stored in the request information storage module 160 as shown in FIG. 5 .
  • the control unit 120 in response to the third request information 163, the storage unit ( A second temporary storage step S110B of reading the second block data B2 from 150 , and storing the second block data B2 in the cache memory 140 may be performed.
  • the third transmission step S120B1 reads the second block data B2 from the cache memory 140 after the end of the second transmission step S120A2 to transmit data of a transmission type, for example, a protocol buffer ( Protobuf) type data may be encoded, and the second block data PB2 in the form of transmission data may be transmitted to the third client terminal 200c.
  • a transmission type for example, a protocol buffer ( Protobuf) type data may be encoded, and the second block data PB2 in the form of transmission data may be transmitted to the third client terminal 200c.
  • the control unit 120 controls the second block from the storage unit 150 .
  • the data B2 is read and stored in the cache memory 140 in advance, and after the second transmission step S120A2 is finished, the third transmission step S120B1 is performed, thereby improving the transmission performance of the peer terminal 100 can be improved
  • each technical feature will be mainly described, but unless the technical features are incompatible with each other, they may be merged and applied.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Business, Economics & Management (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • Accounting & Taxation (AREA)
  • General Business, Economics & Management (AREA)
  • Strategic Management (AREA)
  • Finance (AREA)
  • Human Computer Interaction (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

La présente invention concerne un procédé pour transmettre, par un terminal homologue, des données de bloc à un terminal client dans une structure Hyperledger Fabric. Selon un exemple de la présente invention, le procédé de transmission, à une pluralité de terminaux clients, des données de bloc stockées dans un terminal homologue dans une structure Hyperledger Fabric comprend : une étape de stockage d'informations de requête consistant à stocker, par une unité de commande dans le terminal homologue, des premières et secondes informations de requête pour des premières données de bloc, transmises à partir de chacun des premier et second terminaux clients ; une étape de mise à jour consistant à recevoir des premières et secondes données de bloc en provenance d'un terminal de commande, et à stocker, dans une unité de stockage, les premières et secondes données de bloc reçues sous la forme d'une chaîne de blocs ; une première étape de stockage temporaire consistant à lire les premières données de bloc à partir de l'unité de stockage et à stocker les premières données de bloc lues dans une mémoire cache, en réponse aux premières et secondes informations de requête ; une première étape de transmission consistant à lire les premières données de bloc à partir de la mémoire cache, à coder les premières données de bloc lues en données de transmission d'un type de transmission, et à transmettre les données de transmission codées au premier terminal client ; et une seconde étape de transmission consistant à lire les premières données de bloc à partir de la mémoire cache, à coder les premières données de bloc lues dans les données de transmission, et à transmettre les données de transmission codées au second terminal client.
PCT/KR2021/008762 2020-07-10 2021-07-09 Procédé pour transmettre, par un terminal homologue, des données de bloc à un terminal client dans une structure hyperledger fabric WO2022010297A1 (fr)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
KR10-2020-0085736 2020-07-10
KR20200085736 2020-07-10
KR10-2020-0127064 2020-09-29
KR1020200127064A KR102392150B1 (ko) 2020-07-10 2020-09-29 하이퍼레저 패브릭 구조에서 피어 단말기가 블록 데이터를 클라이언트 단말기로 전송하는 방법

Publications (1)

Publication Number Publication Date
WO2022010297A1 true WO2022010297A1 (fr) 2022-01-13

Family

ID=79553413

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/KR2021/008762 WO2022010297A1 (fr) 2020-07-10 2021-07-09 Procédé pour transmettre, par un terminal homologue, des données de bloc à un terminal client dans une structure hyperledger fabric

Country Status (1)

Country Link
WO (1) WO2022010297A1 (fr)

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20190128590A (ko) * 2018-05-08 2019-11-18 오라클 인터내셔날 코포레이션 블록체인 원장 외부의 애플리케이션과 블록체인 원장의 통합
US20190354397A1 (en) * 2018-05-15 2019-11-21 International Business Machines Corporation Prioritization in a permissioned blockchain
US20190363874A1 (en) * 2018-05-24 2019-11-28 Dapper Labs Inc. Decentralized computation system architecture based on node specialization
US20200174937A1 (en) * 2019-08-30 2020-06-04 Alibaba Group Holding Limited Deploying a smart contract
KR20200077366A (ko) * 2018-12-20 2020-06-30 공주대학교 산학협력단 허가형 블록체인 시스템 상에서의 프라이버시 보존형 데이터 분석 방법

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20190128590A (ko) * 2018-05-08 2019-11-18 오라클 인터내셔날 코포레이션 블록체인 원장 외부의 애플리케이션과 블록체인 원장의 통합
US20190354397A1 (en) * 2018-05-15 2019-11-21 International Business Machines Corporation Prioritization in a permissioned blockchain
US20190363874A1 (en) * 2018-05-24 2019-11-28 Dapper Labs Inc. Decentralized computation system architecture based on node specialization
KR20200077366A (ko) * 2018-12-20 2020-06-30 공주대학교 산학협력단 허가형 블록체인 시스템 상에서의 프라이버시 보존형 데이터 분석 방법
US20200174937A1 (en) * 2019-08-30 2020-06-04 Alibaba Group Holding Limited Deploying a smart contract

Similar Documents

Publication Publication Date Title
WO2018043865A2 (fr) Système de gestion/recherche de fichier reposant sur une chaîne de blocs et procédé de gestion/recherche de fichier
WO2018155822A1 (fr) Procédé pour fournir un service d'enregistrement de compte simplifié et service d'authentification d'utilisateur, et serveur d'authentification l'utilisant
CN100461686C (zh) 生物统计学验证的vlan的系统及方法
WO2020138525A1 (fr) Procédé d'authentification distribuée d'un dispositif dans un environnement de chaînes de blocs de l'internet des objets, et système d'authentification distribuée de dispositif l'utilisant
JP2019185775A (ja) ブロックチェーン基盤の権限認証方法、端末及びこれを利用したサーバ
WO2021137396A1 (fr) Procédé de service de certificat basé sur une preuve à connaissance nulle utilisant un réseau de chaîne de blocs, serveur de support de certification l'utilisant et terminal utilisateur l'utilisant
WO2019184155A1 (fr) Procédé de commande d'autorité de nœud de chaîne de blocs, système de chaîne de blocs et support d'informations
WO2018124856A1 (fr) Procédé et terminal d'authentification d'un utilisateur au moyen d'un id mobile grâce à une base de données de chaînes de blocs, et serveur utilisant le procédé et le terminal
WO2020138532A1 (fr) Procédé de consensus de chaîne de blocs basé sur un vote aveugle dynamique pour un environnement internet des objets
WO2013085217A1 (fr) Système de gestion de la sécurité ayant de multiples serveurs de relais, et procédé de gestion de la sécurité
WO2021145555A1 (fr) Procédé d'authentification de multiples nœuds sur la base d'une chaîne de blocs et appareil associé
WO2019177380A1 (fr) Système de chaîne de blocs hybride et procédé de transmission de transaction de commande utilisant celui-ci
WO2022203328A1 (fr) Dispositif de verrouillage intelligent, système de gestion de verrouillage comprenant ce dispositif et procédé de gestion de verrouillage utilisant ce système
WO2022045419A1 (fr) Procédé de service d'authentification de permis de conduire basé sur un réseau de chaîne de blocs utilisant un id décentralisé, et terminal utilisateur permettant d'effectuer un service d'authentification de permis de conduire
EP2724501A2 (fr) Appareil et procédé destinés à fournir un service à des terminaux de service hétérogènes
WO2017116062A1 (fr) Procédé et serveur d'authentification et de vérification de fichier
WO2021096001A1 (fr) Procédé et système de gestion de dispositif mobile reposant sur une chaîne de blocs privée
WO2022240026A1 (fr) Procédé et appareil pour fournir un service api avec un bloc intermédiaire par intégration d'une pluralité de chaînes de blocs et procédé de vérification d'identité l'utilisant
WO2015178597A1 (fr) Système et procédé de mise à jour de clé secrète au moyen d'un module puf
WO2024090845A1 (fr) Procédé d'authentification de propriété de portefeuille de chaîne de blocs sans fonction de signature, et système l'utilisant
WO2021206289A1 (fr) Procédé, dispositif et programme d'authentification d'utilisateur
WO2022010297A1 (fr) Procédé pour transmettre, par un terminal homologue, des données de bloc à un terminal client dans une structure hyperledger fabric
WO2024005565A1 (fr) Procédé, système, et support d'enregistrement non transitoire lisible par ordinateur de fourniture de service de messagerie
WO2023149660A1 (fr) Procédé et système d'apprentissage fédéré basé sur une signature de groupe, et support d'enregistrement pour la mise en œuvre de ceux-ci
WO2013100636A1 (fr) Tsm maître

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 21837013

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

32PN Ep: public notification in the ep bulletin as address of the adressee cannot be established

Free format text: NOTING OF LOSS OF RIGHTS PURSUANT TO RULE 112(1) EPC (EPO FORM 1205A DATED 22.06.2023)

122 Ep: pct application non-entry in european phase

Ref document number: 21837013

Country of ref document: EP

Kind code of ref document: A1