## 1 Introduction
### Transaction Volume  
As previously mentioned, our first use-case revolves around a national e-business trading system based on transaction volumes in Denmark. Denmark, as a nation with the eleventh largest GDP in the EU and a well-established digital economy, provides an ideal setting for this study. According to reports by Deloitte [8] and the Danish NationalBank [9], the Danish B2B and B2G market manages approximately 225 to 235 million invoices annually. However, before an invoice reaches its final stage between the buyer and seller, an average of five documents, including offer, quote, purchase order, invoice, acceptance note, and credit note (which we refer to as \"related traffic\"), are exchanged [10]. For simplicity, we assume that the related traffic documents have the same size as an invoice.  
Based on these considerations, a national e-business trading system should be capable of handling approximately 1.12 to 1.17 billion transactions annually. In Denmark, e-invoice standards [11] and EU regulations [12] dictate that the maximum document size exchanged is 50 kilobytes (KB), with an estimated average size of 10 KB [12]. Multiplying this quantity of data by the volume of transactions results in a data storage requirement for a blockchain ranging from 11.5 to 12.0 terabytes (TB) annually, three times larger than the current size of the Ethereum blockchain [13] for Denmark alone.  
When considering throughput, the arrival of e-business transactions into the B2B/B2G system exhibits a non-uniform distribution. The majority of transactions occur during business hours, specifically from 8 a.m. to 6 p.m., Monday to Friday. Furthermore, traffic experiences peaks towards the end of the calendar month, end of each quarter, and end of the financial year. In the Danish scenario, the relationship between peak intervals and transaction volume can be described using the formula:  
\[\frac{\text{Number of Invoices}\times\text{ Related Traffic}=\text{Total Traffic}}{\text{12 (months)}\times 20\text{ (working days)}\times 10\text{ (working hours)}}.\]  
In peak times, the transaction volume is between 130 and 135 transactions per second (tps). In terms of response time, there are no strict requirements as the use-case focuses solely on invoices and related business document traffic. Payment processes are assumed to take place off-chain, utilizing traditional financial settlement systems or contemporary peer-to-peer (P2P) financial settlement systems. It is important to note that real-time responses, typically necessary for credit card settlements, are not necessary for this particular type of e-business document exchange system.  
The second scenario entails a transnational e-business trading system spanning the European Union (EU) and the United Kingdom (UK). Extending the use-case to encompass all 27 EU member states, as well as the UK, necessitates a system capable of managing 17 billion invoices [9]. To accommodate this scale, the system needs to handle approximately 2000 transactions per second (tps). However, when accounting for the related traffic documents, the upper range for peak throughput increases to 9000 to 10,000 tps. Given the combined B2B and B2G nature of the use-case, there is an emphasis on governance and compliance particularly regarding the ledger's read and write permissions. Therefore, a permissioned blockchain is a crucial requirement for this scenario.