Filecoin EVM Runtime (FEVM)

[jennijuju]

Original proposer: @Stebalien @raulk

Simple Summary

We introduce a new built-in actor: the Filecoin EVM (FEVM) runtime actor, capable of running EVM smart contracts on top of the Filecoin Virtual Machine.
We also introduce various changes to the Filecoin Virtual Machine and to client implementations, necessary to support the operation of this new actor.

Abstract

The Filecoin EVM (FEVM) runtime built-in actor runs EVM smart contracts compatible with the [Ethereum Paris fork].

It achieves this by embedding a special-purpose EVM interpreter, implementing the integration logic with the Filecoin environment, translating environment-dependent opcodes into their corresponding Filecoin primitives, and mapping all state I/O to the underlying IPLD model.

The EVM interpreter strives for maximal as-is portability. To such avail, it The EVM interpreter supports all required opcodes and Ethereum precompiles to strive for maximal portability.
Functional and technical departures from Ethereum's standard expectations are documented herein.

The FEVM runtime actor motivates some changes in the FVM.

Syscalls are modified, syscalls are added, new environmental data is required, and new exit codes are created.
The concept of a TipsetCID is also introduced formally, and is of required implementation by clients.

This FIP is dependent on [FIP-0048] (f4 address class), [FIP-0049] (Actor events), and [FIP-0055] (Supporting Ethereum Accounts, Addresses, and Transactions).

Change Motivation

A basic requirement to achieve EVM compatibility is to be able to run EVM smart contracts.
Given the inability to deploy user-defined Wasm actors (arriving at a later stage of the FVM roadmap), we introduce this capability by adding a new built-in actor to the network.
This actor is accompanied by FVM and client changes necessary for functional completeness.

Specs

For more technical details, please see https://github.com/filecoin-project/FIPs/pull/569/files.

Feedback & questions are welcomed in this discussion!

[Stebalien]

FEVM interacts with native method numbers in two ways:

1. It allows users to implement "native methods" by implementing handle_filecoin_method in solidity to handle arbitrary filecoin method numbers > 1024.
2. It allows users to call native methods with the call_actor precompile (again, restricted to methods > 1024.

Proposal: Restrict FEVM method numbers to 32 bits. Filecoin itself supports 64bit method numbers, but method numbers > 32 bits aren't currently used. If we ever want to restrict these method numbers, now is the time.

Motivation:

1. This would bring method numbers in-line with Solidity function selectors.
2. If we ship with support for the full 64bit range, we can't change it.

I have no strong motivation for this, but we do need to make a decision.

[Stebalien]

cc @anorth, @ZenGround0, and @arajasek who may care about this particular decision.

[anorth]

That decision sounds fine.

But

allows users to call native methods with the call_actor precompile (again, restricted to methods > 1024.

Why is this restricted? I didn't understand this from my first reading of the FIP. This seems unnecessarily limiting to future native/EVM interop.

[Stebalien]

• For handle_filecoin_method, we needed to reserve space for native methods.
• For call_actor, we didn't want the user to call these methods (for now). There's no way, on the receive side, to distinguish between "was called by some native EVM-runtime level code" and "was called by the user through call_actor".

We can likely loosen the second restriction in a future upgrade.

[Stebalien]

That decision sounds fine.

But do you think it's a good idea?

Currently, we don't restrict the maximum method number. I'm asking if you believe that we should. I don't have a strong motivation to do so, but I figured you might (or might not in which case we won't do anything).

[anorth]

I don't get the call_actor use case. It sounds like something patching over a shortcut/assumption taken elsewhere. But probably not worth explaining to me. A future user-developed FEVM actor can just drop the restriction if we don't do it first.

But do you think it's a good idea?

Soft no, I guess. I can't find a good motivation for it, so simpler not to.

[anorth]

I noticed that some things (like CALL) treat built-in account actors as special. I don't think this is a good idea as it will cripple future account abstraction efforts. With good account abstraction there isn't really a meaning to whether an actor "is an account" – many actors codes will be able to originate messages, and through code upgrades this might even be dynamic. Treating built-in accounts differently will make it difficult for "abstract" accounts to play on the same level ("scare quotes" because I would like to reach a point where there's literally no technical distinction between the built-in account actor and other accounts).

I infer from the FIP that the EVM actor is using the get_builtin_actor_type and/or get_code_cid_for_type syscalls. IMO these should be considered deprecated. We're somewhat actively trying to remove existing uses of them from the built-in actors, especially those that we'd like to eject from the built-in set. filecoin-project/builtin-actors#424 (comment)

What's the reasoning for these decision, and can we change them?

[Stebalien]

@raulk said everything I would. I think the simplest way forward would be to implement InvokeEVM (FRC0042) on the account/eth-account actors, but that can also happen in a future upgrade.

OT:

Re: deprecation of get_builtin_actor_type and get_code_cid_for_type syscalls

• For miner actors, @anorth has previously suggested simply checking with the power actor.
• For placeholders, we'll probably need to introduce an is_placeholder syscall, eventually (unless we replace the current CID with something that's guaranteed to be stable).

[anorth]

now that we've moved InvokeContract to its FRC42-compliant method number, it might be safe to make CALL simply send to that method number on the recipient

This sounds great, especially for all the future-compatible reasons like native actors presenting an EVM API for seamless interop.

For placeholders, yes I think an is_placeholder syscall sounds quite reasonable. This concept is built into the VM and is not specific to EVM, and probably here to stay.

Forgive my ignorance, but is the issue with CALLing EthAccount or other accounts that CALL is how pure sends are made (i.e there's not a different opcode for that) and so you want to avoid dispatch costs when the intention is to make a pure send? Are there alternatives to this? This design seems to be inferring the intention of the caller by the type of the callee but this strikes me as a bit off. It's not going to work for abstract accounts - can we find something that will?

I think the 2300 gas thingy is a reasonable decision, and of course more general because it'll work for other actors too. Is that not sufficient? And what's the tradeoff here? Is it that bad that a user may pay more gas if their UI fails to set 2300 gas?

[Stebalien]

Forgive my ignorance, but is the issue with CALLing EthAccount or other accounts that CALL is how pure sends are made (i.e there's not a different opcode for that) and so you want to avoid dispatch costs when the intention is to make a pure send? Are there alternatives to this? This design seems to be inferring the intention of the caller by the type of the callee but this strikes me as a bit off. It's not going to work for abstract accounts - can we find something that will?

The issue is that other accounts (e.g., the builtin account) don't implement InvokeEVM, so calling the InvokeEVM method on them will fail. So the simple answer here is to implement that method on any account type that wants to be CALLable.

[anorth]

I'm really happy the special-case depending on target type is removed from CALL in https://github.com/filecoin-project/FIPs/pull/607/files. Can we achieve the same for DELEGATECALL?

3. If the target is an account, placeholder, or an EthAccount actor ([FIP-0055]), it returns nothing and success (pushes 1 onto the stack).
4. If the target is any other type of actor, it returns nothing and failure (pushes 0 onto the stack).

Let's say I accept the special case of checking for the same code CID as the caller for "security reasons", and also the introduction of an is_placeholder syscall (or a none/placeholder/actor enum for extensibility). The remaining objection is divergent behaviour for built-in accounts or EthAccounts.

Why do we need the success result for accounts? I did do a bit of searching but couldn't find where this is discussed for Ethereum. Could we generalise to return success if we try to fetch the EVM bytecode from the target and it returns the empty block?

1. Call GETBYTECODE. If this succeeds and returns empty block (account, placeholder, future abstract accounts), return nothing and succeed. If it fails, fail.
2. Check if target code CID matches mine. If so, InvokeContractDelegate on self with it.
3. Otherwise fail, refusing to execute the code

[Stebalien]

This would be an explicit decision with security implications. Right now, the user can assume that the target actor (the one called with DELEGATECALL) "behaves" like a proper EVM contract. Specifically:

1. The bytecode can't change over the course of a transaction.
2. The bytecode "hash" (as reported by the actor) matches the actual bytecode. Ideally we'd just use the bytecode's CID for this, but we don't currently allow keccak256 CIDs.

On the other hand, we could just say "don't delegatecall into actors you don't trust", which is pretty reasonable. To do that, we'd need to:

1. Define a GetEVMBytecode FRC42 method.
2. Blindly call that method on the target actor to get its bytecode, then execute the returned bytecode.

And yes, this would magically work for accounts as well.

[anorth]

Related to the above, what's the motivation for the get_actor_type precompile 😱? The main reason we haven't rushed to deprecate these syscalls sooner is that their use is constrained and we can prevent adding more callers. Exposing it here will lock it in forever, along with the need to support its function as built-in actors change, are ejected from built-ins etc. There's usually a different, better way to achieve whatever the goal is behind using that syscall.

[raulk]

I've been advocating for this behaviour for a while.

[anorth]

Although we probably want to continue rejecting methods less than the minimum FIP-0042 method number by default, right?

No I wouldn't bake FIP-0042 in more than necessary here.

[Stebalien]

@anorth I'm confused. We currently reject calls from non-builtin actors to methods less than the minimum FRC-0042 number.

If we simply accepted low-numbered methods, we'd lose our private space for adding/changing new methods.

[anorth]

Ah I was missing context. You're referring to the fact that all built-in actors currently reject low numbered methods as a means of preserving namespace for builtin-only methods, which is all the old ones.

The built-in account might be a special case here. I'm of course thinking forward to the implementation of AA at which point the account actor would be another candidate for kicking out of built-ins, a totally generic simple thing that just does message validation with a pubkey. The account actor has no methods that we'd want to prevent anyone calling, with the possible exception of that we want to deprecate them, and it's hard to imagine adding any more.

So, ok for simplicity and conformity with other built-ins, fine to keep rejecting them for now. But long term I see no reason to care about the numbers between 3 and 1<<24, and would prefer they inherited the always-succeed functionality. But we can do that later.

[Stebalien]

Fair enough, we can reconsider these restrictions later anyways.

My primary concern is actually just keeping a bit of "private" space. Said space can be used to create groups of actors that all trust each other in some way.

[Stebalien]

Method 0

Currently, EVM contracts accept funds without running code on method 0. Unfortunately, this could turn into a potential footgun if a user sends funds to a smart contract on method-0 (e.g., due to some tooling) and expects that smart contract to run some code to, e.g., credit the user's account.

Proposal

Provide a way to disable accepting funds on method 0.

Specifically:

1. Add a bitfield (stored as an integer) to the actor-root state object to record actor "flags". Define bit 0 as "reject value transfers".
2. Add a new syscall self::reject_value_transfers(boolean) to toggle accepting/rejecting method-0.
3. When sending on method 0, check these flags and reject the send if the bit is set.

This proposal will add exactly one byte to every actor state-root (until we have more than 5 flags), so it shouldn't have a large impact.

Alternatives

• Do nothing: At this point, this is a UX and safety improvement, not a security fix.
• EVM special casing: We could implement this by special-casing the EVM in the FVM (for now) and work towards a more complete feature in the future.
• Implement this with actor-code metadata instead of making it actor-instance specific. This saves a bit of state (one byte per actor object) however:
  • It's less flexible.
  • It requires defining an actor-code metadata format.
  • Value transfers would require loading this additional metadata object (which could be cached).

Future Uses

In the future, native actors can use this feature to strictly control the funds they can accept (e.g., to prevent dusting).

Furthermore, I expect we'll find additional uses for this bitfield (e.g., to opt into new features/semantics).

[raulk]

From a product perspective, it seems quite important to disallow method 0 on EVM smart contracts due to the above reason: the contract must be given an opportunity to reject value (which is the default Solidity behaviour).

If we allowed method 0, native bare sends from native wallets like Glif, or exchange withdrawals, would result in depositing the value via method 0 and moving on, even if the contract was designed to reject those by not implementing the said hooks.

We obviously can work with those transaction origins to ask them to do something different if the target is an EVM smart contract (or an f410f address, since placeholders and EthAccounts can now accept arbitrary method numbers), but this course of action seems like a mitigation for a knowingly poor design decision.

[raulk]

It's already well established in Ethereum that sending the native token to a smart contract won't and can't execute any code.
"Everyone knows" you have to use TransferFrom.

I'm not following this @anorth -- transferFrom is a method on token contracts. How is this related to the native currency?

[raulk]

@Stebalien Proposal as presented SGTM. I'm happy to draft this change in FIP-0054 under FVM changes to take some load off your plate so you can focus on implementing it; let me know.

[Stebalien]

After discussions within the team, we've decided to punt on this change for now to preserve scope. The "best" solution here would be to actually run code on method-0, but that's a larger change that would require an entirely new FIP.

We will revisit this in a future upgrade.

[anorth]

Thanks for the clarifications above. I don't have a particular objection to a mechanism disable accepting funds on method 0 in the future, apart from reductions in complexity. And the alternative of permitting code to run may be better.

[raulk]

Bare sends and code

Context

EVM smart contracts run code on bare value transfers. This code can REVERT to reject the transfer, log an event, query storage. Solidity provides a gas stipend of 2300 when calling address.transfer() or address.send(), which is insufficient to write state, call, create a contract, or do more intensive work. By default, Solidity smart contracts do not accept bare value transfers, unless the author implements the receive() or fallback() function. SELFDESTRUCT is an exceptional instruction as it stealthly deposits the value in the beneficiary without invoking smart contract logicly.

Current design

• EthAccounts and Placeholders now accept any method number. A non-0 method, incurs in a dispatch and no-ops in bytecode.
• EVM smart contracts only expose their logic externally via InvokeEVM (method num FRC42("InvokeEVM")). Sends on method 0 will not dispatch smart contract logic.
• Transitory Delegated signature verification logic only accepts Method = InvokeEVM. In other words, it's not possible for EthAccounts (or Placeholders) to send on method 0.
• Eth JSON-RPC methods eth_sendRawTransaction and eth_call methods produce correct Delegated signatures, i.e. they statically set Method = InvokeEVM.

Product impact evaluation

Origin: external transactions from Ethereum wallets

Eth JSON-RPC always sets Method = InvokeEVM.
Valid senders: EthAccounts and Placeholders that will immediately promote to EthAccounts.

Sender	Receiver	How	Method number	Details
f410 (EthAccount)	EVM smart contract	Submit transaction	InvokeEVM	✅ Incurs in dispatch and triggers smart contract logic
f410 (Placeholder)	EVM smart contract	Submit transaction	InvokeEVM	✅ Incurs in dispatch and triggers smart contract logic
f410 (EthAccount/Placeholder)	EthAccount/Placeholder	Submit transaction	InvokeEVM	✅ Incurs in dispatch and succeeds with no-op
f410 (EthAccount/Placeholder)	Native account	Submit transaction	InvokeEVM	✅ Incurs in dispatch and succeeds with no-op
f410 (EthAccount/Placeholder)	Non-account actor (Miner, Market)	Submit transaction	InvokeEVM	⚠️ Always fails as InvokeContract method is not recognized
f410 (EthAccount/Placeholder)	inexistent Eth address	Submit transaction	InvokeEVM	✅ Creates a placeholder actor

Origin: Filecoin wallets and other Filecoin-aware origins (e.g. exchanges)

Can specify an arbitrary method number

Sender	Receiver	How	Method number	Details
f1 or f3 native account	EVM smart contract	Submit transaction	Send	⚠️ Deposits value in smart contract and moves on
f1 or f3 native account	EVM smart contract	Submit transaction	InvokeEVM	✅ Incurs in dispatch and triggers smart contract logic
f1 or f3 native account	EthAccount/Placeholder	Submit transaction	Any	✅ Incurs in dispatch and succeeds with no-op
f1 or f3 native account	inexistent f410 address	Submit transaction	Any	✅ Creates a placeholder actor

Origin: internal sends from EVM smart contracts

Through CALL opcodes and call_actor precompiles.

Sender	Receiver	How	Method number	Details
EVM smart contract	0x (EthAccount/Placeholder)	CALL opcodes	InvokeEVM	✅ Incurs in dispatch and triggers smart contract logic
EVM smart contract	0x (EVM smart contract)	CALL opcodes	InvokeEVM	✅ Incurs in dispatch and triggers smart contract logic
EVM smart contract	0x (inexistent)	CALL opcodes	Any	✅ Creates a placeholder actor
EVM smart contract	Masked ID 0x (native account)	CALL opcodes	InvokeEVM	✅ Incurs in dispatch and succeeds with no-op
EVM smart contract	Masked ID 0x (built-in non-account)	CALL opcodes	InvokeEVM	☑️ Always fails as InvokeContract method is not recognized (intended, use call_actor precompiles)
EVM smart contract	Masked ID 0x (built-in non-account)	call_actor opcodes	Send	✅ Deposits value at FVM level with no dispatch
EVM smart contract	0x (inexistent)	call_actor opcodes	Any	✅ Creates a placeholder actor
EVM smart contract	0x (EthAccount/Placeholder)	SELFDESTRUCT	Send	✅ Deposits value at FVM level with no dispatch (matching Ethereum)
EVM smart contract	0x (EVM smart contract)	SELFDESTRUCT	Send	✅ Deposits value at FVM level with no dispatch (matching Ethereum)
EVM smart contract	0x (inexistent)	SELFDESTRUCT	Any	✅ Creates a placeholder actor

Origin: from built-in actors

Calling into EVM smart contracts or EthAccounts/Placeholders.

Sender	Receiver	How	Method number	Details
Miner#WithdrawBalance	EthAccount/Placeholder		Send	✅ Incurs in dispatch and succeeds with no-op
Miner#ReportConsensusFault	EthAccount/Placeholder		Send	✅ Incurs in dispatch and succeeds with no-op
Miner#DisputeWindowPoSt	EthAccount/Placeholder		Send	✅ Incurs in dispatch and succeeds with no-op
Market#WithdrawBalance	EthAccount/Placeholder		Send	✅ Incurs in dispatch and succeeds with no-op
Paych#Collect	EthAccount/Placeholder		Send	✅ Incurs in dispatch and succeeds with no-op
(all of the above)	f410 inexistent		Send	✅ Creates a placeholder actor
Miner#WithdrawBalance	EVM smart contract		Send	⚠️ Deposits value in smart contract and moves on
Miner#ReportConsensusFault	EVM smart contract		Send	⚠️ Deposits value in smart contract and moves on
Miner#DisputeWindowPoSt	EVM smart contract		Send	⚠️ Deposits value in smart contract and moves on
Market#WithdrawBalance	EVM smart contract		Send	⚠️ Deposits value in smart contract and moves on
Paych#Collect	EVM smart contract		Send	⚠️ Deposits value in smart contract and moves on

Summary of product caveats

Today:

1. Ethereum accounts can't interact with built-in actors, with the exception of sending value to built-in accounts.
   • That is, an Ethereum account cannot directly call methods on a miner, market, multisig, etc. actor
   • They can do so indirectly, by can invoking EVM smart contracts that end up invoking those methods.
   • If this is immediately needed, some form of a proxy agent actor may be useful while these inabilities are solved at a protocol level.
2. A bare transfer from f1 or f3 accounts to an EVM smart contract will not cause smart contract logic to run.
   • In other words, the smart contract has no possibility of rejecting the transfer. Rejecting is the default state of Solidity, unless the above functions are exported.
3. Filecoin wallets or exchanges should set method number to InvokeEVM to prevent loss of funds when sending to a f410 recipient. Otherwise, if the recipient is a smart contract that would've conditionally or unconditionally rejected the funds, or emitted an event, funds may be lost.
4. When an EVM smart contract is the recipient of funds sent from built-in actors through Miner#WithdrawBalance, Miner#ReportConsensusFault, Miner#DisputeWindowPoSt, Market#WithdrawBalance, Paych#Collect, those sends will NOT trigger smart contract logic.

[raulk]

Notes from work session

Future alternative A: Method 0 runs code and method u64::MAX represents BareTransfer:

Pros:

• No tooling changes. Wallets and exchanges don’t need to adapt. Default send method does the right thing.
• Pretty clean change, just solves the problem.
• EVM SELFDESTRUCT invokes BareTransfer.
• More aligned with the actor model, where all mutations go through the actor's inbox (no mutations are performed on the actor externally). BareTranfer is an exceptional escape hatch.

Cons:

• Changes semantics of method 0. Somewhat unclear consequences of the semantic change itself.
  • AI: study the impact.
• Send now needs to dispatch to Wasm. New overhead on Send. Sends might get more expensive? How much exactly? Tolerable?
  • AI: study impact on naked value transfers.
• Requires built-in actor changes:
  • Paych needs to be updated so that bad actor can't block Collect, needs a FIP. Paych not widely used, could potentially be solved in a next upgrade.
  • Lotus tooling will need to handle the paych change
  • Miner#Withdraw – not a problem because you’re in control (trusted)
  • Market#Withdraw – not a problem because you’re in control (trusted)
• Needs a FIP
• Prior objections from @anorth

Notes:

• No impact to delete_actor as it moves balances in the state tree directly

Future alternative B: New, dedicated ReceiveFIL method that runs code

Pros:

• No changes to the semantics of method 0.

Con:

• Requires every single agent to adapt.
• 99.9999% a no go.

[anorth]

Thanks for this summary and analysis. Running code on method 0 seems like a reasonable proposal to me. As far as I can tell, there's nothing here that involves special-casing built-in account actors or EVM.

I might suggest trying a bit to avoid adding the BareTransfer, to again reduce the complexity. If an EVM contract nominates another contract as beneficiary when destructing, you could add a new method number to accept that value without invoking the EVM code? However I can see it might be tricky to handle a non-EVM beneficiary.

We also need to clarify how this interacts with the read_only flag. Can native value be sent with a read_only method? If the caller can't do anything in response, does this amount to something similar to BareTransfer? Do we need the BareTransfer method number in that case?

[raulk]

I might suggest trying a bit to avoid adding the BareTransfer, to again reduce the complexity.

I am personally for this. I consider it dangerous for the caller to get to determine how the callee gets (or not) to process funds. It adds an extra dimension of complexity for the contract developer to solve for, e.g. now they may have state that's not reconciled with their balance. It also breaks the actor model for the above reason. That said, some protocol devs have defended retaining a "bare transfer" mechanism in prior conversations, so I'm sure this discussion will keep on giving.

If an EVM contract nominates another contract as beneficiary when destructing, you could add a new method number to accept that value without invoking the EVM code? However I can see it might be tricky to handle a non-EVM beneficiary.

Exactly. Although we can also decide to firewall this and disallow SELFDESTRUCT with non-EVM non-account beneficiaries. Alternatively, we can make BareTransfer optional in actors, so actors get to decide if they are willing to unconditionally accept value. SELFDESTRUCT would only work with such actors.

We also need to clarify how this interacts with the read_only flag. Can native value be sent with a read_only method? If the caller can't do anything in response, does this amount to something similar to BareTransfer? Do we need the BareTransfer method number in that case?

I consider these orthogonal.

Method	read_only	Notes
BareTransfer	false	Deposits value and moves on
BareTransfer	true	Deposits value and moves on
Send	false	Deposits value and calls the actor so it can reject it, write state, call another actor, forward it, etc.
Send	true	Deposits value and calls the actor who can query state, reject it, but not forward, call, write state, etc.

A BareTransfer would transfer the value unconditionally, a Send with read_only=true would still allow the callee to reject the transfer.

[anorth]

we can make BareTransfer optional in actors, so actors get to decide if they are willing to unconditionally accept value

At this point it's very similar to to Steb's original proposal to provide a way to refuse deposits on method 0, including the default state of permitting it.

[magik6k]

Future alternative A: [...] Changes semantics of method 0. Somewhat unclear consequences of the semantic change itself.

I believe this is done to make basic transfers really, really cheap. The other nice thing is that you can't reject transfers from actors self-destructing.

Even the very early spec had the method zero be a simple value transfer - https://github.com/filecoin-project/specs/blob/prevspec/state-machine.md#sending-funds, unfortunately no explanation behind that mechanism seems to be there.

We could preserve the really cheap transfers by hard-coding method zero behavior for native accounts.

[arajasek]

What is the timestamp that clients should supply when creating an FVM to execute over a null round? The FIP says it should be the Timestamp of the execution epoch, which suggests it should be the timestamp that the null epoch would have had if there had been a tipset present.

Can we confirm this, and maybe make it explicit in the FIP?

[raulk]

Let's unpack this concern a little.

1. In a null round, there are no explicit messages to execute because there are no blocks.
2. However, we still need to execute cron via an implicit message.
3. This execution happens by backfilling all the null rounds when the next non-null tipset (containing blocks) executes.
4. Cron does not currently use the timestamp; however, it's there for it to use in the future, so we must make sure it's consistent.
5. I would expect the timestamp to be fed to be the timestamp of the execution of the epoch for which we're backfilling that cron execution, i.e. as you say, the would've-been timestamp if that execution would've happened on time.

I will specify this edge case explicitly in the FIP, but also noting that Lotus is non-compliant, as we construct the VM with the timestamp of the block with the smallest timestamp in the tipset we're executing. In practice, this is not a problem because, as I say, Cron does not use the timestamp, but we absolutely should fix it.

Thanks for raising this!

[arajasek]

I will specify this edge case explicitly in the FIP, but also noting that Lotus is non-compliant, as we construct the VM with the timestamp of the block with the smallest timestamp in the tipset we're executing. In practice, this is not a problem because, as I say, Cron does not use the timestamp, but we absolutely should fix it.

Constructing VMs with timestamps is something new introduced in this proposal -- it's misleading to say Lotus is non-compliant when discussing ambiguity in a proposal. Lotus is compliant with what's been proposed so far, and will need to be updated when we clarify this edge-case.

[raulk]

We're probably in bikeshed territory, and I realise my comment might have come across as finger-pointing, which it absolutely wasn't the intention!

What I'm saying is that the execution epoch of a null round is already well-specified. In fact, we already feed it into the VM when we construct it. So the "timestamp of the execution epoch" (as originally phrased crudely), is the timestamp of the epoch we're already feeding into the VM.

I don't think this is a matter of ambiguity, but rather that the spec required the reader to solve for this edge case in their heads. That should be clarified in #623.