Skip to content

Make --optimize the default behavior of stellar contract build, or remove it #2565

@leighmcculloch

Description

@leighmcculloch

What problem does your feature solve?

The stellar contract build command currently has an --optimize flag (gated behind the additional-libs feature) that is opt-in. This creates two problems:

  1. If optimization is meaningful for on-chain contracts, then everyone should be using it, and it should be on by default. Making it opt-in means most users ship un-optimized wasm by accident.
  2. If optimization is not meaningful enough to be on by default, then it doesn't need to be in the CLI at all and could be removed entirely, leaving users to install wasm-opt and run it independently.

Either way, the current state (an off-by-default first-class flag) is the worst of both worlds.

This also matters for build verification. As discussed in stellar/stellar#1923 (comment).

What would you like to see?

Pick one of the following:

Option A (preferred): make --optimize the default.

  • stellar contract build optimizes the wasm by default.
  • --optimize=false (or --no-optimize) disables it for edge cases.
  • The additional-libs feature gating is removed, so optimization is always available in published binaries.
  • Build verification metadata drops the optimize knob and assumes optimization is on.

Option B: remove optimization from the CLI entirely.

  • The --optimize flag on stellar contract build is removed.
  • The stellar contract optimize subcommand is also removed.
  • Users who want optimization install wasm-opt themselves and run it independently.
  • Build verification metadata drops the optimize knob.

How to decide between Option A and Option B

  1. Collect data on how beneficial optimization is for most production contracts (e.g. size reduction, instruction count, fee impact across a representative sample of deployed contracts).
  2. Get feedback from developers in the ecosystem on whether they currently use --optimize, whether they proactively do not use it, and why.

cc @oceans404 @janewang

What alternatives are there?

  • Leave the flag as-is (status quo).

Relevant code

  • cmd/soroban-cli/src/commands/contract/build.rs (the --optimize flag on BuildArgs and its conditional invocation).
  • cmd/soroban-cli/src/commands/contract/optimize.rs (the standalone optimize subcommand).

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    Status

    Backlog (Not Ready)

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions