[mono-move] Add aptos-vm-v2 transaction layer#20181
Draft
vgao1996 wants to merge 1 commit into
Draft
Conversation
Reimplements the AptosVM transaction-execution layer on the MonoMove VM: prologue -> entry-function payload -> epilogue -> write-set publication, producing a VMOutput, executed single-threaded. One MonoMove session with checkpoints replaces the legacy VM's staged sessions and change-set squashing: a failed payload rolls the heap and read-write set back to the post-prologue state, and writes (including resource-group merge-back) are drained exactly once at the end. Scope is deliberately minimal: only the versioned validation path, entry functions only, placeholder gas. Scripts, multisig, publishing, keyless/AA, orderless, IO/storage fees, and Block-STM integration are inline TODOs; write-set publication is a stopgap behind the runtime's new drain API so the real publication workstream can replace it. Differential tests against the legacy VM on FakeExecutor genesis: a p2p transfer (byte-equal writes except the two fee-embedding slots), an insufficient-balance abort (rollback + failure epilogue, matching abort codes), and a two-transaction sequential block through the VMBlockExecutor wrapper. Runtime additions: ResourceReadWriteSet::entries() drain API and InterpreterContext accessors (read_write_set, reset_gas, gas_balance, load_function) so a driver can run several functions in one transaction. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Contributor
mono-move benchmark gate1 regression(s) beyond ±3% noise band
|
| provider: &StateViewResourceProvider<'_, '_, '_, S>, | ||
| ) -> Result<BTreeMap<StateKey, AbstractResourceWriteOp>> { | ||
| let mut writes = BTreeMap::new(); | ||
| let mut group_ops: HashMap<StateKey, BTreeMap<StructTag, MemberOp>> = HashMap::new(); |
Contributor
There was a problem hiding this comment.
I hope we can avoid all these allocations of state keys and struct tags - keep using the interned representation. And simply charge gas for sum of state keys sizes and write sizes so we do not even have a problem of non-deterministic iteration
Contributor
Author
There was a problem hiding this comment.
Totally agreed. The current implementation is quite conservative in the sense that it reuses all the public interfaces. We can and should get this changed as we integrate with BlockSTM
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
Reimplements the AptosVM transaction-execution layer on the MonoMove VM, as a new crate
mono-move/aptos-vm-v2: prologue → entry-function payload → epilogue → write-set publication, producing aVMOutput, executed single-threaded.The core structural change from the legacy VM: one MonoMove session with checkpoints replaces the staged prologue/user/epilogue sessions, respawned sessions, and per-stage change-set squashing. A failed payload rolls the heap and read-write set back to the post-prologue checkpoint, and writes are drained exactly once at the end — including resource-group members merged back into their group slot.
Scope (deliberately minimal)
versioned_prologue/versioned_epilogue).TODO(<group>)placeholder: scripts, multisig, module publishing, keyless/AA, orderless txns, IO/storage fees + refunds,StateValueMetadata, abort locations, Block-STM.ResourceReadWriteSet::entries()drain API, so the real publication workstream can replace it from inside the runtime without touching this crate.Interfaces
AptosVMv2::execute_user_transaction(&StateView, &SignedTransaction) -> (VMStatus, VMOutput)(TODO: move toExecutorView/ResourceGroupViewfor Block-STM).AptosVMv2BlockExecutorimplementsVMBlockExecutorwith a sequential loop over an output-overlay view — the eventual node-level swap point.Runtime additions
ResourceReadWriteSet::entries()(drain seam) andInterpreterContext::{read_write_set, reset_gas, gas_balance, load_function}so a driver can run several functions in one transaction sharing heap/read-write set/extensions.How Has This Been Tested?
aptos-vm-v2/tests/e2e.rs— differential tests against the legacy VM onFakeExecutorhead-genesis state:0xa) and fee events.VMBlockExecutorwrapper (second prologue observes the first's sequence bump via the overlay).Also verified: mono-move runtime and differential testsuites pass with the runtime edits; fmt/clippy clean. (Note:
mono-move-testsuite'saptos_experimental_on_mono_moveunit test stack-overflows in debug builds on the base commit already — pre-existing, unrelated.)🤖 Generated with Claude Code