# Bounce: A High Performance Satellite-Based Blockchain System
## 1 Introduction  
The base layer of a blockchain is meant to provide a single, immutable history containing a total ordering over all committed transactions. This immutable total ordering is called the blockchain ledger or, simply, ledger.  
Here the word _single_ (also known as _unforked_) means the following: if agent \(A\) sees a block of transactions \(x_{1}\) before \(x_{2}\) in the blockchain, then any principal \(B\) will see \(x_{1}\) before \(x_{2}\). (Some blockchains, such as Bitcoin [1], provide a slightly weaker _common prefix_ property [2]. They guarantee only that all parties agree to a growing prefix of the blockchain with high probability.) The term _immutable_ means that once \(x_{1}\) and \(x_{2}\) are in the chain, theywill both remain in the chain and their order will remain as \(x_{1}\) before \(x_{2}\). Immutability is achieved in practice by widespread replication of the blockchain.  
Malicious actors have an interest in introducing forks in blockchains [1]. A double-spending attack, which refers to the ability to spend the same funds more than once, can be performed by introducing forks into a blockchain and spending the same funds in each fork but for different goods or services.  
In addition to preventing forking (or at least long-lived forks), all protocols inherently rely on a set of administrators who are responsible for monitoring the protocol and updating software to enhance its proper functioning. The reliance on these administrators is generally accepted because their intervention is 'punctuated': infrequent, and, in theory, transparent to the public. The practicality of this transparency assumption is questionable, especially when complex software is updated.  
Achieving high throughput, low latency, and resilience against forks remains a challenging trifecta. Current consensus mechanisms often trade off one dimension of performance for another, leaving gaps in scalability and trustworthiness.  
Satellites as system components offer some potential benefits such as global coverage, resistance to tampering, and natural broadcast capabilities. By utilizing satellites as consensus nodes, the _Bounce_ protocol achieves a throughput tens to hundreds of times faster than existing systems and response times in three to ten seconds, all while guaranteeing a no-fork-ever blockchain.  
In order to make this paper self-contained, through Section 4, we heavily paraphrase parts of the second two authors' book [3], recapitulating the assumptions and the overall design presented in that book. This paper extends that book to make the following contributions:  
* This paper allows commit records to consist of multiple Merkle roots instead of just one, thus increasing throughput and reducing response time.
* This paper introduces the notion of two tiers of transactions: **economy** and **premium**. The system can achieve a higher throughput with economy transactions than premium ones, but premium transactions enjoy a shorter response time.
* This paper presents end-to-end experiments with all components and with earth-to-satellite-to-earth times taken from previous experiments with the International Space Station, adjusted for the higher altitude of low-earth orbiting satellites. We do not specify the exact kind of satellite but do specify and test the hardware of the Bounce Unit to be embedded on each satellite. Our experiments show a sustained throughput of 5.2 million transactions per two-second slot and 3 to 10 s response times.
* This paper describes the design and implementation of \"accumulator\" nodes whose job is to maintain account balances based on payment transactions. Section 6 shows that with current hardware, each such node can keep track of balances of up to 1 billion client accounts at 4 million transaction per second throughput rates, thus preventing double-spending.