Cancun upgrade

[arcz]

We need to implement Cancun fork: https://github.com/aalimsahin/execution-specs/blob/master/network-upgrades/mainnet-upgrades/dencun.md

• [ ] EIP-1153: Transient storage opcodes
• [ ] EIP-4788: Beacon block root in the EVM
• [ ] EIP-4844: Shard Blob Transactions
• [ ] EIP-5656: MCOPY - Memory copying instruction
• [ ] EIP-6780: SELFDESTRUCT only in same transaction
• [ ] EIP-7514: Add Max Epoch Churn Limit
• [ ] EIP-7516: BLOBBASEFEE opcode

[msooseth]

Hi,

Thanks for packing it all together and creating an issue! Maybe not too hard to implement :)

At the same time, hevm is still far from being even used in the symbolic execution sense :cry: There was a bug where the released binary didn't even work for most people for the past ~6 months, and nobody caught it. That's... bad. So I am a bit conflicted on what to spend time on. If a tree falls in a forest and no one is around to hear it, does it make a sound? I'm not so sure. I'd rather lots of people heard the tree falling, maybe they'd complain, or fix it, or something. So I wanna make this thing more approachable, more usable, easier to access.

What do you think?

[no-fee-swap]

Hi,

Thanks for packing it all together and creating an issue! Maybe not too hard to implement :)

At the same time, hevm is still far from being even used in the symbolic execution sense 😢 There was a bug where the released binary didn't even work for most people for the past ~6 months, and nobody caught it. That's... bad. So I am a bit conflicted on what to spend time on. If a tree falls in a forest and no one is around to hear it, does it make a sound? I'm not so sure. I'd rather lots of people heard the tree falling, maybe they'd complain, or fix it, or something. So I wanna make this thing more approachable, more usable, easier to access.

What do you think?

@msooseth Thanks for the effort. We are heavily relying on hevm. We have been waiting for this so that we can fuzz our smart contracts. Supporting Cancun (at least "tload", "tstore", and "mcopy") would be greatly appreciated. Anxiously waiting. Thank you.

[0xalpharush]

I believe these won't require changes since they pertain to the consensus layer: EIP-7044: Perpetually Valid Signed Voluntary Exits EIP-7045: Increase Max Attestation Inclusion Slot

[drgorillamd]

Hi, Thanks for packing it all together and creating an issue! Maybe not too hard to implement :) At the same time, hevm is still far from being even used in the symbolic execution sense 😢 There was a bug where the released binary didn't even work for most people for the past ~6 months, and nobody caught it. That's... bad. So I am a bit conflicted on what to spend time on. If a tree falls in a forest and no one is around to hear it, does it make a sound? I'm not so sure. I'd rather lots of people heard the tree falling, maybe they'd complain, or fix it, or something. So I wanna make this thing more approachable, more usable, easier to access. What do you think?

@msooseth Thanks for the effort. We are heavily relying on hevm. We have been waiting for this so that we can fuzz our smart contracts. Supporting Cancun (at least "tload", "tstore", and "mcopy") would be greatly appreciated. Anxiously waiting. Thank you.

First and foremost, thank you for hevm effort @msooseth / EF FV team!

Seconding this answer (and being unfortunately Haskell agnostic, I can't really help beside by voicing my issue), I'm now blocked a bit downstream, when trying to implement echidna property tests for contracts we've wrote using tstore/tload.

[msooseth]

Right, I'll pick some things up here and elsewhere in the issues. I am finally back from my research break so I hopefully can start things moving :)

[ethever]

Hi, any progress about this issue?