Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 58.28%. Comparing base (4470cc3) to head (ff99a30).
Report is 91 commits behind head on master.

That sounds all great (I have one small comment but I will go the dive-deeper later)! ⭐ 😄

Some note: there is only one file (and only types) pushed for now, is this intended?

Yes, and I actually intended not to push that. I have 2 monorepo folders open to experiment a bit, and sometimes (if I switch branches for instance to test a PR) I stash/commit my experiment so I can continue later on. (The local branches here are super dirty 😓 ). I accidentally pushed this branch, will force-push and remove it later on and then cherry-pick the relevant commits in to tidy things up :)

Side note: I think the earliest I can spin up a PR which would be in a kind-of re-viewable state would be Monday

Side note: I think the earliest I can spin up a PR which would be in a kind-of re-viewable state would be Monday

Yeah, I mean this late pushing - especially on larger work - always bears the risk of stronger discussions and eventual change needs, so it also has some benefits to push earlier on, even if things are not fully cleaned up. But as you want. 🙂

Yes, good point. I have to note that I have started over from scratch many times (also recently) with new ideas (or finding out that the previous approach did not work). I will push once I have a clean PoC so we can start to get some eyes on there and leave some feedback and open the discussion 😄

For phase 2 of tx refactor will push more of the composition pattern to the tx, together with Holgers document and some past ideas I had the following idea:

The 7702 transaction for instance is a composition of the logic of Access Lists (2930), Fee Market (1559) and EOA code deployment (7702). What I was thinking about is along the following lines: currently we have Capabilities logic per EIP, but I think we should swap this out to something more specific. For instance, a tx in the future could have parts of an EIP but also some parts not. So I would propose:

The capabilities get renamed: 2930 -> AccessLists, 1559 -> FeeMarket, 4844 -> Blobs, 7702 -> EOACode.

A EOA7702Tx is then a tx composed of: AccessLists, FeeMarket, EOACode.

If we do this composition pattern, then for instance AccessLists capability will demand the accessLists property on the tx, plus it will also allow it in the TxData field. And FeeMarket will reject gasPrice and add maxPriorityFeePerGas and maxFeePerGas to the interface.

Besides this pattern, this new "features" will then also allow is (thinking a bit of L2 support): "Signable" (this allows the v/r/s fields) and we could go even further, "CreateContract" (this allows a to: null field, this is NOT allowed in 7702 / 4844).

This also allows us to create a SUPER MINIMAL tx interface with only the required fields. We now have some super deep logic hardcoded into the tx interface, for instance such as toCreationAddress() (method to figure out if we create a contract, this is also required currently on 7702/4844 but always false.

Minimal interface would likely only be methods as: raw() (before serialization) serialize() (RLP serialize), hash(), toJSON.

Here is the code overview of master as of 287f960 (to track if we blow up the package with a lot of lines or not)