Enabling PragueTime causes the chain to not "seal"

[Amxx]

I noticed that the on the master, enabling prague causes the chain to behave strangely.

How to replicate:

• Take the master branch
  • confirmed on my side with commit 0a2f339 and aadcb88
• Edit params/config.go to add PragueTime: newUint64(0), in AllDevChainProtocolChanges
• compile and run dev
  • make geth && ./build/bin/geth --dev --http --http.api eth,web3,net
• perform a transaction
  • I'm using this node script

I am getting this log

INFO [03-07|10:54:33.034] Submitted transaction                    hash=0x31cbf838e2ab52ef37049d4b15182daaf39e90d4ba16bd9b33a63f0d7ea019ec from=0x54D2a8BC8AEAaf44212Fb60822050a59cC207188 nonce=1 recipient=0x0a8CDFfDE2d2A4e7DCcA85842f9f26516D21929C value=1,000,000,000,000,000,000
INFO [03-07|10:54:33.035] Starting work on payload                 id=0x038e8c8ba99271cd
INFO [03-07|10:54:33.036] Updated payload                          id=0x038e8c8ba99271cd number=1 hash=60320d..23a557 txs=2 withdrawals=0 gas=42000 fees=4.2e-14 root=e5a3ca..139ad4 elapsed="895.431µs"
WARN [03-07|10:54:33.036] Error performing sealing work            err="Unsupported fork"
INFO [03-07|10:54:33.036] Stopping work on payload                 id=0x038e8c8ba99271cd reason=delivery
WARN [03-07|10:54:33.069] Served eth_getTransactionReceipt         conn=127.0.0.1:33210 reqid=10 duration="82.621µs" err="transaction indexing is in progress" errdata="transaction indexing is in progress"

I understand Prague is still pretty much WIP, but this error is affecting testing of candidate EIP.

[Amxx]

Did not mean to add type:docs. Definitelly not a doc issue.

[karalabe]

Engine API spec says GetPayloadV3 can only be called during Cancun :)

Client software MUST return -38005: Unsupported fork error if the timestamp of the built payload does not fall within the time frame of the Cancun fork.

So the question is whether Prague is expected to introduce a new GetPayload version or if the spec will need to allow V3 to run during Prague too. As is, Geth if conforming to the specs :)

[Amxx]

Just to make sure, there are no plan to fix that, and make Prague "usable" ? What are the recommandations for testing Prague candidates ? Marking them as Cancun to bypass that and run them in an cancun dev chain doesn't sound right to me.

[holiman]

Prague uses GetPayloadV3 now, closing

[holiman]

Maybe I was too quick closing this

[holiman]

So, NewPayloadV3 has this check:

	if api.eth.BlockChain().Config().LatestFork(params.Timestamp) != forks.Cancun {
		return engine.PayloadStatusV1{Status: engine.INVALID}, engine.UnsupportedFork.With(errors.New("newPayloadV3 must only be called for cancun payloads"))
	}

And api.eth.BlockChain().Config().LatestFork(params.Timestamp) will return forks.Prague in this case. So this method is unusable.

Not sure how to best resolve this. Since a new payload format for Prague is not yet specified (afaik), I think the simplest would be to just accept Prague too:

	if current := api.eth.BlockChain().Config().LatestFork(params.Timestamp); current != forks.Cancun && current != forks.Prague {
		return engine.PayloadStatusV1{Status: engine.INVALID}, engine.UnsupportedFork.With(errors.New("newPayloadV3 must only be called for cancun payloads"))
	}

[MariusVanDerWijden]

I think this was happening when Prague wasn't fully merged to master yet. I think now that we have NewPayloadV4 I feel like this can be closed. Feel free to reopen if you still think this is an issue

[fvictorio]

Hi, I tried what @Amxx mentioned in the issue description, but it's not working for me. I receive a transaction type not supported: received type 4 error when sending an EIP-7702 transaction.

What's the easiest way to start a geth --dev instance that supports EIP-7702?