Skip to content
Snippets Groups Projects
  1. Feb 04, 2025
    • Alexander Theißen's avatar
      revive: Include immutable storage deposit into the contracts `storage_base_deposit` (#7230) · 4c28354b
      Alexander Theißen authored
      
      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: default avatarcmd[bot] <41898282+github-actions[bot]@users.noreply.github.com>
      Co-authored-by: default avatarPG Herveou <pgherveou@gmail.com>
      Co-authored-by: default avatarBastian Köcher <git@kchr.de>
      Co-authored-by: default avatarOliver Tale-Yazdi <oliver.tale-yazdi@parity.io>
  2. Feb 03, 2025
  3. Jan 29, 2025
  4. Jan 28, 2025
  5. Jan 15, 2025
  6. Dec 19, 2024
  7. Dec 18, 2024
  8. Dec 13, 2024
  9. Dec 12, 2024
  10. Dec 11, 2024
    • Alexander Theißen's avatar
      pallet-revive: Statically verify imports on code deployment (#6759) · f0b5c3e6
      Alexander Theißen authored
      
      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: default avatarGitHub Action <action@github.com>
  11. Dec 05, 2024
    • Alexander Theißen's avatar
      pallet-revive: Adjust error handling of sub calls (#6741) · 0d3d4502
      Alexander Theißen authored
      
      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: default avatarGitHub Action <action@github.com>
  12. Nov 29, 2024
    • Alexander Theißen's avatar
      pallet_revive: Switch to 64bit RISC-V (#6565) · 447902ef
      Alexander Theißen authored
      
      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: default avatarGitHub Action <action@github.com>
  13. Nov 19, 2024
  14. Nov 04, 2024
    • Cyrill Leutwiler's avatar
      [pallet-revive] rework balance transfers (#6187) · d69a80e6
      Cyrill Leutwiler authored
      
      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: default avatarxermicus <cyrill@parity.io>
      Signed-off-by: default avatarCyrill Leutwiler <bigcyrill@hotmail.com>
      Co-authored-by: command-bot <>
      Co-authored-by: default avatarGitHub Action <action@github.com>
      Co-authored-by: default avatarPG Herveou <pgherveou@gmail.com>
  15. Oct 30, 2024
  16. Oct 29, 2024
  17. Oct 22, 2024
    • PG Herveou's avatar
      [pallet-revive] Eth RPC integration (#5866) · 21930ed2
      PG Herveou authored
      
      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: default avatarAlexander Theißen <alex.theissen@me.com>
      Co-authored-by: default avatarCyrill Leutwiler <cyrill@parity.io>
  18. Oct 18, 2024
    • georgepisaltu's avatar
      FRAME: Reintroduce `TransactionExtension` as a replacement for `SignedExtension` (#3685) · b76e91ac
      georgepisaltu authored
      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 ...
    • Ermal Kaleci's avatar
      pallet-revive: EXTCODEHASH to match EIP-1052 (#6088) · 09155dbc
      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
  19. Oct 08, 2024
  20. Oct 05, 2024
    • Cyrill Leutwiler's avatar
      [pallet-revive] immutable data storage (#5861) · a8ebe9af
      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: default avatarCyrill Leutwiler <bigcyrill@hotmail.com>
      Signed-off-by: default avatarxermicus <cyrill@parity.io>
      Co-authored-by: command-bot <>
      Co-authored-by: default avatarAlexander Theißen <alex.theissen@me.com>
      Co-authored-by: default avatarPG Herveou <pgherveou@gmail.com>
  21. Oct 03, 2024
  22. Sep 25, 2024
    • Cyrill Leutwiler's avatar
      [pallet-revive] last call return data API (#5779) · c77095f5
      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: default avatarCyrill Leutwiler <bigcyrill@hotmail.com>
      Signed-off-by: default avatarxermicus <cyrill@parity.io>
      Co-authored-by: command-bot <>
      Co-authored-by: default avatarPG Herveou <pgherveou@gmail.com>
  23. Sep 23, 2024
  24. Sep 18, 2024
    • Cyrill Leutwiler's avatar
      [pallet-revive] write sandbox output according to the provided output buffer length (#5743) · c0d5c4d8
      Cyrill Leutwiler authored
      
      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: default avatarxermicus <cyrill@parity.io>
  25. Sep 13, 2024
  26. Sep 12, 2024
  27. Sep 11, 2024
    • Alexander Theißen's avatar
      Send balance when contract doesn't exist (#5664) · ea5fb02e
      Alexander Theißen authored
      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: default avatarCyrill Leutwiler <cyrill@parity.io>
  28. Sep 08, 2024
    • PG Herveou's avatar
      [pallet-revive] update generic runtime types (#5608) · 868a36bd
      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: default avatarAlexander Theißen <alex.theissen@me.com>
  29. Sep 05, 2024
  30. Sep 03, 2024