Transaction flow

1 Solution

User sends RPC request to node through SDK or curl command to start transaction. Node adds transaction to TxPool after receiving it. Sealer will constantly take out transactions from TxPool and pack them into block through certain conditions. After the blocks are generated, they will be verified as consensus by consensus engine. If there are no mistakes and consensus is made among nodes, the blocks will be taken on chain. When node using sync model to download missing blocks from other nodes, the execution and verification on blocks will be conducted also.

2 Structure

The overall structure is as below:

../../../_images/transaction_stream.jpg

Node: Node of block

TxPool: transaction pool, the memory area maintained by node itself for temporarily saving recerived transactions

Sealer: block packager

Consensus Engine: consensus engine

BlockVerifier: block verifier, to verify the correctness of a block

Executor: execution engine, to execute single transaction

BlockChain: administration model of blockchain, the only authorized model. User should input block data as well as execute contextual data before submiting block interface. This administration model will combine the two types of data into one and send to the bottom storage

Storage: the bottom storage

main relations are as followed:

  1. User starts transaction through SDK or curl command to the connected node.

  2. When node receives transaction, if the current TxPool is not full, node adds transaction to TxPool and propagates to connected nodes; otherwise node discards transaction and output warning notification.

  3. Sealer constantly draws transactions from TxPool and packs them into blocks and sends to consensus engine.

  4. Consensus engine calls BlockVerifier to verify block and do consensus process. BlockVerifier calls Executor to execute every transaction within blocks. When the block is verified and is commonly agreed by nodes within network, consensus engine will send it to Blockchain.

  5. BlockChain receives block and checks the information (block number, etc.), then inputs the block data and table date to bottom storage and moves the block on chain.

3 Process

3.1 Contract Executive Process

Executive engine executes single transaction based on Executive Context, which is created by block verifier to cache data generated by executive engine during execution of temporarily-stored blocks. Executive engine supports both EVM contract and precompiled contract. EVM contract can be created through transaction or contract. The executive process is as below:

../../../_images/EVM_contract_execution.png

After the EVM contract is created and saved in table sys_contracts of executive context, the address of EVM contract will auto-increment in global state starting from 0x1000001 (customizable). During the execution of EVM contract, Storage variable is saved in table c_(contract address) of executive context.

Precompiled contract can be divided into permanent type and temporary type: (1) permanent precompiled contract, integrated in bottom or components with fixed address; (2) temporary precompiled contract, dynamically created during execution of EVM contract and precompiled contract, the address will auto-increment in executive context starting from 0x1000 and ending at 0x1000000. Temporary precompiled contract is only valid in executive context. Precompiled contract has no Storage variable but has to operate table with process like below:

../../../_images/precompiled_contract_execution.png