Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

conformance driver ExecuteMessage function needs to pass timestamp #11890

Closed
5 of 11 tasks
Schwartz10 opened this issue Apr 18, 2024 · 0 comments
Closed
5 of 11 tasks

conformance driver ExecuteMessage function needs to pass timestamp #11890

Schwartz10 opened this issue Apr 18, 2024 · 0 comments
Labels
kind/bug Kind: Bug

Comments

@Schwartz10
Copy link
Contributor

Checklist

  • This is not a security-related bug/issue. If it is, please follow please follow the security policy.
  • I have searched on the issue tracker and the lotus forum, and there is no existing related issue or discussion.
  • I am running the Latest release, the most recent RC(release canadiate) for the upcoming release or the dev branch(master), or have an issue updating to any of these.
  • I did not make any code changes to lotus.

Lotus component

  • lotus daemon - chain sync
  • lotus fvm/fevm - Lotus FVM and FEVM interactions
  • lotus miner/worker - sealing
  • lotus miner - proving(WindowPoSt/WinningPoSt)
  • lotus JSON-RPC API
  • lotus message management (mpool)
  • Other

Lotus Version

Using lotus API:
`github.com/filecoin-project/lotus v1.26.1-0.20240408080634-e68b762b40cd`

Repro Steps

No response

Describe the Bug

When running simulations against FEVM smart contracts using the ExecuteMessage function

func (d *Driver) ExecuteMessage(bs blockstore.Blockstore, params ExecuteMessageParams) (*vm.ApplyRet, cid.Cid, error) {
, the Timestamp field needs to be populated in order for block.timestamp to propagate with data. The result is that any smart contracts that rely on block.timestamp to compute their logic will likely fail, as block.timestamp is always zero.

A few (probably naive) ways to fix:

  1. We treat the VM like mainnet (i.e. chainID 314) and we use the legitimate timestamp for the given epoch. This requires some extra work, as we need to know the genesis epoch or genesis timestamp in order to compute the timestamp at any future epoch. I couldn't see these values coded as constants anywhere, so not sure the best way to arrive at these values
  2. We simply pass the current timestamp (i.e. time.Now()) and treat the passed epoch as "ChainHead".
  3. The caller passes Timestamp through via the MessageParams struct. This is likely my favorite as its most flexible for the caller.

Logging Information

N/A
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/bug Kind: Bug
Projects
Status: ☑️Done (Archive)
Development

No branches or pull requests

2 participants