@gakonst imo it can be done after

• revm release with interpreter trait (with ability to integrate custom interp with bytecode type for RISC-V, which starts with 0xFF and etc.)
• all freq used opcodes implemented as r55 syscalls (I mean, we easily can implement not all bytecodes for first iteration, but it needs to be at least enough for basic contracts)

Interpreter must be like:
“setup emulator from elf if the first byte of the bytecode is 0xff”

Don’t see the way to do it without kinda interpreter wiring released on revm, which we depends on here, because e.g.

we got RISC-V bytecode as interpreter input, it parses like legacy, then stripped 2 first bytes and flow goes incorrect, not going to handler

Maybe I’m missed smth

Btw the "starts with 0xff" thing was a quick convention hack we chose to make it work quickly, but should be improved. Any convention/architecture that makes it easier for revm is welcome

Maybe 2 bytes like other formats (such as EOF / EIP-7702)
To easily slice all types of code in equal way

https://github.com/bluealloy/revm/blob/main/crates/bytecode/src/bytecode.rs#L105-L115

prob with opcode 0xEF and some 2-bytes version will be good - https://github.com/ethereum/EIPs/blob/master/EIPS/eip-7702.md#delegation-designation

revm release with interpreter trait (with ability to integrate custom interp with bytecode type for RISC-V, which starts with 0xFF and etc.)

why not re-use the handler implementation Leo did above, which lets you re-use both EVM and RISCV?

revm release with interpreter trait (with ability to integrate custom interp with bytecode type for RISC-V, which starts with 0xFF and etc.)

why not re-use the handler implementation Leo did above, which lets you re-use both EVM and RISCV?

Was aware about how bytecode goes - will it be interp first like legacy
I intrigued and try to code now

Hi I would love to take on this

I finish, trying to deploy ERC-20

Contract size can get large quite quickly. Find ways to compress/optimize it.

@leonardoalt do we just turn off bytecode size limit for r5 contracts? I guess not. Mb we need to price it better?

Contract size can get large quite quickly. Find ways to compress/optimize it.

@leonardoalt do we just turn off bytecode size limit for r5 contracts?

Currently yes, here afaik: https://github.com/r55-eth/r55/blob/main/r55/src/exec.rs#L25

Though I suspect the reason why even the basic token contract is large is because we're using software TinyKeccak for Mapping instead of the Keccak syscall which is still unimplemented.