Skip to content

Rebase to e33e3c1 - #385

Open
rubujubi wants to merge 835 commits into
m1from
move-rebase-e33
Open

Rebase to e33e3c1#385
rubujubi wants to merge 835 commits into
m1from
move-rebase-e33

Conversation

@rubujubi

@rubujubi rubujubi commented Jun 25, 2026

Copy link
Copy Markdown
Collaborator

Description

Downstream Aptos pre license change commits from last fork f7a17a6 (on movement) to e33e3c1 (on upstream) onto movement m1.

This PR is created by rebasing onto e33e3c1, and solve the merge conflicts. Mechanical conflicts as explained in the below section has been directly fixed in the merge commit.

Mechanical conflicts — rename/delete resolutions

Group Count Rule applied
.github/{workflows,actions} rename/delete 20 Movement renamed these upstream CI files to .bak (archived); upstream deleted them → kept Movement's .bak
aptos-rosetta removal 6 Movement removed the crate; upstream modified the files → honored deletion (git rm) + a git rm -r crates/aptos-rosetta sweep to catch any upstream re-adds
my_first_dapp example manifests 2 Upstream deleted the example; m1 had bumped deps → followed upstream deletion

Total: 28 rename/delete conflicts

junxzm1990 and others added 30 commits October 11, 2025 16:07
The `values_impl::IntegerValue` type introduced a rather unnecessary wrapper for integer values, creating to conversions back and force to `Value`. Moreover, the newtype wrapper `Value` for `ValueImpl` was unnecessary as well and created
overhead because it cannot be eliminated by the compiler when applied in iterators (as in `values.into_iter().map(Value).collect()`). Both have been removed.
This enables intermediate tools to use `$` in identifiers to separate from user identifiers, e.g. names for public struct functions. This is only supported from bytecode version 9 onwards.

Co-authored-by: Teng Zhang <rahxephon89@163.com>
…__`. (aptos-labs#17854)

* [compiler & language] Support builtin constant `__COMPILE_FOR_TESTING__`.

Allow code to branch over a compile time constant `__COMPILE_FOR_TESTING__`. The non-reachable branch will be optimized (or at least turned into dead code.)

The name is under discussion. We should make the right decision here since any future compile time constants should be following this naming convention. I see compile constants as an equivalent to Rust attributes, at least if it comes to conditional compilation.

This falls into the categorie of builtin constants which we already have for the spec llanguage. At the same time, we would enable `MAX_U64` et. all as builtin constants in the language.

Builtin constants can be shadowed by the user, so no harm to existing move programs would be implied.

* Fully support MIN/MAX for all integer types. Also move unit test out of framework, because it may not compile with older compilers.
Co-authored-by: Igor <igor-aptos@users.noreply.github.com>
Pushed to one node and let it run overnight. Seems like compactions can keep up.
…os-labs#17867)

* OrderBook use of iterators and utilities

* don't use iterators
apenzk and others added 5 commits July 1, 2026 09:09
# Resolve consensus conflicts from the e33 rebase

## Summary

Resolves the `consensus/` merge conflicts left after merging upstream
[e33e3c1](e33e3c1)
into [m1](https://github.com/movementlabsxyz/aptos-core/tree/m1).

## Commits

| Commit | Change |
|--------|--------|
|
[2c78c02](2c78c02)
| Drop the old execution pipeline superseded by e33's new pipeline
([6bb63f6](6bb63f6))
— delete `execution_pipeline.rs`, `set_execution_result`,
`mark_successful_pre_commit_for_test` (see below). |
|
[4d0e30b](4d0e30b)
| Parallel proposal verify — adopt e33's `rayon::join` payload+signature
verification
([877e6bb](877e6bb)),
keep Movement's `size_limits` guard
([eb20f39](eb20f39),
#326) |
|
[08e5e7e](08e5e7e587)
| Preserve the `set_randomness` deadlock guard
([04d582b](04d582b),
#322). |
|
[5652f63](5652f63)
| Add upstream's `StateComputer::new_epoch` params —
`consensus_onchain_config`
([1ba9a45](1ba9a45)),
`persisted_auxiliary_info_version`
([69acc1f](69acc1f),
aptos-labs#16927), `network_sender`
([9ecf4a6](9ecf4a6)).
|
|
[e0ff529](e0ff529)
| Drop the unused `new_pipeline_enabled` param from
`TExecutionClient::start_epoch` — no readers after e33 removed the retry
logic that consumed it
([d3f4ac3](d3f4ac3)).
|
|
[102927e](102927e)
| Build `network_sender` in `ExecutionProxyClient::start_epoch` — e33
([9ecf4a6](9ecf4a6))
relocated its construction out of `spawn_decoupled_execution` so one
instance feeds both `spawn_decoupled_execution` and `new_epoch`. |
|
[5010f3a](5010f3a)
| Drop the redundant `order_vote_enabled` param from
`StateComputer::new_epoch` — `PipelineBuilder` now re-derives it from
`consensus_onchain_config`
([d966675](d966675),
aptos-labs#13023). |
|
[e38419e](e38419e)
| Thread Movement's `virtual_genesis_block_id` through `new_epoch` /
`start_epoch`
([6210a73](6210a73)).
|
|
[8b275c5](8b275c5)
| Drop obsolete test-only scaffolding e33 removed
([29fadb1](29fadb1))
— `EmptyStateComputer` + `test_commit_sync_race` use the removed
`StateComputer::commit`, and `state_computer_tests.rs` is orphaned. |
|
[1a63e85](1a63e85c89)
| Fix two compile errors surfaced by `cargo check` — import `HashValue`
in `state_computer.rs`, and thread `size_limits` through the e33-added
`OptProposalMsg::verify` path so it enforces #326's batch-size guard
([eb20f39](eb20f39)).
|

## Old execution pipeline removal


[ExecutionPipeline](https://github.com/movementlabsxyz/aptos-core/blob/e85169336ab9d30cd217ec9d666ebcf60469f470/consensus/src/execution_pipeline.rs#L58)
was the old decoupled-execution engine — its API was
[spawn()](https://github.com/movementlabsxyz/aptos-core/blob/e85169336ab9d30cd217ec9d666ebcf60469f470/consensus/src/execution_pipeline.rs#L63)
(start the background execution task) and
[queue()](https://github.com/movementlabsxyz/aptos-core/blob/e85169336ab9d30cd217ec9d666ebcf60469f470/consensus/src/execution_pipeline.rs#L93)
(submit an ordered block). Its sole owner was
[ExecutionProxy](https://github.com/movementlabsxyz/aptos-core/blob/e85169336ab9d30cd217ec9d666ebcf60469f470/consensus/src/state_computer.rs#L76),
which on m1 held an [execution_pipeline:
ExecutionPipeline](https://github.com/movementlabsxyz/aptos-core/blob/e85169336ab9d30cd217ec9d666ebcf60469f470/consensus/src/state_computer.rs#L84)
field and spawned it in
[new()](https://github.com/movementlabsxyz/aptos-core/blob/e85169336ab9d30cd217ec9d666ebcf60469f470/consensus/src/state_computer.rs#L90).
Blocks queued into it ran execution and produced a
[PipelineExecutionResult](https://github.com/movementlabsxyz/aptos-core/blob/e85169336ab9d30cd217ec9d666ebcf60469f470/consensus/consensus-types/src/pipelined_block.rs#L325),
pushed onto the block via
[set_execution_result](https://github.com/movementlabsxyz/aptos-core/blob/e85169336ab9d30cd217ec9d666ebcf60469f470/consensus/consensus-types/src/pipelined_block.rs#L324).
That whole chain —
[ExecutionPipeline](https://github.com/movementlabsxyz/aptos-core/blob/e85169336ab9d30cd217ec9d666ebcf60469f470/consensus/src/execution_pipeline.rs#L58)
→
[PipelineExecutionResult](https://github.com/movementlabsxyz/aptos-core/blob/e85169336ab9d30cd217ec9d666ebcf60469f470/consensus/consensus-types/src/pipelined_block.rs#L325)
→
[set_execution_result](https://github.com/movementlabsxyz/aptos-core/blob/e85169336ab9d30cd217ec9d666ebcf60469f470/consensus/consensus-types/src/pipelined_block.rs#L324)
— was one engine-and-result-delivery unit.

e33's new pipeline
([6bb63f6](6bb63f6))
rewrote
[ExecutionProxy](https://github.com/movementlabsxyz/aptos-core/blob/e85169336ab9d30cd217ec9d666ebcf60469f470/consensus/src/state_computer.rs#L76)
to drop the
[execution_pipeline](https://github.com/movementlabsxyz/aptos-core/blob/e85169336ab9d30cd217ec9d666ebcf60469f470/consensus/src/state_computer.rs#L84)
field entirely: execution now runs as per-block `Shared`
[TaskFuture](https://github.com/movementlabsxyz/aptos-core/blob/e85169336ab9d30cd217ec9d666ebcf60469f470/consensus/consensus-types/src/pipelined_block.rs#L70)s
wired by
[pipeline_builder](https://github.com/movementlabsxyz/aptos-core/blob/e85169336ab9d30cd217ec9d666ebcf60469f470/consensus/src/pipeline/pipeline_builder.rs#L104),
and
[pre_commit_fut](https://github.com/movementlabsxyz/aptos-core/blob/e85169336ab9d30cd217ec9d666ebcf60469f470/consensus/consensus-types/src/pipelined_block.rs#L89)
is a
[TaskFuture](https://github.com/movementlabsxyz/aptos-core/blob/e85169336ab9d30cd217ec9d666ebcf60469f470/consensus/consensus-types/src/pipelined_block.rs#L70)
with no `.lock()`. So the old unit's only consumer stopped using it,
upstream removed the machinery in
[29fadb1](29fadb1),
and nothing on the merged branch references
[ExecutionPipeline](https://github.com/movementlabsxyz/aptos-core/blob/e85169336ab9d30cd217ec9d666ebcf60469f470/consensus/src/execution_pipeline.rs#L58),
its
[spawn](https://github.com/movementlabsxyz/aptos-core/blob/e85169336ab9d30cd217ec9d666ebcf60469f470/consensus/src/execution_pipeline.rs#L63)/[queue](https://github.com/movementlabsxyz/aptos-core/blob/e85169336ab9d30cd217ec9d666ebcf60469f470/consensus/src/execution_pipeline.rs#L93),
[PipelineExecutionResult](https://github.com/movementlabsxyz/aptos-core/blob/e85169336ab9d30cd217ec9d666ebcf60469f470/consensus/consensus-types/src/pipelined_block.rs#L325),
or
[set_execution_result](https://github.com/movementlabsxyz/aptos-core/blob/e85169336ab9d30cd217ec9d666ebcf60469f470/consensus/consensus-types/src/pipelined_block.rs#L324).

## Verification

All `consensus/` conflict markers resolved. `cargo check -p
aptos-consensus` passes (one pre-existing unrelated warning: unused
`time_service` in `NetworkSender`).
- thread traversal_context through initialize_governed_gas_pool to match exec_function's updated 7-arg signature
- pass the dealer public key to DefaultDKG::generate_transcript in the rand network_messages test
- switch that test from the removed WeightedConfig name to the concrete WeightedConfigBlstrs alias
@blacksmith-sh

This comment has been minimized.

@blacksmith-sh

This comment has been minimized.

@blacksmith-sh

blacksmith-sh Bot commented Jul 2, 2026

Copy link
Copy Markdown

Found 11 test failures on Blacksmith runners:

Failures

Test View Logs
aptos-transactional-test-harness::tests/runner::aptos_test_harness/bug_bbb75fa.move View Logs
aptos-transactional-test-harness::tests/runner::aptos_test_harness/call_function.move View Logs
aptos-transactional-test-harness::tests/runner::aptos_test_harness/diamond_clicker.move View Logs
aptos-transactional-test-harness::tests/runner::aptos_test_harness/
diamond_clicker_noinline.move
View Logs
aptos-transactional-test-harness::tests/runner::aptos_test_harness/publish_module.move View Logs
aptos-transactional-test-harness::tests/runner::aptos_test_harness/
randomness_safety.move
View Logs
aptos-transactional-test-harness::tests/runner::aptos_test_harness/smoke_test.move View Logs
aptos-transactional-test-harness::tests/runner::aptos_test_harness/string_fmt.move View Logs
aptos-transactional-test-harness::tests/runner::aptos_test_harness/tool_attributes.move View Logs
aptos-transactional-test-harness::tests/runner::aptos_test_harness/
write_set_too_large.move
View Logs
e2e-move-tests/tests::cryptoalgebra::test_deep_type_tag View Logs

Fix in Cursor

@ganymedio

ganymedio commented Jul 7, 2026

Copy link
Copy Markdown

@rubujubi does Movement support orderless / nonce transactions? This PR exposes them in the CLI via --replay-protection-type nonce on run/publish/simulate. Default is seqnum so existing behavior is safe, but this exposes an upstream feature that may not be enabled, so if orderless-txn / payload-v2 isn't actually live on Movement then --replay-protection-type nonce produces transactions the node will reject. Which I think is okay, just something to be aware of.

@ganymedio

ganymedio commented Jul 7, 2026

Copy link
Copy Markdown

A couple things to flag in the SDK:

  1. Dead fields on TransactionFactory (likely a half-carried port). The PR adds two fields — use_txn_payload_v2_format and use_replay_protection_nonce — and a build() branch that consumes them:
payload: if self.use_txn_payload_v2_format || self.use_replay_protection_nonce {
    payload.upgrade_payload_with_fn(...)   // + thread_rng() nonce
} else { port). The PR adds two fields — use_txn_payload_v2_format and use_replay_protection_nonce — and a build() branch that consumes them:
payload: if self.use_txn_payload_v2_format || self.use_replay_protection_nonce {
    payload.upgrade_payload_with_fn(...)   // + thread_rng() nonce
} else {
    payload
},

but there doesn't appear to be a setter for either field. They're hardcoded false in new(), never mutated, and the fields are private so no other crate can set them. The factory's only with_* methods are gas/expiration/chain-id. So the if branch is currently unreachable (always takes the else).

It's not a bug, more like dead weight, just wanted to check that upstream didn't add a builder setter (e.g. a with_payload_v2_format(...)) that maybe didn't get carried through the rebase? Not sure if a factory setter dropped in the merge, or are these fields intentionally inert for now?

  1. get_transaction_expiration_time() can panic. It now does unimplemented!() for the new Absolute expiration variant:
TransactionExpiration::Absolute { .. } => unimplemented!(),

No callers currently, so it's latent, but figured I'd flag for awareness.

@rubujubi
rubujubi marked this pull request as ready for review July 9, 2026 17:37
@rubujubi
rubujubi requested a review from seanyoung July 9, 2026 17:37
@rubujubi

Copy link
Copy Markdown
Collaborator Author

@rubujubi does Movement support orderless / nonce transactions? This PR exposes them in the CLI via --replay-protection-type nonce on run/publish/simulate. Default is seqnum so existing behavior is safe, but this exposes an upstream feature that may not be enabled, so if orderless-txn / payload-v2 isn't actually live on Movement then --replay-protection-type nonce produces transactions the node will reject. Which I think is okay, just something to be aware of.

Thanks, Movement does not support it yet. I think it is fine to leave it here since currently --replay-protection-type nonce will be rejected cleanly

@seanyoung seanyoung left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've gone through the merge conflicts and they all look good to me.

The governed gas pool merge moves things around but everything is still there. I will double check once the governed gas pool is ready for merging.

I have to say it painstaking work, I did my best but I hope I did not miss anything.

@areshand

Copy link
Copy Markdown
Collaborator

validated through ephemeral mainnet. The chain is health. let's go ahead and land it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.