KR20230097062A - Blockchain Machine Network Acceleration Engine - Google Patents

Abstract

Embodiments of the present application describe hardware accelerators (eg, network acceleration engines) for blockchain machines or nodes. The hardware accelerator parses the packets containing the individual components of the transaction block to generate data for performing the verification process. To avoid latency introduced when using software, embodiments of the present application describe a hardware accelerator's protocol processor that parses packets and prepares data for consumption by downstream components of the accelerator without software intervention. These downstream components can then perform verification operations to verify one or more transactions before committing (i.e. adding) those transactions to the ledger of the permissioned blockchain.

Description

Blockchain Machine Network Acceleration Engine

Examples of this disclosure relate generally to hardware accelerators for nodes in a blockchain.

Hyperledger Fabric is an open-source, enterprise-grade implementation platform for permissioned blockchains. Transaction flow in Hyperledger Fabric follows a run-sort-verify model, in which transactions are executed first, then sorted into blocks, and finally verified (state to maintain the global state of blocks committed until then). along with the database) are committed to the ledger. As a result, the fabric network includes various types of nodes such as peers, aligners, clients, and the like, and each node has an ID provided by a Membership Service Provider (MSP).

A permissioned blockchain (like Hyperledger Fabric, Quorum, Corda, etc.) is a blockchain network that requires access to be part of it. These blockchains need to be verified before transactions are added to the blockchain's ledger. However, the verification process has to be performed on a specific node, and when a large number of transactions need to be verified, these nodes often become a bottleneck. This bottleneck can limit the blockchain's ability to commit new transactions quickly.

One embodiment describes a computing system that includes a processor, a memory that stores a ledger of a blockchain, and a hardware accelerator. Thus, the hardware accelerator receives multiple packets corresponding to a block of transactions to be committed to the ledger, generates hashes for the different components of the block of transactions, and if it determines that the hashes match previously computed hashes, creates a task to It is configured to verify the transaction block of the hardware accelerator. Further, if one of the processor or hardware accelerator determines that the transaction block is valid, it is configured to commit the transaction block to the ledger.

Another embodiment described in this application is a processor, a memory that stores a ledger of a blockchain, and a hardware accelerator that receives a block of transactions to be committed to the ledger, verifies the signature of the block, and verifies each transaction in the block. and a computing system including the hardware accelerator configured to store a verification result of a transaction. Additionally, either the processor or hardware accelerator is configured to commit the transaction to the ledger.

Another embodiment described in this application includes receiving a plurality of packets corresponding to a transaction block to be committed to a ledger of a blockchain at a hardware accelerator, calculating hashes for different components within the transaction block at the hardware accelerator, A method comprising determining at the hardware accelerator that the hash matches a previously computed hash and generating a task at the hardware accelerator to verify the block of transactions.

In order to provide a detailed understanding of the above-mentioned features, a more detailed description of what is briefly summarized above may refer to example implementations, some of which are illustrated in the accompanying drawings. However, it should be noted that the accompanying drawings merely illustrate typical example implementations and thus should not be considered limiting of their scope.
1 is a timing chart corresponding to a permissioned blockchain according to an example.
2A and 2B are node block diagrams of a blockchain having a hardware accelerator according to an example.
3 illustrates an interface between a protocol processor and a block processor in a hardware accelerator according to an example.
4 is a flow diagram for parsing packets to prepare data for hardware processing according to an example.
5A illustrates sending individual packets for each component of a transaction block according to one example.
5B illustrates packets for sending individual components within a block according to an example.
6 is a block diagram of a protocol processor of a hardware accelerator according to an example.
7 is a block diagram of a block extractor of a protocol processor according to an example.
8 is a flow diagram for verifying a transaction before committing the transaction to a blockchain ledger according to an example.
9 is a block diagram of a block processor according to an example.
10 is a block diagram of block verification according to an example.
11 illustrates communication between a register of a hardware accelerator and a CPU according to an example.

Hereinafter, various features will be described with reference to the drawings. It should be noted that the drawings may or may not be drawn to scale and that elements of like structure or function are represented by like reference numbers throughout the drawings. It should be noted that the drawings are only for facilitating description of features. They are not intended to be exhaustive of the description or limiting of the scope of the claims. Moreover, the illustrated examples need not have all of the aspects or advantages presented. An aspect or advantage described with respect to a particular example is not necessarily limited to that example, and may be practiced in any other example even if not so illustrated or so explicitly described.

Embodiments of the present application describe hardware accelerators (eg, network acceleration engines or compute acceleration engines) for blockchain machines or nodes. The hardware accelerator parses the packets containing the individual components of the transaction block to generate data for performing the verification process. That is, data transmitted using a network protocol (eg, Transmission Control Protocol (TCP)) is typically not suitable for use by a hardware accelerator without first processing the packet by software. To avoid latency introduced when using software, embodiments of the present application describe a hardware accelerator's protocol processor that parses packets and prepares data for consumption by downstream components of the accelerator without software intervention. These downstream components can then perform verification operations to verify one or more transactions before they are committed (i.e. added) to the ledger of the permissioned or permissionless blockchain.

A blockchain can include multiple peer nodes, each containing standard software running on servers or containers. Some peer nodes, known as validator nodes, are a major bottleneck in system performance because they need to quickly verify blocks of tens or hundreds of transactions before these transactions can be committed to the blockchain ledger. Instead of using software to verify blocks of transactions, hardware accelerators can verify transactions in a fraction of the time. After that, the peer node software collects the verification results from the hardware accelerator, combines the results with the received block data to derive a block, and commits it to the stored ledger. In an experimental setup, nodes with hardware accelerators achieved more than a 10x improvement in transaction commit throughput compared to software-only peers running on multi-core servers when coupled to a networking acceleration engine.

1 is a timing chart corresponding to a permissioned blockchain 100 according to an example. Although the timing chart of permissioned blockchain 100 in FIG. 1 relates specifically to Hyperledger Fabric, embodiments of the present application may be applied to any type of permissioned blockchain. In addition, embodiments of the present application can be applied to permissionless blockchains that perform a verification process for transactions before these transactions are committed to the ledger. Thus, Hyperledger Fabric is provided only as one example of a suitable blockchain network that can benefit from the hardware accelerators described below.

The transaction flow of blockchain 100 follows a run-sort-verify model, where transactions are first executed, then sorted into blocks, and finally verified (along with a state database to maintain a global state of blocks that have been committed so far). committed to the ledger. As a result, the permissioned blockchain 100 includes various types of nodes such as peers, aligners, clients, and the like, and each node has an ID provided by the MSP. This identification may be provided in the form of a certificate.

A client can be any entity that submits a transaction to be committed to the blockchain 100. For example, if blockchain 100 is used to track transfers of money from a financial institution, a client may submit a transaction to move funds from a first account to a second account (either the same financial institution or a different institution). In step 1, the client submits a transaction to commit to the blockchain. In particular, transactions are received at multiple endorsing nodes (or peers). Endorsing nodes both execute/endorsee transactions and verify/commit blocks to the ledger. Each endorsing node executes transactions against its own state database to compute a read-write set of transactions (represented by E in FIG. 1). The read set is the key accessed and its version number, while the write set is the key to be updated with its new value.

If the vouching process succeeds (i.e. there are no errors), at step 2 the vouching node adds that vouching to the transaction and returns the transaction to the client. After the client has collected a sufficient number of endorsements, in step 3 the client requests the sort service to submit the transaction to the verification process. In one embodiment, a sorting service includes an orderer (eg, a computing node) that uses a consensus mechanism to establish an overall order for a transaction. A number of pluggable consensus mechanisms are available, such as Raft and Apache Kafka/Zookeeper based consensus mechanisms.

In step 4, the sort service responds back to the client after the transaction has been approved for inclusion in the block (step 4). The sorting service then creates a block 105 of transactions from the sorted transactions. In one embodiment, the sorting service creates blocks 105 from sorted transactions when a user-configured timeout expires or when a user-configured limit on block size is reached.

Once the block 105 is created, the alignment service broadcasts it in step 5 to all vouching and non vouching nodes, for example via the Gossip protocol. Each node verifies all transactions in block 105 and then commits the block to the ledger and state database (denoted by V). Finally, one of the nodes sends a notification to the client that the transaction has been committed or whether the transaction has been marked as either invalid or valid in the ledger (step 6).

Figure 1 shows the verification workflow 110 of the verification phase in more detail on the right. This workflow 110 shows the four steps performed on every node receiving block 105. Upon receiving a transaction block 105 from the sort service (or lead node) via the gossip protocol, in step 1 the node examines the syntactic structure of the block, verifies its signature, and then pipes the various operations to be described in more detail below. Send it over the line. In step 2, each transaction in the block is syntactically checked and its signature is verified. Then, the verification system chaincode (VSCC) is executed for each transaction, where the endorsement is verified and the associated chaincode's endorsement policy is evaluated. If that endorsement policy is not met, the transaction is marked as invalid.

In step 3, a multi-version concurrency control (MVCC) check is performed. This check ensures that there are no read-write conflicts between valid transactions. In other words, it avoids the double-spending problem where two transactions commit when only one transaction was intended. By accessing the state database (illustrated as “statusdb” in FIG. 1), each transaction's read set is again computed and compared to the read set of the assurance phase. If these read sets are different, then at this time some other transaction (either this block 105 or the previous block) has already modified the same key and thus this transaction is marked invalid.

In the final step 4, the block is committed to the node's stored ledger. In one embodiment, the entire block is first written to the ledger along with the transaction's valid/invalid flag. The record set of valid transactions is then committed to the state database.

2A and 2B are block diagrams of a node 200 of a blockchain having a hardware accelerator 210 according to an example. In one embodiment, node 200 is any computing system that performs a verification process when committing a transaction to a blockchain. For example, node 200 may be an endorsement or non-guarantee node or peer as shown in FIG. 1 . In one embodiment, node 200 is a server or other computing system.

In FIG. 2A , node 200A includes CPU 205 , hardware accelerator 210 and memory 235 . CPU 205 represents any number of processors, each of which may contain any number of processing cores. Memory 235 represents volatile memory, non-volatile memory (eg, hard disk drive), and combinations thereof. As shown, memory 235 stores a ledger 240 listing committed transactions of the blockchain.

Hardware accelerator 210 contains various circuit elements for performing verification workflow 110 illustrated in FIG. 1 . In one embodiment, hardware accelerator 210 is an integrated circuit. In another embodiment, the hardware accelerator 210 is a board (eg, a printed circuit board (PCB) such as a PCIe card) on which one or more integrated circuits are mounted. In one embodiment, the integrated circuit is a field programmable gate array (eg, FPGA) or system on a chip (SoC) that includes programmable logic. In this example, various circuit blocks of accelerator 210 are implemented with programmable logic. However, in other embodiments, the integrated circuit may be an application specific integrated circuit (ASIC) in which the circuit blocks of accelerator 210 are implemented only in hardened circuitry. Using FPGAs and SoCs with programmable logic provides flexibility for accelerator 210 to be reprogrammed if the verification process changes, while using an ASIC saves space.

Accelerator 210 includes a network interface 215 for receiving Ethernet packets containing data pertaining to a transaction, a protocol processor 220 for reformatting the data, a block processor 225 for performing verification workflows and verification and a register map 230 (reg_map) (eg, a memory register) to store the result. Protocol processor 220, block processor 225 and register map 230 are described in more detail below. Typically, these hardware blocks work together to verify received transaction blocks. That is, the network interface 215 receives multiple packets containing data corresponding to the transaction block. Because this data may be in an inappropriate format for processing, protocol processor 220 may reformat and output the data to block processor 225 for consumption. While block processor 225 performs most steps of the verification workflow, some of these steps may be performed by protocol processor 220 and register map 230 . Also, since ledger 240 is stored in memory 235 (which cannot be directly accessed by accelerator 210), node 200A relies on CPU 205 to send verified transactions to ledger 240. can commit. That is, the accelerator 210 may store the verification result in the register map 230 that the CPU 205 can evaluate and then commit the transaction to the ledger. That is, in one embodiment all transactions are committed to the ledger, but the validation flags store information about which are valid and which are invalid. However, in the case of the state database (discussed below), only successfully verified transactions are committed. Most of the verification is performed in the hardware accelerator 210, but committing the transaction to the ledger 240 may be performed by software running on the CPU 205.

FIG. 2B illustrates node 200B identical to node 200A of FIG. 2A except for the addition of a network interface card (NIC) 245 . In one embodiment, NIC 245 provides node 200B with the ability to determine what is network traffic flowing through accelerator 210 and what is network traffic flowing through NIC 245. . In one embodiment, all traffic related to the blockchain may originate through the accelerator 210 while received network traffic not related to the blockchain is handled by the NIC 245. In contrast, all network traffic (whether blockchain traffic or non-blockchain traffic) received by node 200A at node 200A may be received at accelerator 210 . For example, protocol processor 220 may pass network traffic related to validation to block processor 225, but pass all other traffic to CPU 205.

In another embodiment, accelerator 210 only receives network traffic related to validating transactions in accelerator 210 while all other traffic (whether other types of blockchain traffic, such as endorsement requests, or non-blockchain traffic) ) is received and processed by the NIC 245.

In another embodiment not shown in FIGS. 2A or 2B , accelerator 210 may perform all blockchain operations without the aid of CPU 205 . In that embodiment, CPU 205 may be used to configure or control accelerator 210, but NIC 245 and CPU 205 are not used to perform blockchain operations. In this scenario, all network traffic passes through accelerator 210, which processes blockchain-related packets but forwards other packets to/from CPU 205.

3 illustrates an interface 300 between a protocol processor and a block processor in a hardware accelerator according to one example. In this example, interface 300 is used to send block data, transaction data (represented as tx data in FIG. 3 ), warranty data, read set data, and write set data to block processor 225 . That is, protocol processor 220 receives Ethernet packets from other nodes in the blockchain (e.g., orderers of a sorting service) containing information used to verify a block of transactions. Protocol processor 220 then reformats/parses the data so that it can be consumed by block processor 225.

4 is a flow diagram of a method 400 for parsing packets to prepare data for hardware processing according to an example. For ease of explanation, the blocks of method 400 are described in parallel with the figures below.

At block 405, the accelerator's network interface receives packets containing the individual components of the transaction block. Because a block is typically too large to send as a single packet (eg, a block can exceed 1 megabyte), software applications rely on network protocols or software drivers to split the block into multiple packets. However, the data is typically transmitted in an ad-hoc fashion as the network protocol/driver typically does not know how the data is structured in blocks. This makes it difficult, if not impossible, for the hardware accelerator to then parse the received packets and reconstruct the transaction block. However, embodiments of the present application describe techniques for transmitting a transaction block such that a hardware accelerator can parse the packet to reconstruct the different components of the transaction block.

5A illustrates sending individual packets for each component in block 505 of a transaction according to an example. Specifically, FIG. 5A shows that a sender 515 (e.g., an aligner or another peer node in a blockchain) sends packets 520 to hardware accelerator 210 so that block message 505 can be reconstructed from these It illustrates a communication system 500 that allows packets to be correctly parsed. To this end, the sender's 515's software splits the block message 505 into its individual block components 510, shown here as a header, transactions (TX) 1-5, and metadata. That is, rather than relying on a network protocol or driver to determine how to split the data in a block message 505 into individual packets, the software of the sender 515 (which knows the structure of the block 505) breaks the block into its components. (510).

5A illustrates sender 515 sending packets 520A-520G to hardware accelerator 210 over a network, eg, a private or public network such as the Internet. As shown, each packet 520 includes only one of the components 510, i.e., packet 520A includes the header of block 505, and packets 520B-520F each include during a transaction. Packet 520G contains the metadata of block 505 . Without software dividing block 505 into its components 510, a network protocol or driver sends a first packet containing a header and part of TX1, and a second packet containing the rest of the data in TX1 and part of TX2. can be, etc. This unpredictable divergence of different components 510 at block 505 can make it difficult to design a hardware accelerator 210 that parses the data so that block 505 can be reconstructed.

Also, although not shown in FIG. 5A , sender 515 can remove the signed certificate associated with component 510 . These certificates can be used to verify block 505 and transactions within the block. However, these certificates (eg, x509 certificates) are large, meaning that a significant amount of bandwidth is required to transmit them to the accelerator 210 . In one embodiment, sender 515 then removes the certificate from block 505 before forming packet 520 that is sent to accelerator 210 . Instead, sender 515 can replace the certificate with an ID (eg, an 8-bit code). In one embodiment, sender 515 individually sends the certificates to accelerator 210 once, which may then cache the certificates for later retrieval. In this way, the certificate is issued once, rather than repeatedly, when associated with multiple components 510 at block 505 .

5B illustrates a packet 520 for sending individual components within a block according to one example. 520 includes L2 and IP/UDP data, transport header 525, block machine protocol header 530 and block message payload 535. The transport header 525 may include a sequence number (Seq), an acknowledgment number (Ack), and control data (Ctrl). The sequence number indicates where the packet is in the sequence of packets representing block 505. The acknowledgment number is used by accelerator 210 when generating an Ack packet to send back to sender 515. Control data may include such information as application level protocol errors and receiver buffer status.

The block machine protocol header 530 includes a message type (MsgType) and comments. The message type indicates whether the data in payload 535 is a block header, transaction or metadata. Comments point out the location of important data. For example, annotations are pointers to relevant data in packet 520 (e.g., where to find specific data in payload 535) and cache or placeholders pointing to data in another packet (but in the same block). can include In one embodiment, the annotation's place setter is used to indicate an ID for packet 520. Payload 535 may include data corresponding to the particular component 510 sent in the packet, ie metadata from block 505 .

Since each packet 520 contains one of the components 510 of block 505, this provides the advantage that accelerator 210 can start processing data before all packets 520 in the block have been received. . That is, instead of waiting for the software to receive all packets and then reconstruct block 505 for verification, accelerator 210 can process transactions as they come in. For example, the protocol processor may parse packet 520B corresponding to TX1 before packet 520C containing TX2 is received at accelerator 210 . Thus, accelerator 210 can begin processing transactions much sooner than software solutions where all packets must be received before the transaction can be reconstructed and verified.

6 is a block diagram of a protocol processor 220 of a hardware accelerator according to an example. As shown, data packet 520 is packet filter 610 which parses a level 4-7 (L4-L7) packet header (e.g., block machine protocol header 530) to extract message type and comments. ) is received from Message types can include block start, block metadata, transaction, etc. Comments on the message payload include block header location, block signature location, block ID, transaction data start, channel name, transaction ID, chaincode name, originator certificate authority (CA) ID, transaction action, transaction CA ID, contract name, contract It may include inputs, endorser actions, read/write sets, endorser lists, transaction signatures, aligner CA IDs, aligner signatures, certificate IDs, certificate public key data, state valid start information, state valid end information, and the like. Packet filter 610 also identifies a sequence number in the transport header and passes this number to response generator 605, which transmits a response packet (e.g., an acknowledgment packet) back to the sender (e.g., aligner). do.

Packet filter 610 passes the message type, annotation, and packet payload to block extractor 615, which processes the message payload based on the annotation and extracts relevant data for block processor 225. The block extractor 615 can also provide a message valid signal to the response generator 605 so that the generator 605 can inform the sender whether the block and its transaction are valid or invalid. Details of block processor 225 are described in the remainder of method 400 and in the figures below.

Returning to method 400, at block 410 the protocol processor's block extractor uses the packet's ID to identify a signed certificate corresponding to the packet. As described above, the sender can remove the certificate from the block before sending it to the hardware accelerator in multiple packets. This can be done because certificates are large and rarely change. Thus, replacing the certificate with the much smaller ID or key of the packet referencing the certificate can save significant bandwidth and ensure that each component of the transaction block can be sent as a single packet.

However, once a packet is received, a block extractor may require certificates to verify blocks (and transactions in blocks) and to ensure that blocks and transactions are syntactically correct. Thus, the block extractor can reconstruct the component, which means that the block extractor identifies and retrieves the certificate.

7 is a block diagram of a block extractor 615 according to an example. As shown, the block extractor 615 includes a data inserter 705 that receives a packet payload and annotations to identify the certificate (or certificates) corresponding to that payload. For example, if the payload is block metadata, the payload may include an ID corresponding to a certificate of an aligner who prepared the block. When a transaction is included in the payload, the payload may include an ID corresponding to the client that submitted the transaction and one or more IDs corresponding to the endorsing node that endorsed the transaction. Thus, data inserter 705 can identify multiple IDs in the payload.

Using the ID, data inserter 705 performs a search in ID cache 710 to retrieve the signed certificate corresponding to the ID. That is, when the aligner issues certificates to the accelerator, the accelerator stores these certificates (and their corresponding IDs) in the ID cache 710, so that it can then retrieve these certificates when verifying the transaction block.

Returning to method 400, at block 415 block extractor 615 reconstructs the individual components of the block. That is, upon receiving each payload, block extractor 615 may retrieve a corresponding certificate. This is illustrated in FIG. 7 where data inserter 705 sends the retrieved certificate (or certificates) to data extractor 715 along with other data in the payload.

Data extractor 715 can reconstruct the components of the transaction block at different times. For example, during time 1 data extractor 715 uses the first received packet to reconstruct the block's header, and at time 2 data extractor 715 uses the second received packet to reconstruct the first transaction in the block. etc. Thus, block extractor 615 can be pipelined so that different components within a block can be executed in parallel at different stages (eg, different circuit modules) within extractor 615 .

At block 420, hash calculator 720 calculates a hash for the delimiter components within the block. In one embodiment, hash calculator 720 generates hashes for the entire block, all transactions in the block, and all guarantees of each transaction. Hash calculator 720 may generate these hashes at different times. For example, hash calculator 720 may generate a hash for a particular transaction (and a hash for all guarantees associated with that transaction) upon receiving packets corresponding to the transaction. However, hash calculator 720 may wait to calculate the hash for the entire block after receiving all packets for the block.

At block 425, hash checker 725 determines whether the hash calculated by hash calculator 720 matches the hash of the packet. That is, packets transmitted by the sender may contain a previously computed hash (or at least a pointer to a hash) that can be compared to the hash generated by hash calculator 720. For example, the sender may compute hashes for the block, each transaction in the block, and each guarantee of the transaction and send these hashes to the accelerator 210 . If these hashes match the local hash generated by hash checker 725, it means that the message is valid and follows the proper syntax for blocks and transactions. If the hashes do not match, the method proceeds to block 445 where the hardware accelerator indicates that there is a syntax error in the received data. In one embodiment, the hardware accelerator sends a response message to the sender indicating that the verification process has failed.

Assuming the hash matches the received hash, the method 400 proceeds to block 430 where the hardware accelerator indicates that the received data has been successfully parsed. In one embodiment, response generator 605 of FIG. 6 sends a response or acknowledgment (ACK) message to the sender indicating that the transaction block was successfully received and processed by protocol processor 220 .

At block 435, task generator 730 creates a task for the block processor to complete the verification process. In one embodiment, job generator 730 creates block jobs, transaction jobs, and surer jobs. A block operation may include a block ID, a block signature (eg, the certificate of the sorter who created the block), and the like. A transaction operation may include a transaction ID, a transaction signature (eg, the certificate of the client that created the transaction), a transaction read/write set, and the like. In one embodiment, task generator 730 creates a transaction task for each transaction in a block. Job generator 730 may also create an endorser job for each endorsement in the transaction. That is, since each transaction may receive multiple endorsements, task generator 730 may create a task for each of these endorsements.

At block 440, task generator 730 passes the task and corresponding data to the block processor of the hardware accelerator. After that, the block processor can verify blocks, transactions and guarantees. In general, a protocol processor (and its circuit components illustrated in FIGS. 5-7) parses received packets to reformat the block's data into a format that can be digested or processed by the block processor without the aid of software. Thus, the verification process of a blockchain can be performed entirely by hardware, reducing the time and computing resources required for this process.

8 is a flow diagram of a method 800 for validating a transaction prior to committing the transaction to a blockchain ledger according to one example. For ease of explanation, the different stages of the method 800 are described according to FIGS. 9-11 below. Further, the stages of method 800 correlate with steps 1-4 of validation workflow 110 illustrated in FIG. 1 .

Method 800 assumes that the hardware accelerator has already received a block of transactions from, for example, a sorting service that needs to be verified before the transaction can be committed to the ledger. Method 800 also allows the protocol processor to perform block syntax checking (eg, "blk syntax checking" in FIG. 1 ) and transaction syntax checking (eg, "tx syntax checking" in FIG. 1 ) to perform verification. Assume that you confirm that all the data you need to do is received.

At stage 805, the hardware accelerator verifies the signature of the transaction block. More specifically, the block processor receives the information shown in FIG. 3 from the protocol processor so as to be able to perform block verification. As shown in FIG. 9 , block processor 225 includes two hardware submodules: block verify 905 and block verify 910 . Block verification 905 includes an Elliptic Curve Digital Signature Algorithm (ECDSA) engine 920 to verify that an aligner signature is present on a block. In other words, the ECDSA engine 920 compares the block's received signature to a signature known to the aligner (eg, a certificate) to ensure that they match. In that way, block confirmation 905 can confirm that the transaction block originated from the approved node. Although an ECDSA engine 920 is shown, any suitable signature algorithm engine may be used.

In addition to including the aligner signature, the block data received at block confirmation 905 may also include the block number, number of transactions within the block, and the like.

Returning to method 800, at stage 810 the hardware accelerator verifies a plurality of transactions within the block. In FIG. 9 this function is performed by block verify 910 . That is, while block verification 905 ensures that a block has been received by a known aligner, block verification 910 verifies the block's individual transactions. To this end, block verify 910 receives transaction data, warranty data, read set data, and write set data from a protocol processor (not shown in FIG. 9). Block verification 910 then outputs block verification data containing verification results such as block number, valid/invalid transaction flags, latency, and the like.

In one embodiment, block verification 905 and block verification 910 are pipelined at the block level. That is, block processor 225 may process the first block of transactions in block verification 905 (pipeline stage 1) while block verification 910 may process the second block of transactions (pipeline stage 2). there is. In other words, block verification 905 can use ECDSA engine 920 to ensure that approved aligners transmit the first block while block verification 910 verifies individual transactions in the second block.

Block processor 225 also includes a block monitor 915 that collects block level and transaction level statistics by monitoring signals received from block verify 905 and block verify 910 . For example, block monitor 915 may determine the time or latency required to verify a block of transactions or the throughput of block processor 225 (eg, number of blocks processed per unit time).

8 also illustrates that stage 810 can be subdivided into stages 815-825. In one embodiment, stages 815 - 825 of method 800 correspond to pipeline stages 2a, 2b and 2c of FIG. 10 illustrating a more detailed view of block verify 910 of FIG. 9 .

In stage 815, the first pipeline stage 2a of block verification 910 verifies the signature of each transaction. As shown in FIG. 10 , stage 2a includes a number of transaction confirmation blocks 1005 each including an ECDSA engine 1035 . These engines 1035 verify the signature of the client (or originator) of the transaction. That is, the ECDSA engine 1035 compares the received signature with a signature calculated based on the tx data and the generator's public key pair to ensure that the transaction was signed by a known client.

Because there are multiple transaction verification blocks 1005, stage 2a can verify client signatures for multiple transactions in parallel. It is a design choice to determine how many transaction confirmation blocks 1005 block verification 910 includes. Having an additional transaction confirmation block 1005 means stage 2a can process more transactions in parallel, but at the cost of using additional space and power in the accelerator.

Returning to method 800, block verification 910 at stage 820 verifies the endorsement of each transaction using the endorsement policy. As shown in FIG. 10 , pipeline stage 2b includes multiple transaction VSCC blocks 1010, each including multiple ECDSA engines 1015 (or any other type of signature verification engine) and endorsement policy evaluator 1020. ). Each transaction VSCC block 1010 verifies the endorsement of a particular transaction. To this end, the transaction VSCC block 1010 receives guarantee data including a guarantor ID and verification data. Since a client transaction can receive multiple guarantees (as shown in Figure 1), each ECDSA engine 1015 can evaluate one of the guarantees in parallel. That is, if transaction A has received two endorsements, the ECDSA engine 1015A can verify that the first endorsement was signed by an approved endorsement node and at the same time the ECDSA engine 1015B can confirm that the second endorsement is signed by an approved endorsement node. You can verify that it has been signed. Again, the number of ECDESA engines 1015 in each block 1010 is a design choice.

In one embodiment, the endorsement policy evaluator 1020 may maintain endorsement policies on a per-chaincode basis. Evaluator 1020 verifies that the transaction has been properly endorsed. That is, assuming the endorsement is given by an approved endorsement node, the evaluator 1020 verifies the transaction for which endorsement has been received from the appropriate endorsement node. For example, if a transaction indicates that money should be transferred between two banks, evaluator 1020 may check to ensure that the transaction received an endorsement from an endorsement node operated by both of these banks. Evaluator 1020 may invalidate the transaction if the transaction is endorsed by the endorsing node for only one bank or by another bank unaffected by the transaction.

Because stage 2b includes multiple transaction VSCC blocks 1010, block verify 910 can verify the guarantees for multiple transactions in parallel. That is, after verifying in stage 2a that the transaction was initiated by an approved client, in stage 2b we can verify that the endorsement for the transaction is valid and meets one or more endorsement policies. The number of transaction VSCC blocks 1010 in block verification 910 is a design choice.

Returning to method 800 , block verify 910 at stage 825 performs a version check and commits the write key to state database 1030 . This is done by stage 2c, which includes a transactional MVCC write block 1025 communicatively coupled to a state database 1030 and a register map (not shown in FIG. 10). Also, the register map is optionally coupled to the node's CPU (not shown). In one embodiment, transaction MVCC record block 1025 queries the read key from state database 1030 to perform a version check and, if verified, commits the valid transaction's updated record key to database 1030. To this end, the transactional MVCC record block 1025 receives read set data (each element contains a read key-version pair) and record set data (each element contains a record key-value pair) from the protocol processor. do. In one embodiment, state database 1030 includes an internal locking mechanism that does not allow reading of keys currently being written (or updated).

Stages 2a-2c of Figure 10 can be pipelined. That is, while Figure 9 illustrates a block-level pipeline between block verification 905 and block verification 910, Figure 10 illustrates a transaction-level pipeline in which transactions of a particular block may be processed in parallel in stages 2a-2c. exemplify That is, stage 2a may process a first set of transactions in a block, while stage 2b processes a second set of transactions in the same block, and stage 2c processes a third set of transactions in the same block. However, in one embodiment, due to dependencies between transactions, block verification 910 may only process transactions in the same block. That is, one stage of block verification 910 may not process transactions of a first block, while another stage may not process transactions of a second block.

Returning to method 800 , block verify 910 at stage 830 stores the result of performing the verify process in a register (eg, register map 230 ). As shown in FIG. 11, the register map receives block verify data from block verify 910, which may contain block number, valid/invalid transaction flags, latency (as measured by the block monitor), and the like. The verification result is written to the register map, where the CPU 205 can access the verification result using an AXI-lite or PCIe interface. In one embodiment, new verification results cannot be written to register map 230 until the currently stored verification results have been read by CPU 205 . 11 also illustrates a system 1100 in which the hardware accelerator's register map 230 is accessible by the CPU 205 as described above, the accelerator may not use the CPU 205 and instead the CPU 205 ) can complete the verification process without the help of software running on it.

At stage 835, the CPU (or hardware accelerator) informs the client whether the transaction is valid or invalid. That is, the CPU can evaluate the verification result to determine whether each individual transaction in the transaction block has been verified. After that, the client can choose to resubmit the invalid transaction.

At stage 840, the transaction is committed to the ledger. In one embodiment, both valid and invalid transactions may be committed to the ledger, and may include a valid/invalid flag indicating whether the committed transaction is valid.

Earlier, reference was made to the examples presented in this disclosure. However, the scope of the present disclosure is not limited to the specifically described embodiments. Instead, any combination of the described features and elements, whether related to other embodiments or not, is contemplated for implementing and practicing the contemplated embodiments. Moreover, while the embodiments disclosed herein may achieve advantages over other possible solutions or over the prior art, it is not intended to limit the scope of the present disclosure whether a particular advantage is achieved by a given embodiment. Accordingly, the foregoing aspects, features, embodiments and advantages are illustrative only and are not considered elements or limitations of the appended claims except where expressly recited in a claim(s).

As will be appreciated by those skilled in the art, the embodiments disclosed in this application may be implemented as systems, methods, or computer program products. Accordingly, aspects may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, microcode, etc.) or an embodiment combining software and hardware aspects, all of which are generally referred to herein as " may be referred to as "circuit", "module" or "system". Furthermore, aspects may take the form of a computer program product embodied in one or more computer readable medium(s) having computer readable program code embodied thereon.

Any combination of one or more computer readable medium(s) may be used. A computer readable medium may be a computer readable signal medium or a computer readable storage medium. A computer readable storage medium may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared or semiconductor system, apparatus or device or any suitable combination thereof. More specific examples (a partial list) of computer readable storage media include: electrical connections having one or more wires, portable computer diskettes, hard disks, random access memory (RAM), read-only memory (ROM), erase programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disc read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In the context of this document, a computer readable storage medium is any tangible medium that can contain or store a program for use by or in connection with an instruction execution system, apparatus or device.

A computer readable signal carrier may contain a propagated data signal having computer readable program code embodied therein, for example in baseband or as part of a carrier wave. These propagating signals may take any of a variety of forms, including but not limited to electromagnetic, optical, or any suitable combination thereof. A computer readable signal medium may be any computer readable medium that is not a computer readable storage medium and that can communicate, propagate or transport a program for use by or in connection with an instruction execution system, apparatus or device.

Program code embodied in a computer readable medium may be transmitted using any suitable medium, including but not limited to wireless, wired, fiber optic cable, RF, etc., or any suitable combination thereof.

Computer program code for performing operations for aspects of the present disclosure may include one or more programming languages, including object oriented programming languages such as Java, Smalltalk, C++, etc., and conventional procedural programming languages such as the "C" programming language or similar programming languages. can be written in any combination of The program code may run entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer, or entirely on a remote computer or server. In the latter scenario, the remote computer can be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or (e.g., using an Internet service provider). A connection to an external computer (via the Internet) can be established.

Aspects of the present disclosure are described below with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems) and computer program products according to embodiments presented herein. It will be appreciated that each block of the flowchart illustrations and/or block diagrams, and block combinations of the flowchart illustrations and/or block diagrams, may be implemented by computer program instructions. Such computer program instructions are provided to a processor of a general-purpose computer, special purpose computer, or other programmable data processing device so that the instructions executed by the computer's processor or other programmable data processing device are shown in a block or blocks in a flowchart and/or block diagram. You can create a machine that allows you to create means for implementing specified functions/behaviors.

Such computer program instructions may also be stored on a computer readable medium so that a computer, other programmable data processing apparatus, or other device can use the instructions stored on the computer readable medium to perform flowcharts and/or block diagram blocks or the functions/acts specified in the blocks. It can be directed to function in a particular way to create an article of manufacture that contains the instructions it implements.

Computer program instructions may also be loaded into a computer, other programmable data processing apparatus, or other device so that a series of operational steps are performed in the computer, other programmable apparatus, or other device such that the instructions executed in the computer or other programmable apparatus are flow diagrams and/or Alternatively, a block may also cause a computer-implemented process to be created to provide a block or a process for implementing the function/behavior specified in the block.

The flow diagrams and block diagrams in the drawings illustrate the architecture, functionality and operation of possible implementations of systems, methods and computer program products according to various examples of the present invention. In this regard, each block of a flowchart or block diagram may represent a module, segment, or portion of instructions that includes one or more executable instructions for implementing a specified logic function(s). In some alternative implementations, functions recited in blocks may occur out of the order recited in the figures. For example, two blocks presented in succession may in fact be executed substantially concurrently, or the blocks may sometimes be executed in reverse order depending on the function involved. Each block of block diagrams and/or flow diagram illustrations, and combinations of blocks within block diagrams and/or flow diagram illustrations, is special purpose that performs specified functions or operations or performs combinations of special purpose hardware and computer instructions. It should also be noted that it can be implemented by hardware based systems.

In addition to what is described in the claims, the disclosed technology can be represented in the following non-limiting examples.

Embodiment 1. An integrated circuit for accelerating a verification process for a blockchain, comprising: a network interface configured to receive a plurality of packets containing a block of transactions from a node in the blockchain; a protocol processor configured to parse the plurality of packets to generate data relating to the transaction; and a block processor that verifies the signature of a block; verify each transaction in the block; and the block processor, configured to store a verification result of a transaction.

Embodiment 2. The integrated circuit of Example 1, wherein the integrated circuit includes at least one of a system on a chip (SoC), a field programmable gate array (FPGA), and an application specific integrated circuit (ASIC).

Embodiment 3. The integrated circuit of example 2, wherein the SoC or FPGA includes programmable logic.

Embodiment 4. The integrated circuit of Example 2, wherein the ASIC includes only enhanced circuitry.

Embodiment 5. The integrated circuit of example 1, wherein the block processor comprises: block verification comprising a first signature algorithm engine configured to verify that a signature of a block matches a known signature of an aligner in a blockchain; and block verification configured to verify each transaction within the block.

Embodiment 6. The integrated circuit of example 5, wherein the block verification comprises a transaction verification module comprising a second signature algorithm engine configured to verify that a signature corresponding to a transaction matches a known signature of a client authorized to use the blockchain; a transaction verification system chaincode (VSCC) block, comprising: a third signature algorithm engine configured to verify that a transaction's endorsement was signed by a known endorsement node in the blockchain; and an endorsement policy evaluator configured to ensure that an endorsement meets an endorsement policy; and a transaction multiple version concurrency control (MVCC) write block configured to read and write key-value pairs associated with transactions in the state database.

Embodiment 7 The integrated circuit of example 6, wherein the block verification comprises a plurality of transaction verification modules configured to operate in parallel to verify signatures of the first set of transactions; and a plurality of transaction VSCC blocks configured to operate in parallel to verify endorsements of a second set of transactions, wherein the plurality of transaction verification modules form a first stage of a pipeline and the plurality of transaction VSCC blocks comprise a plurality of transaction VSCC blocks. A plurality of transaction confirmation modules form a second stage of the pipeline to process the first set of transactions at the same time the block processes the second set of transactions.

Example 8. The integrated circuit of example 7, wherein each of the plurality of transaction verification modules includes a plurality of algorithmic signature engines for verifying in parallel one set of guarantees during a transaction.

Embodiment 9. The integrated circuit of Example 2, wherein block verification forms a first stage in the pipeline while block verification forms a second stage in the pipeline, such that block verification forms the second stage of a transaction to the blockchain. Concurrent with processing the block, block confirmation may process the first block of transactions to the blockchain.

Embodiment 10. A method comprising: receiving a transaction block to be committed to a ledger of a blockchain from a hardware accelerator; verifying the signature of the block in the hardware accelerator; verifying each transaction in the block in the hardware accelerator; Storing the verification result of the transaction in the hardware accelerator; and committing the transaction to the ledger and indicating whether the transaction is valid based on the verification result.

Embodiment 11 The method of example 10, wherein receiving the transaction block comprises receiving a plurality of packets that include the transaction block, the method comprising the plurality of packets to generate data relating to the transaction at the hardware accelerator. Parsing is further included.

Example 12 The method of example 10, wherein verifying each transaction in the block further comprises verifying that the signature of the block matches a known signature of an orderer in the blockchain.

Example 13 The method of example 10, wherein verifying each transaction in the block includes verifying that the endorsement of the transaction was signed by a known endorsement node of the blockchain; and ensuring that the endorsement of the transaction satisfies the endorsement policy.

Embodiment 14. An integrated circuit for accelerating a verification process for a blockchain comprising: a data inserter configured to receive a plurality of packets corresponding to a block of transactions to be committed to a ledger of a blockchain; a hash calculator configured to generate hashes for the different components of the transaction block; a hash checker configured to determine whether the hash matches a previously computed hash; and a job generator configured to create a job to verify the transaction block.

Embodiment 15 The integrated circuit of Example 14, wherein the integrated circuit includes at least one of a system on a chip (SoC), a field programmable gate array (FPGA), or an application specific integrated circuit (ASIC).

Embodiment 16 The integrated circuit of example 15, wherein the SoC or FPGA includes programmable logic.

Embodiment 17 The integrated circuit of example 15, wherein the ASIC includes only enhanced circuitry.

Embodiment 18 The integrated circuit of example 14, wherein the block of transactions includes a block header, a plurality of transactions, and metadata, and the block header, each of the plurality of transactions, and metadata are sent as individual packets of the plurality of packets; The plurality of packets do not contain signed certificates corresponding to the block or the plurality of transactions.

Embodiment 19 The integrated circuit of example 18, further comprising an ID cache storing local copies of signed certificates corresponding to authorized nodes in the blockchain, wherein the data inserter uses the IDs contained in the plurality of packets to and retrieve the signed certificate corresponding to the transaction block from the ID cache.

Example 20. The integrated circuit of Example 19,

Further comprising a data extractor configured to reconstruct a transaction block using data of the plurality of packets and the retrieved signing certificate, a hash calculator configured to generate a hash using the reconstructed transaction block, and a hash checker configured to determine whether the generated hash is previously It is configured to ensure that the transaction block does not contain syntax errors by checking whether it matches the hash computed in

Although the foregoing is directed to specific examples, other and additional examples may be devised without departing from its basic scope, the scope of which is determined by the following claims.

Claims (15)

As a computing system,
processor;
memory that stores the ledger of the blockchain; and
As a hardware accelerator,
receive a plurality of packets corresponding to a transaction block to be committed to the ledger;
generate hashes for the different components of the transaction block;
a hardware accelerator configured to generate a task to verify the transaction block at the hardware accelerator upon determining that the hash matches a previously computed hash;
wherein one of the processor or the hardware accelerator is configured to commit the transaction block to the ledger if it determines that the transaction block is valid. The computing method of claim 1 , wherein the transaction block includes a block header, a plurality of transactions, and metadata, and the block header, each of the plurality of transactions, and the metadata are transmitted as individual packets of the plurality of packets. system. 3. The computing system of claim 2, wherein the plurality of packets do not contain signed certificates corresponding to the block or the plurality of transactions. The method of claim 3, wherein the hardware accelerator,
an ID cache storing local copies of the signed certificates corresponding to authorized nodes in the blockchain; and
and a data inserter configured to retrieve a signed certificate corresponding to the transaction block from the ID cache using the ID included in the plurality of packets. The method of claim 4, wherein the hardware accelerator,
a data extractor configured to reconstruct the transaction block using data of the plurality of packets and the retrieved signed certificate;
a hash calculator configured to generate a hash corresponding to the transaction block using the reconstructed transaction block; and
and a hash checker configured to check that the generated hash matches a previously computed hash to ensure that the transaction block does not contain syntax errors. As a computing system,
processor;
memory that stores the ledger of the blockchain; and
As a hardware accelerator,
receive a block of transactions to be committed to the ledger;
verify the signature of the block;
verify each transaction in the block;
The hardware accelerator, configured to store a verification result of the transaction,
and one of the processor or the hardware accelerator is configured to commit the transaction to the ledger. The method of claim 6, wherein the hardware accelerator,
a network interface configured to receive the transaction block from another node of the blockchain, the transaction block being included in a plurality of packets;
a protocol processor configured to parse the plurality of packets to generate data relating to the transaction; and
and a block processor configured to receive the data from the protocol processor, verify the signature of the block, and verify each transaction within the block. The method of claim 7, wherein the block processor,
block verification comprising a first signature algorithm engine configured to verify that the signature of the block matches a known signature of a sorter in the blockchain; and
and block verification configured to verify each transaction in the block. The method of claim 8, wherein the block verification,
a transaction verification module comprising a second signature algorithm engine configured to verify that a signature corresponding to the transaction matches a known signature of a client authorized to use the blockchain;
As a transaction verification system chaincode (VSCC) block,
a third signature algorithm engine configured to verify that an endorsement of the transaction was signed by a known endorsement node of the blockchain; and
the transaction verification system chaincode (VSCC) block comprising an endorsement policy evaluator configured to ensure that the endorsement meets an endorsement policy; and
and a transaction multiple version concurrency control (MVCC) write block configured to read and write key-value pairs associated with the transaction in a state database. The computing system according to claim 1 or 6, wherein the hardware accelerator includes at least one of a system on a chip (SoC), a field programmable gate array (FPGA), or an application specific integrated circuit (ASIC). As a method,
Receiving, at the hardware accelerator, a plurality of packets corresponding to the transaction block to be committed to the ledger of the blockchain;
at the hardware accelerator, calculating hashes for the different components of the transaction block;
determining, at the hardware accelerator, whether the hash matches a previously computed hash; and
generating, at the hardware accelerator, a task to verify the transaction block. 12. The method of claim 11 , wherein the transaction block includes a block header, a plurality of transactions, and metadata, and the block header, each of the plurality of transactions, and the metadata are transmitted as individual packets of the plurality of packets. . 13. The method of claim 12, wherein the plurality of packets do not contain signed certificates corresponding to the block or the plurality of transactions. According to claim 13,
storing, in an identity cache of the hardware accelerator, a local copy of the signed certificate corresponding to an authorized node of the blockchain;
and retrieving the signed certificate corresponding to the transaction block from the ID cache using the ID included in the plurality of packets. According to claim 14,
Reconstructing the transaction block using data of the plurality of packets and the retrieved signed certificate;
the hash is calculated using the reconstructed transaction block;
and determining that the hash matches a previously computed hash indicates whether the transaction block contains a syntax error.

Images