EIP-7702: first draft of spec design document #193

OlivierBBB · 2025-06-18T19:03:16Z

No description provided.

letypequividelespoubelles · 2025-06-19T02:58:18Z

_notes/EIP-7702: Set Code for EOAs: design document.md

+
+- new transaction type `TYPE_4` flag
+- new `IS_ACCOUNT_DELEGATION` phase
+- new `ACCOUNT_DELEGATION_DATA` perspective, with columns named `deleg/XXX`


not sure a delegation perspective is the best. It could be better to use the TMP colun in Computation perspective (as we do for DATA & Access List phase).

letypequividelespoubelles · 2025-06-19T02:59:43Z

_notes/EIP-7702: Set Code for EOAs: design document.md

+
+NOTE. The above requires the `TXN_DATA -> RLP_TXN` lookup to also provide `txn/SENDER_ADDRESS`.
+
+## `RLP_TXN -> HUB` lookup


don't we need the reverse lookup as well ?

letypequividelespoubelles · 2025-06-19T03:00:35Z

_notes/EIP-7702: Set Code for EOAs: design document.md

+|-------------------------------------|-----------------------------------|
+| source column                       | target column                     |
+|-------------------------------------|-----------------------------------|
+| 1                                   | hub.TX_DLGT                       |


as a source we could : should use IS_TYPE_4 column

letypequividelespoubelles · 2025-06-19T03:02:34Z

_notes/EIP-7702: Set Code for EOAs: design document.md

+|-------------------------------------|-----------------------------------|
+| 1                                   | hub.TX_DLGT                       |
+| rlp_txn.USER_TRANSACTION_NUMBER     | hub.USER_TRANSACTION_NUMBER       |
+| rlp_txn.deleg/DELEGATION_INDEX      | hub.acc/DELEGATION_INDEX          | // is there a better way than introducing such a column ?


again, not sure about the beenfit of a delegate perspective ... I think it would be easier with the use of auxiliary columns in the COMP persp (as for ACCESS_LIST)

letypequividelespoubelles · 2025-06-19T03:04:23Z

_notes/EIP-7702: Set Code for EOAs: design document.md

+    - even the "sender self delegation" rows
+- every row triggers the lookup to `TRM` and to `RLP_ADDR`
+    - TRM:      for obvious reasons (initial prc recognition)
+    - RLP_ADDR: in order that we may use this module to compute the `CODE_HASH_NEW`


I don't get this point, can you explain it please ?

We will need to compute the code hash of an account after delegation. If my memory is correct this is the hash of the concatenation 0xef0000 + delegation_address. What I propose is that this "byte code" not exist in the ROM module but instead only in the account perspective. But we need a way to hash it so I'm suggesting we use the rlp address module to do that since that module already has to do some hashing.

letypequividelespoubelles · 2025-06-19T03:07:30Z

_notes/EIP-7702: Set Code for EOAs: design document.md

+Typically have each and every account delegation be dealt with in a constant size block à la
+
+```
+ACCOUNT_DELEGATION_BLOCK ≡ {


reminder: the RLP_TXN should be responsible to provide the prover the selector columns for the keccak:
"The signature_y_parity, signature_r, signature_s elements of this transaction represent a secp256k1 signature over keccak256(SET_CODE_TX_TYPE || TransactionPayload)"

letypequividelespoubelles · 2025-06-19T03:09:07Z

_notes/EIP-7702: Set Code for EOAs: design document.md

+| EXTCODECOPY                              |    YES    | The simplest solution is likely to have two memory operations   |
+|                                          |           |                                                                 |
+|                                          |           | 1. write to a fresh new context with ID = HUB_STAMP the code    |
+|                                          |           | .  which is simply 0x ef 00 00 <delegated_address> which occu-  |


typo: it's 0xEF0100

letypequividelespoubelles · 2025-06-19T03:10:41Z

_notes/EIP-7702: Set Code for EOAs: design document.md

+|                                          |           | 3. we do a `ramToRam` operation from the context with equal     |
+|                                          |           | .    SRC_ID ≡ HUB_STAMP                                         |
+|                                          |           | .    TGT_ID ≡ CONTEXT_NUMBER                                    |
+|                                          |           | .    SRC_OFFSET = <magical_offset>                              |


what's the magical offset ?

oh, I see with your diagramm below. It's because you MSTORE it instead of RAM_TO_RAM_SANS_PADDING to the virtual context. Why not simplify it with two ramToRam and no source/tgt offset ? It may be less efficient in MMU/MMIO, but easier to understand what we're doing

That would also be acceptable. I suggested the above so that we may do it in a single MMU operation and without any byte decompositions in the MMIO.

The MODEXP pre-compile does something similar: when you copy over the results you start at offset zero, but the return data starts at offset 512 - mbs. It's the same idea here

letypequividelespoubelles · 2025-06-19T03:12:39Z

_notes/EIP-7702: Set Code for EOAs: design document.md

+|                                          |           | recipient (that is, μ_s[0].trim()) and delegatee warming        |
+|                                          |           |                                                                 |
+|                                          |           | We will also have to modify how we set the scenario, in parti-  |
+|                                          |           | cular how we recognize EOA's and SMC's.                         |


I'm wondering if it would make sense to have new "delegated" scenarii

That's what I'm trying to avoid actually.

letypequividelespoubelles · 2025-06-19T03:17:40Z

_notes/EIP-7702: Set Code for EOAs: design document.md

+
+We will need to send stuff to some hasher. It's easiest to do this for every `TX_DLGT` row. There are various options for where to do this.
+One _could_ insert MISC rows between every account row. I don't like this.
+One _could_ use the lookup to RLP_ADDR which we will also trigger, send the DELEGATION_ADDRESS, too, and also request the hashing of the 'code', that is the 


I prefer the RLP_ADDR option too

an other option is to delegate to RLP_TXN and add the CODE_HASH_NEW in the lookup. But I find it weird tbh. I prefer the direct RLP_ADDR way of doing

letypequividelespoubelles · 2025-06-19T03:20:11Z

_notes/EIP-7702: Set Code for EOAs: design document.md

+
+Likely a change: we may ask this module, which already hashes stuff, to hash for us the "code" of a delegated account, i.e. the 23 byte string
+
+    `0x ef 00 00 <delegated_address>`


0x ef 01 00 instead :)

feat: first draft of EIP-7702 spec design document

3beb78e

OlivierBBB self-assigned this Jun 18, 2025

OlivierBBB added documentation Improvements or additions to documentation hardfork prague EIP's for the Pectra hardfork London to Prague London to Pectra labels Jun 18, 2025

ras

73542e8

letypequividelespoubelles reviewed Jun 19, 2025

View reviewed changes

ras: reorganizing

7849ccb


		NOTE. The above requires the `TXN_DATA -> RLP_TXN` lookup to also provide `txn/SENDER_ADDRESS`.

		## `RLP_TXN -> HUB` lookup


		Likely a change: we may ask this module, which already hashes stuff, to hash for us the "code" of a delegated account, i.e. the 23 byte string

		`0x ef 00 00 <delegated_address>`

EIP-7702: first draft of spec design document #193

Are you sure you want to change the base?

EIP-7702: first draft of spec design document #193

Uh oh!

Conversation

OlivierBBB commented Jun 18, 2025

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!

OlivierBBB Jun 19, 2025 • 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!

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!

OlivierBBB Jun 19, 2025 • 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!

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!

OlivierBBB Jun 19, 2025 •

edited

Loading

OlivierBBB Jun 19, 2025 •

edited

Loading