zvm to p22 #6
Open
zvm to p22 #6
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 stellar#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 stellar#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 stellar#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 (stellar#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.
…1450) ### 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 stellar#1463 Before ``` Event log (newest first): 0: [Diagnostic Event] contract:CAXDPD4A5ANAASQ2U74RBW7ULGB3TS5SGSAFYPN6O2R2IJKGEX22SWUS, topics:[error, Error(Contract, stellar#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, stellar#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]>
Just update deps for p22 fix stellar#1353 fix stellar#1313
### 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 stellar#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>
…s from linear memory
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]