- Oct 18, 2024
-
-
Ermal Kaleci authored
# Description Update `ext_code_hash` to match [EIP-1052](https://eips.ethereum.org/EIPS/eip-1052) specs. Since all possible results are written into output pointer then there's no need for a return value. https://github.com/paritytech/revive/pull/77
-
- Oct 05, 2024
-
-
Cyrill Leutwiler authored
This PR introduces the concept of immutable storage data, used for [Solidity immutable variables](https://docs.soliditylang.org/en/latest/contracts.html#immutable). This is a minimal implementation. Immutable data is attached to a contract; to keep `ContractInfo` fixed in size, we only store the length there, and store the immutable data in a dedicated storage map instead. Which comes at the cost of requiring an additional storage read (costly) for contracts using this feature. We discussed more optimal solutions not requiring any additional storage accesses internally, but they turned out to be non-trivial to implement. Another optimization benefiting multiple calls to the same contract in a single call stack would be to cache the immutable data in `Stack`. However, this potential creates a DOS vulnerability (the attack vector is to call into as many contracts in a single stack as possible, where they all have maximum immutable data to fill the cache as efficiently as possible). So this either has to be guaranteed to be a non-issue by limits, or, more likely, to have some logic to bound the cache. Eventually, we should think about introducing the concept of warm and cold storage reads (akin to EVM). Since immutable variables are commonly used in contracts, this change is blocking our initial launch and we should only optimize it properly in follow-ups. This PR also disables the `set_code_hash` API (which isn't usable for Solidity contracts without pre-compiles anyways). With immutable storage attached to contracts, we now want to run the constructor of the new code hash to collect the immutable data during `set_code_hash`. This will be implemented in a follow up PR. --------- Signed-off-by:
Cyrill Leutwiler <bigcyrill@hotmail.com> Signed-off-by:
xermicus <cyrill@parity.io> Co-authored-by: command-bot <> Co-authored-by:
Alexander Theißen <alex.theissen@me.com> Co-authored-by:
PG Herveou <pgherveou@gmail.com>
-
- Sep 25, 2024
-
-
Cyrill Leutwiler authored
This PR introduces 2 new syscalls: `return_data_size` and `return_data_copy`, resembling the semantics of the EVM `RETURNDATASIZE` and `RETURNDATACOPY` opcodes. The ownership of `ExecReturnValue` (the return data) has moved to the `Frame`. This allows implementing the new contract API functionality in ext with no additional copies. Returned data is passed via contract memory, memory is (will be) metered, hence the amount of returned data can not be statically known, so we should avoid storing copies of the returned data if we can. By moving the ownership of the exectuables return value into the `Frame` struct we achieve this. A zero-copy implementation of those APIs would be technically possible without that internal change by making the callsite in the runtime responsible for moving the returned data into the frame after any call. However, resetting the stored output needs to be handled in ext, since plain transfers will _not_ affect the stored return data (and we don't want to handle this special call case inside the `runtime` API). This has drawbacks: - It can not be tested easily in the mock. - It introduces an inconsistency where resetting the stored output is handled in ext, but the runtime API is responsible to store it back correctly after any calls made. Instead, with ownership of the data in `Frame`, both can be handled in a single place. Handling both in `fn run()` is more natural and leaves less room for runtime API bugs. The returned output is reset each time _before_ running any executable in a nested stack. This change should not incur any overhead to the overall memory usage as _only_ the returned data from the last executed frame will be kept around at any time. --------- Signed-off-by:
Cyrill Leutwiler <bigcyrill@hotmail.com> Signed-off-by:
xermicus <cyrill@parity.io> Co-authored-by: command-bot <> Co-authored-by:
PG Herveou <pgherveou@gmail.com>
-
- Sep 23, 2024
-
-
Cyrill Leutwiler authored
This PR adds the EVM chain ID to Config as well as a corresponding runtime API so contracts can query it. Related issue: https://github.com/paritytech/revive/issues/44 --------- Signed-off-by:
xermicus <cyrill@parity.io> Co-authored-by: command-bot <>
-
- Sep 13, 2024
-
-
Cyrill Leutwiler authored
The salt argument should be optional to allow create1 equivalent calls. --------- Signed-off-by:
xermicus <cyrill@parity.io>
-
Cyrill Leutwiler authored
This adds an API method `balance_of`, corresponding to the [BALANCE](https://www.evm.codes/#31?fork=cancun) EVM opcode. In `Ext`, `balance` and `balance_of` are internally routed through the same new `account_balance` method: `balance` is technically the same as `balance_of` with the caller address. This avoids duplicating all the tests and avoids a small inefficiency (in theory, `balance` directly call `balance_of` however this introduces a round trip of converting the target address to a H160 and back). --------- Signed-off-by:
Cyrill Leutwiler <bigcyrill@hotmail.com> Signed-off-by:
xermicus <cyrill@parity.io> Co-authored-by: command-bot <>
-
- Sep 08, 2024
-
-
PG Herveou authored
fix #5574 - Use U256 instead of BalanceOf<T> and MomentOf<T> in Ext trait - Enforce H256 for T::Hash The Ext trait still depends on the associated type `T: Config`, we can look into refactoring it even more later but even in the current state it should not influence how the data is encoded / decoded between the contract and the host ``` fn caller(&self) -> Origin<Self::T>; -> only use to extract the address of the caller fn account_id(&self) -> &AccountIdOf<Self::T>; -> only used to expose the address or access the account_id internally fn gas_meter(&self) -> &GasMeter<Self::T>; fn gas_meter_mut(&mut self) -> &mut GasMeter<Self::T>; -> encoding does not depend on T fn call_runtime(&self, call: <Self::T as Config>::RuntimeCall) -> DispatchResultWithPostInfo; -> Substrate specific, just an opaque blob of bytes from the contract's perspective fn contract_info(&mut self) -> &mut ContractInfo<Self::T>; fn transient_storage(&mut self) -> &mut TransientStorage<Self::T>; -> gated by #[cfg(any(test, feature = "runtime-benchmarks"))] ``` --------- Co-authored-by:
Alexander Theißen <alex.theissen@me.com>
-
- Sep 05, 2024
-
-
PG Herveou authored
start using better type for address, code_hash, and salt in runtime and the uapi crate fix https://github.com/paritytech/polkadot-sdk/issues/5575
-
- Aug 23, 2024
-
-
Alexander Theißen authored
This is a heavily modified and stripped down version of `pallet_contracts`. We decided to fork instead of extend the old pallet. Reasons for that are: - There is no benefit of supporting both on the same pallet as the intended payload for the new pallet (recompiled YUL) will be using a different ABI. - It is much easier since it allows us to remove all the code that was necessary to support Wasm and focus fully on running cross compiled YUL contracts. **The code is reviewable but can't be merged because it depends on an unreleased version of PolkaVM via git.** ## Current state All tests are passing and the code is not quick and dirty but written to last. The work is not finished, though. It is included in the `kitchensink-runtime` and a node can be built. However, we merge early in order to be able to start testing other components as early as possible. Outstanding changes are tracked here and will be merged separately: https://github.com/paritytech/polk...
-
- Jul 16, 2024
-
-
Sebastian Miasojed authored
Introduce transient storage, which behaves identically to regular storage but is kept only in memory and discarded after every transaction. This functionality is similar to the `TSTORE` and `TLOAD` operations used in Ethereum. The following new host functions have been introduced: `get_transient_storage` `set_transient_storage` `take_transient_storage` `clear_transient_storage` `contains_transient_storage` Note: These functions are declared as `unstable` and thus are not activated. --------- Co-authored-by: command-bot <> Co-authored-by:
PG Herveou <pgherveou@gmail.com> Co-authored-by:
Alexander Theißen <alex.theissen@me.com>
-
- Apr 24, 2024
-
-
Francisco Aguirre authored
Revert "pallet-xcm: Deprecate `execute` and `send` in favor of `execute_blob` and `send_blob` (#3749)" This reverts commit feee773d . --------- Co-authored-by:
Adrian Catangiu <adrian@parity.io> Co-authored-by:
Javier Bullrich <javier@bullrich.dev>
-
- Mar 27, 2024
-
-
Francisco Aguirre authored
`execute` and `send` try to decode the xcm in the parameters before reaching the filter line. The new extrinsics decode only after the filter line. These should be used instead of the old ones. ## TODO - [x] Tests - [x] Generate weights - [x] Deprecation issue -> https://github.com/paritytech/polkadot-sdk/issues/3771 - [x] PRDoc - [x] Handle error in pallet-contracts This would make writing XCMs in PJS Apps more difficult, but here's the fix for that: https://github.com/polkadot-js/apps/pull/10350. Already deployed! https://polkadot.js.org/apps/#/utilities/xcm Supersedes https://github.com/paritytech/polkadot-sdk/pull/1798/ --------- Co-authored-by:
PG Herveou <pgherveou@gmail.com> Co-authored-by: command-bot <> Co-authored-by:
Adrian Catangiu <adrian@parity.io>
-
- Mar 04, 2024
-
-
PG Herveou authored
-
- Feb 20, 2024
-
-
PG Herveou authored
Remove `#[unstable]` on `call_v2`, `instantiate_v2`, `lock_delegate_dependency` and `unlock_delegate_dependency`. See ink! integrations: - call_v2: https://github.com/paritytech/ink/pull/2077 - instantiate_v2: <TODO> - lock/unlock dependency: https://github.com/paritytech/ink/pull/2076
-
- Feb 19, 2024
-
-
PG Herveou authored
## Xcm changes: - Fix `pallet_xcm::execute`, move the logic into The `ExecuteController` so it can be shared with anything that implement that trait. - Make `ExecuteController::execute` retursn `DispatchErrorWithPostInfo` instead of `DispatchError`, so that we don't charge the full `max_weight` provided if the execution is incomplete (useful for force_batch or contracts calls) - Fix docstring for `pallet_xcm::execute`, to reflect the changes from #2405 - Update the signature for `ExecuteController::execute`, we don't need to return the `Outcome` anymore since we only care about `Outcome::Complete` ## Contracts changes: - Update host fn `xcm_exexute`, we don't need to write the `Outcome` to the sandbox memory anymore. This was also not charged as well before so it if fixes this too. - One of the issue was that the dry_run of a contract that call `xcm_execute` would exhaust the `gas_limit`. This is because `XcmExecuteController::execute` takes a `max_weight` argument, and since we don't want the user to specify it manually we were passing everything left by pre-charghing `ctx.ext.gas_meter().gas_left()` - To fix it I added a `fn influence_lowest_limit` on the `Token` trait and make it return false for `RuntimeCost::XcmExecute`. - Got rid of the `RuntimeToken` indirection, we can just use `RuntimeCost` directly. --------- Co-authored-by: command-bot <>
-
- Feb 03, 2024
-
-
Cyrill Leutwiler authored
Can this API be marked stable? Implemented in [solang here](https://github.com/hyperledger/solang/pull/1620) --------- Signed-off-by:
Cyrill Leutwiler <bigcyrill@hotmail.com>
-
- Jan 12, 2024
-
-
PG Herveou authored
- Translate all pallet-contracts fixtures from `wat` to Rust files. - Fix read_sandbox_memory_as to not use MaxEncodedLen as this could break if used with types with a non-fixed encoded len. --------- Co-authored-by:
alvicsam <alvicsam@gmail.com> Co-authored-by:
Alexander Samusev <41779041+alvicsam@users.noreply.github.com> Co-authored-by:
Alexander Theißen <alex.theissen@me.com> Co-authored-by: command-bot <>
-
- Jan 04, 2024
-
-
PG Herveou authored
Follow up from #2347 this time to verify that fixtures build to RISC-V --------- Co-authored-by:
alvicsam <alvicsam@gmail.com> Co-authored-by:
Alexander Samusev <41779041+alvicsam@users.noreply.github.com> Co-authored-by:
Alexander Theißen <alex.theissen@me.com>
-
- Nov 29, 2023
-
-
PG Herveou authored
see #2189 This PR does the following: - Bring the user api functions into a new pallet-contracts-uapi (They are currently defined in ink! [here])(https://github.com/paritytech/ink/blob/master/crates/env/src/engine/on_chain/ext.rs) - Add older api versions and unstable to the user api trait. - Remove pallet-contracts-primitives and bring the types it defined in uapi / pallet-contracts - Add the infrastructure to build fixtures from Rust files and test it works by replacing `dummy.wat` and `call.wat` - Move all the doc from wasm/runtime.rs to pallet-contracts-uapi. This will be done in a follow up: - convert the rest of the test from .wat to rust - bring risc-v uapi up to date with wasm - finalize the uapi host fns, making sure everything is codegen from the source host fns in pallet-contracts --------- Co-authored-by:
Alexander Theißen <alex.theissen@me.com>
-