Finalise Framework Upgrade MRB files

[0xmovses]

**Framework Upgrade Items **

BC = Before Core Resource Removal
AD = After Core Resource Removal

• Rotation of Core Resources test complete
  - feat: test core_resources_rotation movement#1288
• BC Feature Flag Upgrade Testing
  • 0xmovses/feature upgrade e2e movement#1294
• Bump aptos movement rev to support Feature flags mentioned here Test Finalise Framework Upgrade MRB files #198 (comment)
• Deploy a Release for all the framework changes to Movement prior to migration cc @musitdev
• Update the epoch interval to 2hr
• Token coin supply remains consistent across epochs (good)
• Removal core-resources (done)
• Enable Full Gov and Testing (partial done)
• Full Gov Check (works, but could do w more e2e)
• Run e2e Tests (against framework, partial complete)

[0xmovses]

These comments were left by @musitdev in the readme. I've more or less answered most of them and will leave my answers in the PR description for movement-network/movement#1294

The comments raised were:

### Features that can be disable without risk
None

### Feature that can cause an issue where we need to decide.
These feature can change the current movement network behavior is their state is changed.

APTOS_STD_CHAIN_ID_NATIVES: Disable in Aptos, some of our deployed smart contract can use it so it would break their execution.

PERIODICAL_REWARD_RATE_DECREASE: Depend on how we reward validators.

PARTIAL_GOVERNANCE_VOTING and DELEGATION_POOL_PARTIAL_GOVERNANCE_VOTING depends on own the new network governance should work.

NEW_ACCOUNTS_DEFAULT_TO_FA_APT_STORE: change how new account are created. Perhaps, it can create some incompatibilities with the current deployed smart contract. 

ENABLE_ENUM_TYPES: I think it's related to move2 that won't be activated during the migration but after.

FEDERATED_KEYLESS: It's a new feature, do we support it?

NEW_ACCOUNTS_DEFAULT_TO_FA_STORE and DEFAULT_ACCOUNT_RESOURCE: change how account are created, it can affect existing application.

[apenzk]

As per #180 we use transaction_fee::collect_fee() to send collected fees to a dedicated account. Let me call this fee pool.

1. However, how are rewards paid out to the validators? is the fee pool used? Or is there a separate reward pool?

2. What is the function that pays out the rewards to the validators.

3. Are rewards paid per block or at end of epochs?

I want to mention that wherever we pay the validators from, we probably have to preload the reward pool and make a conservative guess. For example a conservative estimate would be to assume most blocks are empty and negligible amount of fees are collected.

[musitdev]

About 1 and 2 the most problematic point I see is how to upgrade the framework alone and keep the Aptos Rust code with the movement node rev so that we don't have to apply all the changes we have done on the Rust code.

So third option, there would need to merge some supporting Rust Code so movement node rev would need a bump, but these new bits of rust code are not too difficult to PR into movement branch. This would be the work involved in the next step.

I prefer this option as it reduces operational risk (upgrade the framework after migration), and lowers the amount of steps needed after the migration.

If you know how to bump the Aptos framework version in the current version of Movement repo code, yes do it, it will be better to upgrade before the migration.

[0xmovses]

Sounds good, let's do it before. And do a release for this too.