Approach to adopting aptos-core changes from upstream

[mzabaluev]

Basically, this boils down to two strategies:

1. Make regular syncs with latest revisions from aptos-core upstream, adopting all the changes and making sure any implemented AIPs are approved by Movement governance (see Governance: approach to AIPs accepted in Aptos #476).
   • Pro: easier to do for developers.
   • Pro: delta with upstream stays small.
   • Pro: staying up to date with Aptos is generally good for UX.
   • Con: it's all-or-nothing with regard to AIPs, one disapproved AIP will derail the process.
2. Cherry-pick the important changes (security fixes, API, CLI updates).
   • Pro: can be selective about adopting specific features and AIPs.
   • Con: greater maintenance burden on the engineering team.
   • Con: increasingly diverging delta makes this process harder as time goes on.

Related items

• Governance: approach to AIPs accepted in Aptos #476
• Pros and Cons about aptos-core fork repo #118
• Resolve known security issues in aptos-core #900

[andygolay]

Thanks for starting this discussion @mzabaluev.

It seems to me, based on our difficulties keeping up with Aptos Move already, that option #1 will be the only viable one long-term, if we intend to continue to support Aptos Move. Which I believe we should. We are a small team, and it's not realistic to think we can advance the Move language forward on our own. Sui and Aptos each have hundreds of employees, many of whom are authors of the Move whitepaper. We should "stand on the shoulders of giants" so to speak, and avoid increasingly diverging delta.

Keeping the delta with upstream small means that Movement stays faithful to (Aptos) Move. Because Movement claims to support Aptos Move, this is the ethically correct choice, and it's a good practical choice to make Devrel's lives easier, because devs will be continually asking for whatever new Move features come down the stream.

One concern I have about implementing strategy 1 is that I don't have much of an idea of what was removed from Aptos core already. I've heard that the eng team removed a lot of the framework but I'm just not familiar with what changes were made. I'm not sure how that will affect our ability to make regular syncs that are consistent with the changes we've already made.

Tying to cherry-pick the "important" changes assumes that we can figure out which changes are important and which ones aren't. Such discernment is a huge ask in terms of skill and labor from our small, highly busy engineering team.

I think committing all-or-nothing to AIPs is fine, especially if Movement participates in Aptos governance and discussions around AIPs. This is probably a good practice anyway, for the sake of collaboration with Aptos and being aware of pending AIPs so we can prepare for changes to land in Movement.

[franck44]

I would also support for option 1.

1. There are already a few incompatible Move flavours (Aptos and Sui). So it is probably not a good idea to introduce our own. (it could be that we have to say, "it is not a subset of Aptos, it is not a subset of Sui, it is ... somewhat different ...)
2. if we sync regularly we benefit from the security fixes and performance improvements
3. by adopting the Aptos Move we can re-use their docs, and developer tools
4. we are a small team and in the near-future may opt for the "easier" for maintainers (At Movement).

This does mean that later we don't our customisation of Move (new tools?) but I don't see how it can happen anytime soon.

[mzabaluev]

Here's what you can do to quickly review changelog differences with upstream.

1. Add the upstream remote repo if not done already:

git remote add upstream https://github.com/aptos-labs/aptos-core.git

2. Sync the remote:

git fetch upstream

3. Review the diff:

find . -name CHANGELOG.md | xargs git diff movement..upstream/main --

The usual git log and git diff commands can be used to check in more detail.

[andygolay]

Summary of yesterday's Staying current with aptos-core upstream & Move 2 Upgrade session:

• There are some potential security vulnerabilities that could accompany taking approach 1 of this discussion Approach to adopting aptos-core changes from upstream #901 (Make regular syncs with latest revisions from aptos-core upstream, adopting all the changes and making sure any implemented). The amount of work required to review all aptos-core upstream revisions could be extremely time-consuming. Aptos pushes updates every couple weeks and we would want two engineers reviewing all changes, so that could be 4 days a month for two engineers reviewing aptos-core revisions.

• It could make development easier if we freeze the aptos-core version at 3.5 for now.

• One question is how to make it easy for users to install Movement CLI and install Aptos CLI 3.5. On Mac, a brew installation would be helpful. @andygolay will work on that this week and collaborate with @Rahat-ch on it this weekend time permitting.

• Which specific CLI version to keep up to date with is ultimately a product decision (cc @bhenhsi @rolandoesparza)

• @Rahat-ch mentioned keeping the version the same for now shouldn't be too much of a problem as long as devs know the CLI version to install and how to install it.

• Taking approach 2 (cherry picking changes) still requires governance to implement MIPs approved by the MIP committee. Aptos governance decisions are implemented on the next epoch change after the vote, so we need a way to advance the epoch or modify governance so it works. @l-monninger’s Governed Gas Pool development will ideally result in a solution for that governance mechanism.