# Bounce: A High Performance Satellite-Based Blockchain System
## 6 Experiments, Results, and Analysis
### Slot Protocol Measurements
#### 6.3.3 Scaling to Higher Throughputs  
_Bounce_ can handle high transaction loads by ensuring that disjoint sets of transactions are processed in parallel as illustrated above. This could easily be scaled further. For instance, \(k_{p}\) premium Merkle Trees and \(k_{e}\) economy Merkle Trees can be constructed concurrently. This parallelism not only improves throughput but also reduces response time, because there could be more premium Merkle Trees. For example, given five more Cloud Lab, Clemson clusters, we could add ten more economy Merkle Trees per slot, raising the throughput per slot to 15.2 million transactions per second.  
The Sending Station can assign Merkle Trees to different Broadcast Ground Stations or disjoint groups of at least \(f+1\) Broadcast Ground Stations. An architecture in which different Merkle Trees are built by disjoint sets of processors ensures that an essentially arbitrary number of Merkle Trees can be built in parallel. The only part of a slot whose timing might slow down if there are many Merkle Trees is the satellite processing time.  
Specifically, the satellite Bounce Unit would have to verify multiple roots. This could potentially increase the slot time length, because it is in the critical path and is not parallelizable.  
Table 5 illustrates the impact of having multiple Merkle Tree roots on slot timing. The time for a Sending Station to create a message remains unchanged even if it must send up to 10 roots. The satellite Bounce Unit's validation time increases by approximately 6 milliseconds per additional multisigned root, because it must validate signatures from multiple Broadcast Ground Stations (and a Raspberry Pi 4 is far slower than a server computer).  
Figure 8: The timeline for slot events with one slot every two seconds and three different clusters. “Prem” represents premium sets of transactions that contain 100,000 transactions per Merkle Tree, and “Econ” represents economy transactions with one million transactions per Merkle Tree. From Wisc-Prem to Clemson-Econ, each site has 20, 17, 20, and 10 Broadcast Ground Stations respectively. The Wisconsin cluster has c220g2 hardware, the Utah cluster has hardware c6525-25g, and the Clemson cluster has hardware r6525. \(d\) (described in Section 4) is set to 1 s, so a set of transactions can make it to the current slot if the Sending Stations receive at least 80% of the signatures at least 1 s before the commit event. For example, for the premium set of transactions sent at second 1, the Sending Station receives signatures of 80% Broadcast Ground Stations at second 1.4, and it will go to the next slot and be committed at second 4. Similarly, for a set of economy transactions at Wisconsin sent at second 3, the sending Station receives 80% signatures at around 9, and it is committed at second 12.  
For example, if each Sending Station message contains five roots and there are ten messages from ten different Sending Station messages, the total validation time at the Bounce Unit would still be under 0.5 s. Such a setup would allow the system to maintain a slot duration of two seconds and support ten sets of 100,000 premium transactions and 40 sets of 1,000,000 economy transactions.  
Here we have limited ourselves to what the accumulator node of Section 7 can handle, which is 4 million transactions per second. Better implementations or better hardware could raise that number.