[Feature Request]: Light node can specify an endpoint to retrieve and submit blob data

[cmwaters]

Implementation ideas

Outside of outsourcing all rollup infrastructure to a RaaS partner where the security is guaranteed in contract, a rollup may want to run a light node for the sequencer and point it to a dedicated bridge node that can provide blob retrievability and submission through a SLA (Hibachi for example does not use a RaaS partner). This may be more preferred over using random peers in the network but currently this doesn't seem possible.

Constraints

Currently teams like quicknode will want to be able to add a token to the API endpoint to authorise and track usage from their users so the solution should support this.

To work out:

• Would these API providers support rollup sequencers by providing samples and headers for verification or would they limit to just standard rollup API (blob retrieval and submission) given that validators are expected to provide the service of sampling and verifiability. Naively, I would assume it would just match everything served over the JSON-RPC

[walldiss]

rollup may want to run a light node for the sequencer and point it to a dedicated bridge node that can provide blob retrievability and submission through a SLA

celestia-client-lib allows direct connect to RPC provider or self-hosted (Light or Bridge) node. In this case it seems light node is not the right tool. Or what is the difference in the usecase and why LN is needed here?

[cmwaters]

The same reason why the LN would be preferred to the celestia client in all cases, security. The LN verifies headers and samples which is more secure than the celestia client lib.

[walldiss]

Issue mentions request to use RPC only for blob retrieval. However as you mentioned headers and samples are needed for particular users. So perhaps those should be provided from RPC:

• blobs
• headers
• samples

Some constrains that needs to be considered:

• syncing header chain from RPC might cause a lot of load for given provider. This should be expected by client and provider, considering public serving of those headers is also a pinky promise.
• json-rpc encoding has massive overhead compared to binary p2p protocols such as Shrex. This will impact bandwidth requirements for header sync and blob retrieval.
• RPC providers needs to support multiple connections from same client

[cmwaters]

However as you mentioned headers and samples are needed for particular users.

Yeah, it's unclear to me whether a light node using a paid API provider will:

1. Get all data (including samples and headers) from the single endpoint; or
2. Get all blob data (and proofs) from the single endpoint. Get headers and sample from the rest of the network.

I would start with whatever is simplest to implement first.

[Wondertan]

You can plug the HeaderExchange interface implementation over the node's RPC. This is the easiest, as the RPC client API already implements the interface, and it's only a matter of injecting deps differently.

[Wondertan]

Although personally, I would prefer to introduce a prioritization for the p2p so that the configured RaaS p2p endpoint is preferred, yet there is a fallback to the p2p network. It's less easy, but it has other benefits.

[cmwaters]

p2p network fallback could be a cool follow up but is probably not needed for the first implementation. What could also be done (doesn't need to be immediately) is to support multiple endpoints so the paid API provider can have some redundancy

[Wondertan]

While I see sense in redudancy with multiple endpoints in general, doing that for the paid API case seems excessive, as paid API should already give you sufficient reliability. Otherwise, what are you paying for?

[adlerjohn]

1. Get all data (including samples and headers) from the single endpoint; or
2. Get all blob data (and proofs) from the single endpoint. Get headers and sample from the rest of the network.

IMO it should be (2), no? If you use an RPC provider for headers, then you're making it trivial to partition/eclipse your node. The headers and samples should be over p2p, so they're respectively partition-resistant and unlinkable (with anon sampling). Only the blob data is the heavy part that needs special reliability.