SMA-392: Session Keys V2

[ankurdubey521]

Introduction

Introduces a new SessionKeyManagerHybrid Module to support Session Keys infrastructure with the following enhancements:

• Stores the SessionData(svm, validUntil, validAfter, data) on-chain. This removes any dependency on any off-chain DA solution such as Merkle tree storage, removing the need for synchronization between DApps using Session Keys infrastructure.
• Once a Session has been enabled, allows referencing the Session simply by its bytes32 sessionDigest for subsequent session transactions, resulting in massive calldata savings for long-running sessions. This results in significantly cheaper transactions on L2s (amortized costs).
• Optionally allows for the Session Enable Operation to be batched with the first Session Usage Operation, allowing for offline session creation, decreasing the cost and latency/first time to interact metric.
• Improves transparency for which sessions are enabled since all enabled sessions are stored on-chain. It also opens up the possibility of Security Policies integration in the future.
• Natively supports both execute and executeBatch flows, eliminating the need to separately integrate the Batched Session Router to support sessions while batching.
• Natively supports the creation of multiple (potentially multi-chain) Sessions with a Single Signature, eliminating the need for separately integrating the MultiChain Validator Module for achieving the same.

Other notes:

• Compatible with existing SVMs in both execute and executeBatch modes.
• Densely packed signatures using abi.encodePacked to reduce calldata size to further the gas savings on L2s.

Usage

Definitions

struct SessionData {
    uint48 validUntil;
    uint48 validAfter;
    address sessionValidationModule;
    bytes sessionKeyData;
}

MODE_SESSION_KEY_PRE_ENABLED = 0
MODE_SESSION_KEY_ENABLE_AND_USE = 1

Enabling a Session Manually

/**
 * @dev creates a session for a smart account
 * @param sessionData session data
 */
function enableSession(SessionData calldata sessionData) external;

Disabling a Session Manually

Normally a session will expire automatically based on (validUntil, validAfter), however an option to disable the session manually is available.

/**
 * @notice Explicitly disable a session. Can be useful in situations where a session
 *         needs to be disabled before it expires.
 * @param _sessionDigest digest of session key data
 */
function disableSession(bytes32 _sessionDigest) external;

Single Execute

Enable And Use Session

Prepare a User Operation where op.calldata[0:4] is SmartAccount.execute.selector or SmartAccount.execute_ncC.selector.

Prepare one or more SessionData as described above. Calculate

Prepare bytes sessionEnableData as

 * Offset (in bytes)    | Length (in bytes) | Contents
 * 0x0                  | 0x1               | No of session keys enabled
 * 0x1                  | 0x8 x count       | Chain IDs
 * 0x1 + 0x8 x count    | 0x20 x count      | Session Data Hash

Sign sessionEnableData using EIP1271 to produce sessionEnableSignature

Prepare moduleSignature as

 * Offset (in bytes)    | Length (in bytes) | Contents
 * 0x0                  | 0x1               | MODE_SESSION_KEY_ENABLE_AND_USE
 * 0x1                  | 0x1               | Index of Session Key in Session Enable Data
 * 0x2                  | 0x6               | Valid Until
 * 0x8                  | 0x6               | Valid After
 * 0xe                  | 0x14              | Session Validation Module Address
 * 0x22                 | --                | abi.encode(sessionKeyData, sessionEnableData,
 *                      |                   |   sessionEnableSignature, sessionKeySignature)

Use Pre-Enabled Session

Prepare a User Operation where op.calldata[0:4] is SmartAccount.execute.selector or SmartAccount.execute_ncC.selector.

No sessionEnableData is needed in this case. Simply prepare moduleSignature as

 * Session Data Pre Enabled Signature Layout
 * Offset (in bytes)    | Length (in bytes) | Contents
 * 0x0                  | 0x1               | MODE_SESSION_KEY_PRE_ENABLED
 * 0x1                  | --                | abi.encode(bytes32 sessionDataDigest, sessionKeySignature)

Batch Execute

Prepare a User Operation where op.calldata[0:4] is SmartAccount.executeBatch.selector or SmartAccount.executeBatch_y6U.selector.

Here, for each item of the batch independently follow either the enable-and-use or the pre-enabled flow. The global moduleSignature structure is as follows:

abi.encode(
    bytes[] sessionEnableDataList, 
    bytes[] sessionEnableSignatureList, 
    bytes[] sessionInfo, 
    bytes sessionKeySignature
)

First some invariants:

1. sessionInfo.length == executeBatch-operations.length
2. sessionEnableDataList.length == sessionEnableSignatureList.length >= 0

Each item in sessionInfo corresponds to an operation in the batch. If any session wants to leverage the enable-and-use flow, it can refer to one of the enableData-signature pair. If no sessions use these flows, the first two lists are empty.

Session Enable and Signature List

Follows the same structure as described in the Single Execute Section. This is effectively a 2D array of (sessionDataHash, chainID). Assuming that batch operations A, B and C reference sessions SA, SB and SC, assuming the following Session Enable Data:

sessionEnableDataList = [
    SED1: [ (KECCAK(SA), 137), (KECCAK(SB), 137) ] ,
    SED2: [ (KECCAK(SC), 137)] 
]

1. sessionInfo[0] can refer to it's corresponding SED entry as [0, 0]
2. sessionInfo[1] can refer to it's corresponding SED entry as [0, 1]
3. sessionInfo[2] can refer to it's corresponding SED entry as [1, 0]

Session Info Structure - Enable And Use

* Offset (in bytes)    | Length (in bytes) | Contents
* 0x0                  | 0x1               | MODE_SESSION_KEY_ENABLE_AND_USE
* 0x1                  | 0x1               | Index of Session Enable Data in Session Enable Data List
* 0x2                  | 0x1               | Index of Session Key in Session Enable Data
* 0x3                  | 0x6               | Valid Until
* 0x9                  | 0x6               | Valid After
* 0xf                  | 0x14              | Session Validation Module Address
* 0x23                 | --                | abi.encode(sessionKeyData, callSpecificData)

Session Info Structure - Use Pre-Enabled Session

 * Session Data Pre Enabled Signature Layout
 * Offset (in bytes)    | Length (in bytes) | Contents
 * 0x0                  | 0x1               | MODE_SESSION_KEY_PRE_ENABLED
 * 0x1                  | 0x20              | bytes32 sessionDataDigest
 * 0x21                 | ---               | abi.encode(callSpecificData)

Change Type

• [ ] Bug Fix
• [ ] Refactor
• [x] New Feature
• [ ] Breaking Change
• [ ] Documentation Update
• [ ] Performance Improvement
• [ ] Other

Checklist

• [x] My code follows this project's style guidelines
• [x] I've reviewed my own code
• [x] I've added comments for any hard-to-understand areas
• [x] I've updated the documentation if necessary
• [x] My changes generate no new warnings
• [x] I've added tests that prove my fix is effective or my feature works
• [x] All unit tests pass locally with my changes
• [ ] Any dependent changes have been merged and published

[linear[bot]]

SMA-392 Session Keys V2 - Onchain

[livingrockrises]

resolve conflicts

[ankurdubey521]

PR is ready to be merged. I think we should merge this post the "all-encompassing audit"

[tomarsachin2271]

Looks great 🚀 LGTM

[livingrockrises]

Should we merge this or Not?

[ankurdubey521]

@Aboudjem please let us know when this can be safely merged.

[Aboudjem]

@Aboudjem please let us know when this can be safely merged.

Sure ! let's discuss it next week

[ankurdubey521]

@Aboudjem Any update on this?

[Aboudjem]

@Aboudjem Any update on this?

I thought we had agreed to proceed with the merging after completing the audits, if I'm not wrong

[github-actions[bot]]

This PR has been inactive for 30 days. If it's waiting for a review, please reach out to the team. Otherwise, please update the PR or it will be closed due to inactivity.

[ankurdubey521]

@Aboudjem Any update on this?

I thought we had agreed to proceed with the merging after completing the audits, if I'm not wrong

We have completed 1 audit for the module, I believe it can be safely merged now.