AA-521 EntryPoint support for eip-7702 #529

drortirosh · 2025-01-23T11:57:20Z

Native support for EIP-7702 in EntryPoint.
Depends on EIP-7702 PR ethereum/EIPs#9248 (extcodehash to return the delegate)

overhead: 269 gas per userop (down to 144 on 11th userop) increased (330) with TokenPaymaster - not sure why

contracts/core/Eip7702Support.sol

forshtat · 2025-01-26T11:21:11Z

contracts/core/Eip7702Support.sol

+    }
+
+
+    function _isEip7702InitCode(bytes calldata initCode) pure returns (bool) {


If you write this function without the assembly tricks, how much more gas does it spend? This code is too elaborate for the task of "compare first three bytes".

initCode starts with a prefix, and can be padded with zeros.
in assembly, we take advantage of ABI encoding, which pads shorter values with zeros to next 32 boundary.
In solidity, this padding would have to be done manually.
not only it would cost more, it would also be a longer code.

forshtat · 2025-01-26T11:23:40Z

contracts/core/Eip7702Support.sol

+        // solhint-disable-next-line no-inline-assembly
+        assembly ("memory-safe") {
+            extcodecopy(sender, 0, 0, 32)
+            senderCode := mload(0)
+        }


You don't need any assembly, you can just do sender.code. Also if the code is not exactly 23 bytes long it should revert.

using assembly to avoid creating a dynamic bytes array (even with sender.code, we'd need assembly to grab just the address out of it, as there is no "slice" for memory..)

No need to check it is 23 bytes: since eip-3541, no deployed contract can start with "0xEF", unless it is EOF. The "0xEF0100" prefix of eip-7702 is invalid as EOF, such checking the prefix implies the 23 bytes length...

Even with sender.code, we'd need assembly to grab just the address out of it

I think Solidity now supports just converting bytes to bytes32 to uint256 so as far as I can tell there should be no difference. I may be wrong though.

bytes memory b = sender.code; uint256 senderCode = uint256(bytes32(b));

No need to check it is 23 bytes since EIP-3541

I am concerned some up-and-coming L2s may be a little less rigorous in their implementation of EIP-3541 and that would allow some kind of an attack down the line. It would be dirt-cheap to just double-check.

yes, it is possible. but it reads read entire code, and then extract just the first 32 bytes.
rough check shows it to be 300 gas.
EIP-3541 doesn't really matter here: even if account's code starts with "EF", it will never pass validation anyway (or any other execution call)

it reads read entire code, and then extract just the first 32 bytes

But the code is always 23 bytes long for EIP-7702, what is the problem here?
Please remove assembly if it is technically possible here. No need to overcomplicate things.

I know it is 23 bytes and you know it too, but solidity doesn't... sender.code can possibly be any length, so it copies it as dynamic value before extracting the first word/

contracts/core/EntryPoint.sol

contracts/core/EntryPointSimulations.sol

contracts/core/UserOperationLib.sol

forshtat · 2025-02-11T18:43:04Z

contracts/core/Eip7702Support.sol

+
+/**
+ * get the EIP-7702 delegate from contract code.
+ * requires EXTCODECOPY pr: https://github.com/ethereum/EIPs/pull/9248 (not yet merged or implemented)


This PR is merged so the comment may be removed.

forshtat · 2025-02-11T18:52:44Z

contracts/core/Eip7702Support.sol

+        // senderCode is the first 32 bytes of the sender's code
+        // If it is an EIP-7702 delegate, then top 24 bits are the EIP7702_PREFIX
+        // next 160 bytes are the delegate address
+        if (senderCode >> (256 - 24) != EIP7702_PREFIX) {


You could convert it by doing something like this:

bytes3 EIP7702_PREFIX = 0xef0100; bytes32 senderCode = ...; if (bytes3(senderCode) != EIP7702_PREFIX) {}

It is basically the same thing but >> (256 - 24) != does not look good...

You could even define it as bytes3 senderCode if you wanted to, I think. Not sure about that.

forshtat · 2025-02-11T18:59:29Z

contracts/core/SenderCreator.sol

+
+    // use initCode to initialize an EIP-7702 account
+    // caller (EntryPoint) already verified it is an EIP-7702 account.
+    function initEip7702Sender(


Why can't we use createSender again? It is doing basically the same thing, calling address(initCode[:20] with initCode[20:], what are the main differences?
If they are not critical, let's merge these two methods?

createSender is used to physically create, not initialize.

it would require changing createSender signature, since it requires an extra parameter (not extracting it from initCode)

we already suggested to use call({from:entryPoint, to:senderCreator, data: encode(createSender(...) } as a view function to get account address. changing the API would break it.

so seemed like adding a new one was a better choice.

forshtat · 2025-02-11T19:06:00Z

contracts/core/EntryPoint.sol

+        bytes32 overrideInitCodeHash = _getEip7702InitCodeHashOverride(userOp);
        return
-            MessageHashUtils.toTypedDataHash(getDomainSeparatorV4(), userOp.hash());
+            MessageHashUtils.toTypedDataHash(getDomainSeparatorV4(), userOp.hash(overrideInitCodeHash));


userOp.hash() may only ever be called with the result of _getEip7702InitCodeHashOverride(), which can only be called with the userOp as a parameter. The value of overrideInitCodeHash is only used once.

Do we need this value to bubble up into the EntryPoint itself? Why not call the _getEip7702InitCodeHashOverride directly inside the userOp.hash?

Separation of concerns:
UserOperationLib is a library, and its methods (including hash()) are pure.
_getEip7702InitCodeHashOverride() is a view function, reading the current delegate.

forshtat · 2025-02-11T19:10:32Z

contracts/core/EntryPoint.sol

+            if ( _isEip7702InitCode(initCode) ) {
+                if (initCode.length>20 ) {
+                    //already validated it is an EIP-7702 delegate (and hence, already has code)
+                    senderCreator().initEip7702Sender(sender, initCode[20:]);


This means that EIP-7702 accounts can get two validation phase calls instead of one whenever they want, right?

yes. eip-7702 account is never "new" (from the EntryPoint's view) - it is always "already created".
So we always allow an eip-7702 account to run "initialization" code - as many times as it wishes.
The alternative was to require it to put this initialization data into the "callCode", use it from "validate" and then ignore it during execution.

drortirosh added 17 commits January 1, 2025 21:32

userOpHash as ERC-712 signature

db002af

overhead: 269 gas per userop (down to 144 on 11th userop) increased (330) with TokenPaymaster - not sure why

don't encode "domain" by default.

edb2255

working

dc43285

removed initUserOpHashParams (internal helper)

fc0c4e7

gas cals

263a232

undo gas limit change.

5b052ae

pr review (typo hash1)

38d4714

remove unused comment.

5f0a6b7

initial implementation

68894e4

memory-safe

317d26b

optimize overrideInitCode

2617f03

addeds: zero-tails, fail if not eip-7702 account.

5052317

gas calcs

b8a9d26

lints

d9b3f77

Merge branch 'develop' into AA-521-ep-7702

24b5473

removed extracheck.

fafeca8

gascalc

f98cd95

forshtat requested changes Jan 26, 2025

View reviewed changes

tests passes, including 7702-enabled external geth

fb06bc3

drortirosh force-pushed the AA-521-ep-7702 branch from 951ab2a to fb06bc3 Compare January 29, 2025 17:55

drortirosh added 10 commits January 29, 2025 20:07

gaschecks, geth docker.

69499d0

geth docker.

bac3113

fix geth script, coverage test

e54c2a7

separate entrypoint-7702 tests into a separate test file

146dbbe

Merge branch 'develop' into AA-521-ep-7702

0860e41

Merge branch 'develop' into AA-521-ep-7702

f25a26b

test timeout

ee54899

lints

33b294a

Merge branch 'develop' into AA-521-ep-7702

ea09602

account

8dafd94

drortirosh added 6 commits February 9, 2025 14:12

added wallet tests

c026b2e

test eip-7702 account

1442357

test 7702 with paymaster

b088f05

lnts

6459a16

coverage

192be39

rename to Simple7702Account

26d6a0b

drortirosh force-pushed the AA-521-ep-7702 branch from d29c9d1 to 26d6a0b Compare February 10, 2025 00:37

drortirosh added 2 commits February 11, 2025 14:06

gascalc

a747be1

remove Simple7702Account, into a separate PR

f7c1688

drortirosh force-pushed the AA-521-ep-7702 branch from b9bd6ce to f7c1688 Compare February 11, 2025 13:43

forshtat requested changes Feb 11, 2025

View reviewed changes

drortirosh added 2 commits February 12, 2025 20:16

PR review: cleanup Eip7702Support assembly usage.

074844c

update comments

fac94f7

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

AA-521 EntryPoint support for eip-7702 #529

AA-521 EntryPoint support for eip-7702 #529

drortirosh commented Jan 23, 2025 •

edited

Loading

forshtat Jan 26, 2025

drortirosh Feb 11, 2025

forshtat Jan 26, 2025

drortirosh Jan 29, 2025

forshtat Feb 3, 2025 •

edited

Loading

drortirosh Feb 11, 2025

forshtat Feb 11, 2025

drortirosh Feb 12, 2025

forshtat Feb 11, 2025

forshtat Feb 11, 2025

forshtat Feb 11, 2025

drortirosh Feb 12, 2025

forshtat Feb 11, 2025

drortirosh Feb 12, 2025

forshtat Feb 11, 2025

drortirosh Feb 12, 2025

		}


		function _isEip7702InitCode(bytes calldata initCode) pure returns (bool) {

AA-521 EntryPoint support for eip-7702 #529

Are you sure you want to change the base?

AA-521 EntryPoint support for eip-7702 #529

Conversation

drortirosh commented Jan 23, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

forshtat Feb 3, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

drortirosh commented Jan 23, 2025 •

edited

Loading

forshtat Feb 3, 2025 •

edited

Loading