Holger Drewes

Hmm, honestly: why not? Most of our bug fixing is done fully independent from Hive. And when Hive points to some misbehavior and we can confirm for ourselves this is...

Published! 🎉

Release Overview: - `@ethereumjs/block` [6.0.0-alpha.1](https://github.com/ethereumjs/ethereumjs-monorepo/releases/tag/%40ethereumjs%2Fblock%406.0.0-alpha.1) - `@ethereumjs/blockchain` [8.0.0-alpha.1](https://github.com/ethereumjs/ethereumjs-monorepo/releases/tag/%40ethereumjs%2Fblockchain%408.0.0-alpha.1) - `@ethereumjs/client` [0.10.3](https://github.com/ethereumjs/ethereumjs-monorepo/releases/tag/%40ethereumjs%2Fclient%400.10.3) - `@ethereumjs/common` [5.0.0-alpha.1](https://github.com/ethereumjs/ethereumjs-monorepo/releases/tag/%40ethereumjs%2Fcommon%405.0.0-alpha.1) - `@ethereumjs/devp2p` [7.0.0-alpha.1](https://github.com/ethereumjs/ethereumjs-monorepo/releases/tag/%40ethereumjs%2Fdevp2p%407.0.0-alpha.1) - `@ethereumjs/ethash` [4.0.0-alpha.1](https://github.com/ethereumjs/ethereumjs-monorepo/releases/tag/%40ethereumjs%2Fethash%404.0.0-alpha.1) - `@ethereumjs/evm` [4.0.0-alpha.1](https://github.com/ethereumjs/ethereumjs-monorepo/releases/tag/%40ethereumjs%2Fevm%404.0.0-alpha.1) - `@ethereumjs/genesis` [0.3.0-alpha.1](https://github.com/ethereumjs/ethereumjs-monorepo/releases/tag/%40ethereumjs%2Fgenesis%400.3.0-alpha.1) - `@ethereumjs/mpt` [7.0.0-alpha.1](https://github.com/ethereumjs/ethereumjs-monorepo/releases/tag/%40ethereumjs%2Fmpt%407.0.0-alpha.1) -...

It's super easy to miss out on these renamings, there is so much stuff all over the place

Think we are further ahead down the road now, so this first-round experiment can be closed. Still a use case though mid term.

Great, sounds good! 🙂 👍

Side question: WDYT, we cannot yet declare EOF as stable, or can we? If not, we should (I would then do) declare this in code docs, README and the like.

Ok, I would have thought so (at the end it does not really matter if specs or we or both are not stable yet 😂 )! Will update this along...

Ok, here is a - a the end working (was complicated enough) - workerpool test with a simple keccak256 call, increasing the execution time from 80 to 120 ms: #3697...

Hi Jochem, thanks for directly picking this up and thinking this further along! I would agree that extracting VMExecution would bring the most benefit and might be the most approachable...