Crossdomain Relayer w/ Indexer

[fainashalts]

We need to determine the scope of indexing that we offer developers. This issue is a placeholder until adequate product and engineering scoping can be completed.

Some key points to keep in mind:

• Indexing all chains and events in the growing Superchain could become unwieldy - as the ecosystem grows this will become more resource-intensive.
• Third party indexing solutions may be a better short/medium-term option, reducing internal complexity and time-to-market. Using a third party would allow the team to focus on core capabilities rather than infrastructure-heavy tasks.
• If we invest in an OP Labs-based indexing solution, it seems we have consensus that we should focus on a narrow set of events or contracts rather than indexing everything.
• We may be able to leverage existing infra like the Open Labels Initiative's EAS schema for contract labels, or integrating with existing contract registries.

Next Steps:

1. Clarify the requirements - what do our Q1 projects truly need in terms of indexed data?
   -- It seems contract dashboard may be the only area where we strictly need indexing, so perhaps we should use a third party solution there.
2. Evaluate third-party options - Explore data providers like Goldsky or open initiatives like Open Labels Initiative to determine if they can cover our most pressing needs. Determine whether these solutions can be leveraged quickly and reliably in Q1.

[pharger]

@fainashalts can we tighten the scope of this issue or perhaps we split it into tighter child issues? Based on conversations prior to break the first order of business should be scoped explicitly to the crossdomain bridges to support relayer work. We potentially want three separate issues:

1. Index transactions on the L1<>L2 bridge for all support L2s on sepolia and mainnet (in support of migrating the superchainrelayer.xyz into console
2. Index transactions on the L2<>L2 inbox for sepolia when devnet launches, then standard testnet/mainnet support
3. Index contracts deployed through CLI for contract management dashboard

[fainashalts]

@pharger I think we might need to dive a bit deeper here -- the relayer doesn't strictly need indexing, as its used on a per-transaction basis. I know when we spoke earlier I may have said something different but we were moving fast so I think I misspoke. 😄

We had talked separately about wanting to index interop transactions specifically for observability and potentially to back up other future tools like automatic relaying. We need to do more scoping to figure out what that looks like. I propose as a first step we move the existing relayer into the console (which entails a rewrite as well) and then make it able to do L2-L2 relaying in prep for interop. The auto relay + indexing piece we can do more legwork on defining.

Its hard to narrow indexing needs for contract management which is why we had discussed using a third party service. We could index individual contracts but I'm not sure we should. Curious to know more about your thoughts here.

[pharger]

Hmm maybe I'm missing something - in the scope of this issue, does it need to be more than simply indexing the cross domain messenger for the tx hashs, etc. as specified in the PRD? Im assuming we are carving out the contract indexing pice from this ticket. I guess I'm curious what the MVP really entails if we keep the scope here tight

[pharger]

Also curious if we can't just use a third party solution to get this off the ground adn build the front end capabilities before persuing the full indexer write?

[fainashalts]

Hi @pharger! Have had more convos about this since last we spoke, and I propose we reduce the scope here way down: let's index interop transactioon only (so those that go through the L2toL2CDM) - this will allow us to provide a frontend for these if we want, and also will make the L2 to L2 Relaying UX much nicer.

For contract dashboard, I agree we should find a 3rd party solution, at least until we see if our dashboard has any PMF. Does that align with your thinking?

[pharger]

Confirming we discussed Monday 1/13 and have a path forward for Hamdi to take ownership with the goal fo shipping for ETH Denver. Moving to ready.