## 2 Experimental Set-Up
### Selection of Platforms
#### 2.2.1 The Quorum Blockchain  
Quorum [4] is an open-source blockchain platform built on top of the Ethereum, designed specifically to address the requirements of financial applications. Unlike Ethereum which is public, Quorum is permissioned which means that participation in the blockchain is limited to a known set of provisioned nodes in the network, a feature that is particularly important in industries such as finance. By default, Quorum provides RAFT consensus [24] and Istanbul BFT (IBFT) [25]. Since BFT is required for our study, the IBFT consensus is chosen.  
To understand Quorum, it is important to highlight some specifics about the Ethereum blockchain on which it runs. Ethereum can be characterised as a large distributed finite state machine, where transactions can be viewed as state transitions, i.e., a block is a list of transitions. Transactions (and hence state transitions) should be well-formed (have the right number of values) and carry a valid signature (there are other rules, see the Ethereum whitepaper [26]). A developer can define the specifics of transactions, and these programmable state transitions are known as smart contracts. In other words, a smart contract is a way to encode a state transition. As Ethereum stores the full ordered list of transactions (state transitions), it is possible to re-run the blockchain by replaying every state transition from the original state: this is what occurs when a node is synchronizing. An example of a state transition is shown in Figure 1, this illustrates how a smart contract, located at bb75a980, transitions the State to State'.  
When a developer defines a smart contract, they must define where data is stored. In Ethereum, three locations are available that allow data to persist: these are Storage, Memory and Calldata, and each of these locations have their own merits and gas-costs. Variables located in Storage are written into the State for the defined smart contract, i.e., in the case of Figure 1, the name CHARLIE is located in Storage, and therefore written into State'. Variables written into the State in this way persist and can be accessed through a smart contract at a later point in time. Cryptocurrencies built on Ethereum use Storage to keep track of wallet balances. Memory is a temporary location for mutable variables in a smart contract. Variables in Memory do not update the State, and are not later accessible via smart contracts, namely they persist only within the scope of the smart contract execution. Lastly, Calldata, is an immutable version of Memory that can only be passed from an external address as parameters to a function defined with the scope of a smart contract. Recall that Ethereum stores and orders all the transactions that have occurred in the system, so data passed as arguments in any transaction, or used internally as a variable in a smart contract, remain accessible by examining the transaction, even though they are not retrievable from a smart contract.  
In Figure 1, the data used in the central transaction (Memory), or the parameters passed when it was called, Calldata, will still be on-chain without being written to the State. Since the use-case does not require later access via a smart contract, only proof that data was committed by a specific actor, alternatives to recording data in a State are possibilities. This allows one to utilise on-chain data-availability, and use Memory or Calldata to create a persistent record of data by passing arguments into a noop smart contract, thus avoiding writing them into the State. In so doing, a transaction containing the data and a signature is recorded, and this represents proof that data has been committed. In this way, it is possible for anyone to later look at a specific transaction and examine the data committed to the blockchain.  
As a final note, the performance figures in Table 1 for Quorum are quoted from a non-peer-reviewed study by [PERSON] et al. [27]. That study informs our own work, in particular we use the same 30 s time-frame in which to generate transactions.