Issue with EntryPoint v0.8 Regarding `validUntil`/`validAfter` and EIP-712

[jayden-sudo]

Subject: Issue with EntryPoint v0.8 Regarding validUntil/validAfter and EIP-712

EntryPoint v0.8 introduces many improvements, but it also presents an issue that compromises the elegance of the overall process:

1. Version 0.8 incorporates EIP-712 (via AA-508), which is beneficial for signature security.
2. AA-508 functions well when validUntil and validAfter are not used. However, when users attempt to set these parameters, PackedUserOperation lacks dedicated fields for transaction validity. This forces users to embed validUntil and validAfter within the PackedUserOperation.signature field. To ensure the legitimacy of these user-set values, they must also be included in the raw data signed for the PackedUserOperation, thereby negating the optimization benefits of AA-508.

Proposed Solutions:

1. No Action:

   • If setting validUntil and validAfter is considered an extremely rare requirement, this issue could be left unresolved. (Personally, I disagree with this assumption, as I believe allowing users to set a default transaction validity period enhances security.)

2. Delegate to Wallet Teams for Resolution:

   • Wallets, when needing validUntil and validAfter, would no longer use the userOpHash provided by EntryPoint. Instead, they would use a custom userOpHash derived from a modified PackedUserOperation structure:

   •         struct PackedUserOperation {
                 address sender;
                 uint256 nonce;
                 bytes initCode;
                 bytes callData;
                 bytes32 accountGasLimits;
                 uint256 preVerificationGas;
                 bytes32 gasFees;
                 bytes paymasterAndData;
                 uint48 validUntil; // <---- new
                 uint48 validAfter; // <---- new
             }

   • This is the update our wallet application plans to implement during its migration to v0.8 (ref).

3. Resolve in EntryPoint v0.9:

   • EntryPoint could modify the PackedUserOperation definition to include dedicated fields such as uint48 validUntil and uint48 validAfter, or a combined uint96 validTimeRange. While this would indeed increase on-chain calldata size, I believe the enhanced elegance and security of the protocol would justify this additional data.

*(Of course, any custom data can be set via custom callData, but this approach is not user-friendly — users won’t be able to intuitively see the validTimeRange when signing via TypedData.)