Context

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

Proposal

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

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

Changes

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

array_push_n1

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.

array_push_n100

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.

array_read_n1

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.

array_read_n100

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.

inc_after_fill

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.

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.

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.

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.

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.

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.

Motivation:

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.

Currently:

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.

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.

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.

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.

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.

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.

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.

Use-Case

https://github.com/ethereum/tests/blob/b3d820f4488e2b49674546269a176db021ee4249/GeneralStateTests/EIPTests/stEIP3855/push0.json#LL157C18-L157C18

Draft PR

• Tool for applying test vectors from Ethereum on FEVM by shamb0 · Pull Request #953 · filecoin-project/builtin-actors

Contract-01

Test Case

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

Decompiled ASM code

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

	0003    55    SSTORE

Contract-02

Test Case

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

Decompiled ASM code

label_0000:
	// 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

https://github.com/bluealloy/revm/tree/main/bins/revme

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?