If operating on a L2 reduces the cost of redemption, will this reduce the typical
faceValueof a PM ticket (and assuming the number of Orchestrators in the active set remains constant), will this enable Broadcasters to have smaller deposits / reserves, thus lowering the barrier to entry for Broadcasters?
The reduced cost of redemption on L2 can help reduce reserve requirements by a bit for Bs, but I also think medium/long term updates to the payment protocol will also be desirable to further reduce the barrier to entry for Bs.
For now, an example to illustrate how lower redemption costs can impact reserve requirements:
At a gas price of 100 gwei, I estimate that the redemption cost should be somewhere around 0.02-0.03 ETH [1]. Suppose the ticket redemption cost is 0.025 ETH. Then, given the current typical faceValue of ~0.18 ETH, the overhead for redemption would be ~13%. If the gas price drops to 2 gwei on L2, then the ticket redemption cost should be somewhere around 0.0005 ETH. Then, given the current typical faceValue of ~0.18 ETH, the overhead for redemption would be ~0.2%. As this is less than the target overhead of 1% that is currently set by Os, a B could reduce its reserve in this scenario while still being able to cover lower faceValue tickets that still have an overhead of around 1% for redemption. In fact, given a redemption cost of 0.0005 ETH, a faceValue of 0.05 ETH would achieve an overhead of 1% and this would translate to a 0.05 * 100 = 5 ETH reserve for the B.
[1] I am assuming gas usage of 250000 for ticket redemption. In practice, the gas usage might be slightly different.
I’m assuming that the
-ethUrlwill need to pass in an RPC endpoint for the L2 network, and then I guess the options are:
Yep that’s right. The -ethUrl flag will be able to accept an L2 RPC endpoint which could be backed by a self-hosted L2 node or a hosted service like Infura/Alchemy. There are docs for running a L2 node. Since the Arbitrum stack is not as mature as the L1 Ethereum stack, there will be some kinks to work out for those that intend to run self-hosted L2 nodes (for example, the additional storage requirements for the L2 node given that there haven’t been many optimizations implemented yet targeting storage and connections with L1 nodes). So, for those that are interested in starting to experiment with running self-hosted L2 nodes would be interested in hearing about the experience and any learnings. The core team is also currently experimenting with running L2 nodes as well and will aim to share learnings from the experience.