# Bounce: A High Performance Satellite-Based Blockchain System
## 3 Bounce Protocol
### Straw-Man Multi-Satellite Protocol  
To make the idea clear, we'll first describe a simplified protocol assuming that the satellites never fail. We divide time into _slots_, where each slot is the responsibility of exactly one satellite. The protocol for slot \(i\) is the following:  
1. Each of possibly several Sending Stations gathers transactions and forms a single Merkle tree. 2. Each such Sending Station constructs a message consisting of the signed root of its Merkle tree and signs and sends that root to the satellite for slot \(i\) (phase 1). Please note that for the sake of simplicity, we describe this protocol as sending only one root per Sending Station message; we will generalize this in Section 4. Also, for the sake of simplicity, though the protocol speaks of Sending Stations communicating directly with satellites, there could be specially-equipped relay stations which do the actual \begin{table}
\begin{tabular}{l l l l} \hline \hline
**Blockchain** & **Throughput (tps)** & **Response Time** & **Notable Features** \\ \hline
**Visa** & 65,000 & \textless{}a few seconds & Centralized \\ \hline
**Ethereum** & 12 (avg), 100 k (theoretical) & as long as 6.4 min & Proof of Stake, limited scalability, complex rewards \\ \hline
**Solana** & 3000 (avg), 65,000 (max) & 13 s & Proof of Stake + Proof of History, high-speed blocks \\ \hline
**Polkadot** & 1000, 100k (potential) & 12–60 s & Multi-chain architecture, parallel processing \\ \hline
**Avalanche** & 10 & 2 s & DAG structure, rapid finality \\ \hline
**Algorand** & 10,000 & 2.85 s & Byzantine Agreement, secure validator selection \\ \hline
**Bounce** & 2,600,000 (experimental) & 3–10 s & Satellite-based, tamper-resistant, ultra-high throughput \\ \hline \hline \end{tabular}
\end{table} 
Table 1: Comparative Analysis of Blockchain Protocols. communication with the satellites. Some Sending Stations could be relay stations themselves, but need not be. 3. The satellite for slot \(i\) constructs a Commit Record that contains (a) the number \(i\) and (b) an array of one or more of those Sending Station messages. 4. The satellite signs and sends that Commit Record back to earth (phase 2). Thus, the satellite for each slot constructs a signed Commit Record containing a sequence of zero or more Merkle roots for that slot. The contents of the blockchain are the contents of the Merkle trees whose roots are signed in slot order by the satellites, and, within each slot, in the satellite-imposed sequence order within the slot. Even if we assume the satellites are reliable, the Sending Stations and Ground Control may fail. Here we present a few such issues and preview what the protocol in Section 4 does to handle it. * Malicious Sending Stations may perform a denial of service attack by sending roots to non-existent Merkle trees to a satellite. _Response_: Because Sending Stations sign their messages, those misbehaving Sending Station would be exposed. * A Sending Station might send the root of a legitimate Merkle tree, but then fail before the corresponding Merkle tree has been disseminated. _Response_: In the full protocol, a number of Broadcast Ground Stations Figure 1 will each sign the Merkle root which the Sending Station assembles into a multisignature and sends. Those Broadcast Ground Stations send the Merkle tree to many users with goal of making the tree \"widespread knowledge\". As mentioned above, fault tolerance is achieved by replication. Even if some Ground Stations fail later, the widely spread Merkle tree will be in the hands of many nodes. * The Commit Record might be sent to earth but then might never be broadcast sufficiently widely. _Response_: Just as for Merkle roots, the Sending Station message for slot \(i\) will contain the Commit Record of slot \(i-1\) multisigned by many Broadcast Ground Stations. Before signing the Commit Record for slot \(i-1\), each Broadcast Ground Station will make sure that Commit Record is widespread.