Blockchains in cryptocurrencies allow users to exchange funds securely. However, their performance is limited by their need to achieve consensus for all payments. To overcome this, blockchain payment networks, such as the Lightning Network and Raiden, have proposed forming a second layer on top of the blockchain to allow payments to be executed off-chain, without writing to the blockchain for every transaction, thus enabling much higher transaction throughput with lower latency.
Although existing off-chain payment networks have made great strides towards scalability, they are vulnerable to attack because they assume synchronous blockchain access: they require that users can write transactions to the blockchain within a bounded period of time, τ. Unfortunately however, blockchains don't provide formal write-latency guarantees; they offer only a best-effort service. If I generate a transaction and send it to the blockchain now, there’s no guarantee that it will be placed in a block in the next hour, day, week, or even month, and attackers can further delay transactions as demonstrated by recent attacks. Existing payment networks therefore trade-off fund safety with liveness; funds are locked in escrow on the underlying blockchain during τ, if τ is small to reduce fund lock times, an attacker can more easily delay transactions to steal funds. However, if τ is large to make attacks more expensive, funds are inaccessible and unusable for longer periods of time.
We’d like to propose a solution to this problem: Teechain, a new payment network for blockchains that requires only asynchronous blockchain access. Unlike existing payment networks, Teechain makes no assumptions about bounded transaction write times to the blockchain, protecting against attacks on transaction confirmation times and avoiding the trade-off between fund safety and liveness.
If you’ve been following blockchain scaling solutions for a while, you may have heard of TEEChan (read here), our previous payment channel solution that uses secure hardware to achieve high performance for blockchains. Well, Teechain is the next generation of TEEChan, offering better performance, improved security and novel features. Check out our Alpha release for Bitcoin!
Teechain uses trusted execution environments (e.g. Intel SGX) in recent CPUs to construct secure and high performance payment channels, and also offers a protocol for secure multi-hop payments to build an off-chain payment network. Teechain is different from existing payment networks for several reasons:
Existing payment networks assume that transactions can be placed onto the blockchain within a predetermined and set amount of time. For example, in the Lightning Network, you need to monitor the blockchain to ensure that no one else misbehaves. If someone does, you then have a bounded amount of time in which to react and place a transaction on the blockchain in order to make things right. We term this the “time-out” period and all existing solutions have it in one form or another.
However, assuming that transactions can placed onto the blockchain within a time-out period is insecure: if I generate a transaction and send it to the blockchain now, there’s no guarantee when it will be placed into a block. There are many factors that affect transaction confirmation latencies, and many of these factors are outside user control. In fact, there have already been several cases where blockchain confirmation times have been manipulated by attackers for financial gain. For example, a few months ago an attacker restricted the number of transactions packed by miners in order to steal funds from the Fomo3D smart contract in Ethereum. Another example was earlier this year (see Figure 1), in January/February, when a spam attack caused a spike in the average transaction confirmation time for Bitcoin transactions: spiking from 2 hours, to around 8 days. During this time, if any payment channels assumed a transaction could be placed on the blockchain in less than 8 days, the funds in those channels could be stolen.
So, why is this an issue? Why not just set a really long time-out period, like a month or a year, to tolerate fluctuations in transaction confirmation times? The problem with this is that during time-out periods in payment networks, funds are locked in escrow on the underlying blockchain, and only released once the timeout expires (e.g. see Hashed Timelock Contracts in the Lightning Network). Therefore, if the time-out is set to a large value, it forces users to have to wait large amounts of time for their funds to be released, and waiting a month, or a year before you can access funds in a payment channel is impractical and unrealistic.
Existing solutions therefore face a trade-off between security and practicality; how long your funds are locked up vs. how secure they are due to time-outs. Thus, choosing an appropriate time-out period is not-trivial. An attacker need only delay or censor your transaction for the length of the time-out in order to steal funds. And given that there are many ways in which to do this (e.g. network congestion, transaction fee spiking, transaction censorship through misheaving miners, etc.) the cost to perform such an attack may be reasonable when compared to the funds that can be stolen in the channel.
Teechain avoids this trade-off entirely. Instead, Teechain makes no assumptions about transaction confirmation times, or blockchain latencies; the security of payment channels is unaffected by when a transaction is placed on the blockchain. To achieve this, Teechain exploits trusted hardware to produce a settlement transaction for each payment channel only once. This removes the burden from users to continuously monitor the blockchain to detect other settlement transactions. This means that in Teechain, you can go offline for as long as you need to, without having to worry about the security of your channels.
Teechain uses trusted execution environments (TEEs) to enable many of its cool features and strong security properties. However, there are two concerns that immediately come to mind when talking about TEEs: (i) what happens if the hardware fails? and (ii) how do you protect the hardware from attacks, such as physical CPU attacks or side-channels like foreshadow and spectre ?
To protect against hardware failures and compromised TEEs, Teechain provides Byzantine fault tolerance to the TEEs in the network. To do this, Teechain combines a novel variant of chain replication with threshold secret sharing. The idea is simple: distribute ownership of fund deposits in Teechain to a set of committee TEEs using chain replication and exploit multisignature support from the underlying blockchain (e.g. m-out-of-n signatures) to require a sufficient number of TEEs to sign transactions before funds can be spent. Thus, funds in Teechain are protected from a threshold number of TEE failures. In Teechain, we term the set of TEEs responsible for a single deposit the committee chain.
By offering committee chains, Teechain allows users to decide exactly how they wish to secure their fund deposits, and which other TEEs in the network they trust to do so. For large fund deposits, many committee TEEs might be needed, to overcome potential failures and attacks. However, for small fund deposits, users may require fewer TEEs. However, we note that committee members in Teechain are not trusted third-parties, they are trusted hardware instances, and thus provide security benefits over general purpose committees on the blockchain. What’s more, the use of committee chains doesn’t hinder performance; Teechain can operate with over 30,000 transactions per second, per payment channel with more than 4 committee members per deposit, and offer sub-second payment latencies. We’ll discuss Teechain’s performance in a future blogpost.
Finally, in addition to offering committee chains to tolerate failures, Teechain also hardens itself against TEE side-channel attacks. To do so, Teechain employs the use of static-analysis to prevent leaking private keys inside the TEE. It does this as follows: it uses secure, time-tested side-channel resistant libraries as “building blocks” and employs these building blocks to execute sensitive operations over private keys (such as transaction signing, and encryption). To ensure that the private keys are handled correctly, Teechain further exploits static code analysis to ensure that only these secure building blocks ever access the private keys inside the secure hardware, effectively isolating the private keys from the rest of the code and data. This hardens Teechain against side-channel attacks, making attacks against the TEE more costly and expensive.
One of the benefits of Teechain is that users without TEEs of their own can still take part in the Teechain network. Users can operate a Teechain wallet on their mobile phone or tablet, and outsource their payment channels to committee chains in the network for a small fee. This happens by selecting a set of TEEs in the network that you’d like to make responsible for managing your payment channels, and outsourcing to them. The advantage here is that through outsourcing, you don’t actually need to trust anyone in the network with your funds. Service providers and users who offer outsourcing to others can’t steal, spend, or even access outsourced funds. Instead, their TEEs are responsible for securing and protecting those funds. The only assumption you make when outsourcing is that at least one of the hardware devices you selected is online at any point in time, so that you can issue payments and retrieve funds.
There’s a lot about Teechain that we haven’t discussed in this blogpost. Instead, we wanted to give you a taste of things to come. While you can already play and experiment with Teechain on Bitcoin, we’re working on an up and coming series of blogposts that go into detail about Teechain’s design and performance. Spoiler alert: Teechain is over 30 times faster than the Lightning Network per payment channel, and can achieve over 1 million Bitcoin transactions per second -- so stay tuned!
If you have any thoughts/questions and so on, feel free to find us at: teechain.network or email us at: firstname.lastname@example.org
Written by Joshua Lind.