Building the Theta Protocol: Part III

Breaking Down the Application of a Unidirectional Payment Channel to Video Streaming

By Jieyi Long, CTO Theta Labs

In this blog post I’ll discuss considerations related to micro-transaction handling in the Theta protocol. I’ll review off-chain payment channels, and discuss why it’s not readily applicable in video streaming use cases.

One of the biggest challenges we identified when designing the Theta protocol is how to scale our native chain for ultra high transaction throughput. Although many blockchain projects are facing scaling problems, scaling for live video streaming is different and possibly even more complex. Typically, video segments are a couple seconds long. To achieve the finest granularity of a token reward — one micropayment per video segment — even a live stream with a moderate ten thousand concurrent viewers could generate a couple thousand microtransactions per second, which far exceeds the maximum throughput of today’s public chains, such as Bitcoin and Ethereum. Popular live streams like major esport tournaments can attract more than one million viewers watching one stream simultaneously, not to mention multiple concurrent live streams, which could potentially push the required transaction throughput to the range of millions per second.

New generations of blockchain solutions like Dfinity and Zilliqa are reported to handle thousands or even tens of thousands of on-chain transactions per second. Yet millions of transactions per second is still a far-fetched goal. To get closer, researchers have been looking at the so-called level-two scalability solutions such as payment networks. A payment network refers to a class of techniques designed to allow users to make multiple transactions without committing all of the transactions to the blockchain, and thus improves the scalability of the underlying blockchain.

Let’s briefly review how a unidirectional payment channel works. Then we’ll discuss why it can’t be applied to the video streaming use case.

A Brief Review of the Unidirectional Payment Channel

Say we have Alice and Bob. Alice wants to buy one egg from Bob per day using crypto tokens for a month. Since Alice needs to pay a transaction fee for each token transaction, she’d prefer to do a single lumped payment to Bob at the end of the month. Yet Bob prefers one token transaction for each egg. The last thing he wants to see is Alice run away with all the eggs before she makes the lump-sum payment. How do we break the deadlock here?

A payment channel is a viable option for situations like this. Here is how it works. On day one, Alice deposits 30 tokens into a separate wallet W. This wallet only allows Bob to withdraw from it, i.e. any withdrawal from this wallet requires a transaction signed by both Alice and Bob. After this deposit is recorded on the blockchain, Alice can show the deposit record to Bob, and Bob can confirm that Alice has reserved a sufficient amount of tokens to pay him for the entire month. Moreover, he is the only one that can withdraw from this wallet, since it requires his signature to withdraw. Keep in mind that after a transaction is submitted to the blockchain, the funds in the wallet are depleted (sent to Bob and Alice).

Next, Alice signs a transaction with 1 token paid to Bob and the remaining 29 tokens to herself from wallet W, and sends this partially signed transaction to Bob. Bob can now safely give Alice an egg, since he knows that he will receive one token if he signs and publishes this transaction to the blockchain, which he can do at anytime. Let’s assume that he decides not to publish this transaction for the time being. On day two, Bob gives Alice another egg, and gets a new partially signed transaction in return. This time, the transaction says that 2 tokens are paid to Bob and the remaining 28 tokens return back to Alice. Similarly, on days 3, 4, 5, Alice exchanges a partially signed transaction for an egg from Bob. If everything comes along, on the last day, Alice will have received 30 eggs in total, while Bob will have 30 partially signed transactions from Alice, one from each day. At that point, Bob only needs to sign the last transaction from Alice and submit it to the blockchain. Then he gets the 30 tokens from wallet W all at once.

With this approach, Bob doesn’t need to worry about Alice running away with the eggs without paying. Moreover, Bob is incentivized to submit only the last transaction to the blockchain:

• Suppose Alice disappears on Day 17. In Bob’s hand there is a signed transaction from Alice that pays Bob 17 tokens and returns 13 tokens to Alice. If Alice disappears for a couple days, Bob can simply sign and submit that transaction to the blockchain to claim his 17 tokens.
• Bob cannot publish multiple transactions since the wallet W will be depleted after any of the transactions published to the blockchain. Hence, to Bob’s best interest, he would sign and publish only the last transaction he gets from Alice, since that gives him the most tokens.
• On the other hand, Alice cannot cheat by publishing any of these transactions since it requires both Alice and Bob’s signature.

Thus, a payment channel can significantly improve the scalability of the blockchain since it reduces the number of on-chain transactions. In the example above, it reduces the number of on-chain transactions from 30 to 2. Here we note that the above example is a simplified illustration of unidirectional payment channel. A practical payment channel needs more customization like a time-lock etc. For a more comprehensive discussion of payment channels, please refer to the Lightning Network, the Raiden Network, or the blog post series by Rusty Russell.

Can We Apply a Payment Channel Concept to Video Streaming?

Payment channels look promising for our application at first glance — replacing the eggs in the above example with video segments, a viewer can now pay for many video segments with just one on-chain settlement transaction! However, when we take a closer look, there are a number of problems:

1. Slow node switching times are unconducive to streaming: As discussed above, an on-chain transaction is needed to establish a payment channel between two parties, which might take at least a couple seconds to be confirmed on the blockchain. Typically in a live stream session (one or two hours long), a viewer node could pull stream segments from 10+ caching relay nodes. Each time the viewer needs to pull a stream from a new relay node, it needs to make an on-chain transaction first, which is time consuming. Making matters worse, before the on-chain transaction is confirmed, the viewer node cannot pull streams from the caching/relay node. This could halt the video stream, leading to degraded user experience.
2. Large amounts of tokens are required to be reserved: Each payment channel requires a certain amount of tokens reserved upfront. Thus, creating 10+ payment channels from a viewer to relay nodes may not always be feasible, especially if the viewer doesn’t have enough tokens. As a result, the viewer may not be able to pull from peer nodes even if the peer caching nodes have the desired stream segment, leading to underutilization and less cost savings for the video platforms.

A reader familiar with payment channels might argue that instead of creating a direct payment channel between the viewer and relay node, off-chain “payment networks” can be employed to route the payment through a third node. However, indirect routes may not always exist. Even if an indirect route exists between the viewer and the relay node, sending micropayments through extra hops adds latency and complexity.

To address the two problems above, here is what we need:

1. One-to-many off-chain micropayment pool: Essentially we need to allow a viewer to create a “micropayment pool” that any other account can withdraw from with the viewer’s permission. And yet the viewer doesn’t need to specify which accounts can withdraw ahead of time when he/she created the micropayment pool.
2. Double-spending resistant approach: The creator of the micropayment pool cannot benefit from double spending. In fact, the expected net value in the event of a double spend should be negative for the creator. Hence a rational user would not conduct double spending.

In the next post, we’ll get into the concept of a “resource oriented micropayment pool” that is designed specifically for video streaming. It can handle higher amounts of concurrent transactions off-chain and effectively prevent double spending. It will resolve many of the obstacles we mentioned in this post.