Skip to content

SPIKE: Protocol 28 (CAP-0084)#1924

Draft
sisuresh wants to merge 14 commits into
stellar:mainfrom
sisuresh:p28-cap-0084
Draft

SPIKE: Protocol 28 (CAP-0084)#1924
sisuresh wants to merge 14 commits into
stellar:mainfrom
sisuresh:p28-cap-0084

Conversation

@sisuresh

@sisuresh sisuresh commented Jul 3, 2026

Copy link
Copy Markdown
Contributor

SDK support for CAP-0084 (Muxed Contract Addresses).

Changes

  • Re-pinned rs-soroban-env to Bump version to 25.0.1 #1700 head b5fdf26e; rs-stellar-xdr to Update deps for release #552 head cf7fdedf. env#1700 already depends on the same xdr rev via sisuresh/rs-stellar-xdr, so the source is unified and the former transitive [patch] is now redundant (commented out).

Deferred

Upstream

sisuresh added 5 commits June 26, 2026 17:45
… feature

- Re-pin soroban-env-{common,guest,host} to rs-soroban-env#1696 (CAP-0084 host).
- Re-pin stellar-xdr to rs-stellar-xdr#549 (per-cap layout, self-reports 28.0.0).
- Enable the `cap_0084_muxed_contract` feature across the workspace so
  soroban_sdk::xdr exposes the new ScAddress::MuxedContract arm, and handle
  that arm in the exhaustive ScAddress matches (address/muxed_address).
- Forward cap_0084_muxed_contract to env-common in soroban-sdk-macros so the
  host-compiled (proc-macro) env-common takes the same proto-28 `next` branch
  as the target env-common (avoids the env-macros proto-version assert mismatch).
- Bump the default test ledger protocol_version 27 -> 28 (the env `next` proto
  pulled in by the cap feature stamps proto 28 into compiled contracts).
- Regenerate test_snapshots and Cargo.lock.

No new SDK API: CAP-0084 adds no host functions (muxed-contract handling is
host-side SAC, destination-only). cap_0083 is intentionally NOT enabled: it
gates StellarValue (consensus) types the SDK never uses and env does not enable.
cargo-deny sources allow-org is limited to `stellar`; the SPIKE pins
pointed at sisuresh/ forks. Repoint soroban-env-{common,guest,host} and
stellar-xdr to stellar/rs-soroban-env and stellar/rs-stellar-xdr at the
same stellar#1696/stellar#549 branch commits (reachable via the fork network). The env
crates transitively pull stellar-xdr from sisuresh/rs-stellar-xdr, so add
a [patch] redirecting that source to stellar/ at the identical rev,
collapsing the duplicate. Fixes cargo-deny (bans/licenses/sources all
ok locally); check-git-rev-deps stays red until stellar#1696 and stellar#549 merge.
@sisuresh

sisuresh commented Jul 3, 2026

Copy link
Copy Markdown
Contributor Author

sisuresh added 9 commits July 2, 2026 19:09
…n pins

Repin the three soroban-env crates to sisuresh/rs-soroban-env#1700
(rev 26b035c), relaxing the exact `=27.0.0` constraints to `27.0.0`
per lessons.md:45 since the git-rev package may self-report a differing
patch/prerelease version. Regenerate tests/fuzz/fuzz/Cargo.lock to match
(env->26b035c on the fork, stellar-xdr->cf7fdedf).
The expand-test-wasms check regenerates tests-expanded/*.rs on linux and
diffs against HEAD. The committed test_spec_shaking_v2_tests.rs snapshot was
generated on macOS/aarch64; its embedded `const WASM` bytes differ from the
linux/x86_64 build only in wasm data-segment layout (host-dependent codegen),
which is exactly what CI regenerates. A local `make expand-tests` against the
current env pin 26b035c00663a424a0cdc4732911d49ddb6bb26f reproduces the macOS
bytes with an empty diff, so the fix is to adopt CI's linux bytes verbatim.

Only this one contract's snapshot differs; no other snapshot changed. Env/xdr
pins are unchanged (env stellar#1700's cargo-deny advisory revert is intentional and
out of scope here).
The SPIKE pins soroban-env/stellar-xdr to fork-hosted
rs-soroban-env#1700 and rs-stellar-xdr#552 revs on github.com/sisuresh.
cargo-deny's [sources.allow-org] matches the literal git-URL org, so
allow-org=["stellar"] rejected them (the "reachable via fork network"
comment was wrong). Add "sisuresh", mirroring rs-soroban-env#1700's
deny.toml. Revert to ["stellar"] at productionization once both
upstreams merge and pins re-point to stellar/ revs.

Also re-pin the soroban-env-* crates to rs-soroban-env#1700's new tip
b51329b6 (was 26b035c0), which now carries the anyhow 1.0.75->1.0.103
RUSTSEC fix; env source is unchanged between the two revs.
tests/fuzz/fuzz/Cargo.lock still referenced the prior env rev
26b035c; align it with the workspace/root re-pin to b51329b6
(fixes build-fuzz lockfile-clean check).
…-checks rustdoc build)

ed25519-dalek 3.0.0 (2026-07-06) broke fresh resolves used by
cargo-semver-checks (ChaCha20Rng: CryptoRng no longer satisfied against
the env's pinned rand 0.8.5). rs-soroban-env#1700 (c500d8be) caps the
requirement at <3.0.0; re-pin all three env crates and refresh both
lockfiles. Fresh resolve now picks ed25519-dalek 2.2.0.
…-dalek 3.0.0 baseline break)

ed25519-dalek 3.0.0 (2026-07-06) breaks cargo-semver-checks' fresh baseline
rustdoc build of the v26.1.0 crates: published soroban-env-host 26.1.3 declares
`ed25519-dalek >=2.0.0`, and the baseline resolve (which ignores our Cargo.lock)
now selects 3.0.0, whose SigningKey::generate rejects the old ChaCha20Rng.
The prior workspace cap fixed only the current build. 26->27 is a major bump so
semver-checks enforces nothing this cycle. Temporary; drop once dalek 3.0.0 is
yanked or the published env caps it.
# Conflicts:
#	tests-expanded/test_spec_shaking_v2_tests.rs
# Conflicts:
#	Cargo.lock
#	Cargo.toml
#	tests-expanded/test_spec_shaking_v2_tests.rs
#	tests/fuzz/fuzz/Cargo.lock
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant