JP7674475B2 - Blockchain Machine Network Acceleration Engine - Google Patents

Description

Embodiments of the present disclosure generally relate 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 an execute-order-validate model, where transactions are first executed, then ordered into blocks, and finally validated and committed to the ledger (along with a state database to hold the global state of blocks committed so far). As a result, the Fabric network contains different types of nodes, such as peers, orderers, and clients, and each node has an identity provided by a Membership Service Provider (MSP).

Permissioned blockchains (such as Hyperledger Fabric, Quorum, Corda, etc.) are blockchain networks that require access in order to be a part of. These blockchains require transactions to be verified before they can be added to the blockchain's ledger. However, the verification process must be performed by specific nodes, which often experience a bottleneck when they have to verify multiple transactions. This bottleneck can limit the blockchain's ability to quickly commit new transactions.

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 is configured to receive a number of packets corresponding to a block of transactions to be committed to the ledger, generate a hash of different components in the block of transactions, and generate a task at the hardware accelerator to validate the block of transactions upon determining that the hash matches a previously calculated hash. Further, one of the processor or the hardware accelerator is configured to commit the block of transactions to the ledger upon determining that the block of transactions is valid.

Another embodiment described herein is a computing system including a processor, a memory that stores a ledger of a blockchain, and a hardware accelerator configured to receive a block of transactions to be committed to the ledger, verify a signature of the block, verify each of the transactions in the block, and store a result of the verification of the transactions. Further, one of the processor or the hardware accelerator is configured to commit the transactions to the ledger.

Another embodiment described herein is a method that includes receiving, at a hardware accelerator, a number of packets corresponding to a block of transactions to be committed to a blockchain ledger; computing, at the hardware accelerator, hashes of different components in the block of transactions; determining, at the hardware accelerator, that the hash matches a previously computed hash; and generating, at the hardware accelerator, a task to validate the block of transactions.

So that the above features can be understood in detail, a more particular description, briefly summarized above, can be made by reference to exemplary implementations, some of which are shown in the accompanying drawings. It should be noted, however, that the accompanying drawings illustrate only typical exemplary implementations and therefore should not be considered as limiting the scope thereof.

1 is a timing diagram corresponding to a permissioned blockchain, according to an example. FIG. 1 is a block diagram of a node in a blockchain having a hardware accelerator, according to an example. FIG. 1 is a block diagram of a node in a blockchain having a hardware accelerator, according to an example. 1 illustrates an interface between a protocol processor and a block processor in a hardware accelerator, according to one example. 1 is a flow chart for parsing packets and preparing data for hardware processing according to an example. 14 illustrates sending a separate packet for each component in a block of transactions, according to one example. 1 illustrates packets for transmitting individual components within a block, according to one example. 1 is a block diagram of a protocol processor in a hardware accelerator, according to an example. FIG. 13 is a block diagram of a block extractor in a protocol processor, according to an example. 1 is a flowchart for validating a transaction before committing the transaction to a blockchain ledger, according to an example. FIG. 2 is a block diagram of a block processor, according to an example. FIG. 1 is a block diagram of block verification, according to an example. 1 illustrates communication between registers in a hardware accelerator and a CPU, according to an example.

Various features are described below with reference to the drawings. It should be noted that the drawings may or may not be drawn to scale, and elements of similar structure or function are represented by similar reference numerals throughout the drawings. It should be noted that the drawings are intended only to facilitate the description of features. They are not intended as an exhaustive description of the specification or as limitations on the scope of the claims. Furthermore, an illustrated embodiment need not have all aspects or advantages shown. An aspect or advantage described in connection with a particular embodiment is not necessarily limited to that embodiment and may be implemented in any other embodiment, even if not so illustrated or explicitly described.

Embodiments herein describe a hardware accelerator (e.g., a network acceleration engine or a computational acceleration engine) for a blockchain machine or node. The hardware accelerator parses packets containing separate components of a block of transactions to generate data for performing a validation process. That is, data transmitted using a network protocol (e.g., TCP (Transmission Control Protocol)) is typically not suitable for use by a hardware accelerator without the packets being first processed by software. To avoid the latency associated with using software, embodiments herein describe a protocol processor within the hardware accelerator that parses the packets and prepares the data so that it can be consumed by downstream components within the accelerator without software intervention. These downstream components can then perform validation operations to validate one or more transactions before they are committed (i.e., added) to the ledger of a permissioned or permissionless blockchain.

A blockchain may include multiple peer nodes, each of which contains standard software running on a server or container. Some peer nodes, known as validator nodes, are the main bottleneck in system performance because they need to quickly verify blocks of tens or hundreds of transactions before those transactions can be committed to the blockchain ledger. Instead of using software to verify blocks of transactions, a hardware accelerator can verify transactions in a fraction of the time. The peer node software then collects the verification results from the hardware accelerator and combines them with the received block data to derive a block, which is then committed to a stored ledger. In experimental settings, nodes with hardware accelerators, when coupled to a networking acceleration engine, achieved over 10x improvement in transaction commit throughput compared to software-only peers running on multi-core servers.

1 is a timing diagram corresponding to a permissioned blockchain 100, according to an example. The permissioned blockchain 100 timing diagram of FIG. 1 is specifically directed to Hyperledger Fabric, but the embodiments herein may be applied to any type of permissioned blockchain. Additionally, the embodiments herein may also be applied to non-permissioned blockchains that perform a validation process on transactions before they are committed to the ledger. Thus, Hyperledger Fabric is provided as merely one example of a suitable blockchain network that may benefit from the hardware accelerator described below.

Transaction flow in the blockchain 100 follows an execute-order-validate model, where transactions are first executed, then ordered into blocks, and finally validated and committed to the ledger (along with a state database to hold the global state of blocks committed so far). As a result, a permissioned blockchain 100 includes different types of nodes, such as peers, orderers, and clients, and each node has an identity provided by the MSP. This identification can be provided in the form of a certificate.

A client can be any entity that submits a transaction to be committed on the blockchain 100. For example, if the blockchain 100 is used by a financial institution to track money transfers, a client may submit a transaction to move funds from a first account to a second account (at the same financial institution or a different institution). In step 1, a client submits a transaction to be committed to the blockchain. Specifically, the transaction is received on multiple validating nodes (or peers). The validating nodes both execute/validate the transaction and verify/commit the block to the ledger. Each validating node executes the transaction against its own state database to compute the read-write set of the transaction (marked as E in Figure 1). The read set is the keys that have been accessed and their version numbers, and the write set is the keys that are updated with their new values.

If the endorsement process is successful (i.e., there are no errors), in step 2, the endorsement nodes add those endorsements to the transaction and return the transaction to the client. After the client collects a sufficient number of endorsements, in step 3, the client asks the ordering service to submit the transaction to a validation process. In one embodiment, the ordering service includes an orderer (e.g., a computing node) that uses a consensus mechanism to establish a total ordering of transactions. Several pluggable consensus mechanisms are available, such as Raft and Apache Kafka/Zookeeper-based consensus mechanisms.

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

Once block 105 is created, the ordering service broadcasts it in step 5 to all approving and non-approving nodes, e.g., via a gossip protocol. Each node validates all transactions in block 105 and then commits the block to its ledger and state database (marked as 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 invalid or valid in the ledger (step 6).

Figure 1 shows the validation workflow 110 of the validation phase in more detail on the right. The workflow 110 shows four steps executed on all nodes that receive the block 105. Upon receiving a block of transactions 105 from the ordering service (or lead node) via the gossip protocol, in step 1 the node checks the syntactic structure of the block, verifies its signature, and then sends it through a pipeline of various operations that are described in more detail below. In step 2, each transaction in the block is syntactically checked and its signature verified. A validation system chaincode (VSCC) is then run on each transaction where authorizations are verified and the authorization policies of the associated chaincode are evaluated. A transaction is marked as invalid if its authorization policies are not met.

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-spend problem, where two transactions are committed when only one transaction was intended. The read set of each transaction is again calculated by accessing the state database (illustrated as "statedb" in FIG. 1) and compared with the read set from the confirmation phase. If these read sets are different, then some other transaction (either in this block 105 or in a previous block) has already modified the same key, and therefore this transaction is marked as invalid.

In the final step 4, the block is committed to a ledger stored at the node. In one embodiment, the entire block is first written to the ledger along with valid/invalid flags for its transactions. Then the write set of valid transactions is committed to the state database.

2A and 2B are block diagrams of a node 200 in a blockchain having a hardware accelerator 210, according to an example. In one embodiment, node 200 is any computing system that performs a validation process when committing a transaction to the blockchain. For example, node 200 may be an authorizing or unauthorized 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 include any number of processing cores. Memory 235 represents volatile memory, non-volatile memory (e.g., a hard disk drive), and combinations thereof. As shown, memory 235 stores ledger 240, which lists committed transactions of the blockchain.

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

The accelerator 210 includes a network interface 215 for receiving Ethernet packets containing data related to transactions, a protocol processor 220 for reformatting the data, a block processor 225 for executing the validation workflow, and a register map 230 (reg_map) (e.g., a memory register) for storing the results of the validation. The protocol processor 220, the block processor 225, and the register map 230 are described in more detail below. In general, these hardware blocks work together to validate a block of transactions received. That is, the network interface 215 receives multiple packets containing data corresponding to a block of transactions. This data may be in a format that is not suitable for processing, so the protocol processor 220 can reformat and output the data for consumption by the block processor 225. Although the block processor 225 performs most of the steps in the validation workflow, some of these steps may be performed by the protocol processor 220 and the register map 230. Furthermore, because the ledger 240 is stored in memory 235 (which may not be directly accessible by the accelerator 210), the node 200A may rely on the CPU 205 to commit verified transactions to the ledger 240. That is, the accelerator 210 stores the verification results in the register map 230, which the CPU 205 can evaluate and then commit the transactions to the ledger. That is, in one embodiment, all transactions are committed to the ledger, but the verification flags store information about which transactions were valid and which were invalid. However, only successfully validated transactions are committed to the state database (described below). While most of the verification is performed in the hardware accelerator 210, committing the transactions to the ledger 240 may be performed by software running on the CPU 205.

FIG. 2B illustrates node 200B, which is the same as node 200A of FIG. 2A, except for the addition of network interface card (NIC) 245. In one embodiment, NIC 245 provides node 200B with the ability to determine which network traffic flows through accelerator 210 and which network traffic flows through NIC 245. In one embodiment, all traffic related to blockchain may be sent through accelerator 210, and received network traffic not related to blockchain is processed by NIC 245. In contrast, in node 200A, all network traffic received by node 200A (whether blockchain traffic or non-blockchain traffic) may be received at accelerator 210. For example, protocol processor 220 may forward network traffic related to validation to block processor 225, but forward all other traffic to CPU 205.

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

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

Figure 3 illustrates an interface 300 between a protocol processor and a block processor in a hardware accelerator, according to one example. In this example, the interface 300 is used to transmit block data, transaction data (labeled tx data in Figure 3), acknowledgement data, read set data, and write set data to the block processor 225. That is, the protocol processor 220 receives Ethernet packets from other nodes in the blockchain (e.g., from an orderer in the ordering service) that contain information used to validate blocks of transactions. The protocol processor 220 then reformats/parses the data so that it can be consumed by the block processor 225.

Figure 4 is a flow chart of a method 400 for parsing packets and preparing data for hardware processing, according to one example. For ease of explanation, the blocks in method 400 are described in parallel with the following figures:

At block 405, a network interface in the accelerator receives packets containing separate components of a block of transactions. Because the blocks are typically too large to send in a single packet (e.g., blocks can be over 1 megabyte), the software application relies on the network protocol or software driver to chunk the block into multiple packets. However, the network protocol/driver typically has no knowledge of how the data is structured within the block, and therefore the data is typically transmitted in an ad-hoc manner. This makes it difficult, if not impossible, for a hardware accelerator to parse the received packets and reconstruct the block of transactions. However, embodiments herein describe techniques for transmitting the block of transactions such that the hardware accelerator can parse the packets to reconstruct the different components within the block of transactions.

5A illustrates transmitting separate packets for each component in a block 505 of a transaction, according to one example. Specifically, FIG. 5A illustrates a communication system 500 in which a sender 515 (e.g., an orderer or other peer node in a blockchain) transmits packets 520 to a hardware accelerator 210 so that these packets can be parsed precisely so that a block message 505 can be reconstructed. To do so, software in the sender 515 splits the block message 505 into its separate 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 separate packets, software on the sender 515 (which knows the structure of the block 505) can split the block into its components 510.

5A illustrates a sender 515 transmitting packets 520A-520G to a hardware accelerator 210 over a network, e.g., a private or public network such as the Internet. As shown, each packet 520 contains only one of the components 510, i.e., packet 520A contains the header of block 505, packets 520B-520F each contain one of the transactions, and packet 520G contains metadata for block 505. If software did not split block 505 into its components 510, the network protocol or driver might have sent a first packet containing the header and part of TX1, a second packet containing the remaining data of TX1 and part of TX2, and so on. This unpredictable branching of different components 510 within block 505 can make it difficult to design hardware accelerator 210 to parse the data so that block 505 can be reconstructed.

5A, the sender 515 may also remove the signed certificates associated with the components 510. These certificates may be used to verify the blocks 505 and the transactions within the blocks. However, these certificates (e.g., x509 certificates) are large, which means that sending them to the accelerator 210 requires a significant amount of bandwidth. In one embodiment, the sender 515 removes the certificates from the blocks 505 before forming the packets 520 and then sending them to the accelerator 210. Instead, the sender 515 may replace the certificates with an ID (e.g., an 8-bit code). In one embodiment, the sender 515 transmits the certificates to the accelerator 210 separately at a time, which can then cache the certificates for later retrieval. In this way, if a certificate is associated with multiple components 510 in the block 505, the certificate is sent once, not repeatedly.

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

The block machine protocol header 530 includes a message type (MsgType) and an annotation. The message type indicates whether the data in the payload 535 is a block header, a transaction, or metadata. The annotation points out the location of the important data. For example, the annotation may include a pointer to relevant data in the packet 520 (e.g., where specific data in the payload 535 can be found) and a locator that points to data in a cache or in a different packet (but in the same block). In one embodiment, the locator in the annotation is used to mark the ID of the packet 520. The payload 535 may include data corresponding to a specific component 510 being sent in the packet, i.e., metadata from the block 505.

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

6 is a block diagram of a protocol processor 220 in a hardware accelerator, according to an example. As shown, a data packet 520 is received at a packet filter 610 that parses a level 4-7 (L4-L7) packet header (e.g., block machine protocol header 530) to extract a message type and annotations. The message type may include block start, block metadata, transaction, etc. The message payload annotations may include block header location, block signature location, block ID, transaction data start, channel name, transaction ID, chaincode name, creator certificate authority (CA) ID, transaction action, transaction CA ID, contract name, contract input, approver action, read/write set, approver list, transaction signature, orderer CA ID, orderer signature, certificate ID, certificate public key data, valid since information, valid through information, etc. The packet filter 610 also identifies the sequence number in the transport header and forwards this number to the response generator 605, which sends a response packet (e.g., an acknowledgment packet) back to the sender (e.g., the orderer).

The packet filter 610 forwards the message type, annotation, and packet payload to the block extractor 615, which processes the message payload based on the annotation and extracts relevant data for the block processor 225. The block extractor 615 also provides 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 the block processor 225 are described in the remainder of the method 400 and in the following figures.

Returning to method 400, at block 410, a block extractor in the protocol processor uses the ID in the packet to identify the signed certificate that corresponds to the packet. As mentioned above, the sender may strip the certificate from the block before transmitting the block to the hardware accelerator in multiple packets. This may be done because the certificates are large and rarely change. Thus, replacing the certificate with a much smaller ID or key in the packet that references the certificate may save significant bandwidth and ensure that each component in a block of a transaction can be transmitted in a single packet.

However, when a packet is received, the block extractor may need the certificate to validate the block (and the transactions within the block) and ensure that the syntax of the block and transactions is correct. The block extractor can then reconstruct the components, which means that the block extractor identifies and retrieves the certificate.

Figure 7 is a block diagram of a block extractor 615, according to one embodiment. As shown, the block extractor 615 includes a data inserter 705 that receives the packet payload and annotations and identifies the certificate (or certificates) corresponding to the payload. For example, if the payload is block metadata, the payload may include an ID corresponding to the certificate of the orderer that prepared the block. If the payload includes a transaction, the payload may include an ID corresponding to the client that submitted the transaction and one or more IDs corresponding to the approving nodes that approved the transaction. Thus, the data inserter 705 may identify multiple IDs in the payload.

Using the ID, the data inserter 705 performs a lookup in the identity cache 710 to retrieve the signed certificate that corresponds to the ID. That is, when the orderer sends the certificates to the accelerator, the accelerator stores those certificates (and their corresponding IDs) in the identity cache 710 so that it can retrieve these certificates when validating blocks of transactions.

Returning to method 400, at block 415, the block extractor 615 reconstructs the separate components of the block. That is, as each payload is received, the block extractor 615 can extract the corresponding certificate. This is shown in FIG. 7, where the data inserter 705 transmits the extracted certificate (or certificates) along with other data in the payload to the data extractor 715.

The data extractor 715 may reconstruct components within a block of transactions at different times. For example, during time 1, the data extractor 715 may reconstruct the header of the block using the first received packet, at time 2, the data extractor 715 may reconstruct the first transaction in the block using the second received packet, and so on. Thus, the block extractor 615 may be pipelined such that different components within a block may be executed in parallel at different stages (e.g., different circuit modules) within the extractor 615.

At block 420, hash calculator 720 calculates a hash of the separator components in the block. In one embodiment, hash calculator 720 generates a hash for the entire block, every transaction in the block, and every acknowledgement for 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 hashes for all acknowledgements associated with that transaction) when it receives a packet corresponding to the transaction. However, hash calculator 720 may wait to calculate a hash for the entire block after it has received all packets for the block.

At block 425, hash checker 725 determines whether the hash calculated by hash calculator 720 matches the hash in the packet. That is, the packet transmitted by the sender may include a previously calculated 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 calculate hashes for the block, each transaction in the block, and each acknowledgement in the transaction, and transmit those hashes to accelerator 210. If these hashes match the local hash generated by hash checker 725, this means that the message is valid and the proper syntax for the block and transactions was followed. If the hashes do not match, the method proceeds to block 445, where the hardware accelerator indicates that the received data has a syntax error. In one embodiment, the hardware accelerator sends a response message to the sender indicating that the validation process failed.

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

At block 435, the task generator 730 generates tasks for the block processor to complete the validation process. In one embodiment, the task generator 730 generates block tasks, transaction tasks, and approver tasks. The block tasks may include a block ID, a block signature (e.g., the certificate of the orderer that generated the block), etc. The transaction tasks may include a transaction ID, a transaction signature (e.g., the certificate of the client that generated the transaction), a transaction read/write set, etc. In one embodiment, the task generator 730 generates a transaction task for each transaction in the block. The task generator 730 may also generate approver tasks for each approval in the transaction. That is, since each transaction may receive several approvals, the task generator 730 may generate a task for each of those approvals.

In block 440, the task generator 730 transfers the tasks and corresponding data to the block processor in the hardware accelerator. The block processor can then verify the blocks, transactions, and acknowledgements. In general, the protocol processor (and its circuit components illustrated in Figures 5-7) analyzes the received packets and reformats the data of the blocks into a format that can be summarized or processed by the block processor without the aid of software. Thus, the verification process in the blockchain is performed entirely by hardware, thereby reducing the time and computational resources required for this process.

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

Method 800 assumes that the hardware accelerator has already received, e.g., from an ordering service, a block of transactions that needs to be validated before they can be committed to the ledger. Method 800 further assumes that the protocol processor has performed a block syntax check (e.g., "blk syntax check" in FIG. 1) and a transaction syntax check (e.g., "tx syntax check" in FIG. 1) to ensure that all data necessary to perform the validation has been received.

At stage 805, the hardware accelerator verifies the signature on the block of transactions. More specifically, the block processor can receive the information shown in FIG. 3 from the protocol processor and perform block verification. As shown in FIG. 9, the block processor 225 includes two hardware submodules: block verification 905 and block validation 910. Block verification 905 includes an elliptic curve digital signature algorithm (ECDSA) engine 920 to verify the orderer signature on the block. In other words, the ECDSA engine 920 compares the received signature in the block with a known signature (e.g., a certificate) for the orderer to ensure that they match. In this way, the block verification 905 can verify that the block of transactions came from a recognized node. Although an ECDSA engine 920 is shown, any suitable signature algorithm engine can be used.

In addition to including the orderer signature, the block data received in block confirmation 905 may also include the block number, the number of transactions in the block, etc.

Returning to method 800, at stage 810, the hardware accelerator verifies multiple transactions in a block. In FIG. 9, this function is performed by block verification 910. That is, while block confirmation 905 ensures that a block was received by a known orderer, block verification 910 verifies individual transactions in a block. To do this, block verification 910 receives transaction data, acknowledgement 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, including verification results such as block number, valid/invalid transaction flags, and latency.

In one embodiment, block confirmation 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 confirmation 905 (pipeline stage 1), while block verification 910 processes the second block of transactions (pipeline stage 2). In other words, block confirmation 905 can use ECDSA engine 920 to ensure that an authorized orderer has transmitted the first block at the same time that block verification 910 verifies the 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 confirmation 905 and block verification 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 (e.g., the number of blocks processed per unit time).

Further, FIG. 8 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, which illustrates a more detailed view of block verification 910 of FIG. 9.

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

The presence of multiple transaction confirmation blocks 1005 allows stage 2a to verify client signatures for multiple transactions in parallel. Determining how many transaction confirmation blocks 1005 a block verification 910 includes is a design choice. Having additional transaction confirmation blocks 1005 means that 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, in stage 820, block validation 910 verifies the authorization of each transaction using the authorization policy. As shown in FIG. 10, pipeline stage 2b includes multiple transaction VSCC blocks 1010, each of which includes multiple ECDSA engines 1015 (or any other type of signature verification engine) and authorization policy evaluator 1020. Each transaction VSCC block 1010 verifies the authorization of a particular transaction. To do so, the transaction VSCC block 1010 receives authorization data including an approver ID and verification data. Because a client transaction may receive multiple authorizations (as shown in FIG. 1), each ECDSA engine 1015 can evaluate one of the authorizations in parallel. That is, if transaction A receives two approvals, ECDSA engine 1015A can verify that the first approval was signed by an authorized approval node, while ECDSA engine 1015B verifies that the second approval was signed by an authorized approval node. Again, the number of ECDESA engines 1015 in each block 1010 is a design choice.

In one embodiment, the authorization policy evaluator 1020 can maintain an authorization policy for each chaincode. The evaluator 1020 verifies that the transaction received proper authorization. That is, assuming authorization was given by a recognized authorization node, the evaluator 1020 verifies that the transaction received authorization from the appropriate authorization node. For example, if a transaction indicates that money should be transferred between two banks, the evaluator 1020 may check to ensure that the transaction received authorization from authorization nodes operated by both of those banks. If the transaction is approved by an authorization node for only one bank, or by a different bank that is not affected by the transaction, the evaluator 1020 may invalidate the transaction.

Because stage 2b includes multiple transaction VSCC blocks 1010, block validation 910 can check authorizations for multiple transactions in parallel. That is, after stage 2a verifies that a transaction was originated by an authorized client, stage 2b can verify that the transaction's authorizations are valid and satisfy one or more authorization policies. The number of transaction VSCC blocks 1010 in block validation 910 is a design choice.

Returning to method 800, in stage 825, block verify 910 performs a version check and commits the write key to state database 1030. This is performed by stage 2c, which includes a transactional MVCC write block 1025 communicatively coupled to state database 1030 and a register map (not shown in FIG. 10). In addition, the register map is optionally coupled to a CPU (not shown) in the node. In one embodiment, transactional MVCC write block 1025 looks up the read key from state database 1030, performs a version check, and if verified, commits the updated write key of the valid transaction to database 1030. To do so, transactional MVCC write block 1025 receives read set data (each element includes a read key-version pair) and write set data (each element includes a write key-value pair) from the protocol processor. In one embodiment, state database 1030 includes an internal locking mechanism to not allow reads of the key currently being written (or updated).

Stages 2a-2c of FIG. 10 may be pipelined. That is, while FIG. 9 illustrates a block-level pipeline between block confirmation 905 and block verification 910, FIG. 10 illustrates a transaction-level pipeline in which transactions within a particular block may be processed in parallel within stages 2a-2c. 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 from the same block. That is, one stage in block verification 910 may not be able to process transactions from a first block, but a different stage processes transactions from a second block.

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

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 validation results to determine whether each individual transaction in the block of transactions was validated. The client can then choose to resubmit the invalid transaction.

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

In the foregoing, reference is made to the embodiments presented in this disclosure. However, the scope of the disclosure is not limited to the specific described embodiments. Instead, any combination of the described features and elements, whether related to different embodiments or not, is contemplated for implementing and practicing the contemplated embodiments. Furthermore, the embodiments disclosed herein may achieve other possible solutions or advantages over the prior art, but whether or not a particular advantage is achieved by a given embodiment does not limit the scope of the disclosure. Thus, the foregoing aspects, features, embodiments, and advantages are merely exemplary and are not considered elements or limitations of the appended claims unless expressly recited in the claims.

As will be appreciated by one of ordinary skill in the art, the embodiments disclosed herein may be embodied as a system, method, or computer program product. 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 may be referred to generally herein as a "circuit," "module," or "system." Additionally, 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 therein.

Any combination of one or more computer readable media may be utilized. The computer readable medium may be a computer readable signal medium or a computer readable storage medium. The 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 of the foregoing. More specific examples (non-exhaustive list) of computer readable storage media include an electrical connection having one or more wires, a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the context of this specification, 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 medium may include a propagated data signal in which computer-readable program code is embodied, for example, in baseband or as part of a carrier wave. Such a propagated signal 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 is not a computer-readable storage medium, but may be any computer-readable medium capable of communicating, propagating, or transporting a program for use by or in connection with an instruction execution system, apparatus, or device.

The program code embodied on the computer readable medium may be transmitted using any suitable medium, including but not limited to wireless, wireline, fiber optic cable, RF, or the like, or any suitable combination of the foregoing.

Computer program code for carrying out the operations of aspects of the present disclosure may be written in any combination of one or more programming languages, including, for example, object-oriented programming languages such as Java, Smalltalk, C++, and traditional procedural programming languages such as the "C" programming language or similar programming languages. The program code may run completely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer, partially on a remote computer, or completely on a remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer via any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (e.g., via the Internet using an Internet Service Provider).

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 in the present disclosure. It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general purpose computer, a special purpose computer, or other programmable data processing device such that the instructions, executed via a processor of the computer or other programmable data processing device, result in a machine that creates means for performing the functions/acts specified in the blocks of the flowcharts and/or block diagrams.

These computer program instructions may also be stored on a computer-readable storage medium, where the instructions stored on the computer-readable storage medium can direct a computer, programmable data processing device, and/or other device to function in a particular manner to produce an article of manufacture that includes instructions that implement aspects of the functions/acts specified in the blocks of the flowcharts and/or block diagrams.

Computer program instructions may also be loaded into a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be executed on the computer, other programmable apparatus, or other device to generate a computer-implemented process, such that the instructions executing on the computer or other programmable apparatus provide a process for implementing the functions/acts specified in the flowchart and/or block diagram blocks.

The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block of the flowchart or block diagram may represent a module, segment, or portion of instructions, including one or more executable instructions for implementing a specified logical function. In some alternative implementations, the functions described in the blocks may occur out of the order described in the figures. For example, two blocks shown in succession may in fact be executed substantially simultaneously, or the blocks may be executed in reverse order, depending on the functionality involved. It should also be noted that each block of the block diagrams and/or flowchart illustrations, as well as combinations of blocks in the block diagrams and/or flowchart illustrations, may be implemented by a dedicated hardware-based system that performs the specified functions or acts, or a combination of dedicated hardware and computer instructions.

The disclosed technology can be expressed by the following non-limiting examples in addition to those described in the claims.

Example 1. An integrated circuit for accelerating a validation process for a blockchain, comprising: a network interface configured to receive a plurality of packets including a block of transactions from a node in the blockchain; a protocol processor configured to analyze the plurality of packets to generate data regarding the transactions; and a block processor configured to verify the signature of the block, verify each of the transactions in the block, and store validation results of the transactions.

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

Example 3. The integrated circuit according to Example 2, wherein the SoC or FPGA includes programmable logic.

Example 4. The integrated circuit of example 2, wherein the ASIC includes only the hardening circuitry.
Example 5. The integrated circuit of example 1, wherein the block processor includes a block confirmation including a first signature algorithm engine configured to verify that a signature of the block matches a known signature of an orderer in the blockchain, and a block validation configured to verify each of the transactions in the block.

Example 6. The integrated circuit of Example 5, including a transaction verification module including 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 third signature algorithm engine configured to verify that an authorization in a transaction was signed by a known authorization node in the blockchain, an authorization policy evaluator configured to ensure that the authorization satisfies an authorization policy, and a transaction multi-version concurrency control (MVCC) write block configured to read and write key-value pairs associated with the transaction in a state database.

Example 7. The integrated circuit of Example 6, in which block validation includes a plurality of transaction verification modules configured to operate in parallel to verify signatures of a first set of transactions and a plurality of transaction VSCC blocks configured to operate in parallel to verify authorizations of a second set of transactions, the plurality of transaction verification modules forming a first stage of a pipeline and the plurality of transaction VSCC blocks forming a second stage of the pipeline, such that the plurality of transaction verification modules process the first set of transactions at the same time that the plurality of transaction VSCC blocks process the second set of transactions.

Example 8. The integrated circuit of example 7, wherein each of the multiple transaction verification modules includes multiple algorithmic signature engines for verifying in parallel the set of acknowledgements in one of the transactions.

Example 9. The integrated circuit of Example 2, wherein block confirmation forms a first stage in the pipeline and block verification forms a second stage of the pipeline, such that block confirmation can process a first block of blockchain transactions at the same time that block verification processes a second block of blockchain transactions.

Example 10. A method including: receiving, at a hardware accelerator, a block of transactions to be committed to a blockchain ledger; verifying, at the hardware accelerator, a signature of the block; verifying, at the hardware accelerator, each of the transactions in the block; storing, at the hardware accelerator, a result of the transaction verification; committing the transaction to the ledger; and indicating whether the transaction is valid based on the result of the verification.

Example 11. The method of example 10, wherein receiving the block of transactions includes receiving a plurality of packets that include the block of transactions, and the method further includes parsing the plurality of packets at the hardware accelerator to generate data regarding the transactions.

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

Example 13. The method of example 10, wherein validating each of the transactions in the block further includes verifying that the endorsements in the transaction were signed by a known endorsement node in the blockchain and ensuring that the endorsements in the transaction satisfy an endorsement policy.

Example 14. An integrated circuit for accelerating a validation process for a blockchain, the integrated circuit including: a data inserter configured to receive a plurality of packets corresponding to a block of transactions to be committed to a ledger of the blockchain; a hash calculator configured to generate hashes of different components in the block of transactions; a hash checker configured to determine whether the hash matches a previously calculated hash; and a task generator configured to generate tasks to validate the block of transactions.

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

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

Example 17. The integrated circuit of example 15, wherein the ASIC includes only the hardening circuitry.
Example 18. The integrated circuit of example 14, wherein the block of transactions includes a block header, a plurality of transactions, and metadata, the block header, each of the plurality of transactions, and each of the metadata are transmitted in a separate packet of the plurality of packets, and the plurality of packets does not include a signed certificate corresponding to the block or the plurality of transactions.

Example 19. The integrated circuit of Example 18, further comprising an identity cache that stores local copies of signed certificates corresponding to recognized nodes in the blockchain, and the data inserter is configured to retrieve from the identity cache the signed certificate corresponding to the block of transactions using the IDs included in the plurality of packets.

Example 20. The integrated circuit of Example 19, further comprising a data extractor configured to reconstruct a block of transactions using the data in the plurality of packets and the retrieved signed certificate, a hash calculator configured to generate a hash using the reconstructed block of transactions, and a hash checker configured to check whether the generated hash matches a previously calculated hash to ensure that the block of transactions does not contain syntax errors.

While the foregoing is directed to certain embodiments, other and further embodiments may be devised without departing from the basic scope thereof, which scope is determined by the following claims.

Claims (15)

1. A computing system comprising:
A processor;
A memory that stores the blockchain ledger;
A hardware accelerator, comprising:
receiving a plurality of packets corresponding to a block of transactions to be committed to the ledger;
generating hashes of different components within said block of transactions;
and if the hash matches a previously calculated hash, generating a task at the hardware accelerator to validate the block of transactions;
2. The computing system of claim 1 , wherein the processor or one of the hardware accelerator is configured to commit the block of transactions to the ledger if the processor or one of the hardware accelerator determines that the block of transactions is valid. The computing system of claim 1, 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 the metadata are transmitted in separate packets of the plurality of packets. The computing system of claim 2, wherein the packets do not include signed certificates corresponding to the blocks or the transactions. The hardware accelerator,
an identity cache that stores local copies of the signed certificates corresponding to recognized nodes in the blockchain;
and a data inserter configured to retrieve from the identity cache a signed certificate corresponding to the block of transactions using an ID included in the plurality of packets. The hardware accelerator,
a data extractor configured to reconstruct the block of transactions using data in the plurality of packets and the retrieved signed certificate;
a hash calculator configured to use the reconstructed block of a transaction to generate a hash corresponding to the block of a transaction;
and a hash checker configured to check whether the generated hash matches a previously calculated hash to ensure that the block of transactions does not contain syntax errors. 1. A computing system comprising:
A processor;
A memory that stores the blockchain ledger;
A hardware accelerator, comprising:
receiving a block of transactions to be committed to the ledger;
Verifying the signature of the block; and
validating each of the transactions in the block;
and storing a verification result of the transaction.
1. A computing system, wherein one of the processor or the hardware accelerator is configured to commit the transaction to the ledger. The hardware accelerator,
a network interface configured to receive the block of transactions from another node in the blockchain, the block of transactions being included in multiple packets; and
a protocol processor configured to analyze the plurality of packets to generate data regarding the transaction;
and a block processor configured to receive the data from the protocol processor, verify the signature of the block, and validate each of the transactions in the block. The block processor:
a block validation including a first signature algorithm engine configured to validate that the signature of the block matches a known signature of an orderer in the blockchain;
and a block validator configured to validate each of the transactions in the block. The block verification comprises:
a transaction validation module including a second signature algorithm engine configured to validate that a signature corresponding to the 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 an acknowledgement in the transaction was signed by a known acknowledgement node in the blockchain; and
an authorization policy evaluator configured to ensure that the authorization satisfies an authorization policy; and
and a transactional multi-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 of claim 1 or 6, wherein the hardware accelerator comprises at least one of a system on chip (SoC), a field programmable gate array (FPGA), or an application specific integrated circuit (ASIC). 1. A method comprising:
receiving, at the hardware accelerator, a plurality of packets corresponding to a block of transactions to be committed to the blockchain ledger;
Calculating hashes of distinct components within the block of transactions in the hardware accelerator;
determining, in the hardware accelerator, that the hash matches a previously calculated hash;
generating a task at the hardware accelerator to validate the block of transactions. The method of claim 11, 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 the metadata are transmitted in separate packets of the plurality of packets. The method of claim 12, wherein the packets do not include signed certificates corresponding to the blocks or the transactions. storing local copies of the signed certificates corresponding to recognized nodes in the blockchain in an identity cache of the hardware accelerator;
14. The method of claim 13, further comprising: retrieving a signed certificate corresponding to the block of transactions from the identity cache using an ID contained in the plurality of packets. reconstructing the block of transactions using data in the packets and the retrieved signed certificate;
The hash is calculated using the reconstructed block of a transaction;
15. The method of claim 14, wherein the determining that the hash matches the previously calculated hash indicates whether the block of a transaction contains a syntax error.

Images