gRPC additions

[Mirko-von-Leipzig]

We potentially want to add the following gRPC methods:

• Support validator key rotation by returning the block at which the key was rotated. This must allow clients to SyncMmr from a previously sync'd block to the rotation block, which they can therefore verify is correct. After this they can continue on with the new validator key.
• Trusted methods on the sequencer which allows submission of authenticated txs and batches. This is an internal only set of methods which allows internal replicas to lower the load on the sequencer. Might require a new sequencer specific gRPC service.

[Ollie202]

I’d like to help with this if there is a slice suitable for external work.

The first item looks like the most concrete one to start with: moving the block/proof streaming methods toward the RPC service. From a quick read, the current streams live on the internal store replica API as BlockSubscription and ProofSubscription, implemented in crates/store/src/server/replica.rs, with replica sync consuming them from crates/store/src/server/replica_sync.rs.

My proposed first step would be to trace that path and put together a narrow PR for just the API/service move, keeping the stream semantics the same:

• same start block behavior,
• same live/historical replay behavior,
• same lag/error behavior,
• no changes to validator key rotation or trusted sequencer methods in the same PR.

If that matches the intended direction, could this be assigned to me?

[Mr-kay-cloud2]

Since this issue covers multiple gRPC additions, would you prefer this to be split into smaller PRs?

I can start by looking into moving the block/proof streaming methods to the RPC service if that is the preferred first step.

We potentially want to add the following gRPC methods:

• Move block and proof streaming methods to the RPC service.[ ] Support validator key rotation by returning the block at which the key was rotated. This must allow clients to SyncMmr from a previously sync'd block to the rotation block, which they can therefore verify is correct. After this they can continue on with the new validator key.[ ] Trusted methods on the sequencer which allows submission of authenticated txs and batches. This is an internal only set of methods which allows internal replicas to lower the load on the sequencer. Might require a new sequencer specific gRPC service.

Since this issue covers multiple gRPC additions, would you prefer this to be split into smaller PRs?

I can start by looking into moving the block/proof streaming methods to the RPC service if that is the preferred first step.