Use Proto Types in storage instead of bytes

[MitchTurner]

Linked Issues/PRs

followup to feedback from #3100

Description

Checklist

• Breaking changes are clearly marked as such in the PR description and changelog
• New behavior is reflected in tests
• The specification matches the implemented behavior (link update PR if changes are needed)

Before requesting review

• I have reviewed the code myself
• I have created follow-up issues caused by this PR and linked them here

After merging, notify other teams

[Add or remove entries as needed]

• Rust SDK
• Sway compiler
• Platform documentation (for out-of-organization contributors, the person merging the PR will do this)
• Someone else?

---

Note

Replaces opaque byte blocks with strongly-typed Protobuf messages across API, storage, and streams, adds complete proto schema coverage, and introduces serializers for Fuel <-> Protobuf with tests.

• Protobuf schema:
  • Define comprehensive block model in proto/api.proto (versioned Block, Header with V1/V2, all Transaction/Input/Output variants, metadata, policies, etc.).
• Serialization layer:
  • Add SerializerAdapter to convert Fuel Block/TXs to/from Protobuf (ProtoBlock) with roundtrip support and proptests.
• API/service changes:
  • Generalize BlockAggregatorApi/BlockSource/BlockAggregator to carry a Block type; use ProtoBlock throughout.
  • Replace tonic server/client plumbing to send/receive ProtoBlock literals in GetBlockRange and NewBlockSubscription.
• Storage:
  • Store and stream ProtoBlock in storage_db (Blocks table, StorageStream); track contiguous height unchanged.
• Tests:
  • Update rpc and unit tests to use ProtoBlock and new schema; add proptest regressions.
• Types:
  • Extend headers API (helpers/setters, generate_txns_root public); enable fault-proving paths; add proptest under test-helpers.
• Build/config:
  • Tonic build config derives serde on generated types; new feature flags and minor config updates.

^{Written by Cursor Bugbot for commit c0a6540. This will update automatically on new commits. Configure here.}

[mchristopher]

I think remote should be an object so it's more flexible going forward. My initial thought it that it would look like this:

message RemoteBlockResponse {
  string path = 1;
  oneof config {
    RemoteBlockConfigS3 s3 = 2;
    RemoteBlockConfigHTTP http = 3;
  }
}

message RemoteBlockConfigS3 {
  string region = 1;
  string bucket = 2;
  bool requester_pays = 3;
  optional endpoint = 4;
}

message RemoteBlockConfigHTTP {
  string endpoint = 1;
  optional map<string, string> headers = 2;
}

[MitchTurner]

Cool. Makes sense to me.

[rymnc]

16? is this arbitrary? if the client thats receiving the blocks is really slow, wouldn't that result in send failures from the spawned task?

[MitchTurner]

I'll add better documentation.

if the client thats receiving the blocks is really slow, wouldn't that result in send failures from the spawned task?

I think the task will just block until the stream is cleared. From the okio::sync::mpsc docs:

    /// # Examples
    ///
    /// In the following example, each call to `send` will block until the
    /// previously sent value was received.
    ///
    /// ```rust
    /// use tokio::sync::mpsc;
    ///
    /// #[tokio::main]
    /// async fn main() {
    ///     let (tx, mut rx) = mpsc::channel(1);
    ///
    ///     tokio::spawn(async move {
    ///         for i in 0..10 {
    ///             if let Err(_) = tx.send(i).await {
    ///                 println!("receiver dropped");
    ///                 return;
    ///             }
    ///         }
    ///     });
    ///
    ///     while let Some(i) = rx.recv().await {
    ///         println!("got = {}", i);
    ///     }
    /// }
    /// ```
    ```
    
    I'm not exactly sure what the Tonic stream is doing under the hood. It may be clearing the buffer into its own buffer for us 🤷 

[mchristopher]

Instead of these being ...Tx can we spell out Transaction? It keeps it cleaner & had no impact to the traffic on the wire.

[xgreenx]

It would be nice to verify the deserilziation of the blocks

[xgreenx]

Can you add a todo please? And create an issues to implement it. Or do you want to do that before we merge to the master?

[MitchTurner]

Working on it here:
#3116

I can add an issue to be thorough.

[xgreenx]

For ProtoBlock we want to use protobuf-based encoder and decoder, not Postcard

[MitchTurner]

Done here:
#3106

[xgreenx]

It should work with reference, cloning block looks like an overkill.

[xgreenx]

Yeah, we should work with reference in proto_header_from_header and in proto_tx_from_tx

[xgreenx]

Suggested change

	type GetBlockRangeStream = ReceiverStream<Result<ProtoBlockResponse, Status>>;
	type GetBlockRangeStream = BoxStream<Result<ProtoBlockResponse, Status>>;

If you used BoxStream, then you could avoid usage of the tokio::spawn( below. You can just do inner.map({...}).into_boxed()

[xgreenx]

Yeah, we should work with reference in proto_header_from_header and in proto_tx_from_tx

[cursor]

This PR is being reviewed by Cursor Bugbot

Details

Your team is on the Bugbot Free tier. On this plan, Bugbot will review limited PRs each billing cycle for each member of your team.

To receive Bugbot reviews on all of your PRs, visit the Cursor dashboard to activate Pro and start your 14-day free trial.

[cursor]

Bug: API Trait Block Type Inconsistency

The BlockAggregatorApi trait bound is missing the Block associated type constraint. Line 21 specifies Api: BlockAggregatorApi<BlockRangeResponse = BlockRangeResponse> but doesn't constrain Api::Block to equal Blocks::Block, causing a type mismatch. The handle_query method expects BlockAggregatorQuery<BlockRangeResponse, Blocks::Block> but Api::await_query() returns BlockAggregatorQuery<Api::BlockRangeResponse, Api::Block>, which won't compile unless Api::Block = Blocks::Block.