Revisit `Opcode` type #1642

dmitrylavrenov · 2025-10-31T11:25:54Z

* Add build for evm-tracing at e2e code job * Skip bash tests for evm-tracing test suite * Add template for evm-tracing test suite

Runtime level implementation

Client-side implementation

Implement RPC side

MOZGIII · 2025-11-03T12:49:35Z

I think the original idea of the code structure was that the client doesn't know specifics of the opcodes - but the runtime does; in the same sense - client doesn't have the dependency on an evm crate for the purposes of listing known opcodes; otherwise we can't simply upgrade the runtime. That said, maybe the evm::Opcode type supports opaque conversion and representing the "other" variant - but I didn't check

dmitrylavrenov · 2025-11-03T12:55:44Z

I think the original idea of the code structure was that the client doesn't know specifics of the opcodes - but the runtime does; in the same sense - client doesn't have the dependency on an evm crate for the purposes of listing known opcodes; otherwise we can't simply upgrade the runtime. That said, maybe the evm::Opcode type supports opaque conversion and representing the "other" variant - but I didn't check

In this case we can just use u8 on client side similar to current implementation to avoid being dependent on evm crate.

MOZGIII · 2025-11-03T17:46:18Z

That's ideal too if we always need a single byte; that said - we might need more; the old way of doing things communicated opcodes via, essentially, strings - right? Maybe we want to do the same - but with a more narrow memory footprint

dmitrylavrenov · 2025-11-03T18:27:03Z

@MOZGIII

There are no more than 256 different opcodes. The number can be changed based on future possible more opcodes in future EVM versions.

So, the question is should we take into account more than the current number ? Or, is it enough to consider u8 for current EVM version opcodes number ?

I don't like their current representation as they map opcode to string representation and then convert to vector of u8.

quasiyoke

@MOZGIII

the original idea of the code structure was that the client doesn't know specifics of the opcodes

It’s hard to say that the client previously didn't know what opcodes were, and treated them as black boxes. For example, various kinds of CREATE were listed, as well as different CALLs.

maybe the evm::Opcode type supports opaque conversion and representing the "other" variant.

Yes, they support it in a sense, since opcodes can include "invalid" bytes. They didn't make Opcode an enum.

We might need more [than a single byte].

Currently, they haven't used about 30% of the available opcode space. I think the solution proposed here is a good balance between complexity, future-proofing, and performance.

crates/evm-tracing-client/src/utils.rs

MOZGIII

I think the best way is to have a new type that would pretty much be this:

enum MarshalledOpcode {
  Code(evm::Opcode),
  Unknown(SmallVec<8>), // 8 cause the longest is 13 and the epmeric estimate of max length for the most popular ones in 7-ish
}

It is unlikely that the previously used and deprecated opcodes names will ever be reused - so it quite a safe bet. But then again - maybe just do the SmallVec<8> and be done with this?

We don't want to have constraints from the client side here - we want runtime to fully manage the tracing side. Note that the client side is made such that it never needs to actually deal with the opcode itself - only call context.

dmitrylavrenov · 2025-11-10T08:29:01Z

Revisited by introducing MarshalledOpcode(SmallVec<8>) based on the discussions above.

crates/evm-tracing-events/src/marshalled_opcode.rs

MOZGIII · 2025-11-11T07:23:09Z

crates/evm-tracing-events/src/marshalled_opcode.rs

+impl Encode for MarshalledOpcode {
+    fn encode(&self) -> Vec<u8> {
+        self.0.clone().to_vec().encode()
+    }
+}
+
+impl Decode for MarshalledOpcode {
+    fn decode<I: codec::Input>(input: &mut I) -> Result<Self, codec::Error> {
+        let bytes = Vec::decode(input)?;
+        Ok(MarshalledOpcode(SmallVec::from_vec(bytes)))
+    }
+}


Needs more optimized encode/decode

Can you suggest something as I spent a lot of time trying different ways and met some issues with the encoding and decoding result data.

Then I decided to walk through codec implementation and this approach comes based on implementation for String.

The idea is to avoid going through the Vec and an associated allocation; also through the String due to the underlying Vec.

What about using Cow instead of Vec - eb7fec8

What generics params for cow do you have in mind?

If we have a malloc somewhere it (obviously) defeats the purpose; can we avoid a malloc at all there? Given that they go through the encode/decode traits? I think there should be a way

fixed type - slice [u8]

Check whether Vec<u8> is used under the hood anywhere there - afaik borrow for [u8] is Vec<u8>; then it won't work

crates/evm-tracing-events/src/marshalled_opcode.rs

MOZGIII · 2025-11-13T13:15:13Z

crates/evm-tracing-client/src/serialization.rs

-    let d = std::str::from_utf8(opcode)
-        .map_err(|_| S::Error::custom("Opcode serialize error."))?
-        .to_uppercase();
-
-    serializer.serialize_str(&d)
+    serializer.serialize_str(&opcode.to_string())


Code before didn't malloc (used str); now it does (goes through String); two questions here @dmitrylavrenov.

Do you understand the difference?

Why change it this way?

it comes from Display implementation that uses malloc

I see, should be improved

MOZGIII · 2025-11-13T13:17:53Z

crates/evm-tracing-events/src/marshalled_opcode.rs

+        write!(
+            f,
+            "{}",
+            sp_core::sp_std::str::from_utf8(self.0.as_slice()).map_err(|_| core::fmt::Error)?
+        )


This is a very convoluted way to write this

Suggested change

write!(

f,

"{}",

sp_core::sp_std::str::from_utf8(self.0.as_slice()).map_err(|_| core::fmt::Error)?

)

let s = sp_core::sp_std::str::from_utf8(self.0.as_slice()).map_err(|_| core::fmt::Error)?;

write!(

f,

"{s}",

)

Is much better; and then there are more ways to improve - like .write_str...

dmitrylavrenov and others added 10 commits September 15, 2025 21:13

Add CI check for build with evm-tracing feature

5166496

Add evm-tracing feature to humanode-runtime

d21ad4a

[evm-tracing-0] add evm-tracing test suite to e2e ts tests (#1574)

898bbcd

* Add build for evm-tracing at e2e code job * Skip bash tests for evm-tracing test suite * Add template for evm-tracing test suite

[evm-tracing-0-1] add debug e2e tests logic implementation (#1575)

26f05be

[evm-tracing-1] runtime level implementation (#1544)

85f0c70

Runtime level implementation

[evm-tracing-2] сlient-side implementation (#1565)

898b7b0

Client-side implementation

[evm-tracing-3] implement RPC side (#1568)

580f661

Implement RPC side

[evm-tracing-4] cli part implementation (#1572)

587685a

[evm-tracing] Add more e2e tests (#1622)

a08006e

Imporve opcode type usage by reusing evm::Opcode

e47ffbe

dmitrylavrenov force-pushed the evm-debug-trace-opcode-type branch from 6b58725 to e47ffbe Compare October 31, 2025 11:28

dmitrylavrenov added 2 commits October 31, 2025 22:35

Fix serialization implementation

27a4cf2

Remove unused features

67181fd

dmitrylavrenov marked this pull request as ready for review November 3, 2025 12:35

dmitrylavrenov requested review from MOZGIII and quasiyoke November 3, 2025 12:35

dmitrylavrenov mentioned this pull request Nov 3, 2025

Revisit human-readable presentation of EVM opcodes #1602

Closed

quasiyoke approved these changes Nov 4, 2025

View reviewed changes

crates/evm-tracing-client/src/utils.rs Outdated Show resolved Hide resolved

crates/evm-tracing-client/src/utils.rs Outdated Show resolved Hide resolved

dmitrylavrenov added 2 commits November 4, 2025 13:01

Rename is_known_opcode to opcode_known_name

3025cc5

Use as_u8() for getting opcode byte value

e661328

MOZGIII requested changes Nov 4, 2025

View reviewed changes

dmitrylavrenov force-pushed the evm-debug-trace-opcode-type branch 5 times, most recently from 392b9dd to 6afbfa0 Compare November 7, 2025 14:27

Introduce marshalled opcode type

c238ca6

dmitrylavrenov force-pushed the evm-debug-trace-opcode-type branch from 611dea3 to c238ca6 Compare November 7, 2025 19:25

Implement encoding and decoding through a Vec for MarshalledOpcode

ac78782

dmitrylavrenov requested review from MOZGIII and quasiyoke November 10, 2025 08:29

MOZGIII reviewed Nov 10, 2025

View reviewed changes

crates/evm-tracing-events/src/marshalled_opcode.rs Outdated Show resolved Hide resolved

dmitrylavrenov force-pushed the evm-debug-trace-opcode-type branch 3 times, most recently from 18bc2b5 to 04fc893 Compare November 10, 2025 16:54

Use a string representation for opcode

357c9d9

dmitrylavrenov force-pushed the evm-debug-trace-opcode-type branch from 04fc893 to 357c9d9 Compare November 10, 2025 17:13

dmitrylavrenov requested a review from MOZGIII November 11, 2025 06:44

MOZGIII reviewed Nov 11, 2025

View reviewed changes

crates/evm-tracing-events/src/marshalled_opcode.rs Outdated Show resolved Hide resolved

MOZGIII reviewed Nov 11, 2025

View reviewed changes

crates/evm-tracing-events/src/marshalled_opcode.rs Show resolved Hide resolved

MOZGIII reviewed Nov 11, 2025

View reviewed changes

crates/evm-tracing-events/src/marshalled_opcode.rs Show resolved Hide resolved

MOZGIII reviewed Nov 11, 2025

View reviewed changes

crates/evm-tracing-events/src/marshalled_opcode.rs Show resolved Hide resolved

dmitrylavrenov added 3 commits November 13, 2025 15:09

Return Error for Display

a69d4d6

Avoid using intermediate way to do opcode to string

3af03cb

Return opcode_known_name to original place

ce000a6

dmitrylavrenov force-pushed the evm-debug-trace-opcode-type branch from e520c25 to ce000a6 Compare November 13, 2025 12:22

Use cow instead of vec

9659a59

dmitrylavrenov force-pushed the evm-debug-trace-opcode-type branch from eb7fec8 to 9659a59 Compare November 13, 2025 13:11

MOZGIII reviewed Nov 13, 2025

View reviewed changes

dmitrylavrenov closed this Nov 13, 2025

dmitrylavrenov reopened this Nov 13, 2025

dmitrylavrenov force-pushed the evm-debug-trace branch from a08006e to 0225446 Compare December 3, 2025 14:40

Base automatically changed from evm-debug-trace to master December 4, 2025 11:55

Revisit Opcode type #1642

Are you sure you want to change the base?

Revisit Opcode type #1642

Uh oh!

Conversation

dmitrylavrenov commented Oct 31, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

MOZGIII commented Nov 3, 2025

Uh oh!

dmitrylavrenov commented Nov 3, 2025

Uh oh!

MOZGIII commented Nov 3, 2025

Uh oh!

dmitrylavrenov commented Nov 3, 2025

Uh oh!

quasiyoke left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

MOZGIII left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

dmitrylavrenov commented Nov 10, 2025

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Milestone

Development

Uh oh!

4 participants

Revisit `Opcode` type #1642

Revisit `Opcode` type #1642

dmitrylavrenov commented Oct 31, 2025 •

edited

Loading

MOZGIII left a comment •

edited

Loading