## 3 Testing Framework
### Cloud Computing Configuration
#### 3.3.3 Hyperledger Fabric  
To fit the Hyperledger Fabric terminology to the use-case, 28 organizations were created, so an organization maps to a European country, where each of the organizations had one peer each representing one company per country. ZooKeeper is a component that plays a critical role in coordinating and managing the Apache Kafka cluster. ZooKeeper is used by Kafka as a centralized service for maintaining configuration, tracking the state of the cluster, and managing the metadata associated with Kafka brokers, topics, and consumer groups. We wanted to create an orderer instance containing one Kafka and one Zookeeeper in five separate data centers across the Microsoft Azure European data centers. However, multi-hosting an environment across multiple locations is not presented in the official Hyperledger Fabric documentation. This leads us to a single orderer VM containing five Kafka instances and five zookeepers in one data center. This configuration proves to be favourable to overall system performance.  
Surveying the literature on Hyperledger Fabric performance tests [36; 37; 38; 39; 40] and referring to Hyperledger's own performance benchmark tool, Caliper [41], reveals that there have been no reported peer reviewed papers using in-the-wild performance tests. In fact, every performance study cited above uses large co-located machines. For the Caliper benchmark tests, all of the roles, one orderer and two organizations each with one peer, are hosted on a single machine. This eliminates any variability resulting from network dynamics. This assumption is likewise applied in [PERSON] et al. [36] (p. 12) and noted in their conclusion:\"we assumed that the network is not a bottleneck. However, in a real-world setup, nodes can be geographically distributed and hence, the network might play a role\". This is verified by [PERSON] et al. [42] where the effect of bandwidth limitations in a similar use-case across 28 nodes representing EU member states authorities is evaluated.  
The batchsize parameter is set to 300 transaction per batch (block size), which was found to be an optimum through our own testing and confirms the findings of [PERSON] et al. [36]. The endorsement policy is set to \"any\", which means that only one of the 28 peers needs to endorse a transaction before it is sent to the orderer. The replication configuration is altered towards the use-case of this paper. Since invoices are business critical documents, the replication of data is important to mitigate data loss. Therefore, we replicate data to all five Kafka instances with replication to a minimum of three, before data are made available to peers. The three-out-of-five Kafka rule creates leeway for downtime in two of the ordering services, without crashing the entire system, hence its crash fault tolerance property. Similar to Tendermint, we deployed a smart contract in each of the channels calling a noop function. We run our tests through one and four channels with all 28 peers enrolled in each of the channels. This serves the purpose of understanding and measuring if channels can be used as a way of scaling [36; 40]. The specifications and geographically distribution of the VMs used in the Hyperledger Fabric test consist of 28 VMs each containing a peer, and one VM containing the five orderers in separate docker containers.