3.1.2. Transaction-Processing Architecture

For most of the blockchain systems, a consensus of the order of transactions in a block must be reached before calculating the results of the transactions. Since each node will calculate the results independently to verify the results, the order of the transactions must be determined to maintain consistency among nodes. This architecture renders the computational resources of the blockchain system un-scalable. To solve this problem, HLF adopts a different transaction-processing architecture called "execute-order-validate" [4], in which transactions are calculated concurrently by multiple endorsers then ordered by OSN and later validated by peers.

### 3.1.3. Storage Structure of A Peer

The storage structure of an HLF peer comprises a chain of blocks and several local databases. In HLF, a block consists of three parts [21]:

	- **–** *Block Number* is the sequence of the current block. The block number is counted from 0. The first block is called genesis block.
	- **–** *Data Hash* is the hash value of all the transactions that are recorded in the current block.
	- **–** *Previous Hash* is the Data Hash of its previous block.

The blocks are chained together through the "Previous hash", and they are stored in the file system as block files. The size of block files is configured before the network is started so that the number of blocks that each block file contains is determined.

The blocks preserve all original information pertaining to each transaction, but for data retrieval, local databases are needed to provide the necessary functionality:

