How are Livepeer's Probabilistic Micropayments holding up with these Ethereum high gas prices?

One of the goals of the Livepeer Streamflow upgrade was to make the network cost effective for users of the video transcoding infrastructure independent of fluctuations in Ethereum gas prices. This was accomplished using a mechanism called Probabilistic Micropayments, which is like paying the nodes with a lottery ticket instead of cash. Now that we have observed gas prices rising from 1 gwei to 300+ gwei in the past couple weeks, it’s worth checking in on how this claim has been holding up in practice.

In short, PMs are holding up to this promise well, but with more funds deposited by broadcasters, they could be performing exceptionally.

I’ll start with the ideal case. With 300 gwei gas prices, if a broadcast node had a large deposit of 100 ETH, then they would be able to access the lowest prices on the network and all orchestrators would have confidence that their deposit was large enough to cover their high transaction costs. In this case nodes would see about 3-4% overhead added to the transcoding fees in order to cover transaction costs - in the same ballpark as a credit card processing fee.

100 ETH is a lot of money. Almost $40,000 USD at current ETH value. While this may seem like a lot, Livepeer is most beneficial to those who are doing transcoding at scale - those who would otherwise be paying hundreds of thousands or millions of dollars to infrastructure services. Surely putting down a large deposit may be worth it to access 10-100x improvement in infrastructure costs at those volumes.

But clearly, 100ETH is out of reach for smaller upstart applications just getting off the ground. What might overheads look like here with high gas prices? Here’s a sampling of some of the recent winning ticket transactions…

face_value tx_cost overhead gas_price gas_used
0.043478260869565216 0.01982196 0.45590508 120 165183
0.043478260869565216 0.02341956 0.53864988 120 195163
0.043478260869565216 0.019125974 0.439897402 98 195163
0.043478260869565216 0.013021262256730016 0.29948903190479037 74.000001459 175963
0.043478260869565216 0.007243335 0.166596705 45 160963
0.043478260869565216 0.00831519675 0.19124952525 47.25 175983

What you are seeing here is that as the gas price rose from 47gwei to 120gwei the overhead to pay transaction fees rose from 19% to 53%. Why is this?

When nodes doing work on the network observe that their transaction costs will rise, they either need to raise the face value of the tickets, or charge higher prices to the broadcasters. If the broadcaster has a large enough deposit to guarantee winning tickets will be paid across all orchestrators, it’s not a problem - the nodes can continue charging a low price. But in the network very few Broadcasters have a deposit larger than 2 ETH, so nodes are raising their prices to get the security they need when performing the work.

A 50% overhead may sound like a lot, but in reality this means the nodes are charging double. Ethereum gas prices went up 30000%, but Livepeer transcoding costs only went up 2x, and only up at all if the broadcaster’s deposit wasn’t large enough. And again, at a 10-100x cost savings to begin with, a 2x increase may not be intolerable.

In summary, PM’s are theoretically working at reducing exposure to gas price fluctuations for users - however in practice, if users aren’t willing or able to increase their deposit, they may see some slightly increased prices as gas prices shoot up. Even further work on scaling using enhancements to PMs and other offchain payment mechanisms can mitigate this further, but we think PMs is a working starting point that serves the network well during this bootstrapping phase.

As a reminder, the implementation and spec are open source, and we would love to help other projects get started in adopting this solution.

1 Like

Hmm, I can’t agree with your conclusion. I had 4 winning tickets during the last 24h, each with a face value of 0.0434. On average, I paid 0.03 in transaction fees for each ticket.
Currently, I’m sharing 75% of the earned fees with my stakers -> I’m losing money with transcoding

Essentially I’m losing 70% of the ticket value due to gas cost, which also means that I would need to keep at least 70% of the fees generated for myself only to break even. I wouldn’t call this “holding up well”, sorry.

I’m no expert on Layer 2 solutions (there’s just too much to keep up with…) like zkSync or zkStark but as far as I know, this sounds like a perfect usecase for it. Wouldn’t it save the orchestrators (and broadcasters) a ton of gas compared to the current solution and therefore allow the orchestrators to share a larger % of their earnings with their stakers?

There is some good discussion on this in the Discord, but in summary…

  1. Yes, As L2’s mature and become adoptable, they may offer good solutions with different tradeoffs. It’s definitely on the scaling roadmap to continue this research.

  2. If you’re sharing 70% of your fees with delegators, you’d certainly want to reduce that if you’re losing money. Taken to the extreme, it would be silly to say that “I’m sharing 99.999% of my fees, yet I’m expecting to be profitable on the 0.001%”. The client could certainly add features/options to better configure pricing/fee share dynamically. Feel free to file an issue if you’d like and have ideas.

  3. The txn fees are largely paid by the broadcasters with low deposits through the increased cost of their PM tickets. In your example you received 4 tickets, but if gas prices were really low, you may have only received 1 for 1/4th the face value. Broadcasters can avoid this overhead by increasing the size of their deposit. Then less of the money they’re paying would go to miners.

I still stand by the fact that PMs are holding up well under large deposit assumptions, and they function for the demand side with reasonable overheads. On the supply side, the software could do a better job of either manually making changes to your parameters, surfacing changes that it suggests you make based on current market conditions, or preventing you from ever doing losing work.