utilize pydantic models from eest on t8n #1359

souradeep-das · 2025-08-01T13:36:45Z

What was wrong?

Related to Issue ##1124

How was it fixed?

Pydantic models from eest are input/output for t8n
utilize these models to run t8n

Cute Animal Picture

souradeep-das · 2025-08-01T13:38:44Z

src/ethereum_spec_tools/evm_tools/t8n/t8n_types.py

+                    k: v if (isinstance(v, str) and v.startswith("0x")) else hex(v)
+                    for k, v in acc["storage"].items()
+                }
+        state = t8n.json_to_state(alloc_json)


This could be made more efficient without having to convert from pydantic to json and then json to state

souradeep-das · 2025-08-01T13:40:09Z

src/ethereum_spec_tools/evm_tools/t8n/__init__.py

+        json_output["alloc"] = json_state
+        json_output["result"] = json_result
+        output: TransitionToolOutput = TransitionToolOutput.model_validate(
+            json_output, context={"exception_mapper": self.exception_mapper}


This could potentially also be simplified without having to convert json and then json to pydantic

I think now a direct conversion or individually validating each part of TransitionToolOutput wouldn't really add any efficiency gains here

SamWilsn

So my review amounts basically to just a general Python review.

@gurukamath would you mind giving this a review with an eye specifically to design/architecture, since you've been working in this area lately?

SamWilsn · 2025-08-08T15:52:25Z

src/ethereum_spec_tools/evm_tools/t8n/__init__.py

@@ -80,26 +82,18 @@ class T8N(Load):
    """The class that carries out the transition"""

    def __init__(
-        self, options: Any, out_file: TextIO, in_file: TextIO
+        self, options: Any, out_file: TextIO, in_file: TransitionToolRequest


Does this require changes in the daemon?

SamWilsn · 2025-08-08T15:54:54Z

src/ethereum_spec_tools/evm_tools/t8n/__init__.py

+        output: TransitionToolOutput = TransitionToolOutput.model_validate(
+            json_output, context={"exception_mapper": self.exception_mapper}
+        )
+        return output


Hm, so this change would break the command-line output? Is that what we want?

SamWilsn · 2025-08-08T15:56:16Z

src/ethereum_spec_tools/evm_tools/t8n/env.py

+                def to_canonical_withdrawal(raw):
+                    return t8n.fork.Withdrawal(
+                        index=U64(raw.index),
+                        validator_index=U64(raw.validator_index),
+                        address=raw.address,
+                        amount=U256(raw.amount),
+                    )


Should probably hoist this out of read_withdrawals to avoid creating a bunch of closures that aren't used.

SamWilsn · 2025-08-08T15:59:36Z

src/ethereum_spec_tools/evm_tools/t8n/t8n_types.py

+        if AuthorizationCls is None:
+            from ethereum.osaka.fork_types import Authorization as AuthorizationCls


If the fork doesn't have an Authorization type, but the test transaction does, we should probably error, no? Shoving an osaka type into a frontier block is going to lead to at least an exception somewhere.

SamWilsn · 2025-08-08T16:00:58Z

src/ethereum_spec_tools/evm_tools/t8n/t8n_types.py

+        if isinstance(val, (bytes, bytearray)) and len(val) == 20:
+            return Bytes20(val)
+        if isinstance(val, (bytes, bytearray)) and len(val) == 0:
+            return Bytes20(b"\x00" * 20)
+        if isinstance(val, (bytes, bytearray)):
+            return Bytes20(val.rjust(20, b"\x00"))


Are these special cases necessary or does the rjust handle them all properly?

SamWilsn · 2025-08-08T16:01:25Z

src/ethereum_spec_tools/evm_tools/t8n/t8n_types.py

+        return Bytes20(bytes(val).rjust(20, b"\x00"))
+
+    # build the canonical transaction
+    if tx_cls.__name__ == "FeeMarketTransaction":


Can we use issubclass here instead?

SamWilsn · 2025-08-08T16:04:06Z

src/ethereum_spec_tools/evm_tools/t8n/t8n_types.py

+    # build the canonical transaction
+    if tx_cls.__name__ == "FeeMarketTransaction":
+        return tx_cls(
+            chain_id=U64(tx.chain_id),


Instead of repeating most of the arguments in every branch, would it make sense to do something like:

arguments = { 'nonce': U256(tx.nonce), # The rest of the common items... } if issubclass(tx_cls, AccessListTransaction): arguments["access_list"] = convert_access_list(tx.access_list) elif issubclass(tx_cls, BlobTransaction): ... return tx_cls(**arguments)

SamWilsn · 2025-08-08T16:04:37Z

src/ethereum_spec_tools/evm_tools/t8n/transition_tool.py

+        # output_dict = json.loads(out_stream.getvalue())
+        # output: TransitionToolOutput = TransitionToolOutput.model_validate(
+        #     output_dict, context={"exception_mapper": self.exception_mapper}
+        # )


Remove code instead of commenting it out.

gurukamath · 2025-08-14T11:10:01Z

src/ethereum_spec_tools/evm_tools/t8n/__init__.py

    ) -> None:
        self.out_file = out_file
        self.in_file = in_file
        self.options = options
        self.forks = Hardfork.discover()

-        if "stdin" in (


Would we still be able to consume json files if needed? We will need to continue supporting that use case.

yes! with this commit dc31f96 I added the dual input option where we preserve the older json input route

gurukamath · 2025-08-26T06:26:31Z

src/ethereum_spec_tools/evm_tools/t8n/__init__.py

+        )
+
+        self.chain_id = parse_hex_or_int(options.state_chainid, U64)
+        self.alloc = Alloc(self, in_file.input.alloc)


Perhaps we should re-use the Alloc, Env and Txs types defined by EEST. And if the json inputs are provided, we could just serialize/de-serialize using pydantic. That way, we can get of a lot of redundant code in env.py and t8n_types.py.

right! :) The first thing i tried was to re-use the types (pydantic models) from EEST (to not have these intermediary classes at all) But seems like our execution-spec code isn't directly able to work with those (without some translations/conversions)? To be able to utilize the EEST types directly would definitely be the most efficient - any suggestions?

Would something like this work?

If EEST types are the input: EEST types -> EELS BlockEnvironment -> run the t8n tool

If json input: json input -> EEST types -> EELS BlockEnvironment -> run the t8n tool

You might have to transform the EEST Alloc to the relevant fork's State dataclass but I think this is still much cleaner than what we currently have.

utilize pydantic models from eest on t8n

82b7956

souradeep-das commented Aug 1, 2025

View reviewed changes

fix: imports

1537b01

SamWilsn reviewed Aug 8, 2025

View reviewed changes

souradeep-das added 5 commits August 14, 2025 17:00

convert alloc directly

1f51eaf

rem unnecessary checks

7292acd

simplify txs

bb826c6

add dual input option

dc31f96

update t8n interface

e1dc6a3

souradeep-das marked this pull request as ready for review August 20, 2025 11:24

review fixes

5a17bd9

souradeep-das force-pushed the souradeep/refactor_t8n branch from 5479b3c to 5a17bd9 Compare August 21, 2025 12:25

gurukamath requested changes Aug 26, 2025

View reviewed changes

		if AuthorizationCls is None:
		from ethereum.osaka.fork_types import Authorization as AuthorizationCls

utilize pydantic models from eest on t8n #1359

Are you sure you want to change the base?

utilize pydantic models from eest on t8n #1359

Uh oh!

Conversation

souradeep-das commented Aug 1, 2025

What was wrong?

How was it fixed?

Cute Animal Picture

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!

SamWilsn left a comment

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!

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!