Add ECrecover 0x1 precompile and remove the unstable equivalent host
function.

- depend on https://github.com/paritytech/polkadot-sdk/pull/7676

---------

Co-authored-by: cmd[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Co-authored-by: Alexander Theißen <alex.theissen@me.com>

Partly addresses https://github.com/paritytech/polkadot-sdk/issues/6157

The benchmarks measuring the impact of contract sizes on calling or
instantiating a contract were bogus because they needed to be written in
assembly in order to tightly control the basic block size.

This fixes the benchmarks for:
- call_with_code_per_byte
- upload_code
- instantiate_with_code

And adds a new benchmark that accounts for the fact that the interpreter
will always compile whole basic blocks:
- basic_block_compilation

After this PR only the weight we assign to instructions need to be
addressed.

---------

Co-authored-by: cmd[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Co-authored-by: PG Herveou <pgherveou@gmail.com>

This PR is centered around a main fix regarding the base deposit and a
bunch of drive by or related fixtures that make sense to resolve in one
go. It could be broken down more but I am constantly rebasing this PR
and would appreciate getting those fixes in as-one.

**This adds a multi block migration to Westend AssetHub that wipes the
pallet state clean. This is necessary because of the changes to the
`ContractInfo` storage item. It will not delete the child storage
though. This will leave a tiny bit of garbage behind but won't cause any
problems. They will just be orphaned.**

## Record the deposit for immutable data into the `storage_base_deposit`

The `storage_base_deposit` are all the deposit a contract has to pay for
existing. It included the deposit for its own metadata and a deposit
proportional (< 1.0x) to the size of its code. However, the immutable
code size was not recorded there. This would lead to the situation where
on terminate this portion wouldn't be refunded staying locked into the
contract. It would also make the calculation of the deposit changes on
`set_code_hash` more complicated when it updates the immutable data (to
be done in #6985). Reason is because it didn't know how much was payed
before since the storage prices could have changed in the mean time.

In order for this solution to work I needed to delay the deposit
calculation for a new contract for after the contract is done executing
is constructor as only then we know the immutable data size. Before, we
just charged this eagerly in `charge_instantiate` before we execute the
constructor. Now, we merely send the ED as free balance before the
constructor in order to create the account. After the constructor is
done we calculate the contract base deposit and charge it. This will
make `set_code_hash` much easier to implement.

As a side effect it is now legal to call `set_immutable_data` multiple
times per constructor (even though I see no reason to do so). It simply
overrides the immutable data with the new value. The deposit accounting
will be done after the constructor returns (as mentioned above) instead
of when setting the immutable data.

## Don't pre-charge for reading immutable data

I noticed that we were pre-charging weight for the max allowable
immutable data when reading those values and then refunding after read.
This is not necessary as we know its length without reading the storage
as we store it out of band in contract metadata. This makes reading it
free. Less pre-charging less problems.

## Remove delegate locking

Fixes #7092

This is also in the spirit of making #6985 easier to implement. The
locking complicates `set_code_hash` as we might need to block settings
the code hash when locks exist. Check #7092 for further rationale.

## Enforce "no terminate in constructor" eagerly

We used to enforce this rule after the contract execution returned. Now
we error out early in the host call. This makes it easier to be sure to
argue that a contract info still exists (wasn't terminated) when a
constructor successfully returns. All around this his just much simpler
than dealing this check.

## Moved refcount functions to `CodeInfo`

They never really made sense to exist on `Stack`. But now with the
locking gone this makes even less sense. The refcount is stored inside
`CodeInfo` to lets just move them there.

## Set `CodeHashLockupDepositPercent` for test runtime

The test runtime was setting `CodeHashLockupDepositPercent` to zero.
This was trivializing many code paths and excluded them from testing. I
set it to `30%` which is our default value and fixed up all the tests
that broke. This should give us confidence that the lockup doeposit
collections properly works.

## Reworked the `MockExecutable` to have both a `deploy` and a `call`
entry point

This type used for testing could only have either entry points but not
both. In order to fix the `immutable_data_set_overrides` I needed to a
new function `add_both` to `MockExecutable` that allows to have both
entry points. Make sure to make use of it in the future :)

---------

Co-authored-by: command-bot <>
Co-authored-by: cmd[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Co-authored-by: PG Herveou <pgherveou@gmail.com>
Co-authored-by: Bastian Köcher <git@kchr.de>
Co-authored-by: Oliver Tale-Yazdi <oliver.tale-yazdi@parity.io>

This PR changes the behavior of `instantiate` when the resulting
contract address already exists (because the caller tried to instantiate
the same contract with the same salt multiple times): Instead of
trapping the caller, return an error code.

Solidity allows `catch`ing this, which doesn't work if we are trapping
the caller. For example, the change makes the following snippet work:

```Solidity
try new Foo{salt: hex"00"}() returns (Foo) {
    // Instantiation was successful (contract address was free and constructor did not revert)
} catch {
    // This branch is expected to be taken if the instantiation failed because of a duplicate salt
}
```

`revive` PR: https://github.com/paritytech/revive/pull/188

---------

Signed-off-by: Cyrill Leutwiler <bigcyrill@hotmail.com>
Co-authored-by: cmd[bot] <41898282+github-actions[bot]@users.noreply.github.com>

This PR implements the block author API method. Runtimes ought to
implement it such that it corresponds to the `coinbase` EVM opcode.

---------

Signed-off-by: xermicus <cyrill@parity.io>
Signed-off-by: Cyrill Leutwiler <bigcyrill@hotmail.com>
Co-authored-by: command-bot <>
Co-authored-by: Alexander Theißen <alex.theissen@me.com>
Co-authored-by: cmd[bot] <41898282+github-actions[bot]@users.noreply.github.com>

This PR changes how we call runtime API methods with more than 6
arguments: They are no longer spilled to the stack but packed into
registers instead. Pointers are 32 bit wide so we can pack two of them
into a single 64 bit register. Since we mostly pass pointers, this
technique effectively increases the number of arguments we can pass
using the available registers.

To make this work for `instantiate` too we now pass the code hash and
the call data in the same buffer, akin to how the `create` family
opcodes work in the EVM. The code hash is fixed in size, implying the
start of the constructor call data.

---------

Signed-off-by: xermicus <cyrill@parity.io>
Signed-off-by: Cyrill Leutwiler <bigcyrill@hotmail.com>
Co-authored-by: command-bot <>
Co-authored-by: cmd[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Co-authored-by: Alexander Theißen <alex.theissen@me.com>

Closes https://github.com/paritytech/polkadot-sdk/issues/6891.

cc @athei @xermicus @pgherveou

Remove the `debug_buffer` feature

---------

Co-authored-by: command-bot <>
Co-authored-by: Cyrill Leutwiler <cyrill@parity.io>
Co-authored-by: Alexander Theißen <alex.theissen@me.com>

Closes #6846 .

---------

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: xermicus <cyrill@parity.io>

This PR implements the base fee syscall API method. Currently this is
implemented as a compile time constant in the revive compiler, returning
0. However, since this is an opocde, if we ever need to implement it for
compatibility reasons with
[EIP-1559](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-1559.md),
it would break already deployed contracts. Thus we provide a syscall
method instead.

---------

Signed-off-by: xermicus <cyrill@parity.io>
Signed-off-by: Cyrill Leutwiler <bigcyrill@hotmail.com>
Co-authored-by: command-bot <>

This PR implements the EVM gas price syscall API method. Currently this
is a compile time constant in revive, but in the EVM it is an opcode.
Thus we should provide an opcode for this in the pallet.

---------

Signed-off-by: Cyrill Leutwiler <bigcyrill@hotmail.com>
Signed-off-by: xermicus <cyrill@parity.io>
Co-authored-by: command-bot <>

This PR implements the gas limit API, returning the maximum ref_time per
block. Solidity contracts only know a single weight dimension and can
use this method to get the block ref_time limit.

---------

Signed-off-by: Cyrill Leutwiler <bigcyrill@hotmail.com>
Signed-off-by: xermicus <cyrill@parity.io>
Co-authored-by: command-bot <>

Call data, return data and code sizes can never exceed `u32::MAX`; they
are also not generic. Hence we know that they are guaranteed to always
fit into a 64bit register and `revive` can just zero extend them into a
256bit integer value. Which is slightly more efficient than passing them
on the stack.

---------

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>

This PR implements the ref_time_left API method. Solidity knows only a
single "gas" dimension; Solidity contracts will use this to query the
gas left.

---------

Signed-off-by: xermicus <cyrill@parity.io>
Signed-off-by: Cyrill Leutwiler <bigcyrill@hotmail.com>
Co-authored-by: command-bot <>

This PR implements the call data copy API by adjusting the input method.

Closes #6770

---------

Signed-off-by: xermicus <cyrill@parity.io>
Co-authored-by: command-bot <>

Follow up refactor to
https://github.com/paritytech/polkadot-sdk/pull/6844#pullrequestreview-2497225717

I still need to finish adding `#[cfg(feature = "unstable-api")]` to the
rest of the tests and make sure all tests pass, I want to make sure I'm
moving into right direction first

@athei @xermicus



---------

Co-authored-by: DavidK <davidk@parity.io>
Co-authored-by: Alexander Theißen <alex.theissen@me.com>

This PR adds an API method to query the contract call data input size.

Part of #6770

---------

Signed-off-by: Cyrill Leutwiler <bigcyrill@hotmail.com>
Co-authored-by: command-bot <>
Co-authored-by: Alexander Theißen <alex.theissen@me.com>

Resolves https://github.com/paritytech/polkadot-sdk/issues/6720

List of used host functions in PolkaVM recompiler is here
https://github.com/paritytech/revive/blob/main/crates/runtime-api/src/polkavm_imports.c#L65

---------

Co-authored-by: DavidK <davidk@parity.io>

This PR implements the call data load API akin to [how it works on
ethereum](https://www.evm.codes/?fork=cancun#35).

There will also be a second PR to adjust the input function to resemble
the call data copy opcode on EVM.

---------

Signed-off-by: Cyrill Leutwiler <bigcyrill@hotmail.com>
Co-authored-by: command-bot <>

Previously, we failed at runtime if an unknown or unstable host function
was called. This requires us to keep track of when a host function was
added and when a code was deployed. We used the `api_version` to track
at which API version each code was deployed. This made sure that when a
new host function was added that old code won't have access to it. This
is necessary as otherwise the behavior of a contract that made calls to
this previously non existent host function would change from "trap" to
"do something".

In this PR we remove the API version. Instead, we statically verify on
upload that no non-existent host function is ever used in the code. This
will allow us to add new host function later without needing to keep
track when they were added.

This simplifies the code and also gives an immediate feedback if unknown
host functions are used.

---------

Co-authored-by: GitHub Action <action@github.com>

We were trapping the host context in case a sub call was exhausting the
storage deposit limit set for this sub call. This prevents the caller
from handling this error. In this PR we added a new error code that is
returned when either gas or storage deposit limit is exhausted by the
sub call.

We also remove the longer used `NotCallable` error. No longer used
because this is no longer an error: It will just be a balance transfer.

We also make `set_code_hash` infallible to be consistent with other host
functions which just trap on any error condition.

---------

Co-authored-by: GitHub Action <action@github.com>

This PR updates pallet_revive to the newest PolkaVM version and adapts
the test fixtures and syscall interface to work under 64bit.

Please note that after this PR no 32bit contracts can be deployed (they
will be rejected at deploy time). Pre-deployed 32bit contracts are now
considered defunct since we changes how parameters are passed for
functions with more than 6 arguments.

## Fixtures

The fixtures are now built for the 64bit target. I also removed the
temporary directory mechanism that triggered a full rebuild every time.
It also makes it easier to find the compiled fixtures since they are now
always in `target/pallet-revive-fixtures`.

## Syscall interface

### Passing pointer

Registers and pointers are now 64bit wide. This allows us to pass u64
arguments in a single register. Before we needed two registers to pass
them. This means that just as before we need one register per pointer we
pass. We keep pointers as `u32` argument by truncating the register.
This is done since the memory space of PolkaVM is 32bit.

### Functions with more than 6 arguments

We only have 6 registers to pass arguments. This is why we pass a
pointer to a struct when we need more than 6. Before this PR we expected
a packed struct and interpreted it as SCALE encoded tuple. However, this
was buggy because the `MaxEncodedLen` returned something that was larger
than the packed size of the structure. This wasn't a problem before. But
now the memory space changed in a way that things were placed at the
edges of the memory space and those extra bytes lead to an out of bound
access.

This is why this PR drops SCALE and expects the arguments to be passed
as a pointer to a `C` aligned struct. This avoids unaligned accesses.
However, revive needs to adapt its codegen to properly align the
structure fields.

## TODO
- [ ] Add multi block migration that wipes all existing contracts as we
made breaking changes to the syscall interface

---------

Co-authored-by: GitHub Action <action@github.com>

Enhance the `delegate_call` function to accept an `address` target
parameter instead of a `code_hash`. This allows direct identification of
the target contract using the provided address.
Additionally, introduce parameters for specifying a customizable
`ref_time` limit and `proof_size` limit, thereby improving flexibility
and control during contract interactions.

---------

Co-authored-by: Alexander Theißen <alex.theissen@me.com>

This PR removes the `transfer` syscall and changes balance transfers to
make the existential deposit (ED) fully transparent for contracts.

The `transfer` API is removed since there is no corresponding EVM opcode
and transferring via a call introduces barely any overhead.

We make the ED transparent to contracts by transferring the ED from the
call origin to nonexistent accounts. Without this change, transfers to
nonexistant accounts will transfer the supplied value minus the ED from
the contracts viewpoint, and consequentially fail if the supplied value
lies below the ED. Changing this behavior removes the need for contract
code to handle this rather annoying corner case and aligns better with
the EVM. The EVM charges a similar deposit from the gas meter, so
transferring the ED from the call origin is practically the same as the
call origin pays for gas.

---------

Signed-off-by: xermicus <cyrill@parity.io>
Signed-off-by: Cyrill Leutwiler <bigcyrill@hotmail.com>
Co-authored-by: command-bot <>
Co-authored-by: GitHub Action <action@github.com>
Co-authored-by: PG Herveou <pgherveou@gmail.com>

- Bound T::Hash to H256
- Implement the block hash API

---------

Signed-off-by: xermicus <cyrill@parity.io>
Signed-off-by: Cyrill Leutwiler <bigcyrill@hotmail.com>
Co-authored-by: command-bot <>
Co-authored-by: GitHub Action <action@github.com>

This PR implements the contract API to query the code size of a given
address.

---------

Signed-off-by: Cyrill Leutwiler <bigcyrill@hotmail.com>
Signed-off-by: xermicus <cyrill@parity.io>
Co-authored-by: GitHub Action <action@github.com>
Co-authored-by: command-bot <>
Co-authored-by: PG Herveou <pgherveou@gmail.com>

Implement a syscall to retreive the transaction origin.

---------

Signed-off-by: Cyrill Leutwiler <bigcyrill@hotmail.com>
Signed-off-by: xermicus <cyrill@parity.io>
Co-authored-by: GitHub Action <action@github.com>
Co-authored-by: command-bot <>
Co-authored-by: Alexander Theißen <alex.theissen@me.com>

This PR introduces the necessary changes to pallet-revive for
integrating with our Ethereum JSON-RPC.
The RPC proxy itself will be added in a follow up.

## Changes

- A new pallet::call `Call::eth_transact`. This is used as a wrapper to
accept unsigned Ethereum transaction, valid call will be routed to
`Call::call` or `Call::instantiate_with_code`

- A custom UncheckedExtrinsic struct, that wraps the generic one usually
and add the ability to check eth_transact calls sent from an Ethereum
JSON-RPC proxy.
- Generated types and traits to support implementing a JSON-RPC Ethereum
proxy.

## Flow Overview:
- A user submits a transaction via MetaMask or another
Ethereum-compatible wallet.
- The proxy dry run the transaction and add metadata to the call (gas
limit in Weight, storage deposit limit, and length of bytecode and
constructor input for contract instantiation)
- The raw transaction, along with the additional metadata, is submitted
to the node as an unsigned extrinsic.
- On the runtime, our custom UncheckedExtrinsic define a custom
Checkable implementation that converts the unsigned extrinsics into
checked one
 - It recovers the signer
- validates the payload, and injects signed extensions, allowing the
system to increment the nonce and charge the appropriate fees.
- re-route the call to pallet-revive::Call::call or
pallet-revive::Call::instantiateWithCode

## Dependencies

- https://github.com/koute/polkavm/pull/188

## Follow up PRs
- #5926  
- #6147 (previously #5953)
- #5502

---------

Co-authored-by: Alexander Theißen <alex.theissen@me.com>
Co-authored-by: Cyrill Leutwiler <cyrill@parity.io>

Original PR https://github.com/paritytech/polkadot-sdk/pull/2280
reverted in https://github.com/paritytech/polkadot-sdk/pull/3665

This PR reintroduces the reverted functionality with additional changes,
related effort
[here](https://github.com/paritytech/polkadot-sdk/pull/3623).
Description is copied over from the original PR

First part of [Extrinsic
Horizon](https://github.com/paritytech/polkadot-sdk/issues/2415)

Introduces a new trait `TransactionExtension` to replace
`SignedExtension`. Introduce the idea of transactions which obey the
runtime's extensions and have according Extension data (né Extra data)
yet do not have hard-coded signatures.

Deprecate the terminology of "Unsigned" when used for
transactions/extrinsics owing to there now being "proper" unsigned
transactions which obey the extension framework and "old-style" unsigned
which do not. Instead we have __*General*__ for the former and
__*Bare*__ for the latter. (Ultimately, the latter will be phased out as
a type of transaction, and Bare will only be used for Inherents.)

Types of extrinsic are now therefore:
- Bare (no hardcoded signature, no Extra data; used to be known as
"Unsigned")
- Bare transactions (deprecated): Gossiped, validated with
`ValidateUnsigned` (deprecated) and the `_bare_compat` bits of
`TransactionExtension` (deprecated).
  - Inherents: Not gossiped, validated with `ProvideInherent`.
- Extended (Extra data): Gossiped, validated via `TransactionExtension`.
  - Signed transactions (with a hardcoded signature) in extrinsic v4.
- General transactions (without a hardcoded signature) in extrinsic v5.

`TransactionExtension` differs from `SignedExtension` because:
- A signature on the underlying transaction may validly not be present.
- It may alter the origin during validation.
- `pre_dispatch` is renamed to `prepare` and need not contain the checks
present in `validate`.
- `validate` and `prepare` is passed an `Origin` rather than a
`AccountId`.
- `validate` may pass arbitrary information into `prepare` via a new
user-specifiable type `Val`.
- `AdditionalSigned`/`additional_signed` is renamed to
`Implicit`/`implicit`. It is encoded *for the entire transaction* and
passed in to each extension as a new argument to `validate`. This
facilitates the ability of extensions to acts as underlying crypto.

There is a new `DispatchTransaction` trait which contains only default
function impls and is impl'ed for any `TransactionExtension` impler. It
provides several utility functions which reduce some of the tedium from
using `TransactionExtension` (indeed, none of its regular functions
should now need to be called directly).

Three transaction version discriminator ("versions") are now permissible
(RFC [here](https://github.com/polkadot-fellows/RFCs/pull/84)) in
extrinsic version 5:
- 0b00000100 or 0b00000101: Bare (used to be called "Unsigned"):
contains Signature or Extra (extension data). After bare transactions
are no longer supported, this will strictly identify an Inherents only.
Available in both extrinsic versions 4 and 5.
- 0b10000100: Old-school "Signed" Transaction: contains Signature, Extra
(extension data) and an extension version byte, introduced as part of
[RFC99](https://github.com/polkadot-fellows/RFCs/blob/main/text/0099-transaction-extension-version.md).
Still available as part of extrinsic v4.
- 0b01000101: New-school "General" Transaction: contains Extra
(extension data) and an extension version byte, as per RFC99, but no
Signature. Only available in extrinsic v5.

For the New-school General Transaction, it becomes trivial for authors
to publish extensions to the mechanism for authorizing an Origin, e.g.
through new kinds of key-signing schemes, ZK proofs, pallet state,
mutations over pre-authenticated origins or any combination of the
above.

`UncheckedExtrinsic` still maintains encode/decode backwards
compatibility with extrinsic version 4, where the first byte was encoded
as:
- 0b00000100 - Unsigned transactions
- 0b10000100 - Old-school Signed transactions, without the extension
version byte

Now, `UncheckedExtrinsic` contains a `Preamble` and the actual call. The
`Preamble` describes the type of extrinsic as follows:
```rust
/// A "header" for extrinsics leading up to the call itself. Determines the type of extrinsic and
/// holds any necessary specialized data.
#[derive(Eq, PartialEq, Clone)]
pub enum Preamble<Address, Signature, Extension> {
	/// An extrinsic without a signature or any extension. This means it's either an inherent or
	/// an old-school "Unsigned" (we don't use that terminology any more since it's confusable with
	/// the general transaction which is without a signature but does have an extension).
	///
	/// NOTE: In the future, once we remove `ValidateUnsigned`, this will only serve Inherent
	/// extrinsics and thus can be renamed to `Inherent`.
	Bare(ExtrinsicVersion),
	/// An old-school transaction extrinsic which includes a signature of some hard-coded crypto.
	/// Available only on extrinsic version 4.
	Signed(Address, Signature, ExtensionVersion, Extension),
	/// A new-school transaction extrinsic which does not include a signature by default. The
	/// origin authorization, through signatures or other means, is performed by the transaction
	/// extension in this extrinsic. Available starting with extrinsic version 5.
	General(ExtensionVersion, Extension),
}
```

## Code Migration

### NOW: Getting it to build

Wrap your `SignedExtension`s in `AsTransactionExtension`. This should be
accompanied by renaming your aggregate type in line with the new
terminology. E.g. Before:

```rust
/// The SignedExtension to the basic transaction logic.
pub type SignedExtra = (
	/* snip */
	MySpecialSignedExtension,
);
/// Unchecked extrinsic type as expected by this runtime.
pub type UncheckedExtrinsic =
	generic::UncheckedExtrinsic<Address, RuntimeCall, Signature, SignedExtra>;
```

After:

```rust
/// The extension to the basic transaction logic.
pub type TxExtension = (
	/* snip */
	AsTransactionExtension<MySpecialSignedExtension>,
);
/// Unchecked extrinsic type as expected by this runtime.
pub type UncheckedExtrinsic =
	generic::UncheckedExtrinsic<Address, RuntimeCall, Signature, TxExtension>;
```

You'll also need to alter any transaction building logic to add a
`.into()` to make the conversion happen. E.g. Before:

```rust
fn construct_extrinsic(
		/* snip */
) -> UncheckedExtrinsic {
	let extra: SignedExtra = (
		/* snip */
		MySpecialSignedExtension::new(/* snip */),
	);
	let payload = SignedPayload::new(call.clone(), extra.clone()).unwrap();
	let signature = payload.using_encoded(|e| sender.sign(e));
	UncheckedExtrinsic::new_signed(
		/* snip */
		Signature::Sr25519(signature),
		extra,
	)
}
```

After:

```rust
fn construct_extrinsic(
		/* snip */
) -> UncheckedExtrinsic {
	let tx_ext: TxExtension = (
		/* snip */
		MySpecialSignedExtension::new(/* snip */).into(),
	);
	let payload = SignedPayload::new(call.clone(), tx_ext.clone()).unwrap();
	let signature = payload.using_encoded(|e| sender.sign(e));
	UncheckedExtrinsic::new_signed(
		/* snip */
		Signature::Sr25519(signature),
		tx_ext,
	)
}
```

### SOON: Migrating to `TransactionExtension`

Most `SignedExtension`s can be trivially converted to become a
`TransactionExtension`. There are a few things to know.

- Instead of a single trait like `SignedExtension`, you should now
implement two traits individually: `TransactionExtensionBase` and
`TransactionExtension`.
- Weights are now a thing and must be provided via the new function `fn
weight`.

#### `TransactionExtensionBase`

This trait takes care of anything which is not dependent on types
specific to your runtime, most notably `Call`.

- `AdditionalSigned`/`additional_signed` is renamed to
`Implicit`/`implicit`.
- Weight must be returned by implementing the `weight` function. If your
extension is associated with a pallet, you'll probably want to do this
via the pallet's existing benchmarking infrastructure.

#### `TransactionExtension`

Generally:
- `pre_dispatch` is now `prepare` and you *should not reexecute the
`validate` functionality in there*!
- You don't get an account ID any more; you get an origin instead. If
you need to presume an account ID, then you can use the trait function
`AsSystemOriginSigner::as_system_origin_signer`.
- You get an additional ticket, similar to `Pre`, called `Val`. This
defines data which is passed from `validate` into `prepare`. This is
important since you should not be duplicating logic from `validate` to
`prepare`, you need a way of passing your working from the former into
the latter. This is it.
- This trait takes a `Call` type parameter. `Call` is the runtime call
type which used to be an associated type; you can just move it to become
a type parameter for your trait impl.
- There's no `AccountId` associated type any more. Just remove it.

Regarding `validate`:
- You get three new parameters in `validate`; all can be ignored when
migrating from `SignedExtension`.
- `validate` returns a tuple on success; the second item in the tuple is
the new ticket type `Self::Val` which gets passed in to `prepare`. If
you use any information extracted during `validate` (off-chain and
on-chain, non-mutating) in `prepare` (on-chain, mutating) then you can
pass it through with this. For the tuple's last item, just return the
`origin` argument.

Regarding `prepare`:
- This is renamed from `pre_dispatch`, but there is one change:
- FUNCTIONALITY TO VALIDATE THE TRANSACTION NEED NOT BE DUPLICATED FROM
`validate`!!
- (This is different to `SignedExtension` which was required to run the
same checks in `pre_dispatch` as in `validate`.)

Regarding `post_dispatch`:
- Since there are no unsigned transactions handled by
`TransactionExtension`, `Pre` is always defined, so the first parameter
is `Self::Pre` rather than `Option<Self::Pre>`.

If you make use of `SignedExtension::validate_unsigned` or
`SignedExtension::pre_dispatch_unsigned`, then:
- Just use the regular versions of these functions instead.
- Have your logic execute in the case that the `origin` is `None`.
- Ensure your transaction creation logic creates a General Transaction
rather than a Bare Transaction; this means having to include all
`TransactionExtension`s' data.
- `ValidateUnsigned` can still be used (for now) if you need to be able
to construct transactions which contain none of the extension data,
however these will be phased out in stage 2 of the Transactions Horizon,
so you should consider moving to an extension-centric design.

---------

Signed-off-by: georgepisaltu <george.pisaltu@parity.io>
Co-authored-by: Guillaume Thiolliere <gui.thiolliere@gmail.com>
Co-authored-by: Branislav Kontur <bkontur@gmail.com>

# 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

This bumps `ethbloom`, `ethereum-types`, `primitive-types` and `rlp` to
their latest version.

Fixes: https://github.com/paritytech/polkadot-sdk/issues/5870

---------

Co-authored-by: command-bot <>
Co-authored-by: ggwpez <ggwpez@users.noreply.github.com>
Co-authored-by: Oliver Tale-Yazdi <oliver.tale-yazdi@parity.io>
Co-authored-by: Shawn Tabrizi <shawntabrizi@gmail.com>
Co-authored-by: Dónal Murray <donal.murray@parity.io>

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>

- update baseline for pallet_revive
- update cmd pipeline name
- Fix compilation after renaming some of benchmarks in pallet_revive.
[Runtime Dev]. Changed the "instr" benchmark so that it should no longer
return to little weight. It is still bogus but at least benchmarking
should not work. (by @athei

 )

---------

Co-authored-by: GitHub Action <action@github.com>
Co-authored-by: Alexander Theißen <alex.theissen@me.com>
Co-authored-by: Alexander Samusev <41779041+alvicsam@users.noreply.github.com>
Co-authored-by: command-bot <>

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>

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 <>

Instead of error out if the provided output buffer is smaller than what
we want to write, we can just write what fits into the output buffer
instead. We already write back the actual bytes written to the in-out
pointer, so contracts can check it anyways.

This in turn introduces the benefit of allowing contracts to implicitly
request only a portion of the returned data from calls and incantations.
Which is especially beneficial for YUL as the `call` family opcodes have
a return data size argument and this change removes the need to work
around it in contract code.

---------

Signed-off-by: xermicus <cyrill@parity.io>

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 <>

fix https://github.com/paritytech/polkadot-sdk/issues/5683

Fixes #5577 

I decided to bubble up the error from where we actually try to load the
contract info. This helps to make sure that we don't miss some entry
point by accident. The draw back is that we have to live with some
additional `.expect`.

@pgherveou

 With this logic the proxy and its runtime part should be
completely unaware whether something is a contract call or a balance
transfer. They should just route everything into pallet_revive.

---------

Co-authored-by: Cyrill Leutwiler <cyrill@parity.io>