## 3 Testing Framework
### Cloud Computing Configuration
#### 3.3.1 Quorum  
Quorum has a number of configuration options, see Table 2. Prior to running our tests we experimented with various configurations in order to optimise the setup to best meet the requirements of the use-case. We experimented with different block periods; 1, 3, 5 and 10 s. Maximum throughput is achieved by optimising for the minimum block period where consensus is reached, in this case, a block period of 5 s.  
The validator node cache is the amount of memory allocated to internal caching and is set to 14 GB, leaving 2 GB of memory for the OS. In comparison, a default full node on Ethereum's mainnet has 4 GB allocated to cache. The transaction pool for global slots was set to 100,000 transactions (the default is 4096), which is the maximum global number of executable transaction slots for all accounts. The transaction pool global and account  
\begin{table}
\begin{tabular}{l c} \hline \hline
**Parameter** & **Value** \\ \hline \hline \multicolumn{2}{c}{_Quorum_} \\ \hline istanbul.blockperiod & 5 s \\ cache & 14 GB \\ tpool.globalslots & 100,000 tx \\ tpool.globalqueue & 1,000,000 tx \\ tpool.accountqueue & 1,000,000 tx \\ block.gasLimit & 50,000,000 \\ \hline \multicolumn{2}{c}{_Tendermint_} \\ \hline mempool.size & 560,000 tx \\ mempool.cache\_size & 600,000 tx \\ mempool.max\_txs\_bytes & 1 GB \\ mempool.recheck & false \\ \hline \multicolumn{2}{c}{_Hyperledger Fabric_} \\ \hline endorsement policy & any \\ batchsize & 300 tx \\ kafka\_default\_replication\_factor & 5 \\ kafka\_min\_insync\_replicas & 3 \\ \hline \multicolumn{2}{c}{_Kafka_} \\ \hline num.network.threads & 8 \\ num.io.threads & 8 \\ offsets.topic.replication.factor & 3 \\ transaction.state.log.min.isr & 3 \\ \hline \hline \end{tabular}
\end{table}
Table 2: Configuration for Quorum, Tendermint, Hyperledger Fabric and Apache Kafka.  
queue is set to 1,000,000 transactions (the default is 1024), which is the maximum number of global and account non-executable transaction slots for all accounts. We experimented using 20,000 transactions for global slots and queue, based on the performance review on Quorum's GitHub page [4], but in our experiments we achieved optimal performance using a value of 100,000. We reserve a single thread for the OS and allocate all remaining threads for each core to validator nodes.  
When testing with the default value of 3,758,096,384 as the gasLimit, latency is significant and we received only a few very large blocks that require multiple minutes of processing each. In order to optimize for our use-case (a preference for a steady flow of blocks) we decreased the gasLimit to 50,000,000 (as recommended by Microsoft [34]).  
The two scenarios described in Section 3.1 were tested with the three different data storage methods allowed by the Quorum blockchain, State, Memory and Calldata. These three data storage methods are tested through implementation of three different smart contracts. Since Quorum is based on Ethereum, much of the terminology and functionality are the same, e.g., the concept of gas as the computational incentive for smart contract execution. Further, each block has an upper limit on the allowed computational effort (measured in gas). Since the three storage methods have different gas costs, it is important to investigate the performance implications of each.