WASM-compiled built-in actors used by all Filecoin clients


Built-in Filecoin actors (v8)

This repo contains the code for the on-chain built-in actors that power the Filecoin network starting from network version 16.

These actors are written in Rust and are designed to operate inside the Filecoin Virtual Machine. A reference implementation of the latter exists at filecoin-project/ref-fvm.

The build process of this repo compiles every actor into Wasm bytecode and generates an aggregate bundle to be imported by all clients. The structure of this bundle is standardized. Read below for details.

This codebase is on track to be canonicalized in FIP-0031. As a result, this actor implementation will be the only one recognized by the network.

Pre-FVM actors

Actors for the following network versions are provided as well:

  • nv14 actors are provided to facilitate testing.
  • nv15 actors are provided to enable the eventual nv15=>nv16 upgrade.

Importable bundle

The main output of this repo is a CARv1 archive bundling all Wasm bytecode for all actors into a single file, with the following characteristics:

  • The CARv1 header points to a single root CID.
  • The CID resolves to a Manifest data structure that associates code CIDs with their corresponding built-in actor types.
  • The Manifest payload should be interpreted as an IPLD Map<Cid, i32>. Every entry represents a built-in actor.
  • Manifest keys (CID) point to the Wasm bytecode of an actor as a single block.
  • Manifest values (i32) identify the actor type, to be parsed as the fvm_shared::actor::builtin::Type enum:
    • System = 1
    • Init = 2
    • Cron = 3
    • Account = 4
    • Power = 5
    • Miner = 6
    • Market = 7
    • PaymentChannel = 8
    • Multisig = 9
    • Reward = 10
    • VerifiedRegistry = 11

The CARv1 is embedded as a byte slice at the root of the library, and exported under the BUNDLE_CAR public const, for easier consumption by Rust code.

Precompiled actor bundles may also be provided as release binaries in this repo, if requested by implementors.


We usually release all actors, the runtime, and the bundle at the same time. That means releasing:

  • fil_actors_runtime
  • fil_actor_account
  • fil_actor_cron
  • fil_actor_init
  • fil_actor_market
  • fil_actor_miner
  • fil_actor_multisig
  • fil_actor_paych
  • fil_actor_power
  • fil_actor_reward
  • fil_actor_system
  • fil_actor_verifreg
  • fil_builtin_actors_bundle

(in that order)

To make this easier, we've added some helper scripts to the Makefile. Instructions follow.

1: Install Dependencies


  • jq (with your favorite package manager)
  • cargo-edit (with cargo install cargo-edit).

2: Bump Versions (Release)

You can bump the runtime, actors, and bundle versions with the bump-version target. See Versioning to determine the correct version bump.

make bump-version

By default, this bumps the patch version. To bump to a different version, append, e.g. BUMP=major. Valid options are:

  • patch
  • minor
  • major
  • alpha
  • beta

You can also set a specific version with the set-version target.

make set-version VERSION=7.1.1

Commit the version changes:

git commit -a -m "Release $(make --quiet version)"

Finally, create a PR to commit your changes, make sure your PR is approved and merged before move to the next step!

3: Publish Crates

NOTE: If you're a not a member of the core FVM team, you'll need help with this step. Please make a PR at this point and ask the core team to publish a release.

Run make publish to publish all crates to crates.io. This will likely take a while as it re-builds everything from scratch for validation (multiple times).

NOTE: To do this, you'll need to:

  1. Register an account with https://crates.io and confirm your email address (if you haven't already).
  2. Login locally with cargo login.
  3. Get yourself added to the fvm-crate-owners team.

4: Bump Versions (Alpha)

Finally, bump the versions to the next alpha and commit the changes:

make bump-version BUMP=alpha
git commit -a -m "Release $(make --quiet version)"

Instructions for client implementations

Obtaining an actors bundle

There are two options:

  1. Building from source.
  2. Downloading the precompiled release bundle from GitHub.

Instructions to build from source (option 1):

  1. Clone the repo.
  2. Check out the relevant branch or tag (see Versioning section below).
  3. make bundle from the workspace root.

The bundle be written to output/builtin-actors.car.

Both options are compatible with automation via scripts or CI pipelines.

Integrating an actors bundle

This part is implementation-specific. Options include:

  1. Embedding the bundle's CARv1 bytes into the distribution's binary.
  2. Downloading CARv1 files on start (with some form of checksumming for added security).

Loading and using the actors bundle with ref-fvm

Once the implementation has validated the authenticity of the bundle, it is expected to do the following:

  1. Import the CARv1 into the blockstore.
  2. Retain the root CID in memory, indexed by network version.
  3. Feed the root CID to ref-fvm's Machine constructor, to tell ref-fvm which CodeCID maps to which built-in actor.

Multiple network version support

Because every network version may be backed by different actor code, implementations should be ready to load multiple actor bundles and index them by network version.

When instantiating the ref-fvm Machine, both the network version and the corresponding Manifest root CID must be passed.


A fair question is how crate versioning relates to the protocol concept of ActorVersion. We adopt a policy similar to specs-actors:

  • Major number in crate version correlates with ActorVersion.
  • We generally don't use minor versions; these are always set to 0.
  • We strive for round major crate versions to denote the definitive release for a given network upgrade. However, due to the inability to predict certain aspects of software engineering, this is not a hard rule and further releases may be made by bumping the patch number.

Development versions will use qualifiers such as -rc (release candidate).

As an example of application of this policy to a v10 actor version lineage:

  • Unstable development versions are referenced by commit hash.
  • Stable development versions are tagged as release candidates: 10.0.0-rc1, 10.0.0-rc2, etc.
  • Definitive release: 10.0.0.
  • Patched definitive release: 10.0.1.
  • Patched definitive release: 10.0.2.
  • Network upgrade goes live with 10.0.2.

About this codebase

Relation to specs-actors

This repo supersedes specs-actors, and fulfils two roles:

  • executable specification of built-in actors.
  • canonical, portable implementation of built-in actors.


This codebase was originally forked from the actors v6 implementation of the Forest client, and was adapted to the FVM environment.


Because this codebase is a common good across all Filecoin client implementations, it serves as a convergence area for all Core Devs regardless of the implementation or project they identify with.


Dual-licensed: MIT, Apache Software License v2, by way of the Permissive License Stack.

  • Discuss: Versioning and FVM M2 development

    Discuss: Versioning and FVM M2 development


    The FVM M2 milestone requires changes to these actors:

    • init actor, to introduce the ability to install code and instantiate arbitrary actors
    • (maybe) system actor
    • (presumably) account actor, to enable Account Abstraction to represent EVM accounts and validate Ethereum transactions

    Furthermore, we propose bringing in EVM actors into the builtin-actors tree (#482).

    We would like to figure out ways to support concurrent development of nv17 and FVM M2 (presumably nv18).


    • The master branch contains the actor changes that are confidently going to ship in the next network version, either because their FIPs have already been approved for inclusion in the next network version, or they are de facto on track for that.
    • Rely on develop/<project name> branches for future changes. FVM M2 develoment would happen under develop/fvm-m2, but would still use the pull request process to merge changes there, so that the community has visibility and can review.
    opened by raulk 19
  • EVM-890: No hashing by HAMT

    EVM-890: No hashing by HAMT

    resolves https://github.com/filecoin-project/ref-fvm/issues/890


    This is a simple PR, all it does is replaces the default Sha256 hashing algorithm with Identity in the EVM actor. This is because the Solidity compiler already uses 32 byte keys and hashes them where it needs to, but the HAMT also hashed that another time, destroying the properties of array keys for example, which are designed to be in contiguous slots.

    By removing the extra hashing we should see that the array items are colocated, but it will have some tradeoffs in that the tree will become deeper. Previously the random hashing resulted in nodes being saturated evenly, probably growing the tree to logarithmic height in the number of entries. Now the keys of array slots are going to be neighbours, which means they will have share a long prefix of their keys, resulting in the tree being very deep at those places, exhausting all nibbles (32 with the default bit width of 8) until the items can be inserted into separate buckets.

    The purpose of the PR is to see this effect in action, that's why it's opened not against the next branch directly but an branch accumulating all changes. https://github.com/filecoin-project/ref-fvm/issues/891 be able to improve the tradeoffs before we decide whether to adopt this change.

    The measurements are run against a branch of ref-evm that contains https://github.com/filecoin-project/ref-fvm/pull/901

    Analysis of measurement changes


    The first ~25 iterations are similar to what we had before: 4 GETs and 2 PUTs per item added to the array. Solidity packs multiple numbers into the same slot, so the slot index grows slower than the number of items in the array. Then at some point we want to insert the 4th item into the key-value bucket where the first 3 arrays slots have already been added, and suddenly the tree has to be expanded all the way to level 32. From this point we have 35 GETs and 33 PUTs per iteration.

    The number of bytes read and written goes up linearly until iteration ~80, when there's a drop. This is most likely the point where we completely filled a Node with data and we start writing to the next one, so from then on the previous Node doesn't have to be copied any more after each addition.

    Notably the the first and the second series are now almost identical, unlike previously, which means writing to array1 and array2 no longer affect each other. This is because previously they both saturated the root node, but now by the time array2 is being written to, array1 has already sunk to the bottom of the tree, and array2 is in a completely different address space.

    In terms of bytes read and written, we are worse than when we used hashing because of all the links that have to be maintained.


    The number of reads and writes are constant at 35 and 33, corresponding to the total height of the tree. The amount of bytes read/written follow a sawtooth pattern ranging from 5kB to 35kB, which is better than previously, where we had values go up to 50kB and go down to 35kB on the long average.


    Here we fill the array with 10,000 items, then read the first 100, one by one. The number of reads is the same 35. Until iteration 80 the amount of bytes read is ~5kB, but then jumps to over 35kB. This is strange; according to array_push_n1 this is where we probably started writing to a second node, but it's already filled, so why should reading it back be different?

    Explanation: The reason there was a jump in the amount of bytes read is no problem, it just happened that the start of the array landed somewhere towards the end of a node, with only a few items written to it, then the rest were in the next node, which is substantially larger because it's full. So the first 80 iterations accessed a small node, the last 20 read from the large node.


    In this scenario we read 100 items at a time, 100 times. The bytes read are ~38kB most of the time, but every ~20th iteration they jump up to ~72kB. Most likely this is where the 100 items span two nodes, so we have to fetch two blocks from the store to cover the first and second half.


    We can see that very quickly, after the second iteration, the cost of incrementing a counter becomes independent of adding more items to the array. Previously the cost of the counter increased as the array saturated the root node with more and more data, but now the data sinks to the bottom of the tree. By contrast the second series where we add entries to a mapping still affects the cost.

    Scenarios with mappings

    Mappings have been largely unaffected by this change because they hash their keys individually. The final key values changed because of the removal of the hashing by the HAMT, so the measurements are not identical, but the patterns and the values are very similar.

    opened by aakoshh 14
  • Implement Drop as a safeguard for programmer errors

    Implement Drop as a safeguard for programmer errors

    It addresses https://github.com/filecoin-project/builtin-actors/issues/605

    Another idea was to throw error if there's any unverified expectation which would be less automagical. But it would require checking all parts of expectations 1 by 1 which would be tedious to maintain.

    opened by maciejwitowski 13
  • Check actor ID in singleton actor constructors

    Check actor ID in singleton actor constructors

    Currently, we have an "is singleton" check inside the FVM and refuse to create an actor if it's a known singleton. Instead, singleton actors should assert that their ID address is the expected ID address in their constructors, and assert that the sender is the system actor.

    In practice, this should basically make them impossible to construct, but it would remove a special-case check from the FVM.

    good first issue area/actors 
    opened by Stebalien 13
  • Maintain older versions of the actor crates

    Maintain older versions of the actor crates

    As it stands right now, the older versions of the actor crates cannot be maintained without breaking semver. This is due to their version (eg 8.0.0) being tied directly to the actor versions on the Filecoin network.

    This is a problem for Forest because, unlike Lotus, we need to use the Rust crates to support the older actors.

    How to maintain the older builtin-actors was discussed in Slack (https://filecoinproject.slack.com/archives/C029MT4PQB1/p1666171262331519) and the general consensus was to divorce the Rust crate versions from the Filecoin network versions. This would mean the actor crate names would include their network version, like: fil_actor_init_v8. Since Lotus doesn't use the older Rust crates at all, Forest has volunteered to maintain these crates.

    Open questions:

    • Should the versioned actors live in the main branch or in separate branches? If if live in separate branches then the CI cannot test them when changes are made in the shared crates. We need an automated way to ensure that all the versioned actors still work and compile. If this can be done while they live in separate branches, fine. If not then they'll have to go in the main branch.
    • Forest doesn't require the smart-contract code. If the actor crates were split into a state crate and a smart-contract crate, the ongoing maintenance burden would be significantly lower. Not sure if this should be done now or later.
    opened by lemmih 11
  • Builtin actor registry

    Builtin actor registry

    for #122

    Depends on https://github.com/filecoin-project/ref-fvm/pull/401 which needs to be merged and published first, for the From type to string converter.

    opened by vyzo 11
  • feat: enable wasm optimizations using binaryen

    feat: enable wasm optimizations using binaryen

    This enables both the speed (3) and size (z) optimizations, bringing the miner actor down to 1MiB.

    ~Draft because, while this PR is correct, there's a bug in the FVM https://github.com/filecoin-project/ref-fvm/issues/602.~

    This PR has two main parts:

    1. It strips the binary, bringing, e.g., the miner actor down to 1.4MiB (ish).
    2. It then uses binaryen to both optimize and further trim down the binary to 1.0MiB.


    1. Reduce the block sizes (try to get them down below a megabyte).
    2. Reduce the CAR size. With these changes (even without the binaryen optimization step), we can get the compressed CAR size down to about half a megabyte.
    3. Optimize the WASM itself for better performance. Parity is doing this with substrate as well.

    In terms of how much this helps.... we'll need more thorough testing, but it looks like it helps a bit...

    The main downside of this change is that it would:

    1. Add an additional compile-time dep on a non-rust project (binaryen).
    2. Add a compile-time dependency on cmake (to build binaryen).

    I'm happy to drop the binaryen part if we feel that it's too risky, too late. But I'd like to drop the debug info from the release builds so we can get the bundle size down. This would let us check-in the main bundles into the lotus source, significantly simplifying the build process.

    opened by Stebalien 9
  • Builtin Actor Registry

    Builtin Actor Registry


    1. Actor code (wasm) is passed into the FVM via a CAR file.
    2. We use "fake" CIDs to address actors.

    As of nv16, this code will live on-chain as state and will be referenced by real CIDs. We could continue passing in a CAR file with these actors when we construct the machine, however:

    1. Parsing the CAR file each time is inefficient.
    2. This actor code is state, so it should live in the state-tree. Otherwise, we could end up with strange mismatches.
    3. Not all actor types will be instantiated at genesis. If we import the CAR file once when we, e.g., start a test network, something like the splitstore may garbage collect these actors before anyone constructs one of them.

    Proposal: Include a builtin-actor "manifest" in either the init actor, or the system actor.

    Specifically (ish):

    1. Change the "manifest" block in the actor bundle (https://github.com/filecoin-project/builtin-actors/blob/76eecbfc1828bab6e46623b5582b845a2d18404e/src/lib.rs#L23) to be "correct" IPLD.
      1. Currently, this manifest block is a mapping of CIDs to numbers identifying the different actor types.
      2. We should change this to a mapping of actor names (strings) to actors. This is slightly less efficient, but we can optimize lookups at runtime. We could also change it to be a list of some sort, but I feel that this is a case where we might as well be verbose.
    2. Link this manifest into the init actor's state, or the system actor's state. Where this should live isn't entirely cut and dry:
      1. Eventually, we'll have an actor "registry" in the init actor so the init actor knows which actors can and cannot be deployed. However, the builtin actor manifest is a bit different because we use it for permission checks, not just initialization/deployment.
      2. We have quite a few tools that read the init actor's state, and the state layout hasn't ever changed. If we put this registry in the init actor, we'd need to support reading multiple versions of this state. This isn't hard, just slightly annoying.
    opened by Stebalien 9
  • Handle or migrate away from non-utf8 DealProposal Labels

    Handle or migrate away from non-utf8 DealProposal Labels

    See https://github.com/filecoin-project/FIPs/issues/187 and https://github.com/filecoin-project/FIPs/blob/master/FIPS/fip-0027.md.

    • According to the FIP, these should be migrated to byte strings.
    • For now, we should accept non-utf8 strings. But that's... nasty.
    • An alternative is to just migrate labels to utf8.

    At the moment, we reject non-utf8 labels. But we need to make a decision before we ship.

    area/actors P0 area/ipld 
    opened by Stebalien 9
  • Add a simple Makefile [edit: and use it for CI]

    Add a simple Makefile [edit: and use it for CI]

    Add basic rules to help people unfamiliar with Rust development environment get started.

    Ensure there is a rule that replicates the checks that will run on CI.

    good first issue 
    opened by anorth 9
  • Create reference rust vm for integration test

    Create reference rust vm for integration test

    Similar to https://github.com/filecoin-project/specs-actors/blob/master/support/vm/vm.go - we need a simplified message execution framework that FVM like for integration tests.

    P1 area/test 
    opened by jennijuju 9
  • EVM: userspace selfdestruct

    EVM: userspace selfdestruct

    Implements filecoin-project/ref-fvm#1221

    Rewrite of #972 (still TBD tests and one todo).

    Main differences are:

    1. This doesn't introduce a new method (just uses the constructor because it was simpler).
    2. Doesn't touch the init actor.
    3. When an actor is "dead", this version returns an empty System to simplify some of the logic.
    opened by Stebalien 1
  • Adds log() method to runtime, calling through to the VM syscall

    Adds log() method to runtime, calling through to the VM syscall

    Context: https://github.com/filecoin-project/ref-fvm/issues/1397

    At present the mock runtime just prints the message, but we could accumulate them in the future. No actual log calls are checked in here because they cost gas.

    opened by anorth 3
  • FEVM | Howto access cross contract pre-compile functions.

    FEVM | Howto access cross contract pre-compile functions.

    Discussion Thread ...

    Bit blocked in the bring-up of test-suite push0.json. Use-case trying to invoke functions between contracts. To be specific looking for some clarity on how "CALL(0xF1)" works under FEVM context. Tried my best to mimic the test app implementation from revme, but no luck. Captured the traces from revme & FEVM context.



    Draft PR


    Test Case

     "0x0000000000000000000000000000000000000100" : {
                    "balance" : "0x00",
                    "code" : "0x60015f55",
                    "nonce" : "0x00",
                    "storage" : {

    Decompiled ASM code

    	0000    60  PUSH1 0x01
    	0002    5F  5F
    	// Stack delta = +1
    	// Outputs[1] { @0000  stack[0] = 0x01 }
    	// Block terminates
    	0003    55    SSTORE


    Test Case

          "0xb94f5374fce5edbc8e2a8697c15331677e6ebf0b" : {
                    "balance" : "0x00",
                    "code" : "0x6000600060006000600060003560601c620186a0f16000556001600155",
                    "nonce" : "0x00",
                    "storage" : {

    Decompiled ASM code

    	// Inputs[3]
    	// {
    	//     @000C  msg.data[0x00:0x20]
    	//     @0014  memory[0x00:0x00]
    	//     @0014  address(msg.data[0x00:0x20] >> 0x60).call.gas(0x0186a0)(memory[0x00:0x00])
    	// }
    	0000    60  PUSH1 0x00
    	0002    60  PUSH1 0x00
    	0004    60  PUSH1 0x00
    	0006    60  PUSH1 0x00
    	0008    60  PUSH1 0x00
    	000A    60  PUSH1 0x00
    	000C    35  CALLDATALOAD
    	000D    60  PUSH1 0x60
    	000F    1C  SHR
    	0010    62  PUSH3 0x0186a0
    	0014    F1  CALL
    	0015    60  PUSH1 0x00
    	0017    55  SSTORE
    	0018    60  PUSH1 0x01
    	001A    60  PUSH1 0x01
    	001C    55  SSTORE
    	// Stack delta = +0
    	// Outputs[3]
    	// {
    	//     @0014  memory[0x00:0x00] = address(msg.data[0x00:0x20] >> 0x60).call.gas(0x0186a0)(memory[0x00:0x00])
    	//     @0017  storage[0x00] = address(msg.data[0x00:0x20] >> 0x60).call.gas(0x0186a0)(memory[0x00:0x00])
    	//     @001C  storage[0x01] = 0x01
    	// }
    	// Block terminates

    Execution of testcase under revme context


    Use-case is working fine on revme context, and the execution flow & traces looks OK.

    Execution of Contract-02

    Contract-02 invokes Contract-01

    Complete Trace

    2022-12-25T14:56:51.336398Z  INFO revme::statetest::cmd: Start running tests on: "tests/GeneralStateTests/EIPTests/stEIP3855/push0.json"
    2022-12-25T14:56:51.336671Z  WARN revme::statetest::runner: Processing 1/1
    2022-12-25T14:56:51.336745Z  WARN revme::statetest::runner: Processing 1/1
    2022-12-25T14:56:51.336809Z  WARN revme::statetest::runner: Processing 1/1
    2022-12-25T14:56:51.336845Z  WARN revme::statetest::runner: Processing 1/1
    2022-12-25T14:56:51.336873Z  WARN revme::statetest::runner: Processing 1/1
    2022-12-25T14:56:51.336907Z  WARN revme::statetest::runner: Processing 1/1
    2022-12-25T14:56:51.336942Z  WARN revme::statetest::runner: Processing 1/1
    2022-12-25T14:56:51.336973Z  WARN revme::statetest::runner: Processing 1/1
    2022-12-25T14:56:51.336997Z  WARN revme::statetest::runner: Processing 1/1
    2022-12-25T14:56:51.339193Z DEBUG revme::statetest::runner: Pre Processing => "push0"
    2022-12-25T14:56:51.340249Z DEBUG revme::statetest::runner: Executing Spec => Merge
    2022-12-25T14:56:51.340349Z  INFO revm::evm_impl: TransactTo::Call()=>
    2022-12-25T14:56:51.340370Z  INFO revm::evm_impl: Host::code => 0xb94f5374fce5edbc8e2a8697c15331677e6ebf0b
    2022-12-25T14:56:51.340390Z  INFO revm::evm_impl: Host::load_account => 0xb94f5374fce5edbc8e2a8697c15331677e6ebf0b
    2022-12-25T14:56:51.340433Z  INFO revm::evm_impl: Host::step =>
    2022-12-25T14:56:51.340445Z TRACE revm::interpreter: run=>PC:[0x0], OC:[0x60]
    2022-12-25T14:56:51.340457Z  INFO revm::evm_impl: Host::step_end =>
    2022-12-25T14:56:51.340463Z  INFO revm::evm_impl: Host::step =>
    2022-12-25T14:56:51.340470Z TRACE revm::interpreter: run=>PC:[0x2], OC:[0x60]
    2022-12-25T14:56:51.340476Z  INFO revm::evm_impl: Host::step_end =>
    2022-12-25T14:56:51.340482Z  INFO revm::evm_impl: Host::step =>
    2022-12-25T14:56:51.340489Z TRACE revm::interpreter: run=>PC:[0x4], OC:[0x60]
    2022-12-25T14:56:51.340496Z  INFO revm::evm_impl: Host::step_end =>
    2022-12-25T14:56:51.340502Z  INFO revm::evm_impl: Host::step =>
    2022-12-25T14:56:51.340508Z TRACE revm::interpreter: run=>PC:[0x6], OC:[0x60]
    2022-12-25T14:56:51.340514Z  INFO revm::evm_impl: Host::step_end =>
    2022-12-25T14:56:51.340520Z  INFO revm::evm_impl: Host::step =>
    2022-12-25T14:56:51.340526Z TRACE revm::interpreter: run=>PC:[0x8], OC:[0x60]
    2022-12-25T14:56:51.340532Z  INFO revm::evm_impl: Host::step_end =>
    2022-12-25T14:56:51.340538Z  INFO revm::evm_impl: Host::step =>
    2022-12-25T14:56:51.340544Z TRACE revm::interpreter: run=>PC:[0xa], OC:[0x60]
    2022-12-25T14:56:51.340552Z  INFO revm::evm_impl: Host::step_end =>
    2022-12-25T14:56:51.340558Z  INFO revm::evm_impl: Host::step =>
    2022-12-25T14:56:51.340564Z TRACE revm::interpreter: run=>PC:[0xc], OC:[0x35]
    2022-12-25T14:56:51.340575Z  INFO revm::evm_impl: Host::step_end =>
    2022-12-25T14:56:51.340582Z  INFO revm::evm_impl: Host::step =>
    2022-12-25T14:56:51.340588Z TRACE revm::interpreter: run=>PC:[0xd], OC:[0x60]
    2022-12-25T14:56:51.340595Z  INFO revm::evm_impl: Host::step_end =>
    2022-12-25T14:56:51.340602Z  INFO revm::evm_impl: Host::step =>
    2022-12-25T14:56:51.340608Z TRACE revm::interpreter: run=>PC:[0xf], OC:[0x1c]
    2022-12-25T14:56:51.340617Z  INFO revm::evm_impl: Host::step_end =>
    2022-12-25T14:56:51.340624Z  INFO revm::evm_impl: Host::step =>
    2022-12-25T14:56:51.340630Z TRACE revm::interpreter: run=>PC:[0x10], OC:[0x62]
    2022-12-25T14:56:51.340638Z  INFO revm::evm_impl: Host::step_end =>
    2022-12-25T14:56:51.340644Z  INFO revm::evm_impl: Host::step =>
    2022-12-25T14:56:51.340651Z TRACE revm::interpreter: run=>PC:[0x14], OC:[0xf1]
    2022-12-25T14:56:51.340664Z  INFO revm::evm_impl: Host::load_account => 0x0000000000000000000000000000000000000100
    2022-12-25T14:56:51.340686Z  INFO revm::evm_impl: Host::call =>
    2022-12-25T14:56:51.340693Z  INFO revm::evm_impl: Host::code => 0x0000000000000000000000000000000000000100
    2022-12-25T14:56:51.340705Z  INFO revm::evm_impl: Host::load_account => 0x0000000000000000000000000000000000000100
    2022-12-25T14:56:51.340735Z  INFO revm::evm_impl: Host::step =>
    2022-12-25T14:56:51.340744Z TRACE revm::interpreter: run=>PC:[0x0], OC:[0x60]
    2022-12-25T14:56:51.340752Z  INFO revm::evm_impl: Host::step_end =>
    2022-12-25T14:56:51.340758Z  INFO revm::evm_impl: Host::step =>
    2022-12-25T14:56:51.340765Z TRACE revm::interpreter: run=>PC:[0x2], OC:[0x5f]
    2022-12-25T14:56:51.340772Z  INFO revm::evm_impl: Host::step_end =>
    2022-12-25T14:56:51.340788Z  INFO revm::evm_impl: Host::step_end =>
    2022-12-25T14:56:51.340796Z  INFO revm::evm_impl: Host::step =>
    2022-12-25T14:56:51.340803Z TRACE revm::interpreter: run=>PC:[0x15], OC:[0x60]
    2022-12-25T14:56:51.340810Z  INFO revm::evm_impl: Host::step_end =>
    2022-12-25T14:56:51.340816Z  INFO revm::evm_impl: Host::step =>
    2022-12-25T14:56:51.340823Z TRACE revm::interpreter: run=>PC:[0x17], OC:[0x55]
    2022-12-25T14:56:51.340839Z  INFO revm::evm_impl: Host::sstore =>
    2022-12-25T14:56:51.340856Z  INFO revm::evm_impl: Host::step_end =>
    2022-12-25T14:56:51.340864Z  INFO revm::evm_impl: Host::step =>
    2022-12-25T14:56:51.340870Z TRACE revm::interpreter: run=>PC:[0x18], OC:[0x60]
    2022-12-25T14:56:51.340877Z  INFO revm::evm_impl: Host::step_end =>
    2022-12-25T14:56:51.340884Z  INFO revm::evm_impl: Host::step =>
    2022-12-25T14:56:51.340890Z TRACE revm::interpreter: run=>PC:[0x1a], OC:[0x60]
    2022-12-25T14:56:51.340896Z  INFO revm::evm_impl: Host::step_end =>
    2022-12-25T14:56:51.340902Z  INFO revm::evm_impl: Host::step =>
    2022-12-25T14:56:51.340908Z TRACE revm::interpreter: run=>PC:[0x1c], OC:[0x55]
    2022-12-25T14:56:51.340915Z  INFO revm::evm_impl: Host::sstore =>
    2022-12-25T14:56:51.340926Z  INFO revm::evm_impl: Host::step_end =>
    2022-12-25T14:56:51.340932Z  INFO revm::evm_impl: Host::step =>
    2022-12-25T14:56:51.340939Z TRACE revm::interpreter: run=>PC:[0x1d], OC:[0x0]
    2022-12-25T14:56:51.340945Z  INFO revm::evm_impl: Host::step_end =>
    2022-12-25T14:56:51.340991Z  INFO revme::statetest::runner: exit_reason::[Stop], gas_used::[148031], gas_refunded::[0], logs::[[]]
    2022-12-25T14:56:51.342130Z  WARN revme::statetest::runner: Ignoring the spec => MergePush0
    2022-12-25T14:56:51.342154Z DEBUG revme::statetest::runner: TestDone => 0/"tests/GeneralStateTests/EIPTests/stEIP3855/push0.json"

    Execution of testcase under fevm context

    FEVM Error

    Complete Trace

    2022-12-25T14:41:45.676742Z  WARN test_fevm_eth_compliance::statetest::runner: Processing status sender:false to:true
    2022-12-25T14:41:45.676757Z  INFO test_fevm_eth_compliance::statetest::runner: Pre Processing TestCase "push0"::9::0xb94f5374fce5edbc8e2a8697c15331677e6ebf0b
    2022-12-25T14:41:45.677142Z TRACE fil_actor_init: called exec; params.code_cid: Cid(bafkqaelgnfwc65dfon2c63lvnr2gs43jm4)    
    2022-12-25T14:41:45.677169Z TRACE fil_actor_init: caller code CID: Cid(bafkqad3gnfwc65dfon2c643zon2gk3i)    
    2022-12-25T14:41:45.677188Z TRACE fil_actor_init: robust address: Address { payload: Actor([83, 79, 152, 179, 173, 99, 8, 25, 210, 132, 40, 123, 100, 114, 131, 161, 213, 219, 207, 144]) }    
    2022-12-25T14:41:45.678144Z TRACE fil_actor_init: delegated address: Address { payload: Delegated(DelegatedAddress { namespace: 10, length: 20, buffer: [54, 30, 204, 175, 91, 188, 185, 119, 30, 170, 64, 66, 213, 189, 192, 126, 103, 122, 13, 118, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0] }) }    
    2022-12-25T14:41:45.678177Z TRACE fil_actor_init: robust address: Address { payload: Actor([85, 148, 66, 220, 206, 30, 3, 194, 148, 67, 169, 132, 24, 251, 193, 115, 118, 21, 218, 203]) }    
    2022-12-25T14:41:45.678310Z TRACE fil_actor_evm: Entering::constructor=>
    2022-12-25T14:41:45.678351Z TRACE fil_actor_evm::interpreter::execution::opcodes: Entering=>PC:[0x0], [0x60]
    2022-12-25T14:41:45.678369Z TRACE fil_actor_evm::interpreter::execution::opcodes: Entering=>PC:[0x2], [0x60]
    2022-12-25T14:41:45.678382Z TRACE fil_actor_evm::interpreter::execution::opcodes: Entering=>PC:[0x4], [0x60]
    2022-12-25T14:41:45.678394Z TRACE fil_actor_evm::interpreter::execution::opcodes: Entering=>PC:[0x6], [0x60]
    2022-12-25T14:41:45.678407Z TRACE fil_actor_evm::interpreter::execution::opcodes: Entering=>PC:[0x8], [0x60]
    2022-12-25T14:41:45.678421Z TRACE fil_actor_evm::interpreter::execution::opcodes: Entering=>PC:[0xa], [0x60]
    2022-12-25T14:41:45.678438Z TRACE fil_actor_evm::interpreter::execution::opcodes: Entering=>PC:[0xc], [0x35]
    2022-12-25T14:41:45.678456Z TRACE fil_actor_evm::interpreter::execution::opcodes: Entering=>PC:[0xd], [0x60]
    2022-12-25T14:41:45.678469Z TRACE fil_actor_evm::interpreter::execution::opcodes: Entering=>PC:[0xf], [0x1c]
    2022-12-25T14:41:45.678479Z TRACE fil_actor_evm::interpreter::execution::opcodes: Entering=>PC:[0x10], [0x62]
    2022-12-25T14:41:45.678492Z TRACE fil_actor_evm::interpreter::execution::opcodes: Entering=>PC:[0x14], [0xf1]
    thread '<unnamed>' panicked at 'address is a precompile: BadAddress("cannot convert precompile 0 to an f4 address")', /home/popoyi/dscbox/sun/ws-020-blocks/ws-030-filecoin-project/dev-030-01-fvm/builtin-actors/actors/evm/src/interpreter/instructions/call.rs:216:65
    note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
    Error: Statetest(SystemError)

    Some Highlights for Discussion.

    Q1.1 | As part of ConstructorParams, Is it good idea to split contract bytecode, into optional initcode & runtimecode ?

    Most of the bytecodes in Eth test vectors, have only runtime codes, I hope this approach helps to deploy the actor as it is. and manage the state & invokation of contract runtime function from other actors.

    #[derive(Serialize_tuple, Deserialize_tuple)]
    pub struct ConstructorParams {
        /// The actor's "creator" (specified by the EAM).
        pub creator: EthAddress,
        /// The initcode that will construct the new EVM actor.
        pub initcode: Option<RawBytes>,
        /// The runtime code of the solidity contract.
        pub runtimecode: RawBytes,    

    Q1.2 | Is it possible to use pre-compiled bytecode as it is from ethereum/tests: Common tests for all Ethereum implementations, or do we need any adoptation to make Eth & f4 address for compatibility. Under FEVM context, hit with error message of "BadAddress("cannot convert precompile 0 to an f4 address")", looks like I am missing some thing on state initialization. Can I have some more clarity over here?

    opened by shamb0 0
RDF playground using WASM-compiled Sophia

SoWasm: an RDF playground based on Sophia This started as an experiment of compiling Sophia into WebAssembly, and grew into a (hopefully) useful playg

Pierre-Antoine Champin 4 Dec 19, 2023
Zinnia is a runtime for Filecoin Station modules. It provides a sandboxed environment to execute untrusted code on consumer-grade computers.

?? Zinnia Zinnia is a runtime for Filecoin Station modules. It provides a sandboxed environment to execute untrusted code on consumer-grade computers.

Filecoin Station 5 Jan 25, 2023
A minimal library for building compiled Node.js add-ons in Rust via Node-API

A minimal library for building compiled Node.js add-ons in Rust via Node-API

Node-API (N-API) for Rust 3.1k Dec 29, 2022
A forth-inspired, bytecode-compiled scripting language for Anachro Powerbus

Anachro Forth (core) Anachro Forth is a forth-inspired, bytecode-compiled scripting language for Anachro Powerbus platform. Use Case The intended use

null 14 May 27, 2022
Distribute a wasm SPA as HTML by wrapping it as a polyglot "html+wasm+zip"

A packer that adds a webpage to WASM module, making it self-hosted! Motivation At the moment, Browsers can not execute WebAssembly as a native single

Andreas Molzer 3 Jan 2, 2023
STUPID stuffs built by abusing Harfbuzz WASM Shaper.

Harfbuzz-WASM-Fantasy ?? STUPID stuffs built by abusing Harfbuzz WASM Shaper. Bad Apple Maze Game MORE CRAZY STUFFS TO COME SOON! Run with Docker You

hsfzxjy 7 Sep 7, 2023
A weekly dive into commonly used modules in the Rust ecosystem, with story flavor!

Rust Module of the Week A weekly dive into commonly used modules in the Rust ecosystem, with story flavor! Build status Release Draft The goal The goa

Scott Lyons 20 Aug 26, 2022
A programming environment that aims to help people learn how to program in JavaScript, while giving them a tour on how old computers and their limitations used to be.

This repository is for the new under renovation rewrite of the LIKO-12 project. The legacy version with the original stars and contributions is still

null 1k Jan 5, 2023
📦✨ your favorite rust -> wasm workflow tool!

?? ✨ wasm-pack Your favorite Rust → Wasm workflow tool! Docs | Contributing | Chat Built with ?? ?? by The Rust and WebAssembly Working Group About Th

Rust and WebAssembly 4.8k Jan 5, 2023
Facilitating high-level interactions between Wasm modules and JavaScript

wasm-bindgen Facilitating high-level interactions between Wasm modules and JavaScript. Guide | API Docs | Contributing | Chat Built with ?? ?? by The

Rust and WebAssembly 5.9k Jan 8, 2023
Gun port in rust & wasm

gun-rs-wasm Rust & WASM port of Gun. For a non-wasm version, check out gun-rs Example (source) Use npm install rusty-gun import { Node as Gun } from "

Martti Malmi 39 Dec 19, 2022
Install `wasm-pack` by downloading the executable

wasm-pack-action Install wasm-pack by downloading the executable (much faster than cargo install wasm-pack, seconds vs minutes). Usage - uses: jetli/w

Jet Li 33 Nov 23, 2022
`wasm-snip` replaces a WebAssembly function's body with an `unreachable`

wasm-snip wasm-snip replaces a Wasm function's body with an unreachable instruction. API Docs | Contributing | Chat Built with ?? ?? by The Rust and W

Rust and WebAssembly 177 Dec 28, 2022
gc-sections for wasm

wasm-gc Note: you probably don't need to use this project. This project is no longer necessary to run by hand, nor do you need the wasm-gc executable

Alex Crichton 245 Oct 22, 2022
List the symbols within a wasm file

wasm-nm List the symbols within a wasm file. Library Executable License Contributing Executable To install the wasm-nm executable, run $ cargo install

Nick Fitzgerald 38 Nov 6, 2022
Instrument and transform wasm modules.

wasm-instrument A Rust library containing a collection of wasm module instrumentations and transformations mainly useful for wasm based block chains a

Parity Technologies 31 Dec 16, 2022
Just a little game I made in a day to try out the WASM-4 fantasy console.

Dodgeball This is just a little game I made in a day to try out the WASM-4 fantasy console. Play it here. The palette is SODA-CAP by Cappuchi. License

Sander in 't Veld 1 Jan 15, 2022
WebAssembly (Wasm) interpreter.

Continuous Integration Test Coverage Documentation Crates.io wasmi- WebAssembly (Wasm) Interpreter wasmi was conceived as a component of parity-ethere

Parity Technologies 1k Jan 4, 2023
📝 A template for creating WASM + Typescript + Rust workflow libraries.

Create Rust + TypeScript libraries with ease! PR'S WELCOMED! ✨ Inspiration I wanted to create a WebAssembly/Rust library with additional JS features,

Shaoru Ian Huang 25 Dec 24, 2022