Enabling standardized on chain executions through Modular Accounts
Introduction
This blogpost is intended to be an extension from a previous work “ Self-sovereign identity and account abstraction for privacy preserving cross chain user operations across roll ups ” with the intent of proposing a system implementation of network features. In the previous work I tried to envision a system combining a three-layered architecture that I will briefly summarize here:
- An application layer comprises wallets and other service apps to facilitate the generation and management of Verifiable Credentials, set a permission logic for compiling user operation objects through apps.
- A network layer based on different L2s, which include a Keystore contract and Smart Contract Accounts. This layer is responsible for generating Zero-Knowledge Proofs (ZKPs) and Merkle proofs for Sequencers. The Keystore contract manages encryption keys and user authentication, ensuring the correct key pairing for Verifiable Credentials and Operations. Smart Contract Accounts verify user operations, by validating ZK cryptographic proofs to ensure the integrity of the signatures of the transactions before they are executed.
- A sequencing layer which interconnects L2s with Ethereum main-net and manages the execution of batches of transactions anchoring Roll-up IDs to sequencing networks batching, validation cross chain atomic transactions via the Keystore roll-up, and the Roll-up contract within Ethereum’s slots.
Today, I am trying to focus on some elements on the 1 and 2 layer, sitting in the conjunction between External Owned Accounts and Contract Accounts trying to envision an implementation pathway for the adoption of standardized on chain execution.
The concept
To facilitate the adoption of blockchain based services globally there is a need for standardizing secure, privacy and regulatory-compliant on chain executions to scale. As we move towards a more decentralized future, ensuring cyber security, data minimization from origination to processing, and improving UX in executing on chain operations is crucial.
This blog post introduces a framework based on the ERC 7579 proposal, which integrates a module to lavage onchain verifiable credentials and zero-knowledge (zk) proofs in the context of modular smart accounts. This framework aims to standardize onchain executions by separating user authentication and transaction authorization while preserving privacy and regulatory requirements throughout the transaction lifecycle.
The core function of the system described involves validating zk proofs generated by VCs to authenticate users and authorize operations. This makes the Validation Module the most appropriate choice, as it is designed to validate user operations before they are executed.
The Validation Module allows for checking the validity and authenticity of zk proofs, ensuring that only legitimate user operations are processed.
For reference, the framework considers a minimal set of ERC for implementation:
-
ERC 7579 - Minimal Modular Smart Accounts: to set a module to validate user operations by verifying ZK proofs derived from verifiable credentials (VCs) ensuring that user operations are authenticated and authorized before execution.
-
ERC 1271 - Standard Signature Validation Method for Contracts: to standardize how smart contracts validate signatures, defining the function to verify the validity of a signature, crucial for transaction authorization.
-
ERC 4337 - Account Abstraction Using Alt Mempool: to abstract account management and operations, enabling more complex and user-friendly interactions allowing smart contract accounts to handle user operations and transaction executions.
-
ERC 165 - Standard Interface Detection: to allow contracts to declare support for certain interfaces and enabling smart contracts to query and interact with other contracts that implement specific interfaces.
High-level process flow
The framework leverages the strengths of different proposals to create a robust, secure, and privacy-preserving onchain execution environment.
I list here a high-level overview:
- Users issue on chain merklized Verifiable Credentials (VCs) through a contract identifier operated by an issuer. These credentials are stored in the user’s identity wallet (EOA)
- Users generate and validate ZK proofs derived from their VCs through a contract verifier to access service apps and compile User Operation objects.
- Smart Contract Account entry point perform canonical verification loop according ERC 4337.
- The validation module verifies the zk proofs against the VCs in the execution loop and upon successful validation, the module calls the isValidSignature function as defined by ERC 1271 to authorize entry point to executeUserOps.
- Smart contract Account entry point executes onchain operations and distributes the fees to the Bundler address.
Market & Business Considerations
This framework offers significant value for large-scale enterprise services requiring validation logic before authorizing onchain operations. By integrating SSI and zk proofs, enterprises can ensure privacy and regulatory compliance while enhancing security and efficiency. The separation of authentication and authorization further strengthens the system’s robustness.
Here a short list of valuable use cases that would fit nicely with this logic:
- Trading: A DeFi platform allows users to interact with various financial services such as lending, borrowing, and trading. The platform issues VCs containing user identity and KYC information. Whenever a user wants to execute a financial transaction, they submit a zk proofs on VC and compile user operations objects along as operation request. The Validation Module verifies the zk proof against the stored VC and upon successful verification, the entry point is executing the operations on chain.
- DAOs: a decentralized voting system allows DAO members to vote for grants allocation privacy preserving and reducing conflict of interest. Voters authenticate themselves using VCs and zk proofs to cast their votes and upon the voting completion the entry point executes grants allocations on chain according to the voting results.
- Supply chain: a management system tracks the manufacturing and logistics of goods, participants in the supply chain authenticate using VCs and zk proofs to update and access the status of goods up to the distributor and at the moment of the sale the entry point execute onchain rewards, or payment premiums, to the different members.
Conclusion & further thoughts
When we look forward to what kind of functionalities we would like to have as user for the future I believe there has been a big trend in providing standardization through native abstraction, modularity, and functional collaboration between EOAs and SCAs. Considering the future road map of Ethereum in Pectra, EIP 7702 sets the way for a new transaction type which enables account properties of both externally owned accounts (EOAs) and Smart Contract Accounts (SCAs). Furthering looking ahead, there is a way to set “native account abstraction” by RIP 7560 and ERC 7562 which align with ERC 4337 rules at least on validation rules.
A side of this is also important EIP 7212 proposes a precompiled contract to perform signature verifications using the secp256r1 elliptic curve. This curve, also known as P-256, is widely supported in modern devices like Apple’s Secure Enclave, Webauthn, and Android Keychain, and Passkeys. This would allows more efficient and flexible management of accounts by transaction signs in mobile devices. Both EIP 7702 and EIP 7212 are potentially taking place in Pectra.
Network harmonization is a key capability of every growing community, in this context personally I see value in further exploring the use of keystore contracts, session keys and passkeys as additional features to provide security, flexibility and usability to the product experience.
Passkeys can be used to authenticate users providing a smoother UX while combining strong user authentication. Session keys can improve security of communication at application level, meaning when users are interacting with dapps for using market services, and keystore contract could represent an reliable solution for setting a functional framework for operating key sessions.
The shared focus on improving account flexibility and security through different methods highlights the committment of the community’s to address scalability, usability, and security concerns within the Ethereum network. In this setting collaboration between EOAs and SCAs, and additional features as passkeys keystore contracts can live in a modular setting where specific modules enforce optional rules for executions, and different cryptographic tecniques could ensure data minimization for controllers and processors.