bootstrap broadcasters entirely from subgraph data

[iameli]

Summary

go-livepeer -broadcaster interacts with the Ethereum/Arbitrum blockchain in three ways:

1. Prints tickets to pay Os for transcoding.
2. livepeer_cli commands to initialize broadcaster deposit/reserves and such
3. Retrieval of an orchestrator list from the registry contract

1 is an entirely offchain process and 2 is an administrative process that can be performed away from production servers.

3 is a blocker right now, but the orchestrator registry is trivially retrievable from on-chain data.

Therefore, we should implement the ability for broadcasters to boot up without an -ethUrl, only a subgraphUrl.

Rationale

Currently, your options for running a high-availability Livepeer broadcaster node are:

1. Run a Prysm + Geth + Arbitrum full node, which requires a ton of NVMe storage and is a big PITA.
2. Use Infura/Alchemy/etc, which is centralized and high-latency, substantially increasing bootup times

This patch would replace these options with two much more appealing options:

1. Run your own graph-nodes, which have lower system requirements and minimal storage requirements
2. Use the Graph Protocol decentralized service, which should be able to offer reasonably low latencies

EDIT with some further justification:

What appeals to me about the architecture is that it moves the HA layer. Currently to ensure that broadcasters have access to a high availability blockchain layer we have to set up redundant Prysm + Geth + Arbitrum nodes, including monitoring and failure detection on all of that so that traffic can be routed away from nodes that fall out of sync. We're in the process of setting up 9 big servers for this; 3x redundancy in 3x regions around the globe. Big, expensive, and still higher latency than a local node!

With the graph-node architecture, we'd still want to run our own nodes, but the individual blockchain nodes no longer need to be HA. Rather, we could have a smaller number of Prysm + Geth + Arbitrum + graph-nodes that redundantly write to a Postgres database. As long as one of those remains up, the database gets updated — no more 3x redundant blockchain node requirements. Then that small, lightweight database can get replicated to each cluster for low-latency node bootup and day-to-day operations.

[leszko]

I think that Point 1 is not entirely offchain process, since we use the current block number for the ticket params

[iameli]

@leszko Fair point, but an up-to-date graph node will have that information as well.