Split the interface version into protocol and pre-release-version (curr)

[leighmcculloch]

What

Split the 64bit interface version field in the env meta into two separate fields for the data it contains.

Why

The interface version is a 64bit value that contains two 32 bit values, the protocol version and the prerelease version.

In formal releases the prerelease version is always zero.

Because the values are joined together in the 64bit value it renders are a confusing large number that developers don’t understand. Humans can’t see a large integer and know that it actually means “protocol 21”.

While there has been some attempt to render the larger number as its components in developer tooling like the CLI, developers end up looking at the code decoded in other formats based off the xdr structure, such as the json equivalent, and seeing the large integers still.

There was discussion in the following thread about splitting the components into their own env meta key value pairs, and in hindsight that’s how we should have implemented it in the first place:

• Replace the Env Meta Interface Version with two new meta fields for the Protocol Version and the Pre-Release Version stellar-protocol#1476

However, we can get 80% of the benefit by changing the xdr structure to interpret the existing bytes as two distinct fields. It’ll be backwards compatible.

Visible difference in developer tooling:

Before:

$ wasm-cs contract.wasm read contractenvmetav0 --format binary \
    | stellar-xdr decode --type ScEnvMetaEntry --input stream --output json-formatted
{
  "sc_env_meta_kind_interface_version": 94489280512
}

After:

$ wasm-cs contract.wasm read contractenvmetav0 --format binary \
    | stellar-xdr decode --type ScEnvMetaEntry --input stream --output json-formatted
{
  "sc_env_meta_kind_interface_version": {
    "protocol": 22,
    "pre_release": 0
  }
}