RouTEE: A Secure Payment Network Routing Hub using Trusted Execution Environments

TL;DR

RouTEE tackles the scalability and privacy limitations of off-chain payment networks by introducing a secure TEEs-based routing hub. It enables high-liquidity, privacy-preserving multi-hop payments through a star topology with a spend-all settlement protocol and pending routing fees that align host incentives, while letting users verify block headers via light clients. The authors implement a Bitcoin prototype on SGX, achieving throughput of approximately $1.8\times 10^{4}$ payments per second and significantly improving multi-hop reliability over conventional hubs like the Lightning Network. The work demonstrates practical, scalable, and privacy-enhancing off-chain payments with robust security guarantees against rational adversaries, offering a compelling path toward more efficient blockchain-based payments.

Abstract

Cryptocurrencies such as Bitcoin and Ethereum have made payment transactions possible without a trusted third party, but they have a scalability issue due to their consensus mechanisms. Payment networks have emerged to overcome this limitation by executing transactions outside of the blockchain, which is why these are referred to as off-chain transactions. In order to establish a payment channel between two users, the users lock their deposits in the blockchain, and then they can pay each other through the channel. Furthermore, payment networks support multi-hop payments that allow users to transfer their balances to other users who are connected to them via multiple channels. However, multi-hop payments are hard to be accomplished, as they are heavily dependent on routing users on a payment path from a sender to a receiver. Although routing hubs can make multi-hop payments more practical and efficient, they need a lot of collateral locked for a long period and have privacy issues in terms of payment history. We propose RouTEE, a secure payment routing hub that is fully feasible without the hub's deposit. Unlike existing payment networks, RouTEE provides high balance liquidity, and details about payments are concealed from hosts by leveraging trusted execution environments (TEEs). RouTEE is designed to make rational hosts behave honestly, by introducing a new routing fee scheme and a secure settlement method. Moreover, users do not need to monitor the blockchain in real-time or run full nodes. They can participate in RouTEE by simply verifying block headers through light clients; furthermore, having only one channel with RouTEE is sufficient to interact with other users. Our implementation demonstrates that RouTEE is highly efficient and outperforms Lightning Network that is the state-of-the-art payment network.

Figures (8)

• Figure 1: The RouTEE system overview.
• Figure 2: An example of the RouTEE network. It forms a star graph which has RouTEE as a unique intermediary node. Each user has one of three kinds of channels with RouTEE, but channels between users are not necessary.
• Figure 3: RouTEE channel type transition diagram. Channels could be dynamically opened, closed, and changed to other types of channels.
• Figure 4: An example of a multi-hop payment in RouTEE. Alice tries to send her balance derived from the deposit $D_2$ in block 3 to Bob, but his boundary block number is 1 which is less than 3. This means that Bob does not trust Alice's balance yet. (a) Alice informs Bob of her maximum source block number (in this case, 3). Bob downloads block headers from full nodes to verify whether block 3 is valid. He receives up to block 4 and sets his boundary block as it by update_boundary_block, in order to prepare to receive from Alice. (b) Alice executes a multi-hop payment to send 30 to Bob. RouTEE checks that Bob believes Alice's balance is valid (i.e., Alice's maximum source block number is less than or equal to Bob's boundary block number. In this case, check $3 \leq 4$). Then Alice's balance is moved to Bob, and the host gets a pending routing fee for this multi-hop payment from Alice. Now Bob has balances from different source blocks, so Bob's maximum source block number should be updated to 3.
• Figure 5: An attack scenario using fake blockchain data. (a) White blocks are included in a valid main chain. A red block is generated by the malicious host. The host inserts the red block into RouTEE to add the fake deposit $D_A$ and tries to settle its invalid balance. (b) If RouTEE picks old deposits to make a settlement transaction (naive approach), the deposit $D_A$ is not spent, which means the transaction is valid in both chains. Thus, the host can broadcast the transaction to the Bitcoin network, stealing other valid deposits. (c) On the contrary, if the settlement transaction contains all deposits (spend-all-settlement), it is only valid in the fake chain as there is no $D_A$ in the main chain. Thus the host is not able to gain illegal benefits.