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:
- 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.
- 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
- 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).
- 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).
What problem does your feature solve?
The
stellar contract buildcommand currently has an--optimizeflag (gated behind theadditional-libsfeature) that is opt-in. This creates two problems:wasm-optand 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
--optimizethe default.stellar contract buildoptimizes the wasm by default.--optimize=false(or--no-optimize) disables it for edge cases.additional-libsfeature gating is removed, so optimization is always available in published binaries.Option B: remove optimization from the CLI entirely.
--optimizeflag onstellar contract buildis removed.stellar contract optimizesubcommand is also removed.wasm-optthemselves and run it independently.How to decide between Option A and Option B
--optimize, whether they proactively do not use it, and why.cc @oceans404 @janewang
What alternatives are there?
Relevant code
cmd/soroban-cli/src/commands/contract/build.rs(the--optimizeflag onBuildArgsand its conditional invocation).cmd/soroban-cli/src/commands/contract/optimize.rs(the standaloneoptimizesubcommand).