Simple, Scalable, Serverless Arbitrum RPC

[AuthorityNull]

Give a 3 sentence description about this proposal. This proposal simplifies the configuration, management, and operations of Arbitrum RPC endpoints. Using serverless technology with “Edge Compute” Workers, we built a custom proxy to enable simple load balancing and failover support for several Arbitrum RPC endpoints with zero downtime for orchestrators. While the community Arbitrum node is a great solution, this adds further functionality, scalability, and redundancy.

Describe the problem you are solving. Managing the evolving Arbitrum RPC ecosystem is complex, time-consuming, and expensive, regardless of technical aptitude.

Describe the solution you are proposing. A totally open source serverless approach to Arbitrum RPC access using Cloudflare workers.

• Custom worker to proxy many RPC URLs behind one DNS name.
  • Low latency
  • High flexibility
  • Redundancy
  • Zero downtime maintenance
  • Low cost
  • Geo-location
  • Leverages existing community Arbitum node

Describe the scope of the project including a rough timeline and milestones

Phase 1 - 7/15/2022 7/31/2022 - Fully completed

• Develop the worker app - 30 hours
  • Basic proxying funcionality
  • Load balancing
  • Failover support
  • KV storage support

Phase 2 - 7/22/2022 - 08/17/2022 - Fully completed

• Initial beta test with several orchs (Authority_Null, Mike Zupper, Ultima Ratio, Pon, Papa_Bear, lptnode) - 20 hours
• Prepare grant proposal - 2 hours
• Torubleshooting and code optimization from beta test results - 10 hours

Final Phase 3 - 8/15/2022 - 09/15/2022 - To be completed

• Create Livepeer forum post outlining the setup of the worker with Livepeer orch - 4 hours
• Create full video walk-though - 20 hours
• Conduct multiple “office hours” round table discussions live event (streamed on livepeer.studio) - 4 hours
• Discord support of worker - no charge
• GitHub repo of code included - no charge

Additional Task - Code Enhancement

• Reduce Cloudflare cost and increase efficiency by upgrading CF worker with new code - no charge
  • Eliminate need for KV storage support due to cost
  • Attempt to eliminate the need for multiple Alchemy accounts

Please estimate hours spent on project based on the above Phase 1 - 30 hours (completed) Phase 2 - 32 hours (completed) Phase 3 - 28 hours (pending)

Total hours: 90 at $125/hr Total cost: $11,250 Hours completed: 62 = $7,750 Hours pending: 28 = $3,500

[Franck-UltimaRatio]

This proposal deserve a grant ! All our nodes actually working like a charm since few weeks with part of this project in developement.

[Stronglikebull111]

Thanks for doing this work! This is tremendous for the LivePeer community! Such value! Plan to use immediately…

[papabear99]

Since moving to L2 RPC stability has been a major pain point for most Os including myself. During this time I have used Alchemy, Infura, the Offchain Labs public node, running a private node, and the Community node. So far the Cloudflare Serverless RPC solution is the only one that has proven 100% reliable. The reliability of this setup is IMO invaluable to the Livepeer network.

[Titan-Node]

Love it! A potential huge breakthrough for Livepeer node uptimes. Just as long as Arbitrum chain does not go down, all Livepeer nodes can hopefully achieve near 100% uptime

[0xcadams]

Cool! I haven't been following very closely, but is this a proxy server for the community arb node? What other providers would it proxy to?

[AuthorityNull]

Cool! I haven't been following very closely, but is this a proxy server for the community arb node? What other providers would it proxy to?

This can be used with any and every RPC including the community node and is easily managed through Cloudflare's UI.

[monitor-ap]

Thank you for putting forth the effort. This will be a game changer for stability and uptime!

[Pon-node]

I've been running this set up nearly a month now and did not see any outages on my orchestrators, meaning my up time is great and it can help everyone to keep their orchestrator up even if one of the RPC ends fails. You can add as many as you want RPC ends to it! In last couple months we all been pulling our hair out due to RPC end issues and this is solution that will help to keep your orchstrators running!!!!!

[RyanC92]

This is awesome, its been a huge pain point for orchestrators to find a reliable RPC solution, if this is it then we need this ASAP! Great job guys.

[MnrGreg]

Out of interest, will the more stateful filter polling methods still work when using RPC-over-HTTP or will we need to use Websockets for these?

eth_newFilter
eth_newPendingTransactionFilter
eth_getFilterChanges

[mikezupper]

Out of interest, will the more stateful filter polling methods still work when using RPC-over-HTTP or will we need to use Websockets for these?

eth_newFilter
eth_newPendingTransactionFilter
eth_getFilterChanges

That’s a good question. It was not intended to be stateful. I did not test any web socket scenarios. Livepeer has a very niche set of rpc methods it uses. My suspicion is that it does not work. But I’m not 100% sure… please test it out and let me know what you find. It may be an easy fix!

[AuthorityNull]

Out of interest, will the more stateful filter polling methods still work when using RPC-over-HTTP or will we need to use Websockets for these?

eth_newFilter

eth_newPendingTransactionFilter

eth_getFilterChanges

Mike wrote the code for this so I'd take his word for it! There's a guide available for getting this up and running if you'd like to play with it:

https://forum.livepeer.org/t/guide-simple-scalable-serverless-arbitrum-rpc/1867

[mikezupper]

Out of interest, will the more stateful filter polling methods still work when using RPC-over-HTTP or will we need to use Websockets for these?

eth_newFilter
eth_newPendingTransactionFilter
eth_getFilterChanges

Interestingly enough, Cloudflare does support web sockets. This maybe an upcoming test ;)

https://developers.cloudflare.com/workers/learning/using-websockets/

[nelsorya]

Hey @AuthorityNull, thanks for putting this together. This looks like a very well-thought-through proposal with a lot of the work already completed. It's also great to see the community support behind this proposal. We are excited to fund this with the phases and amounts you outlined above.

[adrianmyatt]

I've moved most of my nodes across and setup was straightforward. Mike ran through the configuration so I understand the basics of how it works and can make adjustments as needed. I've only been running this for a few days but so far have seen no rate limiting.

This is a good alternative for load balancing multiple RPC sources and removes the need to manually switch nodes between providers when they rate limit or go down.