utilize pydantic models from eest on t8n by souradeep-das · Pull Request #1359 · ethereum/execution-specs

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


    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

        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.

…thereum#1359) * fix(types): tests: Add serialization unit tests * fix(types): tests: Fix unit tests * feat(base_types): Implement serialization RLP types * feat(base_types,types,fixtures): Apply serialization RLP types * fix(types): Auth tuple defaults * fix(fixtures,rpc,specs,types,tests): Transaction.rlp is a function * fix(base_types,types,rpc): fixes * refactor(base_types,types): Network wrapped transaction * fix(tests): Network wrapped transactions * fix(types): Fix NetworkWrappedTransaction rlp prefix * docs: Changelog * Apply suggestions from code review Co-authored-by: spencer <spencer.taylor-brown@ethereum.org> * Add network wrapper explanation * fix: tox * Update docs/CHANGELOG.md Co-authored-by: spencer <spencer.taylor-brown@ethereum.org> * Add comment --------- Co-authored-by: spencer <spencer.taylor-brown@ethereum.org>

SamWilsn · 2025-12-15T20:06:22Z

I think we still need to figure out what we're doing for this PR, so don't worry about rebasing onto forks/amsterdam for now.

gurukamath · 2026-01-09T09:50:06Z

Just mentioning #1883 here since it looks to tackle a similar issue

felix314159 · 2026-03-04T14:46:17Z

@souradeep-das the issue guru linked is still relevant, are you willing to rebase and move forward with this PR or should it be closed?

gurukamath · 2026-03-04T15:03:45Z

@souradeep-das the issue guru linked is still relevant, are you willing to rebase and move forward with this PR or should it be closed?

We are working through some re-factors in #2381 post which, it should be a little easier to use the pydantic models. I am tracking this PR and will re-factor/re-base if needed

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

SamWilsn modified the milestones: osaka, Post-Osaka Refactoring Dec 15, 2025

gurukamath self-assigned this Mar 4, 2026

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

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!

SamWilsn commented Dec 15, 2025

Uh oh!

gurukamath commented Jan 9, 2026

Uh oh!

felix314159 commented Mar 4, 2026

Uh oh!

gurukamath commented Mar 4, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants