Scaling Bitcoin with Secure Hardware

Bitcoin suffers from a fundamental limit on how far it can scale. While the number of transactions sent per day has been growing exponentially since Bitcoin's inception, the number of transactions the system can clear is firmly capped at 7 tx/sec under the best of circumstances, and at around 3.3 tx/sec with realistic transaction sizes. This means that, for example, if Venezuela were to switch over to Bitcoin today, every adult would be able to conduct at most one financial transaction every 72 days. And on the latency side, every non-trivial transaction would incur at least an hour's delay.

There have been no shortage of suggestions to improve the scale of the protocol. One possibility is to increase the block size. While a reasonable stopgap measure, changing the blocksize does not appreciably improve latencies for confirmations. And a 2X or 4X increase in block size delivers at most a 2X or 4X improvement in throughput. Even a highly controversial 10X increase in block size would yield only one transaction per week for Venezuelans, still far short of the target. Another possibility, suggested in efforts such as Bitcoin-NG, ByzCoin, and Hybrid Consensus by research groups including ours, is to change the protocol to construct blocks incrementally over time, avoiding centralization bottlenecks. Quixotically, the practitioner community has been reticent about adopting these techniques or even acknowledging their existence during scaling discussions, reportedly because these proposals require changes to the underlying protocol.

Instead, most practitioners have focused on off-chain scaling, through a technique known as payment channels. Payment channels, such as the Lightning Network (LN) and Duplex Micropayment Channels (DMC), allow for efficient transactions in which two parties can engage in a large number of fund transfers off chain, only settling the net result on the blockchain. While this can potentially improve scale immensely, these protocols, also, require substantial changes to the underlying protocol. Specifically, Lightning Network implementations are vulnerable to transaction malleability, whose current proposed fix, SegWit, has become mired in controversy, partly as a result of its implementation complexity.

A New Solution We have developed a new scalability solution for Bitcoin, called Teechan. It is a new, practical, high throughput, low latency off-chain transaction protocol that can be deployed securely on the Bitcoin network, as it exists today. Teechan is similar in design to the Lightning Network, save for one crucial differentiating factor: it leverages trusted execution environments (TEEs), that is, secure hardware components found in recent commodity processors such as the latest batch of Intel CPUs with Software Guard Extensions (SGX). This key technology enables Teechan to provide surprisingly strong guarantees. Specifically: Teechan does not require any changes to the existing Bitcoin network; it is secure even in the presence of transaction malleability. Teechan is efficient: Payments are completed with a single message. Network latency does not impair its throughput. Teechan enables infinite channel reuse as long as the balance does not exceed the channel credit. Teechan is space-efficient, requiring only two transactions to be placed in the blockchain in total under all scenarios. As a consequence of lower dependence on on-chain transactions, Teechan is less open to attacks based on blockchain flooding. Consequently, Teechan lends itself to an efficient implementation. Our prototype achieves a throughput of 2480 transactions per second per channel, with settlement latency overheads of 0.4 ms. The first feature alone is worth its weight in bitcoin, as this means that all the touted benefits of payment channels can be had on top of the regular, unmodified Bitcoin protocol right now, avoiding the thorny discussion around SegWit and its deployment. It's worth explaining why Teechan is able to provide these features.

Power of Secure Hardware SGX is a set of instruction set extensions for CPUs released in Fall 2015 and available on recent CPUs. The key ability SGX provides is the notion of confidential, private execution with integrity guarantees. In essence, the chip has a special construct called an enclave. An enclave is like an ordinary program, except that the memory contents of an enclave are encrypted whenever they are off-chip, and accessible only on-chip, and only while the special enclave code is running. Further, the decryption keys are available solely to code with a certain hash: if you or a hacker were to hack the enclave code and change its hash, that hacked code will no longer have access to the encryption keys, repelling attacks. As a result, this ingenious technology does not permit anyone, even the owner of the machine who can modify the code arbitrarily, to peek at the contents of the enclave or to modify execution within an enclave. Further, the SGX hardware enables remote attestation, that is, the ability to prove to a remote computer that a given enclave is running a particular software distribution. In essence, the chip is able to issue a statement that says "I guarantee to any remote party that I am running this code with this particular hash," which is a critical bootstrapping mechanism. Teechan is built on these two underlying features, which, together, provide a trusted execution environment (TEE). Now, SGX is not the only way of building a trusted execution environment. It's quite possible to do the same using, for instance, secure hardware co-processors known as trusted platform modules (TPMs). TPMs can be found in almost every laptop and cost somewhere between $1-$5, and come from multiple vendors. Rumor has it that they can even be manufactured with self-destruct circuitry in the packaging, where attempts to shave off the packaging result in the chip destructing its private key. While the Teechan protocol is suitable for building on top of any platform that supports TEEs, including TPMs, we decided to build our prototype implementation on top of SGX. The nice thing about SGX is that the security guarantees are built into the CPU. SGX enclaves are secure against an attacker who has placed probes on the system bus, has special attack hardware on the USB ports, has modified disk contents and is able to forge network packets any which way. The only way to compromise these guarantees is to shave off the CPU packaging and place probes on the silicon wafer, a costly undertaking requiring a clean room and significant reverse-engineering effort. And users currently already trust Intel (or AMD) to execute their transaction signing code correctly.

Channels Over Secure Hardware Teechan uses TEEs to build lightweight duplex payment channels. Compared to software implementations of payment channels, such as the Lightning Network, a hardware-based implementation has several advantages: First of all, current payment channel implementations require segwit to be activated and transaction malleability to be fixed to reduce implementation complexity. Lightning has been the big impetus behind SegWit, which is currently stuck without sufficient miner support. Teechan enables us to build secure payment channels without having to change the base protocol, without having to bicker over SegWit. Sending money with Teechan is incredibly fast, because payments are completed with a single message. The alternatives are either DMC, which puts a bound on the maximal amount transacted in a single direction of the channel (deposit amount times max number of channel resetes), or LN, which requires multiple round trips between the two parties to complete a single transaction.

Caveats There is no such thing as a free lunch. While Teechan represents very good news for Bitcoin, it comes with some caveats: Teechan requires a trusted execution environment. This requires some special hardware, so you may need a special machine with the right kind of hardware to create a channel. Our current prototype is implemented on top of Intel SGX, so if you want to use this particular prototype, you'll have to trust Intel. This is not an onerous requirement, because you already trust Intel for the correct execution of your code, and these extensions are just a part of the new instruction set being rolled out by Intel. If you do not currently trust Intel and use AMD or another vendor instead, then you'll have to wait for that vendor's implementation of SGX, or else port Teechan to other trusted execution environments. Note that only the entities at the two ends of the channel, you and the person you are transacting with, need to trust each others’ TEEs. The blockchain and the rest of the world are oblivious.

Our measurements purposefully leave out the effects of the network, which depend on your deployment. You need to factor in the network latency between the two parties, as well as the bottleneck bandwidth. As noted above, higher latency does not impair Teechan’s throughput.

It is yet unknown by how much Teechan, or other solutions, will help Bitcoin scale. The exact benefit depends on the emergent credit network on top, which has yet to emerge, because it has not been possible to deploy payment channels securely until now. Our hope is that Teechan will be used in concert with payment network design by LN and others.

Payment channels rely on the ability to place certain transactions on-chain when needed. This requires space in blocks on the underlying blockchain. As mentioned in the LN paper, full blocks interfere with this and can open payment channels to attack.

Bottom Line If you have the right hardware, you can run Teechan over the unmodified Bitcoin protocol right now. Our unoptimized prototype of Teechan is able to achieve 2480 transactions per second per channel, with transaction latencies of 0.4 ms. Not only does this enable paying for a coffee, but also enables Bitcoin to achieve very high aggregate throughput, to enable cheap & fast micropayments, as well as a host of other usage scenarios that require frequent, high-speed payments.

Where Do We Go From Here? If you are interested in the operation of the Teechan protocol for building secure payment channels on trusted execution environments, a working draft paper is available. We will be making the Teechan implementation public in the next few weeks. Caveat emptor: this code is going to be an alpha release. It is quite possible for software bugs to lead to loss of coins. The prototype will be made available as is, with no express warranty of its suitability for any purpose. We do hope to build an open-source effort around Teechan. If you're interested in contributing to the effort, please get in touch with us.

Summary While Bitcoin has to embrace on-chain scaling to not only scale, but to ensure the security of off-chain protocols, it is essential to tackle scalability at all levels of the protocol stack. Overall, we have outlined a best-of-breed off-chain solution to help Bitcoin scale. Teechan builds on secure hardware to yield a secure payment channel implementation that achieves high throughput and extracts a very low latency overhead. It side-steps a controversial proposal to change the underlying Bitcoin protocol, and provides all of the much-touted benefits of Lightning Networks today, without having to modify the base protocol at all.

Share on Twitter Share on Twitter

Share on Facebook Share on Facebook

Share on Linkedin Share on Linkedin

Share on Reddit Share on Reddit

Share on E-Mail Share on E-Mail

Please enable JavaScript to view the comments powered by Disqus.

Disqus