Blockchains are designed to produce a secure, append-only sequence of transactions. Establishing transaction sequentiality is typically achieved by underlying consensus protocols that either prevent forks entirely (no-forking-ever) or make forks short-lived. The main challenges facing blockchains are to achieve this no-forking condition while
[...] Read more.
Blockchains are designed to produce a secure, append-only sequence of transactions. Establishing transaction sequentiality is typically achieved by underlying consensus protocols that either prevent forks entirely (no-forking-ever) or make forks short-lived. The main challenges facing blockchains are to achieve this no-forking condition while achieving high throughput, low response time, and low energy costs. This paper presents the
Bounce blockchain protocol along with throughput and response time experiments. The core of the
Bounce system is a set of satellites that partition time slots. The satellite for slot
i signs a commit record that includes the hash of the commit record of slot
as well as a sequence of zero or more Merkle tree roots whose corresponding Merkle trees each has thousands or millions of transactions. The ledger consists of the transactions in the sequence of the Merkle trees corresponding to the roots of the sequence of commit records. Thus, the satellites work as arbiters that decide the next block(s) for the blockchain. Satellites orbiting around the Earth are harder to tamper with and harder to isolate than terrestrial data centers, though our protocol could work with terrestrial data centers as well. Under reasonable assumptions—intermittently failing but non-Byzantine (i.e., non-traitorous) satellites, possibly Byzantine Ground Stations, and “exposure-averse” administrators—the
Bounce System achieves high availability and a no-fork-ever blockchain. Our experiments show that the protocol achieves high transactional throughput (5.2 million transactions per two-second slot), low response time (less than three seconds for “premium” transactions and less than ten seconds for “economy” transactions), and minimal energy consumption (under 0.05 joules per transaction). Moreover, given five more cloud sites of the kinds currently available in CloudLab, Clemson, we show how the design could achieve throughputs of 15.2 million transactions per two second slot with the same response time profile.
Full article