refactor(iota-framework/iota-system): Remove multiple versions from the iota-system types

[jkrvivian]

Description of change

This PR will be merged to the feature branch core-node/feat/remove-multiple-types.

Reduce amount of versioned types V2 to V1:

• SystemParametersV1
• IotaSystemStateInnerV1
• VotingPowerInfoV1

---

This PR also includes renaming changes in accordance with the rules:

• Add version postfix to those that will certainly be upgraded in the future.
• No version postfix to those that won't be new version.
• For the wrappers, we don't add Wrapper postfix.
• For inner types, we don't add Inner, just add version postfix {structure}V1.

Structures with versioning:

• SystemParametersV1
• IotaSystemState (the wrapper)
• IotaSystemStateV1
• Validator (the wrapper)
• ValidatorV1
• ValidatorMetadataV1
• ValidatorSetV1
• ValidatorEpochInfoEventV1
• SystemEpochInfoEventV1
• StakingPoolV1
• PoolTokenExchangeRateV1
• StakedIotaV1
• StorageFundV1
• TimelockedStakedIotaV1
• VotingPowerInfoV1

Structures that would not get changed, thus with no version postfix:

***** genesis *****

• GenesisValidatorMetadata
• GenesisChainParameters
• TokenDistributionSchedule
• TokenAllocation

***** validator cap *****

• UnverifiedValidatorOperationCap
• ValidatorOperationCap

***** validator *****

• ValidatorJoinEvent
• ValidatorLeaveEvent
• StakingRequestEvent
• UnstakingRequestEvent

Links to any relevant issues

Close #2089

Type of change

• Enhancement
• Breaking change

How the change has been tested

Run the build and test commands:

• iota move build
• iota move test

Change checklist

• I have followed the contribution guidelines for this project
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• I have checked that new and existing unit tests pass locally with my changes

[alexsporn]

Why did you add V1 suffixes to existing types?

[jkrvivian]

Why did you add V1 suffixes to existing types?

Because there's V1 in the Rust side (crates/iota-types/src/iota_system_state/iota_system_state_inner_v1.rs), I thought it'd be good to align the naming to start with V1.

Still the question is, should we have V1 for all the existing structures? Or should we start without versioning {structure}, and for the next version it goes {structure}V2?

for example:

ValidatorV1{}
ValidatorV2{}
...

V.S.

Validator{}
ValidatorV2{}
...

[github-actions]

✅ Vercel Preview Deployment is ready!

View Preview

[miker83z]

Looks good!

[lzpap]

Since we modify the framework and don't intend to release a new protocol version for this, we should update the framework-snapshot bytes for protocol version 1. If this is not done then nodes will panic on startup that they have a different framework loaded from the snapshot than what is present in the node software.

We don't have to do this once we start bumping protocol versions, then we only create a new snapshot cut when the new protocol version is introduced.

[jkrvivian]

Since we modify the framework and don't intend to release a new protocol version for this, we should update the framework-snapshot bytes for protocol version 1. If this is not done then nodes will panic on startup that they have a different framework loaded from the snapshot than what is present in the node software.

We don't have to do this once we start bumping protocol versions, then we only create a new snapshot cut when the new protocol version is introduced.

Yes! Thanks for the reminder, we will do this update in a sole commit in the feature branch so it will not be squashed.

[lzpap]

Since we modify the framework and don't intend to release a new protocol version for this, we should update the framework-snapshot bytes for protocol version 1. If this is not done then nodes will panic on startup that they have a different framework loaded from the snapshot than what is present in the node software.
We don't have to do this once we start bumping protocol versions, then we only create a new snapshot cut when the new protocol version is introduced.

Yes! Thanks for the reminder, we will do this update in a sole commit in the feature branch so it will not be squashed.

IMHO it doesn't matter right now if the commit is squashed or not, I would keep it together with the framework changes (this PR), unless you plan to modfiy other stuff in the iota-framework crate.

[jkrvivian]

Since we modify the framework and don't intend to release a new protocol version for this, we should update the framework-snapshot bytes for protocol version 1. If this is not done then nodes will panic on startup that they have a different framework loaded from the snapshot than what is present in the node software.
We don't have to do this once we start bumping protocol versions, then we only create a new snapshot cut when the new protocol version is introduced.

Yes! Thanks for the reminder, we will do this update in a sole commit in the feature branch so it will not be squashed.

IMHO it doesn't matter right now if the commit is squashed or not, I would keep it together with the framework changes (this PR), unless you plan to modfiy other stuff in the iota-framework crate.

I talked to @miker83z , and he mentioned there will be additional changes for deny list type. So, it'd be good to do it later. 💪

[miker83z]

@lzpap

Since we modify the framework and don't intend to release a new protocol version for this, we should update the framework-snapshot bytes for protocol version 1. If this is not done then nodes will panic on startup that they have a different framework loaded from the snapshot than what is present in the node software.
We don't have to do this once we start bumping protocol versions, then we only create a new snapshot cut when the new protocol version is introduced.

Yes! Thanks for the reminder, we will do this update in a sole commit in the feature branch so it will not be squashed.

IMHO it doesn't matter right now if the commit is squashed or not, I would keep it together with the framework changes (this PR), unless you plan to modfiy other stuff in the iota-framework crate.

I suggested to create the snapshot after the changes to the framework are finalized in the feature branch core-node/feat/remove-multiple-types given that there can be maybe other changes -> #3095

[lzpap]

TimelockedStakedIota and StakedIota are part of the public API, so it will have ramifications in the TS SDK, wallet and explorer too. FYI @begonaalvarezd