Sui’s Major Execution Layer Upgrade: What Has Changed?

Yesteray, Sui announced the most significant execution layer upgrade since its launch. On the surface, the summary seems straightforward: faster execution, per-package caching, and groundwork for next-generation Move features. But dig into the actual code, and the picture becomes more interesting. This update introduces a genuine paradigm shift in how the execution engine works. Here's a breakdown of the key changes, based on the code published on GitHub.

1. What Changed

1.1 The Execution Pipeline

Sui's execution engine is managed in isolation across protocol versions. With this update, the engine moves to v3. The centerpiece of v3 is a brand-new execution pipeline called static_programmable_transactions, toggled on or off by a single protocol configuration flag.

1.1.1 The Old Way: Validate as You Go

The v2 execution model was straightforward. It pulled commands from a PTB (Programmable Transaction Block) one at a time, checked types at the point of execution, verified borrow rules, and returned results. All of this happened inside a single file (execution.rs).

The approach is intuitive, but structurally limited. Because every check happens at runtime, type mismatches and borrow violations can only be caught mid-execution. Results from package loading and type resolution are difficult to reuse. This wasn't a problem when the network was small, but as the number of on-chain packages grew and transactions became more complex, the architecture started to become a bottleneck.

1.1.2 The New Way: Analyze First, Execute Later

The v3 pipeline does not execute transactions immediately. Instead, it runs them through a multi-stage analysis and verification process before execution begins, much like a compiler would.

Let's walk through each stage.

• Loading: Classifies the transaction's inputs, loads the referenced packages and functions, and produces an intermediate representation (Loading AST). The CachedPackageStore caches previously loaded packages during this step.

• Typing: Statically infers the input and return types for each command based on the Loading AST. Then, using that type information, it verifies memory safety, drop safety, and argument compatibility, all before execution begins. This is by far the heaviest stage in the new VM.

• Execution: Runs the Typed AST, whose types have already been resolved and verified. Because there's almost no need for additional runtime type checks, execution itself becomes much lighter.

The sheer scale of the code tells the story. The old execution core was roughly 3,500 lines. The new pipeline comes in at 10,529 lines, nearly three times the size. That growth isn't incidental; it reflects how much more work now happens before a single instruction is actually executed.

The shift from runtime dynamic interpretation to pre-execution static analysis is not just an optimization. It's a change in the design philosophy of the execution engine itself. This foundation will allow the network to handle increasingly complex transaction patterns without compromising stability.

With Loading, Typing, and Execution cleanly separated, each stage can be independently optimized or even swapped out. For example, if Sui were to introduce advanced optimizations like JIT or AOT compilation down the road, adding a new Execution backend that takes the Typed AST as input becomes a realistic possibility.

1.2 Per-Package Caching

Another major change in the new VM is the introduction of CachedPackageStore.

Previously, every time a package was needed, it was fetched from the store. The new VM caches up to 200 loaded packages in memory and separately caches up to 1,000 type origin mappings (which track where each type was originally defined). When a transaction calls functions across multiple packages, there's no need to reload the same package repeatedly.

This might look like a minor optimization, but given Sui's execution model, the impact is significant. A single PTB on Sui can chain multiple Move function calls, and in the case of DeFi protocols, it's common for a single transaction to invoke functions from several different packages in sequence: a DEX, a lending protocol, an oracle, and so on. Package caching meaningfully reduces execution time for these kinds of composed transactions.

That said, the current CachedPackageStore is a transitional implementation. A comment in the source reads: "FUTURE: Most/all of this will be replaced by the VM runtime cache in the new VM. For now though, we need to use this." In fact, a separate cache structure called MoveCache already exists at the Move VM runtime layer, featuring a DashMap-based concurrent package cache and per-linkage VTable caching. As the role currently handled by the Sui adapter-level CachedPackageStore is gradually absorbed into the VM internals, caching will operate deeper within the execution engine, enabling further performance gains.

1.3 New Bytecode Instructions

At the code level, one of the more interesting additions is the set of new bytecode instructions in the v3 Move VM interpreter.

These instructions exist to support enums in the Move language. Until now, Move only had structs, which meant developers had to rely on workaround patterns to represent multiple states. With enums, pattern matching becomes possible, and state machines in smart contracts can be expressed far more naturally.

The bytecode verifier has also gained new modules: ability_cache.rs, data_defs.rs, and regex_reference_safety/, among others. This isn't just about adding one feature. It signals that Move's type system is expanding as a whole. The Sui team has stated that this upgrade lays the groundwork for next-generation Move features that the previous architecture could not easily accommodate.

2. How to Think About This

Rewriting an entire VM carries real security risk. The execution layer is the most critical part of any blockchain, and vulnerabilities here can directly lead to lost funds or network failures.

The Sui team appears to be taking this risk seriously. Beyond completing internal reviews and independent audits by OtterSec and Zellic, they've opened a bug bounty on HackenProof at mainnet-level payouts before the code has even reached testnet. Typically, bounty rewards scale up as code gets closer to production. Offering mainnet rates at this stage reads as a deliberate move to pull community security review forward as early as possible.

The addition of static type analysis is itself a net positive for security. Verifying types and borrow rules before execution reduces the chance of unexpected type confusion or reference misuse at runtime. Of course, there could be bugs in the static analysis code itself, so thorough verification is a prerequisite. But in the long run, this is a structural improvement to the safety of the execution layer.

Sui's new VM is targeting mainnet deployment in early April. Between now and then, hopefully the bug bounty draws enough scrutiny from the community. It will be worth watching how this upgrade shapes the long-term scalability of Sui's execution layer.