CI is red on main: ed25519-dalek 3.0 resolved into soroban-env-host (no lockfile)

[neromtoobad]

Problem Statement

Tests (host target) fails on main and therefore on every open PR:

error[E0277]: the trait bound `ChaCha20Rng: ed25519_dalek::rand_core::CryptoRng` is not satisfied
   host.with_test_prng(|chacha| Ok(SigningKey::generate(chacha)))
   note: required by a bound in `ed25519_dalek::SigningKey::generate`
     --> ed25519-dalek-3.0.0/src/signing.rs:213
error: could not compile `soroban-env-host` (lib)

No code change caused this. main was green on 28 Jun and red from ~14 Jul with no commits in between.

Root cause

soroban-env-host declares an unbounded requirement:

[dependencies.ed25519-dalek]
version = ">=2.0.0"

When ed25519-dalek 3.0.0 was published it satisfied >=2.0.0 and was resolved in — but env-host only compiles against 2.x, since 3.0 tightened CryptoRng (now requiring DerefMut/TryRng, which ChaCha20Rng does not implement).

Because Cargo.lock is git-ignored, CI re-resolves from crates.io on every run and keeps picking the new major.

Note that crates/tools' own ed25519-dalek = "2.2" does not prevent this: Cargo allows majors to coexist, so tools gets 2.2.0 while soroban-env-host independently takes 3.0.0.

Why it Matters

• Every PR is red, so CI signal is currently worthless — a real regression would be indistinguishable from this noise.
• Without a lockfile the build is not reproducible, which matters for a repo that ships deployable contracts and verifies WASM hashes.

Expected Outcome

Commit Cargo.lock (pinned to ed25519-dalek 2.2.0) and remove it from .gitignore.

Acceptance Criteria

• Tests (host target) passes on main
• Cargo.lock is tracked, so dependency resolution is reproducible

Verification

With the pin, CI's exact commands pass locally:

cargo test <contracts> --locked   -> 166 passed; 0 failed
cargo clippy <contracts> --locked -- -D warnings  -> clean

Optional follow-ups

• Add --locked to CI's cargo invocations so a stale lock fails loudly.
• Upstream: soroban-env-host capping to >=2.0.0, <3 would fix this for everyone.

[zeemscript]

I'd like to take this on. I've reviewed the requirements and have a clear implementation plan. I'll deliver a clean, well-tested solution that aligns with the existing codebase, with clear communication and a high-quality PR.

[webdevayo]

Hello Maintainer. I will like to work on this issue

[grantfox-oss]

🦊 GrantFox — @webdevayo has been assigned to this issue as part of the Official Campaign | FWC26 campaign!

Next steps:

1. Open a Pull Request referencing this issue (e.g., Closes #161)
2. Your PR will be reviewed by the OrbitChainLabs maintainers

Good luck! Track your progress on GrantFox.

[neromtoobad]

Heads-up for anyone picking this up, and for @Alqku: a fix is already open and CI-verified — #157 (Closes #161). All four checks are green on it, which makes it the only green PR on the repo right now.

Context so nobody duplicates the diagnosis: nothing in this repo changed. soroban-env-host declares ed25519-dalek = ">=2.0.0" with no upper bound, so when ed25519-dalek 3.0.0 was published Cargo resolved it in — but env-host only builds against 2.x (3.0 tightened CryptoRng to require DerefMut/TryRng, which ChaCha20Rng doesn't implement). Since Cargo.lock is git-ignored, CI re-resolves on every run and keeps picking the new major. Hence green on 28 Jun, red from ~14 Jul, no commits in between.

The fix is committing the lockfile pinned to ed25519-dalek 2.2.0. With it, CI's exact commands pass locally (cargo test <contracts> --locked → 166 passed; clippy -- -D warnings → clean).

I filed this issue at @Alqku's request because #157 had no issue to close — not to claim it. If a maintainer would rather assign it to someone else, that's completely fine; the diagnosis above should make it quick either way, and I'm happy to close #157.

One thing worth knowing regardless of who takes it: this blocks everything else. Until it lands, every PR on the repo shows a red Tests (host target) that has nothing to do with its own changes.