update zvm soroban env #5
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This does the most minimal set of changes to the host -- switching it from protocol 21 to 22 -- and produces a new set of observations with that change. Note that it's done in two steps, first by making an _exact_ copy of the protocol 21 observations and then by updating them after the change with a re-observation. You can observe [this change](36bf7b742d1ab40ef2d90ef103e08e90217d3fc6) to see that the only things that changed are what you'd expect from the minimal change: some object hashes (and therefore footprints and such) of contracts. The idea here is to merge this change, which is obviously semantically benign, _before_ we land anything that makes a substantive change to the semantics of protocol 22, so that we have a better chance of isolating "what changed" in subsequent re-observations of the changed protocol 22.
### What Unpin all non-stellar dependencies. ### Why We have had reports that the libs are difficult to integrate into other projects due to the rigid dependency requirements. We ultimately need the dependencies to be pinned in stellar-core. There's benefit to the tests in this repo running with the same dependencies as what core pins to. There's benefits to stellar-rpc also using the same dependencies so as to decrease the chance that simulation runs with different behavior. Also, the same applies to the SDK for test behavior. Pinning the deps were an easy way to keep the dependencies consistent everywhere, but it also makes it difficult for folks to use the env libraries. Close #1351 ### Other things that need to happen @graydon is making a tool to check that Cargo.lock files are using consistent versions where possible across the env repo, core repo, and we can also use that in the rpc repo. It won't be practical to expect contract devs to use it on their contract projects, so contract devs will be able to use whatever combination of dependencies and that's just a limitation. ### Why not We could say again that not doing this has greater benefits than allowing folks to more easily use the libraries in their own projects.
This is a _much_ simpler alternative to #1434 -- though it cribs some code from there -- focused on the cruder strategy of "just ship two sorobans in core", with soroban 22 not being able to replay soroban 21 contracts precisely, but soroban 21 being linked-in to core to handle such replay. This makes the task here dramatically simpler -- just adapt to API changes in wasmi and recalibrate -- with a certain amount more work to do on the core side, but not a ton.
### What Formatting fixes
### What The implementation itself is fairly simple (thanks to not needing to support v21 semantics) and follows the [CAP-58](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0058.md). It only has a few caveats: - Pre-v22 protocol Wasms are treated as if they don't have a constructor (they shouldn't have it anyway, but just in case they do we ignore it in order to not break the contract semantics). Thus we don't need to even try calling constructor for them - We try to call constructor for all v22+ contracts, so we charge for VM instantiation, which increases the creation cost to some degree. I'm not sure if we can discount calling non-existent functions; if we find that necessary, we can still improve this before the protocol release. Bulk of this change is tests, and testing is really not trivial as we want to cover a set product of several different options: - p21 vs p22 contracts - v1 vs v2 host function - Constructor return values and errors - constructor arguments present/not present/'default' constructor - auth for constructor itself and inside the constructor - deployer support - invoker auth support - custom account support To make things worse, a contract may only have a single constructor, so this needed a lot of new test Wasms. ### Why See CAP-58 motivation. ### Known limitations I'm sure I haven't covered every possible combination of parameters in tests, but at least tried to have some basic coverage for most of the cases and most obvious combinations.
### What Resolves #812 Improved error message for Symbol validation error. ### Why Error improvement ### Known limitations N/A
### What Update with stellar-xdr with split interface version. ### Why See: - stellar/stellar-xdr#212 Dependent on: - stellar/stellar-xdr#212 - stellar/stellar-xdr#213 - stellar/rs-stellar-xdr#389
…ory (#1454) This is just a small test harness to help people who want to run simple testcases they've generated outside soroban. Put your wasm file in `soroban-env-host/src/test/hostile_inputs` and run `cargo test test_misc_hostile_wasms` and it should just pick your wasm up and attempt to instantiate and run it. Requirements: - The wasm has to have the normal contract metadata section on the front! Absent that it will be rejected immediately. - The wasm of course has to comply with the limited profile soroban uses (few-if-any post-MVP features, no floating point, etc.) - The wasm has to expose a 0-arg function called "test" which is the only thing the test tries to execute.
### What This is a simple improvement to the rounding of budget model evaluation, when the model is linear and iteration > 1. Current: 1. evaluates the linear equation, 2. scale the result back, then 3. multiply by iteration. This change: 1. evaluates the linear equation, 2. multiply by iteration 3. scale the result back. The latter results in less rounding and better precision when the iteration count is large. Also added a test to illustrated expected behavior. ### Why [TODO: Why this change is being made. Include any context required to understand the why.] ### Known limitations [TODO or N/A] --------- Co-authored-by: Siddharth Suresh <[email protected]>
### What Call constructors for the test contracts. Also added some utilities to support setting up contracts with constructors in the SDK. ### Why Supporting constructors in the test framework. ### Known limitations I had to reduce the number of iterations in `check_caller_and_callee_seed_always_different` test as the observations library chokes due to too many observations. I'm not sure what's the reason, but the bug and fix are unrelated to this PR.
### What Add tests that cover recursion with self re-entrance. This is kind of an esoteric/edge case scenario, so I'm covering it in the 'hostile' test suite combined with exercising the deep call stacks. ### Why Improving test coverage. ### Known limitations N/A
This bumps the tracy-client crate to 0.17, so that we can access the `delayed-init` feature (it's not present in 0.16.4 but necessary to use with core). Previously we were patching this dep entirely with a local vendored build of tracy in core, so this potentially moves us closer to upstream (if it work).
### What
Moved backtrace in the Host's DebugInfo behind a new feature.
### Why
The backtrace output is included in the Debug formatting of errors when
testutils are enabled, but the trace has not turned out to be that
useful in contract tests written with the SDK.
When an error occurs in a contract test the output includes two long
stack traces. The first is the one provided by backtrace. The second is
one provided by the Rust test harness. Both are very similar and contain
approximately the same information. The Rust test harness' trace is
actually a little easier to read because it's not quite so verbose.
Here's a before and after of what a test failing looks like before and
after this change:
#### Before
```
HostError: Error(Auth, InvalidAction)
Event log (newest first):
0: [Diagnostic Event] topics:[error, Error(Auth, InvalidAction)], data:"escalating error to panic"
1: [Diagnostic Event] topics:[error, Error(Auth, InvalidAction)], data:["contract call failed", exec, [CAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFCT4]]
2: [Failed Diagnostic Event (not emitted)] contract:CAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHK3M, topics:[error, Error(Auth, InvalidAction)], data:"caught error from function"
3: [Failed Diagnostic Event (not emitted)] contract:CAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHK3M, topics:[error, Error(Auth, InvalidAction)], data:"escalating error to panic"
4: [Failed Diagnostic Event (not emitted)] contract:CAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHK3M, topics:[error, Error(Auth, InvalidAction)], data:["Unauthorized function call for address", CAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFCT4]
5: [Diagnostic Event] topics:[fn_call, Bytes(0000000000000000000000000000000000000000000000000000000000000003), exec], data:CAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFCT4
6: [Diagnostic Event] topics:[fn_call, Bytes(0000000000000000000000000000000000000000000000000000000000000005), __constructor], data:Void
7: [Diagnostic Event] topics:[fn_call, Bytes(0000000000000000000000000000000000000000000000000000000000000004), __constructor], data:Void
8: [Diagnostic Event] topics:[log], data:["holder_2", CAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAK3IM]
9: [Diagnostic Event] topics:[log], data:["holder_1", CAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAITA4]
10: [Diagnostic Event] topics:[log], data:["test_id", CAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHK3M]
11: [Diagnostic Event] topics:[fn_call, Bytes(0000000000000000000000000000000000000000000000000000000000000003), __constructor], data:Void
12: [Diagnostic Event] topics:[log], data:["auth_id", CAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFCT4]
13: [Diagnostic Event] contract:CAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFCT4, topics:[fn_return, init], data:Void
14: [Diagnostic Event] topics:[fn_call, Bytes(0000000000000000000000000000000000000000000000000000000000000002), init], data:[CAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD2KM, 2]
15: [Diagnostic Event] topics:[fn_call, Bytes(0000000000000000000000000000000000000000000000000000000000000002), __constructor], data:Void
16: [Diagnostic Event] topics:[fn_call, Bytes(0000000000000000000000000000000000000000000000000000000000000001), __constructor], data:Void
Backtrace (newest first):
0: backtrace::backtrace::libunwind::trace
at /Users/leighmcculloch/.cargo/registry/src/index.crates.io-6f17d22bba15001f/backtrace-0.3.74/src/backtrace/libunwind.rs:116:5
backtrace::backtrace::trace_unsynchronized
at /Users/leighmcculloch/.cargo/registry/src/index.crates.io-6f17d22bba15001f/backtrace-0.3.74/src/backtrace/mod.rs:66:5
1: backtrace::backtrace::trace
at /Users/leighmcculloch/.cargo/registry/src/index.crates.io-6f17d22bba15001f/backtrace-0.3.74/src/backtrace/mod.rs:53:14
2: backtrace::capture::Backtrace::create
at /Users/leighmcculloch/.cargo/registry/src/index.crates.io-6f17d22bba15001f/backtrace-0.3.74/src/capture.rs:292:9
3: backtrace::capture::Backtrace::new_unresolved
at /Users/leighmcculloch/.cargo/registry/src/index.crates.io-6f17d22bba15001f/backtrace-0.3.74/src/capture.rs:287:9
4: soroban_env_host::host::error::<impl soroban_env_host::host::Host>::maybe_get_debug_info::{{closure}}
at /Users/leighmcculloch/.cargo/git/checkouts/rs-soroban-env-230c62c6b1f3d3f1/75b7821/soroban-env-host/src/host/error.rs:299:37
5: soroban_env_host::budget::Budget::with_shadow_mode
at /Users/leighmcculloch/.cargo/git/checkouts/rs-soroban-env-230c62c6b1f3d3f1/75b7821/soroban-env-host/src/budget.rs:1039:21
6: soroban_env_host::host::Host::with_debug_mode
at /Users/leighmcculloch/.cargo/git/checkouts/rs-soroban-env-230c62c6b1f3d3f1/75b7821/soroban-env-host/src/host.rs:650:24
7: soroban_env_host::host::error::<impl soroban_env_host::host::Host>::maybe_get_debug_info
at /Users/leighmcculloch/.cargo/git/checkouts/rs-soroban-env-230c62c6b1f3d3f1/75b7821/soroban-env-host/src/host/error.rs:296:13
8: soroban_env_host::host::error::<impl soroban_env_host::host::Host>::error::{{closure}}
at /Users/leighmcculloch/.cargo/git/checkouts/rs-soroban-env-230c62c6b1f3d3f1/75b7821/soroban-env-host/src/host/error.rs:280:23
9: soroban_env_host::budget::Budget::with_shadow_mode
at /Users/leighmcculloch/.cargo/git/checkouts/rs-soroban-env-230c62c6b1f3d3f1/75b7821/soroban-env-host/src/budget.rs:1039:21
10: soroban_env_host::host::Host::with_debug_mode
at /Users/leighmcculloch/.cargo/git/checkouts/rs-soroban-env-230c62c6b1f3d3f1/75b7821/soroban-env-host/src/host.rs:650:24
11: soroban_env_host::host::error::<impl soroban_env_host::host::Host>::error
at /Users/leighmcculloch/.cargo/git/checkouts/rs-soroban-env-230c62c6b1f3d3f1/75b7821/soroban-env-host/src/host/error.rs:267:9
12: <soroban_env_host::host::Host as soroban_env_common::env::EnvBase>::escalate_error_to_panic
at /Users/leighmcculloch/.cargo/git/checkouts/rs-soroban-env-230c62c6b1f3d3f1/75b7821/soroban-env-host/src/host.rs:838:26
13: soroban_sdk::env::internal::reject_err::{{closure}}
at /Users/leighmcculloch/.cargo/git/checkouts/rs-soroban-sdk-0ab58a716c671239/a101940/soroban-sdk/src/env.rs:52:23
14: core::result::Result<T,E>::map_err
at /rustc/eeb90cda1969383f56a2637cbd3037bdf598841c/library/core/src/result.rs:854:27
15: soroban_sdk::env::internal::reject_err
at /Users/leighmcculloch/.cargo/git/checkouts/rs-soroban-sdk-0ab58a716c671239/a101940/soroban-sdk/src/env.rs:52:9
16: <soroban_sdk::env::Env as soroban_env_common::env::Env>::call
at /Users/leighmcculloch/.cargo/git/checkouts/rs-soroban-sdk-0ab58a716c671239/a101940/soroban-sdk/src/env.rs:1796:13
17: soroban_sdk::env::Env::invoke_contract
at /Users/leighmcculloch/.cargo/git/checkouts/rs-soroban-sdk-0ab58a716c671239/a101940/soroban-sdk/src/env.rs:379:18
18: auth::tests::TestContractClient::exec
at /Users/leighmcculloch/Code/talk-stellar-meridian24-testing/auth/src/tests.rs:17:1
19: auth::tests::unit_test
at /Users/leighmcculloch/Code/talk-stellar-meridian24-testing/auth/src/tests.rs:61:5
20: auth::tests::unit_test::{{closure}}
at /Users/leighmcculloch/Code/talk-stellar-meridian24-testing/auth/src/tests.rs:35:15
21: core::ops::function::FnOnce::call_once
at /rustc/eeb90cda1969383f56a2637cbd3037bdf598841c/library/core/src/ops/function.rs:250:5
stack backtrace:
0: rust_begin_unwind
at /rustc/eeb90cda1969383f56a2637cbd3037bdf598841c/library/std/src/panicking.rs:665:5
1: core::panicking::panic_fmt
at /rustc/eeb90cda1969383f56a2637cbd3037bdf598841c/library/core/src/panicking.rs:74:14
2: <soroban_env_host::host::Host as soroban_env_common::env::EnvBase>::escalate_error_to_panic
at /Users/leighmcculloch/.cargo/git/checkouts/rs-soroban-env-230c62c6b1f3d3f1/75b7821/soroban-env-host/src/host.rs:839:9
3: soroban_sdk::env::internal::reject_err::{{closure}}
at /Users/leighmcculloch/.cargo/git/checkouts/rs-soroban-sdk-0ab58a716c671239/a101940/soroban-sdk/src/env.rs:52:23
4: core::result::Result<T,E>::map_err
at /rustc/eeb90cda1969383f56a2637cbd3037bdf598841c/library/core/src/result.rs:854:27
5: soroban_sdk::env::internal::reject_err
at /Users/leighmcculloch/.cargo/git/checkouts/rs-soroban-sdk-0ab58a716c671239/a101940/soroban-sdk/src/env.rs:52:9
6: <soroban_sdk::env::Env as soroban_env_common::env::Env>::call
at /Users/leighmcculloch/.cargo/git/checkouts/rs-soroban-sdk-0ab58a716c671239/a101940/soroban-sdk/src/env.rs:1796:13
7: soroban_sdk::env::Env::invoke_contract
at /Users/leighmcculloch/.cargo/git/checkouts/rs-soroban-sdk-0ab58a716c671239/a101940/soroban-sdk/src/env.rs:379:18
8: auth::tests::TestContractClient::exec
at ./src/tests.rs:17:1
9: auth::tests::unit_test
at ./src/tests.rs:61:5
10: auth::tests::unit_test::{{closure}}
at ./src/tests.rs:35:15
11: core::ops::function::FnOnce::call_once
at /rustc/eeb90cda1969383f56a2637cbd3037bdf598841c/library/core/src/ops/function.rs:250:5
12: core::ops::function::FnOnce::call_once
at /rustc/eeb90cda1969383f56a2637cbd3037bdf598841c/library/core/src/ops/function.rs:250:5
```
#### After
```
HostError: Error(Auth, InvalidAction)
Event log (newest first):
0: [Diagnostic Event] topics:[error, Error(Auth, InvalidAction)], data:"escalating error to panic"
1: [Diagnostic Event] topics:[error, Error(Auth, InvalidAction)], data:["contract call failed", exec, [CAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFCT4]]
2: [Failed Diagnostic Event (not emitted)] contract:CAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHK3M, topics:[error, Error(Auth, InvalidAction)], data:"caught error from function"
3: [Failed Diagnostic Event (not emitted)] contract:CAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHK3M, topics:[error, Error(Auth, InvalidAction)], data:"escalating error to panic"
4: [Failed Diagnostic Event (not emitted)] contract:CAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHK3M, topics:[error, Error(Auth, InvalidAction)], data:["Unauthorized function call for address", CAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFCT4]
5: [Diagnostic Event] topics:[fn_call, Bytes(0000000000000000000000000000000000000000000000000000000000000003), exec], data:CAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFCT4
6: [Diagnostic Event] topics:[fn_call, Bytes(0000000000000000000000000000000000000000000000000000000000000005), __constructor], data:Void
7: [Diagnostic Event] topics:[fn_call, Bytes(0000000000000000000000000000000000000000000000000000000000000004), __constructor], data:Void
8: [Diagnostic Event] topics:[log], data:["holder_2", CAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAK3IM]
9: [Diagnostic Event] topics:[log], data:["holder_1", CAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAITA4]
10: [Diagnostic Event] topics:[log], data:["test_id", CAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHK3M]
11: [Diagnostic Event] topics:[fn_call, Bytes(0000000000000000000000000000000000000000000000000000000000000003), __constructor], data:Void
12: [Diagnostic Event] topics:[log], data:["auth_id", CAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFCT4]
13: [Diagnostic Event] contract:CAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFCT4, topics:[fn_return, init], data:Void
14: [Diagnostic Event] topics:[fn_call, Bytes(0000000000000000000000000000000000000000000000000000000000000002), init], data:[CAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD2KM, 2]
15: [Diagnostic Event] topics:[fn_call, Bytes(0000000000000000000000000000000000000000000000000000000000000002), __constructor], data:Void
16: [Diagnostic Event] topics:[fn_call, Bytes(0000000000000000000000000000000000000000000000000000000000000001), __constructor], data:Void
stack backtrace:
0: rust_begin_unwind
at /rustc/eeb90cda1969383f56a2637cbd3037bdf598841c/library/std/src/panicking.rs:665:5
1: core::panicking::panic_fmt
at /rustc/eeb90cda1969383f56a2637cbd3037bdf598841c/library/core/src/panicking.rs:74:14
2: <soroban_env_host::host::Host as soroban_env_common::env::EnvBase>::escalate_error_to_panic
at /Users/leighmcculloch/Code/rs-soroban-env/soroban-env-host/src/host.rs:839:9
3: soroban_sdk::env::internal::reject_err::{{closure}}
at /Users/leighmcculloch/.cargo/git/checkouts/rs-soroban-sdk-0ab58a716c671239/a101940/soroban-sdk/src/env.rs:52:23
4: core::result::Result<T,E>::map_err
at /rustc/eeb90cda1969383f56a2637cbd3037bdf598841c/library/core/src/result.rs:854:27
5: soroban_sdk::env::internal::reject_err
at /Users/leighmcculloch/.cargo/git/checkouts/rs-soroban-sdk-0ab58a716c671239/a101940/soroban-sdk/src/env.rs:52:9
6: <soroban_sdk::env::Env as soroban_env_common::env::Env>::call
at /Users/leighmcculloch/.cargo/git/checkouts/rs-soroban-sdk-0ab58a716c671239/a101940/soroban-sdk/src/env.rs:1796:13
7: soroban_sdk::env::Env::invoke_contract
at /Users/leighmcculloch/.cargo/git/checkouts/rs-soroban-sdk-0ab58a716c671239/a101940/soroban-sdk/src/env.rs:379:18
8: auth::tests::TestContractClient::exec
at ./src/tests.rs:17:1
9: auth::tests::unit_test
at ./src/tests.rs:61:5
10: auth::tests::unit_test::{{closure}}
at ./src/tests.rs:35:15
11: core::ops::function::FnOnce::call_once
at /rustc/eeb90cda1969383f56a2637cbd3037bdf598841c/library/core/src/ops/function.rs:250:5
12: core::ops::function::FnOnce::call_once
at /rustc/eeb90cda1969383f56a2637cbd3037bdf598841c/library/core/src/ops/function.rs:250:5
```
### Note
I'm not attached to this change if we need back traces for something,
but if we need to keep them, I'm interested in how we can silence them
for errors in contract tests.
### Bonuses
As a bonus, this removes 7 deps from the dep graph for contract
developers! 🎉
### What Add e2e tests to cover unsupported Wasm upload failure. While we do cover this at a lower level, it's nice to have an e2e test that makes sure that VM configuration is correct. We also do have e2e tests for completely malformed Wasm failures, this scenario is different because Wasm is not malformed. ### Why Improving test coverage ### Known limitations N/A
### What Resolves #1463 Before ``` Event log (newest first): 0: [Diagnostic Event] contract:CAXDPD4A5ANAASQ2U74RBW7ULGB3TS5SGSAFYPN6O2R2IJKGEX22SWUS, topics:[error, Error(Contract, #8)], data:["negative amount is not allowed", -1] 1: [Diagnostic Event] topics:[fn_call, Bytes(2e378f80e81a004a1aa7f910dbf45983b9cbb234805c3dbe76a3a4254625f5a9), mint], data:[GD4YHMIZ7IGW7E4XJ4TXIJPLJU255JXPM2PKTV6H4PA4N5RTM6T2R73D, -1] 2: [Diagnostic Event] contract:CAXDPD4A5ANAASQ2U74RBW7ULGB3TS5SGSAFYPN6O2R2IJKGEX22SWUS, topics:[fn_return, init_asset], data:Void 3: [Diagnostic Event] topics:[fn_call, Bytes(2e378f80e81a004a1aa7f910dbf45983b9cbb234805c3dbe76a3a4254625f5a9), init_asset], data:Bytes(00000001616161610000000000fc065517dbbca3e37ec0e97dbfcd80e6bcdfdac732be1e4152b259f1f7ea88) ``` After ``` Event log (newest first): 0: [Diagnostic Event] contract:CAXDPD4A5ANAASQ2U74RBW7ULGB3TS5SGSAFYPN6O2R2IJKGEX22SWUS, topics:[error, Error(Contract, #8)], data:["negative amount is not allowed", -1] 1: [Diagnostic Event] topics:[fn_call, CAXDPD4A5ANAASQ2U74RBW7ULGB3TS5SGSAFYPN6O2R2IJKGEX22SWUS, mint], data:[GD4YHMIZ7IGW7E4XJ4TXIJPLJU255JXPM2PKTV6H4PA4N5RTM6T2R73D, -1] 2: [Diagnostic Event] contract:CAXDPD4A5ANAASQ2U74RBW7ULGB3TS5SGSAFYPN6O2R2IJKGEX22SWUS, topics:[fn_return, init_asset], data:Void 3: [Diagnostic Event] topics:[fn_call, CAXDPD4A5ANAASQ2U74RBW7ULGB3TS5SGSAFYPN6O2R2IJKGEX22SWUS, init_asset], data:Bytes(00000001616161610000000000fc065517dbbca3e37ec0e97dbfcd80e6bcdfdac732be1e4152b259f1f7ea88) ```
### What This PR adds support for BLS12-381 in Soroban, by adding host functions for the field and curve operations, new metering cost types, and their calibration. ### Why Please refer to the [CAP](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0059.md) for motivation and design rationale. ### Known limitations The unit tests currently covers the low-level operations: G1/G2 operations, hashing to curve, pairing. More test coverage will be added before the PR merged, at the integration level such as BLS signature and the Ethereum test vectors. --------- Co-authored-by: Plamen Hristov <[email protected]>
### What Update stellar-xdr ### Why Routine.
### What Replace cargo-deny `skip-tree` with explicit `skip`s for each dependency we wish to allow duplicates. ### Why The `skip-tree` obfuscates the dependencies that we're allowing to be duplicated, and even seems to hide some dependencies being duplicated that don't seem to be part of the soroban-wasmi dependency graph that we depend. This may be due to a bug, or possibly the dep is in the dev dependencies of soroban-wasmi, or some feature that we don't use. I became aware of this issue because I noticed that in #1456 the Cargo.lock file gained a duplicate dependency on the `syn` crate, having already a dependency on version `2.0.39` and gaining a dependency on version `1.0.109`. This is fine and not a problem in and of itself – we can't eradicate all duplicates – except that the `deny.toml` file gained no new entry, no statement to say that we were okay with this new duplicate. In my own testing locally it appears that when the `skip-tree` entry containing `soroban-wasmi` is present, the `syn` duplicate dependency is hidden/silenced, even though it was not a dependency prior to the change that did not involve the `soroban-wasmi` crate. The `skip-tree` config obfuscates the duplicate dependencies in a couple ways. Firstly due to the odd behaviour detailed above we appear to not get notified of new duplicate dependencies, even if they do not appear to be an active in use dependency in our existing graph. Secondly because the `skip-tree` communicates only partially about what is being allowed. In our case the `skip-tree` allows two versions of the `hashbrown` dep, but we actually need the two versions for reasons other than `soroban-wasmi`, so it doesn't tell the full story. Listing out the duplicate dependencies one-by-one is explicit, and it helps us at a glance know what our dupes are, and how many we have, as a signal to "how bad it is getting". ### Known limitations N/A
### What We want to release an rc version first.
### What Bump to RC release
### What Update stellar-xdr to latest rc release. ### Why Routine. So that downstream tools can use the latest xdr lib.
### What Bump version to 22.0.0-rc.1.1, creating release branch. ### Why Triggered by @leighmcculloch in https://github.com/stellar/rs-soroban-env/actions/runs/11133495292. ### What is next See the release instructions for a full rundown on the release process: https://github.com/stellar/actions/blob/main/README-rust-release.md Commit any changes to the `release/v22.0.0-rc.1.1` branch that are needed in this release. If this is a regular release releasing from `main`, merge this PR when ready, and after merging, create a release for this version by going to this link: https://github.com/stellar/rs-soroban-env/releases/new?tag=v22.0.0-rc.1.1&title=22.0.0-rc.1.1 If this is a backport or patch release of a past version, see the release instructions. When ready to release this branch create a release by going to this link: https://github.com/stellar/rs-soroban-env/releases/new?tag=v22.0.0-rc.1.1&title=22.0.0-rc.1.1&target=release/v22.0.0-rc.1.1 Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
This reverts wasmi from 0.36 to 0.31 while retaining everything else that's happened in p22. In particular the host still only speaks p22 and refuses to emulate p21.
### What Bump version to 22.0.0-rc.2, creating release branch. ### Why Triggered by @graydon in https://github.com/stellar/rs-soroban-env/actions/runs/11152907046. ### What is next See the release instructions for a full rundown on the release process: https://github.com/stellar/actions/blob/main/README-rust-release.md Commit any changes to the `release/v22.0.0-rc.2` branch that are needed in this release. If this is a regular release releasing from `main`, merge this PR when ready, and after merging, create a release for this version by going to this link: https://github.com/stellar/rs-soroban-env/releases/new?tag=v22.0.0-rc.2&title=22.0.0-rc.2 If this is a backport or patch release of a past version, see the release instructions. When ready to release this branch create a release by going to this link: https://github.com/stellar/rs-soroban-env/releases/new?tag=v22.0.0-rc.2&title=22.0.0-rc.2&target=release/v22.0.0-rc.2 Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
#1477) ### What Ported the implementation of binary search from Rust <=1.81 to Soroban env. ### Why This is necessary for 2 reasons: - Fix the immediate issue of CI failing due to observation divergence in Rust 1.82 caused by the binary search implementation change - Protect ourselves from the similar issues in the future - we were effectively observing the stdlib implementation and that's incorrect and risky in the long term. ### Known limitations N/A
### What Bump version to 22.0.0-rc.3, creating release branch. ### Why Triggered by @anupsdf in https://github.com/stellar/rs-soroban-env/actions/runs/11449306506. ### What is next See the release instructions for a full rundown on the release process: https://github.com/stellar/actions/blob/main/README-rust-release.md Commit any changes to the `release/v22.0.0-rc.3` branch that are needed in this release. If this is a regular release releasing from `main`, merge this PR when ready, and after merging, create a release for this version by going to this link: https://github.com/stellar/rs-soroban-env/releases/new?tag=v22.0.0-rc.3&title=22.0.0-rc.3 If this is a backport or patch release of a past version, see the release instructions. When ready to release this branch create a release by going to this link: https://github.com/stellar/rs-soroban-env/releases/new?tag=v22.0.0-rc.3&title=22.0.0-rc.3&target=release/v22.0.0-rc.3 Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
### What Fill gaps in ref conversions to Val. ### Why Needed for: - stellar/rs-soroban-sdk#1382
### What Disable semver checks temporarily. ### Why The check is broken due to `arbitrary` crate update (rust-fuzz/arbitrary#203). ### Known limitations N/A
…#1476) ### What Emulate access to custom account instance and Wasm in recording auth. The change gracefully handles failures (e.g. allows for the instance not being present) in order to not spam diagnostics in unit tests that don't care about the footprint (which makes up for majority of the unit tests). ### Why Better emulate the authorization behavior (in some edge cases this might allow for single-pass simulation of custom accounts). Resolves #1443 ### Known limitations In theory, we could also try calling `__check_auth` on the contract (if possible), but that will likely produce confusing diagnostics for most of the contracts (e.g. signature verification errors).
### What Re-enable semver-checks. ### Why They should be unstuck now. ### Known limitations N/A
### What Update the main branch to v22.0.0
…t. (#1486) ### What Fix an issue in footprint simulation and add some test coverage for it. The issue occurs when a non-existent entry gets in a failed contract call that is then handled gracefully via `try_call`. The value won't appear in storage and due to how simulation is implemented it also wasn't included in the result footprint due to that. The fix is to just add the footprint-only entries to the recorded ledgers diffs (as a 'never existed' entry). ### Why Bug fix. ### Known limitations N/A
… per-invocation (#1482) ### What This is an opt-in feature that will reset the budget and take a storage snapshot for every 'logical' invocation (such as `call` or a lifecycle operation). Then when the invocation is done we use the snapshot and current budget to produce the estimate for the resources consumed by the invocation (budget-related, IO-related and rent bumps). This also provides a rough estimation for the respective fee breakdown given a fee config. ### Why Make unit tests more useful for rough performance evaluation. This is the initial env-side implementation for stellar/rs-soroban-sdk#1319 ### Known limitations Some of the resources are tricky to model. Specifically, this omits: - transaction size - return value size - some XDR roundtrips that always happen for production scenarios These shouldn't be too significant though and are likely better addressed via e2e runs (like simulation or some `e2e_invoke`-based mechanism)
### What This function avoids accessing storage as that's not necessary for covering I/O (storage is just an in-memory map on the host side). It also emits events. Also cleaned up the build configs of the examples. ### Why Apply load benchmark improvements. ### Known limitations N/A
### What Bump version to 22.1.0, creating release branch. ### Why Triggered by @sisuresh in https://github.com/stellar/rs-soroban-env/actions/runs/11863204012. ### What is next See the release instructions for a full rundown on the release process: https://github.com/stellar/actions/blob/main/README-rust-release.md Commit any changes to the `release/v22.1.0` branch that are needed in this release. If this is a regular release releasing from `main`, merge this PR when ready, and after merging, create a release for this version by going to this link: https://github.com/stellar/rs-soroban-env/releases/new?tag=v22.1.0&title=22.1.0 If this is a backport or patch release of a past version, see the release instructions. When ready to release this branch create a release by going to this link: https://github.com/stellar/rs-soroban-env/releases/new?tag=v22.1.0&title=22.1.0&target=release/v22.1.0 --------- Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com> Co-authored-by: Siddharth Suresh <[email protected]>
…to recording mode (#1495) ### What Add a function to inherit the recording auth settings when switching to recording mode. ### Why This is necessarily for the test utilities that snapshot the auth manager and unconditionally switch to recording mode (such as helpers for deploying the contracts). Previously we just disallowed non-root auth because that didn't matter, but with the constructors it does matter. ### Known limitations N/A
### What Expose structs used for invocation metering. ### Why These are meant to be public. ### Known limitations N/A
### What Bump version to 22.1.1, creating release branch. ### Why Triggered by @dmkozh in https://github.com/stellar/rs-soroban-env/actions/runs/12286865866. ### What is next See the release instructions for a full rundown on the release process: https://github.com/stellar/actions/blob/main/README-rust-release.md Commit any changes to the `release/v22.1.1` branch that are needed in this release. If this is a regular release releasing from `main`, merge this PR when ready, and after merging, create a release for this version by going to this link: https://github.com/stellar/rs-soroban-env/releases/new?tag=v22.1.1&title=22.1.1 If this is a backport or patch release of a past version, see the release instructions. When ready to release this branch create a release by going to this link: https://github.com/stellar/rs-soroban-env/releases/new?tag=v22.1.1&title=22.1.1&target=release/v22.1.1 Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
### What Update stellar-xdr ### Why To get the recent changes in stellar-xdr available in a compatible env that pins to a specific version of stellar-xdr.
### What Bump version to 22.1.2, creating release branch. ### Why Triggered by @leighmcculloch in https://github.com/stellar/rs-soroban-env/actions/runs/12295359246. ### What is next See the release instructions for a full rundown on the release process: https://github.com/stellar/actions/blob/main/README-rust-release.md Commit any changes to the `release/v22.1.2` branch that are needed in this release. If this is a regular release releasing from `main`, merge this PR when ready, and after merging, create a release for this version by going to this link: https://github.com/stellar/rs-soroban-env/releases/new?tag=v22.1.2&title=22.1.2 If this is a backport or patch release of a past version, see the release instructions. When ready to release this branch create a release by going to this link: https://github.com/stellar/rs-soroban-env/releases/new?tag=v22.1.2&title=22.1.2&target=release/v22.1.2 Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
### What Update README.md for rs-soroban-env ### Why Improving documentation ### Known limitations N/A --------- Co-authored-by: Siddharth Suresh <[email protected]>
### What Allow passing the setting for non-root auth to the simulation. This is unfortunately a breaking change and thus it needs to be guarded by unstable-next-api feature. ### Why This allows for more control over the simulation logic - while the default is sufficient 99% of the time, there is still 1% of the cases where non-root auth should be allowed. ### Known limitations N/A
### What Add invocation resource metering to check auth testutil. Also harden the unit tests a bit to ensure that budget matches the CPU/memory we report in invocation resources and add a test case for a failed call. ### Why Fix for stellar/rs-soroban-sdk#1421, still needs to be picked up by the SDK. ### Known limitations N/A
### What Bump version to 22.1.3, creating release branch. ### Why Triggered by @dmkozh in https://github.com/stellar/rs-soroban-env/actions/runs/12640513942. ### What is next See the release instructions for a full rundown on the release process: https://github.com/stellar/actions/blob/main/README-rust-release.md Commit any changes to the `release/v22.1.3` branch that are needed in this release. If this is a regular release releasing from `main`, merge this PR when ready, and after merging, create a release for this version by going to this link: https://github.com/stellar/rs-soroban-env/releases/new?tag=v22.1.3&title=22.1.3 If this is a backport or patch release of a past version, see the release instructions. When ready to release this branch create a release by going to this link: https://github.com/stellar/rs-soroban-env/releases/new?tag=v22.1.3&title=22.1.3&target=release/v22.1.3 Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
### What Bump XDR for env. This currently only affects the vnext of XDR. ### Why Preparing for Core changes. ### Known limitations N/A
This PR _strictly_ bumps the protocol to p23 (and re-observes tests) not changing anything else. The commit that needs the most scrutiny is f4dc35d since it is the reobservation run: only small changes that derive from the protocol number itself should be visible (typically "the change of protocol number in the wasm metadata").
The goals of this PR are: 1. Surface the `ModuleCache` from inside soroban to its embedding environment. 2. Allow a module cache to _outlive_ the soroban `Host`, and be reused from one `Host` to the next. 3. Allow the `ModuleCache` to be _pre-populated_ from before the lifetime of a single `Host`, (eg. by stellar-core, with all the non-archived contracts currently live in the ledger, at startup or such.) These goals are accomplished by the following structural changes: 1. Factoring out error-handling / error-mapping functionality of `Host` into a separate trait `ErrorHandler` that `Host` implements, and adding a new trait `CompilationContext` that extends both `ErrorHandler + AsBudget`. This abstracts the services the `ModuleCache` _needs_ from the `Host`, such that the embedding environment can provide its own `CompilationContext` in the times pre- or post-`Host` lifetime. 2. Modifying the internal map that stores `Module`s inside the `ModuleCache` to use a refcounted-shared-mutable `std::map::BtreeMap` that can be incrementally and efficiently added-to or removed-from, and is _not_ metered. 3. `Module` storage and arguments that were `Rc<>` are made `Arc<>` and the whole `ModuleCache` is made `Send+Sync`. This is mainly because we want to work with the reusable `ModuleCache` across C++ threads, and while Rust has no idea about C++ threads it at least helps us shoot ourselves in the foot less if all the Rust code that works with it preserves the sense of "this would be threadsafe in Rust if Rust was making the threads". 4. There is also a bit of gratuitous churn where things get renamed from `foo` => `wasmi_foo` and `Foo` => `wasmi::Foo`. This is because this change was done as part of (and there'll be a followup PR including) work equipping the `Vm` and `ModuleCache` with an experimental wasmtime/winch backend. It turns out this PR's work (on just the `ModuleCache` reuse part) is high enough value, and agnostic enough to which backend it's using, that we want to split this work out, move it up in the schedule and explore getting it into as early a release as possible. But I didn't bother reverting-out the `wasmi_`-qualification since it's intertwined with other changes here and harmless to keep. This PR is a continuation of #1511 and should be merged after it. This PR implements [CAP-0065](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0065.md)
### What Tighten the budget estimations in e2e tests. There was a small bug in the module cache construction - we didn't consider the proper version of the code entry when building the module cache to pass to the enforcing mode. This fix allows us to bring the discrepancy between the recording and enforcing modes back to 0.02. ### Why Test fixes ### Known limitations N/A
### What Remove `unstable-next-api` feature guards. ### Why We don't need these anymore as host has already been switched to v23. ### Known limitations N/A
### What Remove the check_same_env function from the EnvBase trait and move it into the Host impl. ### Why Functions in the EnvBase are implemented by Host and Guest. The check_same_env function is only used by the soroban-sdk. In stellar/rs-soroban-sdk#1436 the soroban-sdk is no longer going to be calling the function on the Guest, and only calling it directly on the Host. So there's no longer a need for it to be part of this trait/interface.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What
[TODO: Short statement about what is changing.]
Why
[TODO: Why this change is being made. Include any context required to understand the why.]
Known limitations
[TODO or N/A]