Aptos node 1.49.1 makes Block-STM v2 the default executor
Victoria Shinder1 min readAptos Labs published aptos-node v1.49.1 on 23 September, described in the release notes as the open source release of a hotfix version. The notes are a list of merged pull requests between v1.48.6 and v1.49.1, and a few of them change how the network runs.
The most visible is in execution: Block-STM v2 is now enabled by default (#20116). Block-STM is Aptos's parallel execution engine, which runs a block's transactions optimistically in parallel and re-runs those that conflict. The gas schedule moves to version 49 (#20050).
Several entries concern encrypted transactions in consensus. One decouples the encryption round from the consensus round (#20065); another excludes retryable encrypted transactions from execution (#20115); a third tests transitions between versions of the decryption metadata. Keyless accounts, which let users sign in with existing identity providers, get a change to lazily prepare the verification key (#20148), and the federated JWK limit is raised (#20105).
Much of the rest is groundwork. A large number of entries belong to "mono-move", work on a new Move execution pipeline with generics monomorphisation, vector operations, enums and native functions. Storage gains hot-state snapshot APIs and a fix for non-deterministic hot-state promotions (#20057), and the notes include a native position framework module for trading.
What it means
For node operators, the release is a routine upgrade with one behavioural change worth monitoring: a new default executor. Parallel execution engines are sensitive to workload, so throughput and latency after the switch are the numbers to watch.
The encryption entries point to where Aptos is investing - transactions whose contents are hidden until ordering is fixed, which targets front-running. The release notes describe code changes rather than rollout plans, so they indicate direction, not timing.