oguimbal / hyvm

Run arbitrary code on the EVM

👋 Hi ! I'm a technologist, and an opensource enthusiast.

---

I mostly maintain:

... among others 😀

---

I usualy prefer...

But I'm playing with/interested in...

...so I may switch to one of those soon

I also know quite well, but dont like as much...

hyvm's Issues

How to interact with the HyVM?

As a new user, how can I interact with the HyVM?

Are there tools available to compile to the bytecode executable by the HyVM? Or alternatively, Is there a particular method of extracting a specific function's bytecode from a previously compiled evm contract?

Verifier feature development

At this time, HyVM do not use a verifier but it can be enabled. A verifier can be used to add some check on calls to the HyVM. For example prevent specific opcodes to be executed or being able to only call one contract with the HyVM.
Other checks can be implemented at the discretion of the user.

The feature is not maintained for now, it needs tests, refactor and fixes.

refactor: improve static wrapper

I think the flow would be a bit more consistent if staticExec was actually just a fallback.

staticHyvm.staticcall("")

vs

staticHyvm.staticExec("")

There's an example here. 🫡

Jump destination validity

At this time, op_jump only checks if the destination is equal to 0x5B (jumpdest). But this is not sufficient to validate that the destination is valid: 0x5B could be a value inside a PUSH. More checks need to be done.
In case checks consume too much gas, those could be made optional as not verifying them would not prevent correct bytecode to be correctly executed (for example if bytecode was compiled using solc or equivalent).

https://ethereum.org/en/developers/tutorials/yellow-paper-evm/#943-jump-dest-valid

implement create?

is there any particular reason create is not implemented?

Feat request: Calldata

Right now it appears like calldata opcodes are essentially unused, they appear to just load zeros.

Would it make sense to add a calldata mechanism where calldata can be appended to the bytecode?

This might be a breaking change though.

Our use case would be that users can sign bytecode they wish to execute (eg. bytecode to do a limit order), but then the executing agent can add some execution-time variables in (eg. the execution fee recipient wallet or an extra slippage parameter).