'Soft' deprecation of get_ledger_version host function

[dmkozh]

Soroban supports get_ledger_version host function that gets ledger protocol version. The function has been included just for the sake of 'completeness' of ledger information in the initial release of Soroban (p20), alongside with get_ledger_sequence and get_ledger_timestamp functions. However, unlike the latter functions, there is seemingly no valid use case for get_ledger_version:

• If the code depends on the ledger version older than current, then it will never be executed (because protocols never go backward)
• If the code depends on the ledger version newer than current, then it won't be able to import functions from the newer protocol (that's prohibited by the Soroban host). Since the semantics of the host functions that exist in the current protocol won't change in the next protocol, there shouldn't be any reason to write logic conditioned on the protocol version.

This observation is also confirmed by the fact that there are no live Soroban contracts on mainnet that use get_ledger_version host function.

The presence of this function increases conceptual complexity for certain actually useful use cases, such as replaying the older ledger snapshots with the newer versions of host. Thus the proposal is to deprecate this function starting from protocol 25. Since just removing the host function is still potentially dangerous, even if no-one uses it right now, a 'soft' deprecation mechanism is proposed:

• The function is considered to be deprecated right now, which is also already reflected in the Soroban SDK: (Deprecate protocol_version method in Ledger rs-soroban-sdk#1625)
• Starting with protocol 25 the function will return 25 for the version, but it will never return any other value past that, i.e. protocols 26 and higher will still have 25 as the return value of the function, thus discouraging usage of the function
• A full cleanup with function removal can be considered in the future, but that's not necessary

Note, that this plan doesn't require any protocol changes until protocol 26, so there is still plenty of time to share any feedback or concerns here.

[leighmcculloch]

This is reasonable imo, especially because there's no use of the fn on mainnet at all, no contract imports it.

Iirc the fn was added in the early days with the intent that someone might release a new wasm that uses new features coming in a future protocol version, but those features wouldn't be triggered until a new protocol was available. When it was decided that the protocol would not support contracts built for future versions until an upgrade occurred, we never thought to remove the fn or revisit its purpose.

[tomerweller]

I understand the motivation but why does this warrant a protocol change? If no one is using it and we're deprecating it in the SDK why bother?

[leighmcculloch]

It is technically a protocol change, and a short CAP is cheap to write, why not?

[leighmcculloch]

• Starting with protocol 25 the function will return 25 for the version, but it will never return any other value past that, i.e. protocols 26 and higher will still have 25 as the return value of the function, thus discouraging usage of the function

Did we end up doing this?

[dmkozh]

There was nothing to do, the function returns 25 for protocol 25. The change is to keep that value going forward.