Skip to content

Revisit human-readable presentation of EVM opcodes #1602

Description

@quasiyoke

During the discussion of pull request #1544, we discussed that the representation of the opcode list in memory may be improved (#1600), and the code displaying opcodes may need refinement #1544 (review)

I prefer a solution like this. It has disadvantages:

  1. Requires new dependencies:
    • num-derive — we haven’t used this before.
    • num-traits — we already use this directly.
    • strum — is used in our subdependencies.
  2. Will increase build time.
#!/usr/bin/env rust-script
//! ```cargo
//! [dependencies]
//! num-derive = "0.4.2"
//! num-traits = "0.2.19"
//! strum = { version = "0.27.2", features = ["derive"] }
//! ```

use num_derive::FromPrimitive;
use num_traits::FromPrimitive;
use strum::IntoStaticStr;

#[derive(FromPrimitive, IntoStaticStr)]
#[repr(u8)]
enum Opcode {
    Stop = 0,
    Add = 1,
    Mul = 2,
}

fn main() {
    let s: &str = Opcode::from_u8(2).unwrap().into();
    assert_eq!(s, "Mul");
    println!("{}", s);
}

A part of #1560
As a follow up of #1544 (review)

Activity

  1. MOZGIII commented on Aug 27, 2025

    @MOZGIII
    Contributor

    Keep in mind we have to interop with evm::Opcode which we don't own

  2. quasiyoke commented on Aug 28, 2025

    @quasiyoke
    ContributorAuthor

    Via recent TWiR: https://sailor.li/ints-to-enums

    TLDR

    There're also:

    • derive_more::TryFrom — has a more idiomatic interface, is available in derive_more since 1.0.0.
    • int_enum — impls TryFrom<repr> as well.

    In beta there's std::mem::variant_count.

  3. MOZGIII commented on Aug 28, 2025

    @MOZGIII
    Contributor

    We would also need to support "other" opcodes - the ones we don't have the names for. Also, from my experience, strum is the to-go solution (other ones are worse one way or another).

  4. dmitrylavrenov commented on Nov 3, 2025

    @dmitrylavrenov
    Contributor

    Probably, reusing evm::Opcode and applying #1642 should cover our goal ?

    @quasiyoke

  5. quasiyoke commented on Nov 4, 2025

    @quasiyoke
    ContributorAuthor

    I underestimated how important future-proof support for “invalid” opcodes might be to us. For this reason, evm::Opcode is simply a wrapper around a u8, allowing for opcodes that are not yet known; so using an enum here would not be straightforward.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions