Building the Theta Protocol: Part IV
Approaching Ultra High Transaction Throughput via Off-Chain Micropayment Pool
By Jieyi Long, CTO Theta Labs
Motivated by the concept of a payment channel, in this blog post, we introduce the concept of an off-chain “Resource Oriented Micropayment Pool” that is purpose-built for video streaming, which could potentially have applications in other fields.
In the last post, we discussed the inefficiency of applying a direct payment channel approach to the video streaming use case. Switching between relay nodes is cumbersome because an on-chain transaction must be made before video streams are relayed, and an allocation of tokens must be reserved for every different relay node on-chain transaction, which quickly amounts to a large sum of tokens.
To address these problems, we need to make two primary adjustments: 1) Allow a viewer to create a “micropayment pool that any other account can withdraw from without needing to pre-specify which accounts; 2) Ensure the approach is double-spend resistant.
A Straw Man Solution
To create a one-to-many payment pool, the first step is still for Alice to deposit a certain amount of tokens to a seperate wallet W. Yet differing from the aforementioned payment channel, we don’t place the restriction that only Bob can withdraw from it.
Using the example above, Alice makes a deposit of 30 tokens to wallet W. Then Alice can sign an off-chain transaction Tx1 to send 4 tokens to Bob, and Tx2 to send 7 tokens to Carol. Later, Bob signs Tx1 and commits it to the blockchain, and Carol does the same. Likewise, Alice can send off-chain transactions to any recipient from this wallet. This seems to address the flexibility problem. However unfortunately, this opens the door to double-spending as shown below.
In the diagram above. The sender, Alice, creates the micropayment pool with 30 tokens. Then she signs an off-chain transaction of 30 tokens to Bob to buy eggs, as well as a transaction of 30 tokens to Carol to buy apples. As a result, Alice gets 60 tokens worth of goods while only spending 30 tokens! Later when Bob and Carol sign and publish their respective transactions, one of them will find out the pool has been depleted.
The Resource Oriented Off-Chain Micropayment Pool
It is worth pointing out that in the above example, the very reason that Alice gains extra value from double-spending is that Bob and Carol give different physical goods to Alice in exchange for tokens. If instead, Bob and Carol send Alice the same digital contents (e.g. two identical video files), Alice gains no extra value. We note that this is a very common case for video streaming. Imagine Alice being a viewer and both Bob and Carol are caching/relay nodes. If what Bob and Carol returned to Alice are the same video file, then Alice gains no extra value from double spending. Furthermore, if we can penalize Alice heavily when the double spending attempt is detected, Alice will lose more than she gains.
This observation motivated us to construct the following protocol.
Step 1. Micropayment pool creation: As the first step, Alice publishes an on-chain transaction to create a micropayment pool with a time-lock and a slashable collateral.
A couple things to be noted. To create the pool, Alice needs to specify the “Resource ID” resourceId that uniquely represents the digital content she intends to retrieve. It may refer to a video file, or a live stream.
The deposit amount needs to be at least the total value of the resource to be retrieved. For instance, if the resource is a video file which is worth 10 tokens, then the deposit has to be at least 10 tokens.
The collateral is required to discourage Alice from double spending. If a double spending attempt from Alice is detected by the validators of the blockchain, the collateral will be slashed. Later in the blogpost we will show that if collateral > deposit, the net return of a double spend is always negative, and hence any rational user will have no incentive to double spend.
The duration is a time-lock similar to that of a standard payment channel. Any withdrawal from the payment pool has to be before the time-lock expires.
The blockchain returns Alice the Merkle proof of the CreatePool() transaction after it has been committed to the blockchain, as well as createPoolTxHash, the transaction hash of the CreatePool() transaction.
Step 2. Initial handshake between peers: Whenever Alice wants to retrieve the specified resource from a peer (Bob, Carol, or David, etc.). She sends the Merkle proof of the on-chain CreatePool() transaction to that peer. The recipient peer verifies the Merkle proof to ensure that the pool has sufficient deposit and collateral for the requested resource, and both parties can proceed to the next steps.
Step 3. Off-chain micropayments: Alice signs ServicePayment transactions and sends them to the peers off-chain in exchange for parts of the specified resource (e.g. a piece of the video file, a live stream segment, etc.). The ServicePayment transaction contains the following data:
The targetAddress is the address of the peer that Alice retrieves the resource from, and the transferAmount is the amount of token payment Alice intends to send. The targetSettlementSequence is to prevent a replay attack. It is similar to the “nonce” parameter in an Ethereum transaction. If a target publishes a ServicePayment transaction to the blockchain (see the next step), its targetSettlementSequence needs to increment by one.
The recipient peer needs to verify the off-chain transactions and the signatures. Upon validation, the peer can send Alice the resource specified by the CreatePool() transaction.
Also, we note that the off-chain ServicePayment transactions are sent directly between two peers. Hence there is no scalability bottleneck for this step.
Step 4. On-chain settlement: Any peer (i.e. Bob, Carol, or David, etc) that received the ServicePayment transactions from Alice can publish the signed transactions to the blockchain anytime before the timelock expires to withdraw the tokens. We call the ServicePayment transactions that are published the “on-chain settlement” transactions.
Note that the recipient peers needs to pay for the gas fee for the on-chain settlement transaction. To pay less transaction fees, they would have the incentive to publish on-chain settlements only when necessary, which is beneficial to the scalability of the network.
We note that no on-chain transaction is needed when Alice switches from one peer to another to retrieve the resource. In the video streaming context, this means the viewer can switch to any caching node at any time without making an on-chain transaction that could potentially block or delay the video stream delivery. As shown in the figure, in the event that Bob leaves, Alice can switch to Carol after receiving k chunks from Bob, and keep receiving video segments without an on-chain transaction.
Moreover, the total amount of tokens needed to create the micropayment pool is (collateral + deposit), which can be as low as twice of the value of the requested resource, no matter how many peers Alice retrieves the resource from. Using computational complexity language, the amount of reserved token reduces from O(n) to O(1) compared to the unidirectional payment channel approach, where n is the number of peers Alice retrieves the resource from.
Double Spending Detection and Penalty Analysis
To prevent Alice, the creator of the micropayment pool from double spending, we need to 1) be able to detect double spending, and 2) ensure that the net value Alice gains from double spending is strictly negative.
Detecting double spending is relatively straightforward. The validators of the Theta Network check every on-chain transaction. If a remaining deposit in the micropayment pool cannot cover the next consolidated payment transaction signed by both Alice and another peer, the validators will consider that Alice has conducted a double spend.
Next, we need to make Alice worse off if she double spends. This is where the collateral comes in. Earlier in the blogpost we mentioned that the amount of collateral tokens has to be larger than the deposit. And here is why.
In the diagram above, Bob, Carol, and David are honest. Alice is malicious. Even worse, she colludes with another malicious peer Edward. Alice exchanges partially signed transactions with Bob, Carol, and David for the specified resource. Since Alice gains no extra value for the duplicated resource, the maximum value she gets from Bob, Carol, and David is at most the deposit amount. As Alice colludes with Edward, she can send Edward the full deposit amount. She then asks Edward to commit the settlement transaction before anyone else and return her the deposit later. In other words, Alice gets the resource which is worth at most the deposit amount for free, before the double spending is detected. Later when Bob, Carol, or David commit the settlement transaction, the double spending is detected, and the full collateral amount will be slashed. Hence, the net return for Alice is
Therefore, we can conclude that for this scenario, as long as collateral > deposit, Alice’s net return is negative. Hence, if Alice is rational, she would not have any incentive to double spend.
We can conduct similar analysis for other cases. The details are omitted here, but it can be shown that in all cases Alice’s net return is always negative if she conducts a double spend.
Another case is that Alice is honest, but some of her peers are malicious. After Alice sends a micropayment to one of those peers, it might not return Alice the resource she wants. In this case, Alice can turn to another peer to get the resource. Since each incremental micropayment can be infinitesimally small in theory, Alice’s loss can be made arbitrarily small.
Applications of Micropayment Pool Beyond Video Streaming
In the above discussion, we have presented the resource oriented micropayment pool concept in the video delivery context. It is worth pointing out that it can be used in other applications as well, as long as we can identify a resource where a user can gain no extra value when he obtains multiple copies of the resource from different peers. Here are a few examples:
- A resource can be a generic file. So the resource oriented micropayment pool can facilitate generic file sharing/storage.
- In the context of app distribution (e.g. Apple AppStore, GooglePlay), an app can be considered as a resource.
- A resource can be a certain type of service. E.g. file compression service, video transcoding service, solving a set of linear equations, etc. For these services, the requester gains no extra value by getting the same service from two vendors.
In summary, I hope I have been able to present to you our thoughts on the video streaming micropayment problem, as well as the concept of a resource oriented micropayment pool as our solution to the problem. In fact, there is more we can do with the resource oriented micropayment pool. Specifically, the resourceId parameter required to create the micropayment pool can be used to trace the authorship of the stream, and thus has implications on copyright tracking and content creation rewards. We will leave the details to the subsequent blog posts. As always, stay tuned for more!
