Skip to content

Latest commit

 

History

History
90 lines (51 loc) · 4.68 KB

cap-0060.md

File metadata and controls

90 lines (51 loc) · 4.68 KB
Raw

Preamble

CAP: 0060
Title: Update to Wasmi register machine
Working Group:
    Owner: Graydon Hoare <@graydon>
    Authors: Graydon Hoare <@graydon>
    Consulted: Dmytro Kozhevin <@dmkozh>, Siddharth Suresh <@sisuresh>, Nicolas Barry <@MonsieurNicolas>, Tomer Weller <@tomerweller>
Status: FCP: Accepted
Created: 2024-08-19
Discussion: https://github.com/stellar/stellar-protocol/discussions
Protocol version: 22

Simple Summary

Transition Soroban from the Wasmi 0.31 stack machine to the post-Wasmi-0.32 register machine (0.36 at the time of writing).

Working Group

As specified in the Preamble.

Motivation

Improving the performance of Soroban transactions.

Goals Alignment

This CAP is aligned with the following Stellar Network Goals:

  • The Stellar Network should run at scale and at low cost to all participants of the network.

Abstract

Wasmi 0.32 shipped a new execution engine. The new engine is both faster at straight-line code and also supports lazy validation and translation of its internal representation, reducing the amount of work performed during instantiation and thereby enabling lower-latency transactions.

In general the new execution engine runs the same Wasm bytecode as the old one, with the same semantics, typically at lower cost and higher speed. However there are some minor differences that can be detected by a careful observer.

Specification

XDR Changes

None.

Semantics

VM IR: translation cost, execution cost and gas model

Both the old and new versions of Wasmi execute Webassembly code by translating it to an internal representation (IR) that is convenient to execute, and then executing the IR. The old IR corresponded more closely to Webassembly's natural form than the new one. This has two immediate consequences:

  1. It takes more work to translate any given Webassembly function into the new IR. This will be reflected in higher per-function CPU instruction costs during translation.

  2. It takes less work to execute the new IR produced by translating any given Webassembly function. This will be reflected in lower per-function CPU instruction costs during execution.

Lazy compilation

In addition to the cost differences arising from the IR, the new version of Wasmi supports a significant new mode: lazy compilation.

When compiling a module lazily, Wasmi performs only a minimal "initial parse" of the structure of a module and defers the majority of work involved in validation and translation of each of the functions in the module until each function gets called. If any function is never called in a transaction, only the minimal initial parse gets charged.

Lazy compilation will be enabled for modules after they are uploaded to the ledger, during subsequent execution.

During upload, compilation will be performed eagerly, ensuring that any invalid Webassembly code is caught before being admitted to the ledger at all.

Design Rationale

Stack vs. register machines

The new VM engine is a register machine. This model has been repeatedly shown in many VM designs over many years to provide measurably higher execution throughput by reducing the size of the IR and number of instruction-dispatches that occur when processing the same input code.

The tradeoff is that it takes a bit more time to compile, thereby increasing latency.

If we were considering only the latency and throughput of the same amount of total work, we might not consider this tradeoff worthwhile: it would be good for the longest-running (compute-intensive) transactions but bad for the shortest-running (latency-sensitive) transactions.

However, this change is being accompanied by a major improvement in latency as well: lazy compilation.

Lazy compilation

Most contracts call only a subset of the code in a module. The exact amount will vary by contract, but for example if a transaction only calls half of the functions available in a contract, then only the minimal initial parse gets charged for the un-called (cold) functions. The initial parse of a function is as much as 100x cheaper than a full validation and translation of the function. So our expectation is that for the majority of functions, there will also be a significant improvement in latency.

Test Cases

Testing so far has been included extensive upstream validation tests of the VM as well as the existing Soroban testsuite. We will additionally be replaying segments of the Stellar network's history of Soroban transactions to confirm identical behaviour (besides cost differences).

Implementation

A pull request is available at stellar/rs-soroban-env#1442

At the time of writing there remains some integration work but the code works well enough to pass most tests.