What is required for framework upgrade?

[andygolay]

If I'm understanding the requirements correctly, we need to be able to upgrade the framework so it runs as part of a proper mainnet.

Feature Flag Analysis

First, I compared feature flags between Aptos testnet and Aptos mainnet, using the following script:

#!/bin/bash

# Temp files
MAINNET_OUTPUT="mainnet_flags.txt"
TESTNET_OUTPUT="testnet_flags.txt"

# Clean up old results
> "$MAINNET_OUTPUT"
> "$TESTNET_OUTPUT"

echo "Querying mainnet..."
for i in {1..100}; do
    result=$(movement move view \
        --function-id 0x1::features::is_enabled \
        --args u64:$i \
        --profile mainnet 2>/dev/null)

    echo "$i:$result" >> "$MAINNET_OUTPUT"
done

echo "Querying testnet..."
for i in {1..100}; do
    result=$(movement move view \
        --function-id 0x1::features::is_enabled \
        --args u64:$i \
        --profile testnet 2>/dev/null)

    echo "$i:$result" >> "$TESTNET_OUTPUT"
done

echo "Comparing results..."
echo "Differences found at the following feature IDs:"

for i in {1..100}; do
    mainnet_value=$(grep -A 2 "^$i:{" mainnet_flags.txt | grep -oE 'true|false')
    testnet_value=$(grep -A 2 "^$i:{" testnet_flags.txt | grep -oE 'true|false')

    if [ "$mainnet_value" != "$testnet_value" ]; then
        echo "Feature ID $i: mainnet = $mainnet_value | testnet = $testnet_value"
    fi
done

I found that the only difference was feature flag 85: ACCOUNT_ABSTRACTION is enabled on Aptos testnet but not on mainnet.

Next, I compared Bardock testnet and Aptos testnet with a similar script.

I found quite a few differences between Bardock and Aptos testnet feature flags:

| Feature ID | Feature Name                                 | Bardock | Aptos Testnet |
|------------|----------------------------------------------|---------|----------------|
| 4          | APTOS_STD_CHAIN_ID_NATIVES                  | true    | false          |
| 16         | PERIODICAL_REWARD_RATE_DECREASE             | false   | true           |
| 17         | PARTIAL_GOVERNANCE_VOTING                   | false   | true           |
| 21         | DELEGATION_POOL_PARTIAL_GOVERNANCE_VOTING   | false   | true           |
| 40         | VM_BINARY_FORMAT_V7                         | false   | true           |
| 47         | KEYLESS_BUT_ZKLESS_ACCOUNTS                 | true    | false          |
| 48         | *(Unknown – not listed in features module)* | true    | false          |
| 54         | KEYLESS_ACCOUNTS_WITH_PASSKEYS              | true    | false          |
| 57         | MODULE_EVENT_MIGRATION                      | true    | false          |
| 72         | *(Unknown – not listed in features module)* | false   | true           |
| 74         | *(Unknown – not listed in features module)* | false   | true           |
| 76         | *(Unknown – not listed in features module)* | false   | true           |
| 77         | *(Unknown – not listed in features module)* | false   | true           |
| 78         | *(Unknown – not listed in features module)* | false   | true           |
| 79         | *(Unknown – not listed in features module)* | false   | true           |
| 80         | *(Unknown – not listed in features module)* | false   | true           |
| 81         | *(Unknown – not listed in features module)* | false   | true           |
| 82         | *(Unknown – not listed in features module)* | false   | true           |
| 85         | ACCOUNT_ABSTRACTION                         | false   | true           |

One thing I don't understand is why Aptos testnet is showing as "true" for eg feature flag 82, which doesn't appear to be listed in features.move.

GenesisConfiguration

In aptos-move/vm-genesis/src/lib.rs there's a struct GenesisConfiguration with field is_test.

This is used in the movement repo in the execution protocol unit's bootstrap.rs in the function encode_genesis_change_set called in genesis_change_set_and_validators, which is called in Executor::maybe_bootstrap_empty_db, which is called in Executor::boostrap which is called in Executor::try_from_config.

In https://github.com/movementlabsxyz/movement/blob/main/protocol-units/execution/maptos/framework/releases/README.md?plain=1#L4 we see the following:

• Each crate herein should export a [ReleaseBundle](https://github.com/movementlabsxyz/aptos-core/blob/ac9de113a4afec6a26fe587bb92c982532f09d3a/aptos-move/framework/src/release_bundle.rs#L16) s.t. it can be used with - encode_genesis_change_set` for the genesis transaction;
  - framework upgrades.

So it looks like encode_genesis_change_set is the key to the configuration setup.

Next step: dig into how encode_genesis_change_set is used in the genesis transaction. It looks like is_test: true, is currently hard coded in, and we have a todo to get the config from somewhere:

fn genesis_change_set_and_validators(
	chain_id: ChainId,
	count: Option<usize>,
	public_key: &Ed25519PublicKey, //Core resource account.
	release: &impl Release,
) -> Result<(ChangeSet, Vec<TestValidator>), anyhow::Error> {
	let framework = release.release_bundle().map_err(|e| anyhow::anyhow!(e))?;
	let test_validators = TestValidator::new_test_set(count, Some(100_000_000));
	let validators_: Vec<Validator> = test_validators.iter().map(|t| t.data.clone()).collect();
	let validators = &validators_;

	warn!("Genesis validators: {:?}", validators);

	// This number should not exceed u64::MAX / 1_000_000_000
	// to avoid overflowing calculations in aptos-vm-genesis.
	// This will last several centuries.
	const EPOCH_DURATION_SECS: u64 = 60 * 60 * 24 * 1024 * 128;

	// by default leave the initial gas parameters, this better suited to the kind of upgrades we routinely want to test
	let gas_parameters = AptosGasParameters::initial();
	// gas_parameters.vm.txn.max_transaction_size_in_bytes = GasQuantity::new(100_000_000);
	// gas_parameters.vm.txn.max_execution_gas = GasQuantity::new(10_000_000_000);

	let gas_schedule = aptos_types::on_chain_config::GasScheduleV2 {
		feature_version: aptos_gas_schedule::LATEST_GAS_FEATURE_VERSION,
		entries: gas_parameters
			.to_on_chain_gas_schedule(aptos_gas_schedule::LATEST_GAS_FEATURE_VERSION),
	};

	let genesis = encode_genesis_change_set(
		&public_key,
		validators,
		&framework,
		chain_id,
		// todo: get this config from somewhere
		&GenesisConfiguration {
			allow_new_validators: true,
			epoch_duration_secs: EPOCH_DURATION_SECS,
			is_test: true,

[l-monninger]

@andygolay Yes, I do think it has primarily to do with the genesis change setting parameters which cause core operations to take different branches. I will take a closer look in my early afternoon.

[l-monninger]

@andygolay I think you should trace down through the reconfiguration a bit:

https://github.com/movementlabsxyz/aptos-core/blob/1d1cdbbd7fabb80dcb95ba5e23213faa072fab67/aptos-move/framework/aptos-framework/sources/reconfiguration_with_dkg.move#L46

[l-monninger]

The other thing is we'll want to make sure we won't be able to run proposals with...

let core_signer = aptos_governance::get_signer_testnet_only(core_resources, @0000000000000000000000000000000000000000000000000000000000000001);

let core_address: address = signer::address_of(core_resources);

I vaguely remember that get_signer_testnet_only being strewn we illustrative differences.

[l-monninger]

A clear procedure for how we add new validators with governance proposals should be described.

[0xmovses]

I am thinking that while we are in a pre-governance mainnet state, we use this state to run other upgrades, such as adding the GGP modules. Any number of changes can be passed through, before finally doing the last step. Upgrade to be at latest mainnet state (with governance)

This way we wont have to battle with governance at the code level until the final change goes through.