Support `ProtocolConfig` (v0.17)

[Mirko-von-Leipzig]

In v0.17, fee asset ID is factored out into ProtocolConfig, who's commitment is instead part of the block header.

Clients now need a way to get this configuration, at the very least to access the fee asset ID that they could previously get from the header.

Support therefore includes:

1. Storing this config
2. Verifying the commitment
3. Exposing this config via RPC

We are expecting this config to change very rarely - on the order of months. (1) therefore makes sense to keep this in a separate table which can be looked up via commitment.

For (3) we need a new endpoint. The values can be heavily cached since they change so rarely, and are therefore valid for large block ranges. I imagine query by commitment makes the most sense.

[Mirko-von-Leipzig]

This has additional implications that initially went unnoticed.

1. This impacts block subscriptions. Two options come to mind:
   a. Add config changes as an optional field; specified whenever there is a delta.
   b. Subscriber is responsible for config change detection and can request it separately.
2. This impacts the genesis block and bootstrapping. The simplest solution here is likely that the genesis data should contain both block and protocol config.
3. Clients need to support this, including internal clients which submit txs i.e. monitor and ntxb.

[Mirko-von-Leipzig]

Discussed offline; option (1a) seems good. For (3) we can add this to the SyncMmr function call, or as a separate RPC endpoint - cc @igamigo.

[igamigo]

Discussed offline; option (1a) seems good. For (3) we can add this to the SyncMmr function call, or as a separate RPC endpoint

I think adding it to SyncMmr probably makes the most sense here as we can also decide to return the data only when there has been a delta since the block_from that the user passes.

[kkovaacs]

@igamigo There's a potential problem with including the ProtocolConfig in the SyncChainMmr response.

The client always fetches the genesis block header first if that's missing from its store using GetBlockHeaderByNumber. That header does not include the ProtocolConfig, only its commitment.

It then calls SyncChainMmr with the genesis block as its current block. The semantics of the SyncChainMmr request mean that it's returning information starting with the block after the current block of the client. That means that if there were no protocol config changes since genesis then the response wouldn't contain the current protocol config (as it has not changed since genesis).

So ultimately even with the proposed modifications there's no way to fetch the genesis protocol config via the API. So maybe we should add a separate endpoint that returns the protocol config given a block number?

[Mirko-von-Leipzig]

Probably the client should not be fetching the genesis block from the node, but rather some other trusted source. On official networks this would be genesis.<network>.miden.io - and it would include the protocol config.

On local networks this is more up to the user to connect.

Alternatively we need to always send the protocol config along with block one ranges.

[kkovaacs]

Or we can make an exception in SyncChainMmr so that if the current block of the client is genesis we're always sending a protocol config in the response...

[bobbinth]

I think there are 4 potential solutions (and probably more):

1. Have client get the genesis block commitment (together with the related protocol config) from a trusted source (e.g., genesis.<network>.miden.io as @Mirko-von-Leipzig proposed).
2. Have a separate endpoint for getting protocol config at a given block.
3. Add special handling of the genesis block starting point in SyncChainMmr as @kkovaacs proposed.
4. Modify GetBlockHeaderByNumber endpoint to optionally return the protocol config as an optional element.

I think option 4 could work pretty well here since the GetBlockHeaderByNumber endpoint already does the same thing for the MMR proof. The request could look like:

message BlockHeaderByNumberRequest {
    optional uint32 block_num = 1;
    optional bool include_mmr_proof = 2;
    optional bool include_protocol_config = 3;
}

And correspondingly, the response could look like:

message BlockHeaderByNumberResponse {
    blockchain.BlockHeader block_header = 1;
    optional primitives.MerklePath mmr_path = 2;
    optional fixed32 chain_length = 3;
    optional ProtocolConfig protocol_config = 4;
}

[igamigo]

Yeah, I was also going to suggest the option of returning the config every time a client syncs from block 0. Modifying GetBlockHeaderByNumber sounds like it would be a good alternative as well. Otherwise while SyncChainMmr does not take a block_to parameter, there would also be no easy way of getting the protocol config for an arbitrary block.
A dedicated endpoint would work too, it just feels like more surface than needed for a value that should not change often.