## 2 Experimental Set-Up  
### Benchmarking Methodology  
Performance studies on blockchains [15; 16; 17; 18] typically adhere to standard practices in distributed system testing. These studies aim to maintain consistent parameters to enable fair and comparable comparisons of resource demand, throughput, and transaction latency across different blockchain frameworks. However, this approach can introduce biases towards or against specific blockchain systems, making it challenging to draw conclusive comparisons among them.  
To address this limitation, researchers have attempted to develop advanced testing frameworks, such as Blockbench [19] and Chainhammer [20], which aim to provide more sophisticated evaluation environments. However, these frameworks are still considered research in progress [21].  
Many existing blockchain performance tests suffer from being largely artificial; they do not accurately reflect real-world deployment scenarios, in terms of network topology, geographic distribution, message lengths, and transaction volume. This paper aims to overcome this limitation by conducting in-the-wild distributed system tests. The specific requirements of a national and transnational B2B/B2G invoicing system serve as the foundation for defining performance expectations.  
The main novelty of this paper is its utilization of an in-the-wild testing methodology to assess the performance of crash fault tolerance (CFT) and Byzantine fault tolerance (BFT) blockchain technologies. The testing closely aligns with the transaction volume encountered in a (trans)national e-business platform, employing commodity hardware. This allows a comprehensive evaluation of alternative technologies in realistic scenarios, contributing to a deeper understanding of their capabilities and limitations. To achieve realistic testing, empirical experiments are designed to closely resemble the actual use-case. This involves ensuring that the size and number of transactions entering the system align as closely as possible with the anticipated system load. Furthermore, the number and geographic distribution of nodes and consensus validators are configured to mimic the characteristics of the use-case. Importantly, all systems evaluated are deployed on commonly available hardware and network infrastructure, underlining practicality and feasibility.  
By adopting this approach, the paper endeavors to provide a more accurate assessment of blockchain performance in real-world settings, ensuring that the testing methodology aligns with the intended deployment scenario. This enables a comprehensive evaluation that informs performance expectations for national and (trans)national B2B/B2G invoicing systems. To summarize, the test parameters encompass the following features:  
* the number of transacting nodes: this refers to the count of nodes actively participating in exchanging transactions within the system.
* the size of individual transactions: denotes the data size or complexity of each transaction processed within the system.  
the number of nodes participating in consensus/ordering: this parameter relates to the quantity of nodes involved in the consensus or ordering process within the tested platforms.
* the volume of transactions over time: this represents the rate at which transactions are generated and processed within the e-business system, typically measured as transactions per second (tps).  
The above test parameters provide a framework to evaluate the performance characteristics of the system, enabling an understanding of how these factors impact system performance and efficiency.