Versioned RPCs and hard fork

[akoptelov]

Hi, I have a question regarding Mina RPC bin_prot encoding and versions pre and post hard fork.

I can see that the RPC get_transition_chain_proof has version 1 in both compatible and develop branches (here and here). That looks fine as the same versions are used. Still bin_prot encoding of e.g. the query will be different. Indeed, in Mina V1 the state hash has version encoded, while in V2 it does not.

Here is a query from mainnet:

00000000: 01 1a 67 65 74 5f 74 72 61 6e 73 69 74 69 6f 6e  ..get_transition
00000010: 5f 63 68 61 69 6e 5f 70 72 6f 6f 66 01 fe c2 79  _chain_proof...y
00000020: 21 01 dd bf e5 64 13 9c b7 ce 54 54 a3 39 36 f4  !....d....TT.96.
00000030: ed d7 30 c7 8c 1b 1b ab 83 5e 3b 26 9f 58 40 2b  ..0......^;&.X@+
00000040: 5e 07                                            ^.

Note that 01 byte at address 0x21 representing the version, followed by 32 bytes of the hash,

Here's a query from berkeleynet:

00000000: 01 1a 67 65 74 5f 74 72 61 6e 73 69 74 69 6f 6e  ..get_transition
00000010: 5f 63 68 61 69 6e 5f 70 72 6f 6f 66 01 fe 98 00  _chain_proof....
00000020: 20 37 37 aa d4 23 2b eb 1a 62 35 7d 43 a0 bc bb   77..#+..b5}C...
00000030: 01 26 3c a5 4a 80 c9 99 7c b4 43 07 c9 3c 60 d2  .&<.J...|.C..<`.
00000040: 09                                               .

Here the state hash starts right after query length, at address 0x21

I'm not sure if this is an issue for Mina itself (I'm not sure how hard fork transition will happen, if there will be a need to support both pre- and post fork messages in a single program), but this is an issue for our tool that analyses Mina traffic, as currently it can support either pre-fork traffic, or post-fork.

My question is, shouldn't the version be changed in case of bin_prot representation is different?

[nholland94]

Hi @akoptelov. Thanks for your question.

The RPC versions are for identifying incompatible RPCs within a protocol version. During a hard fork, we are upgrading the protocol version entirely. As such, any node running the upgraded protocol version will also be running upgraded RPCs as well, so there is no need to support or be able to negotiate down to the prior RPC version from before the hard fork.

In some sense, you can think about the actual version of the RPC body to be the <protocol_version>.<rpc_version>. I would recommend modeling it like this in your tool accordingly, where you are aware not only of the version listed in Async RPC, but also the protocol version the node is operating on.

[akoptelov]

Thanks for you reply!

As such, any node running the upgraded protocol version will also be running upgraded RPCs as well

Does that mean that the stream protocol will be something /coda/rpcs/0.0.2? Or what protocol version do you mean?

[nholland94]

The protocol version is set here https://github.com/MinaProtocol/mina/blob/develop/src/config/protocol_version/current.mlh#L1. The major protocol version contributes to the chain id, which is used to ensure nodes you are connecting to are operating on the same chain that you are.