Merged
Conversation
Fix seal_call benchmark, ensure that the benchmarked block actually succeed --------- Co-authored-by: cmd[bot] <41898282+github-actions[bot]@users.noreply.github.com>
The latest XCM version is 5. A lot of parachains are still running V3 or V4 which is why we haven't removed them, but the XCM precompile is new and should only have to deal with versions 5 and onwards. No need to keep dragging 3 and 4 in contracts.
On Ethereum, 1 ETH is represented as 10^18 wei (wei being the smallest unit). On Polkadot 1 DOT is defined as 1010 plancks. It means that any value smaller than 10^8 wei can not be expressed with the native balance. Any contract that attempts to use such a value currently reverts with a DecimalPrecisionLoss error. In theory, RPC can define a decimal representation different from Ethereum mainnet (10^18). In practice tools (frontend libraries, wallets, and compilers) ignore it and expect 18 decimals. The current behaviour breaks eth compatibility and needs to be updated. See issue #109 for more details. Fix paritytech/contract-issues#109 [weights compare](https://weights.tasty.limo/compare?unit=weight&ignore_errors=true&threshold=10&method=asymptotic&repo=polkadot-sdk&old=master&new=pg/eth-decimals&path_pattern=substrate/frame/**/src/weights.rs,polkadot/runtime/*/src/weights/**/*.rs,polkadot/bridges/modules/*/src/weights.rs,cumulus/**/weights/*.rs,cumulus/**/weights/xcm/*.rs,cumulus/**/src/weights.rs) --------- Co-authored-by: cmd[bot] <41898282+github-actions[bot]@users.noreply.github.com> Co-authored-by: Alexander Theißen <[email protected]> Co-authored-by: Oliver Tale-Yazdi <[email protected]>
The existential deposit to create a new account is part of the storage deposit. Hence if the storage deposit limit is too low to create a new account we fail the transaction. However, this limit was not enforced for plain transfers. The reason is that we only enforce the limit at the end of each frame. But for plain transfers (transferring to a non contract) there is no frame. This PR fixes the situation by enforcing the limit when transferring the existential deposit in order to create a new account. --------- Co-authored-by: PG Herveou <[email protected]> Co-authored-by: cmd[bot] <41898282+github-actions[bot]@users.noreply.github.com>
fix issue: paritytech/contract-issues#141 Corrects the condition for minting a new currency unit when transferring dust. The condition was incorrectly checking `to_info.dust.saturating_add(dust) >= plank` which could lead to unexpected minting behavior. It now correctly checks if `to_info.dust >= plank` before minting.
…_blake2_256` into it (#9441) Part of closing #8572. Just the `hash_blake2_256` in this PR, to gauge if you're fine with this setup. cc @athei @pgherveou --------- Co-authored-by: Alexander Theißen <[email protected]>
…ll depth to 25 (#9267) This PR changes the contract code limit from roughly 100KiB to exactly 1MiB. It also raises the call stack depth from 5 to 25. Those limits were in place because of memory constraints within the runtime. We work around them in those ways: 1) Removing the 4x safety margin for allocations which is no longer needed due to the new allocator. 2) Limiting the size of the compilation cache to a fixed size. 3) Resetting the compilation cache and flat map every time we call into a new contract. 4) Limiting the size of calldata and return data to 128KiB (only capped by tx size and RAM before). While this is a breaking change nobody will be affected since Geth effectively limits the call data to 128KiB. This is large enough so that all known contracts won't fail for size issues anymore. The new limit is also much simpler to understand since it does not depend on the number of instructions. Just those two constraints: ``` PVM_BLOB.len() < 1 MiB PVM_BLOB.len() + (rw/ro/stack) < 1MiB + 512KiB ``` This means: 1) A contract is guaranteed to have at least 512KiB of memory available. 2) A contract that is smaller in code can use more memory. 3) Limit is exactly 1MiB unless a user manually increase the memory usage of a contract to be larger than 512KiB. The limit of `5` was problematic because there are use cases which require deeper stacks. With the raise to `25` there should be no benign use cases anymore that won't work. Please note that even with the low limit of `25` contracts are not vulnerable to stack depth exhaustion attacks: We do trap the caller's context when the depth limit is reached. This is different from Eth where this error can be handled and failure to do so leaves the contract vulnerable. --------- Co-authored-by: cmd[bot] <41898282+github-actions[bot]@users.noreply.github.com>
acatangiu
added
the
T7-smart_contracts
acatangiu
approved these changes
Aug 14, 2025
Contributor
acatangiu
left a comment
acatangiu
left a comment
There was a problem hiding this comment.
Did not review substrate/frame/revive code changes, someone from contracts team make sure to review.
Everything else LGTM!
pgherveou
approved these changes
Aug 15, 2025
This was referenced Aug 15, 2025
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
6 participants
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.
Systempre-compile, moveseal_hash_blake2_256into it #9441Those are all the changes we want to get onto the next Kusama release. The new gas mapping and EVM backend will not make it.