## 5 Key Findings  
The key performance findings are summarized in Table 6. Based on the performance claims made in the framework survey in Table 1, we assumed from the outset that Tendermint would be faster than Quorum with the reasoning that the smart contract layer is implemented in GOLANG compared to the implementation of smart contracts in Quorum running on the distributed Etherum Virtual Machine. This proved not to be the case using our testing regime, however Tendermint might still outperform Quorum in a computational intensive use-case--one relying on the presence and interaction of many smart contracts. Although this is not proven, it underscores an important learning: tuning the platform choice to the application use-case is important and will influence design choices made in future systems. System developers need to ask themselves, how much smart contract activity is anticipated and how important are smart contract transactions to the orderly operation of the e-business ecosystem? Hyperledger Fabric was used as a baseline since it is one of the most popular enterprise blockchain frameworks, and while it is not Byzantine fault tolerant (BFT), it is crash fault tolerant (CFT), and would therefore be expected to be faster than its BFT alternatives. This proved to be the case, but only for maximum throughput, not for average throughput. Apache Kafka, uncoupled from Hyperledger Fabric, was tested in order to have a distributed CFT alternative that runs on the same infrastructure. Uncoupling was performed to understand the performance gap between Hyperledger Fabric using Apache Kafka and plan Apache Kafka, under identical network, hardware and transaction loads. \begin{table}
\begin{tabular}{c c c c} \hline
**Quorum** & **Type** & **Max (tps)** & **Average (tps)** \\ \hline \multirow{3}{*}{2 KB} & Calldata & 622 & 360 \\  & Memory & 620 & 323 \\  & State & 205 & 182 \\ \hline \multirow{3}{*}{10 KB} & Calldata & 139 & 125 \\  & Memory & 139 & 120 \\  & State & 43 & 39 \\ \hline \multirow{2}{*}{**Tendermint**} & **Block size** & **Max (tps)** & **Average (tps)** \\ \hline \multirow{3}{*}{2 KB} & 2 MB & 337 & 164 \\  & 4 MB & 472 & 120 \\ \hline \multirow{3}{*}{10 KB} & 2 MB & 76 & 31 \\  & 4 MB & 58 & 29 \\ \hline \multirow{2}{*}{**Hyperledger Fabric**} & **\#ch** & **Max (tps)** & **Average (tps)** \\ \hline \multirow{3}{*}{2 KB} & 1 & 763 & 245 \\  & 4 & 723 & 142 \\ \hline \multirow{3}{*}{10 KB} & 1 & 714 & 137 \\  & 4 & 678 & 130 \\ \hline \end{tabular}
\end{table} 
Table 6: Throughput results for all Blockchain frameworks, averages and maximums for 2 KB and 10 KB transaction sizes, Quorum, Tendermind and Hyperledger Fabric. The best 2 KB throughput is highlighted in red, The best 10 KB throughput is highlighted in orange. Unexpectedly, the average tps is faster for Quorum than for Hyperledge Fabric. From Table 5, the findings are that Hyperledger Fabric handles large messages well in comparison to its overall performance. Furthermore, Hyperledger Fabric incurs a performance penalty when using multiple channels with 28 participants on small machines. Other work [36] has shown that endorsement policies are highly influential on Hyperledger Fabric performance, our results show this not to be the case for smaller machines, as the ordering service is computational bounded. Apache Kakfa's performance advantage is achieved because the system can write data in parallel, it does not have to achieve consensus before it adds data to the ledger. This observation implies that systems designers need to consider the cost and need for distributed trust: especially if the proposed system has the nature of being permissioned and private. The question needs to be asked, is Byzantine fault tolerance necessary when participants are known to each other and have a vested interest in the e-business system being trustworthy? However, in large dynamic e-business ecosystems, where bad actors could be present, the extra level of distributed trust that BFT delivers may be worthwhile.