RPC provider AVS

Screenshots

Problem Statement

RPC providers are a centralization pain point for ethereum. Sic. Tornadocash censorship, mev and payment for orderflow resulting in users being front/back run and loosing out.Incentives for running ETH rpcs are non-existent even though theyre the main entry point for users to interface with onchain. Heavy centralization towards MM default/infura/consensys or perhaps paradigm.Goals: Incentivize independent smaller RPC providers. Incentivize LST protocols and small/solo stakers to offer public RPCs to users. Diversify RPC landscape. Reduce payment for order flow and mev capture at main centralization points like infura/metamask default RPC. Reduce total network censorship. Decentralize RPC providers geographically vs current centralization with infura arch running in US.Steps/overviewRpc operator purchases token (mockERC20 here, ref RPCOPToken)RPC operator signs up via registry contract (provided by eigenlayer) by running make cli-setup-operator using their RPCOPToken as a stake and their default rpc uri.Task generator in aggregator.go runs offchain, creating tasks to check RPC ping response times/censorship status.Validators that opt into this AVS run operator.go from geographically distinct locationsConsume Task stream generated by aggregator.go. Generate response times from RPC URI in taskAggregator aggregates responsesRPC operators are incentivized and awarded tokens (MockERC20/RPCOPToken here, same as used to sign up/register for the serviceRPC operators with prolonged downtime or heavy censoring or incorrect responses have stakes slashed (TODO/not impl)

Solution

combines rpc infra and eigenlayer avs for net positive economic incentivesbuilt using the eigenlayer Incredible Squaring AVS demo codeGo lang, offchain aggregator and operatoronchain registry contracts from eigenlayer; aggregate and task service managertested via go test, forge test, and anvilPartner targets : Nethermind, L2s that may introduce more RPCs/MEV