BPU: A Blockchain Processing Unit for Accelerated Smart Contract Execution

What is BPU?

• A high-performance modularized blockchain processing unit
• BPU aims at bringing performance and flexibility to the blockchain and DApp processing.

The necessity of BPU

• To trigger the functions in Smart Contract, users need to broadcast a transaction to the network targeting the contract account. 

(SCs can be treated as a condition checking logic and a state updating method, even though they could be implemented differently.)

• In blockchain, these transactions are collected by all the participating nodes and executed locally in a distributed manner. 

-> This procedure is called the transaction processing. 

• Transaction processing is very time consuming and inevitable for all full nodes in blockchain. When a new node joins the network, it needs to sync all the blockchain history from peers and re-exeute all the transactions locally in order to build up its own history copy.
• Once the synchronization is done, the node continues to process new blocks received in the network as a maintainer.

-> At this time, its poor performance on processing transactions also limits the throughput of the whole system, which prevents blockchain from replacing current established centralized systems.

• SC transaction will modify the state of the contract storage.

-> Compared to token transfer transactions, smart contract transactions are much slower and more computationally intensive.

• Meanwhile, the proportion of smart contracts in a block is increasing as the time goes.
• BPU out-performs the current software implementation on CPU with the help from architectural optimization.

=> proposed a modularized architecture using pipeline optimization to improve the performance of blockchain processing, especially the SCs execution.

The components and dataflow of BPU architecture

• BPU will read data from Input Buffer via a Scheduler, process the transactions in the Transaction Processor (TP), and finally write the result to the Receipt Buffer. 
• The essential parts of TP are an Application Engine and an General Smart Contract (GSC) Engine.
  • Application Engine is deeply optimized to accelerate specific applications or standardized SCs
  • GSC handles the general purpose SCs.
• TransBuf stores the transactions to be executed, which contains a series of fixed-length parameters, such as the 160-bits address, the 80-bits value etc., and an arbitrary length byte array Inputdata.
• We stored the fixed-length part and variable-length part separately in Transaction information buffer (TransInfo) and transaction input buffer(TransInput) respectively.

-> concatenate the fixed-length data together and read them as a single piece at one cycle.

-> also makes it possible for App Engine to read both sections concurrently. 

• StateDB contains the state before the transactions get processed, including all the related accounts and target contracts. 

(It has the Code and Storage buffers and AccountInfo buffer seperately.)

• The Scheduler is a module that reads data from the input buffer and fills the Local Buffer (LocalBuf) with the appropriate format.
  • identify the function being called and distribute the transaction to either EVM Engine or Application engine using the first eight bytes of the input data. (the identifier of the function)
  • save the target code field and storage field data to the LocalBuf in order to set up the local copy for Transaction Processor (TP).
• Local Buffer is a piece of cache that saves a copy of the target contract.
  • Transaction Information Buffer (TIB) - provides contract address, sender address and input argument.
  • Local Database (LDB) - serves as a copy of the preprocessing state.

•  If the transaction is executed successfully -> LDB will overwrite the StateDB.

(It has the Code and Storage buffers and AccountInfo buffer seperately.)

•                                                        -> LDB will be discarded so that StateDB is unchanged, which is also called “revert”
• Before the execution, the scheduler will move the target data from Input Buffer into the local buffer. When the execution starts, the controller will fetch the target code using Program Counter (PC) and apply a pre-decoding check.

•  If the decoder is ready, the controller pushes the instruction into the decoding stage -> decode the operation and choose the appropriate submodule of interpreter to send. -> the temporary result is latched and stored to the Stack and Memory in the writeback stage.
•  the EVM Engine decides to terminate, it will generate an EVM receipt based on the status of the local memory and stack, and return to the Receipt Buffer.

Special optimization on these opcode executions in order to achieve better performance.

• In early versions of Ethereum ISA, there is no bit shifting operations. -> They are always implemented by 256-bit division (DIV) operation.
• Due to the lack of shifting, compilers often implement these by using the 256-bit integer divided by constant value 2 224, in order to get first 8 bytes.
• In practice, such big number division and exponent operation is very time consuming if implemented by dividers and multipliers, so we optimize such special cases using bit shifting registers, which significantly saves the time and reduces the additional cost.

•  Two input units will read the 160-bits receiver’s address and sender’s address respectively, and then calculate the corresponding keccak256 hash value. The other input unit will read the transaction data field and get the amount of tokens to be transferred. The ALU will calculate the output value. The Assertion unit is used to revert the execution by discarding the current state changes, if specific conditions do not meet.
• Finally results will be passed to the DBWrite unit and Receipt generation unit to finalize the transaction. All the above modifications are done to the local database and if everything goes well, the world state will be overwritten at the last step.