The Streamflow release of the Livepeer protocol will bring a variety of performance, reliability and scalability improvements to the Livepeer video transcoding network. One of the major scalability improvements is the use of off-chain micropayments with periodic on-chain settlement to pay for video transcoding which will be enabled by an implementation of a probabilistic micropayment (PM) protocol. In this protocol, users pay service providers with lottery tickets — an approach that brings scalability advantages, but also creates security challenges. To address these security concerns, the current design involves user provided collateral to guarantee value for service providers even if users run out of funds and a mechanism for allocating collateral for specific service providers. While the draft technical specification formally defines the protocol, this post will provide a high level overview of the design and candidate solutions for problems such as double spend prevention encountered in the design process.
Introduction
The Livepeer network connects broadcasters, users that need their video transcoded, with orchestrators, service providers with access to compute and bandwidth capacity for video transcoding. Broadcasters send micropayments with segments of their video stream that compensate orchestrators for transcoding the segments. An ideal off-chain micropayment protocol suitable for the Livepeer network fulfills the following requirements:
- Low latency: After receiving a micropayment, orchestrators should be able to respond to broadcasters immediately
- Supports switching between recipients: A broadcaster should be able to switch from paying orchestrator A to orchestrator B immediately mid-stream
- Supports paying multiple recipients simultaneously: A broadcaster should be able to pay multiple orchestrators simultaneously with the transcoding work either being split or redundantly done by multiple orchestrators depending on the broadcaster’s preferences
- Supports paying new recipients without additional on-chain setup: A broadcaster should be able to pay an orchestrator that just joined the network without incurring additional on-chain setup overhead
- No expectation of long lived relationships with some minimum value transacted: An orchestrator should not be affected by broadcasters that disconnect after sending a small amount of micropayments
An additional nice-to-have property for a micropayment protocol is minimal third party infrastructure dependence. Ideally, broadcasters should be able to pay orchestrators without relying on additional always online third party infrastructure outside of a smart contract deployed to the blockchain. However, that being said, broadcasters and orchestrators could certainly benefit from value-added services offered by third parties in the future. In the short term, broadcasters should have the option of paying orchestrators directly. In the long term, broadcasters could have the option of accessing services offered by third party infrastructure providers such as liquidity provision to reduce personal collateral requirements or currency exchange to pay for transcoding with different currencies.
Background
PM has been an area of interest for the academic cryptography community for many years [1][2][3]. This interest was largely motivated by the following question: how can parties send micropayments to each other while minimizing costly interactions with a bank (the cost of processing a transaction might exceed the value of a micropayment)? The key insight from this research was that a lottery ticket can serve as a micropayment of the ticket’s expected value as long as many tickets are received such that the payee will be guaranteed fair payment over the long term due to the law of large numbers. By configuring the pay out and winning probability of tickets, parties can control how often winning tickets are created and thus, the frequency of bank settlements.
The term “bank” in the aforementioned question can be swapped for the term “blockchain” and the updated question would reflect the motivations driving efforts by researchers and engineers today building layer 2 payment protocols on top of blockchains. Various constructions such as payment/state channels and commit chains (i.e. NOCUST, Plasma) have emerged each with their own set of benefits and tradeoffs (see [6] for an overview for these constructions). PM can also be adapted to this setting and serve as a layer 2 payment protocol with a blockchain settlement layer as previously noted by the Orchid project. Instead of relying on a bank as the opaque trusted third party, parties can rely on a smart contract deployed on a blockchain as a transparent trusted third party with pre-programmed rules for handling escrowed funds and processing winning tickets.
Payers will first create a deposit with a smart contract that holds payers’ funds in escrow. When a payer wishes to send tickets to a payee, it first requests ticket parameters from the payee which consists of faceValue (the pay out for a winning ticket), winProb (winning probability) and a commitment to a secret random number generated by the payee. The payer will then use the received parameters in tickets sent to the payee with each ticket representing a payment of faceValue * winProb(i.e. the expected value of the ticket). The payer includes its own random number with each ticket along with its signature over the ticket.
Winning tickets are selected based on a ticket’s winProb and a random value produced by hashing the payer’s random number with the payee’s secret random number which corresponds to the commitment included in the ticket. If a payee receives a winning ticket, it can submit the ticket along with its secret random number and the payer’s signature to a smart contract which will verify that the ticket indeed won. Given a distinct payer and payee pair, neither party can bias the random value used to select winning tickets because the payer only sees the payee’s commitment to a random number when generating its own random number and the payee is forced to commit to its random number before it sees the payer’s random number.
In the Livepeer protocol, payers are broadcasters and payees are orchestrators. Broadcasters can send each video segment of a stream with a ticket that pays an orchestrator to transcode the segment.
Double Spending with Tickets
The simplest PM protocol uses a single on-chain deposit to back tickets that are sent to arbitrary recipients. This design is vulnerable to a double spend attack where a malicious broadcaster sends winning tickets to many orchestrators with insufficient deposit funds to cover all outstanding winning tickets.
In their design for a PM protocol built on Bitcoin, Pass & Shelat suggest payers lock up collateral (in addition to their deposit) which is slashed if a double spend by the payer is detected [4]. If the value of the collateral is sufficiently high such that the payer would lose more value when its collateral is slashed than it stands to gain from double spending, then double spending would be economically irrational. However, Pass & Shelat’s design does not describe a specific mechanism for setting a sufficiently high collateral requirement for payers.
In [5], Chiesa et. al. contributed a formal economic analysis of double spend attacks in PM protocols which noted that in order to set a collateral requirement to deter double spending, the additional utility that a malicious payer can gain from double spending must be bounded. The utility from double spending can be bounded by placing bounds on a few parameters including the maximum number of recipients and the maximum value of winning tickets accepted by recipients during a time period. With a bound on the utility from double spending, the collateral requirement can be set to be higher than the bounded utility.
Claimable Reserves
In the designs of [4] and [5], when a double spend is detected the payer loses all of its collateral and victim payees are left uncompensated for received winning tickets that are no longer redeemable. In a service economy, these victim payees would have expended some amount of resources to provide a costly service in exchange for tickets. Thus, while the payer suffers from lost collateral, the victim payees are also not any better off.
An alternative to fully slashing collateral upon double spend detection is to treat the collateral as a payer’s reserve that can only be drawn upon if the payer’s deposit is depleted. When a payer overspends from its deposit, a payee with a winning ticket can claim from the payer’s reserve up to a certain pre-defined amount. A payer can commit a certain amount of its reserve to a particular payee which will guarantee the payee that amount in the event that the payer’s deposit is insufficient to cover a payee’s winning ticket.
A payee can treat the guaranteed amount from the payer’s reserve as the maximum float the payee will allow for a payer. In traditional finance, float is money that a payee receives, but due to processing delays is still accounted for in the balances of both the payer and payee’s balances. Similarly, in PM, float is the value of winning tickets that a payee has received, but has not yet successfully redeemed on-chain. In PM, the maximum float for a payer is the cumulative value of winning tickets that a payee will accept prior to rejecting additional tickets until the payee observes the successful redemption of its winning tickets. The payee accepts winning tickets up until this maximum float because the allocation from payer’s reserve guarantees this amount even if the payer’s deposit is depleted. As a payee receives winning tickets, it increases its current float for the payer and as a payee observes successful ticket redemptions, it decreases its current float for the payer.
Local Recipient Set Commitments
While a payer reserve can be used to compensate payees in the event of payer overspending, a payer still needs to:
- Define a recipient set with a bounded size (as noted by [5])
- Allocate a certain amount of the reserve to each recipient
These two requirements can be fulfilled using recipient set commitments (a concept introduced in [5]). When a payer creates its reserve, it will also create a recipient set commitment for the reserve — only the recipients included in the commitment will be eligible to claim from the reserve. This commitment is the root of a Merkle sum tree, a variant of a Merkle tree where each leaf contains an additional numerical value and parent nodes contain the sum of the numerical values in their child nodes. A payer can specify the value to commit to a particular payee by including the value in a leaf node along with the payee’s address. Then, the root of the tree will contain the sum of all the committed values in the leaves which is the total reserve for the recipient set.
Payees will only accept a ticket as valid payments if it is sent with a valid Merkle proof that demonstrates:
- The payee was included in the payer’s recipient set commitment
- The payer’s reserve contains at least enough funds to cover the value of the allocation committed to the payee
We refer to this type of recipient set commitment as a local recipient set commitment to indicate that the construction of the recipient set commitment is locally executed by the payer who decides which recipients to include and how much value to guarantee each recipient from the payer’s reserve.
The below diagram describes the use of a local recipient set commitment based PM design within the Livepeer protocol. A round represents a fixed time period in the protocol denominated in Ethereum blocks and at the beginning of each round the orchestrator set is locked in for the duration of the round. In the diagram, a broadcaster updates its recipient set commitment after observing modifications to the orchestrator set in a new round.
A local recipient set commitment based construction fulfills the following requirements for a micropayment protocol mentioned at the beginning of this post:
- Low latency: As long as an orchestrator does not accept tickets after reaching the maximum float for a broadcaster with its received winning tickets, then an orchestrator can respond immediately to tickets knowing that it will eventually be paid for any received winning tickets
- Supports switching between recipients: A broadcaster can pay any orchestrator within its recipient set commitment
- Supports paying multiple recipients simultaneously: A broadcaster can pay multiple orchestrators simultaneously as long as they are within its recipient set commitment
- No expectation of long lived relationships with some minimum value transacted: An orchestrator is not affected by broadcasters that send a few non-winning tickets and then disconnect because it knows that it will eventually receive a sufficient number of tickets from the numerous broadcasters it works for such that it will be paid fairly. Furthermore, since orchestrators set the face value of tickets, they can always ensure that it will be profitable to redeem received winning tickets
The protocol also has the nice-to-have property of minimal third party infrastructure dependence since a broadcaster is able to send tickets directly to an orchestrator. However, since a broadcaster would need to submit an on-chain transaction to update its recipient set commitment to include new recipients, this construction does not fulfill the requirement of paying new recipients with no additional setup.
Global Recipient Set Commitments
The previous construction can be modified based on how orchestrators are registered in the Livepeer protocol to address the last unfulfilled requirement of paying new recipients without additional on-chain setup overhead. In the Livepeer protocol, the orchestrator set is updated at the beginning of each round based on stake delegation from the previous round. Furthermore, the size of the orchestrator set is capped. Thus, instead of having broadcasters create a local recipient set commitment, broadcasters can create a global recipient set commitment — their reserve would always be committed to the members of the global orchestrator set for the current round. The reserve funds would be split into equal size allocations with each allocation committed to one of the registered orchestrators during the round.
As indicated by the above diagram, while a broadcaster might maintain a constant reserve over the course of many rounds, at the beginning of each round, the broadcaster’s reserve is committed to the orchestrator set for the round. If the broadcaster overspends from its deposit during a round, its reserve is frozen and orchestrators registered during the round can redeem winning tickets to claim from the broadcaster’s reserve.
This construction no longer requires an additional on-chain transaction to allow a broadcaster to pay new entrant orchestrators and thus fulfills the requirement of paying new recipients without additional setup. However, side effects from committing equal allocations of the broadcaster’s reserve to the orchestrator each round include:
- While a broadcaster can freely adjust the size of its reserve, it is unable to increase or decrease allocations committed to particular orchestrators
- Since some orchestrators might refuse to work for a broadcaster with a small reserve (i.e. less value guaranteed for the orchestrator via the reserve allocation), a broadcaster’s reserve requirement will likely increase with the maximum size of the orchestrator set since a constant reserve would be split into smaller allocations as the number of orchestrators increases
Both points could potentially be addressed by allowing for local recipient set commitments in addition to global recipient set commitments. A broadcaster could choose the tradeoff it would like to make. If the broadcaster uses a global recipient set commitment it faces increased collateral requirements and less flexibility to increase/decrease allocations committed to particular orchestrators, but it incurs minimal on-chain setup overhead to pay new orchestrators that enter the network. If the broadcaster uses a local recipient set commitment, it incurs additional on-chain setup overhead to pay new orchestrators that enter the network, but it can control its collateral requirements by increasing/decreasing the number of orchestrators it commits to and it has increased flexibility to increase/decrease allocations committed to particular orchestrators.
Conclusion
In summary, the Streamflow PM protocol design uses claimable broadcaster reserves that are automatically committed to the global orchestrator set during each protocol round in order to mitigate the risk of broadcaster double spending for orchestrators accepting PM tickets. The downsides of this design can potentially be addressed by allowing broadcasters to instead choose to use a local recipient set commitment. However, offering broadcasters a choice only allows broadcasters to choose what to prioritize given a set of unavoidable tradeoffs. As the Livepeer protocol evolves beyond the Streamflow release, research and development in scalable payment protocols will continue in an effort to either improve the set of tradeoffs faced by network participants or in the best case avoid the tradeoffs altogether.
- Technical specification that covers the on-chain smart contract for winning ticket redemption and off-chain protocol for sending tickets
- Research issues in Github containing continued design discussion
Thanks to Doug Petkanics, Eric Tang and Josh Allmann for many design discussions.
References
[1] Wheeler. “Transactions Using Bets”
[2] Rivest. “Electronic Lottery Tickets as Micropayments”
[3] Micali & Rivest. “Micropayments Revisited”
[4] Pass & Shelat. “Micropayments for Decentralized Currencies”
