List of active and deprecated Ethereum testnets, including Kintsugi.
Features
Optimistic rollup
ZK-rollup
Proof
Uses fraud proofs to prove transaction validity.
Uses validity (zero-knowledge) proofs to prove transaction validity.
Capital efficiency
Requires waiting through a 1-week delay (dispute period) before withdrawing funds.
Users can withdraw funds immediately because validity proofs provide incontrovertible evidence of the authenticity of off-chain transactions.
Data compression
Publishes full transaction data as calldata to Ethereum Mainnet, which increases rollup costs.
Doesn't need to publish transaction data on Ethereum because ZK-SNARKs and ZK-STARKs already guarantee the accuracy of the rollup state.
EVM compatibility
Uses a simulation of the Ethereum Virtual Machine (EVM), which allows it to run arbitrary logic and support smart contracts.
Doesn't widely support EVM computation, although a few EVM-compatible ZK-rollups have appeared.
Rollup costs
Reduces costs since it publishes minimal data on Ethereum and doesn't have to post proofs for transactions, except in special circumstances.
Faces higher overhead from costs involved in generating and verifying proofs for every transaction block. ZK proofs require specialized, expensive hardware to create and have high on-chain verification costs.
Trust assumptions
Doesn't require a trusted setup.
Requires a trusted setup to work.
Liveness requirements
Verifiers are needed to keep tabs on the actual rollup state and the one referenced in the state root to detect fraud.
Users don't need someone to watch the L2 chain to detect fraud.
Security properties
Relies on cryptoeconomic incentives to assure users of rollup security.
Learn How Different Smart Contract Account Concepts Use Modules and Plugins to Create New Extensions for Accounts
Last Updated:
July 19, 2023
Table of Contents
Table of Contents
Table of Contents
{{aa-cta}}
Modular AA is a movement aimed at evangelizing modularized smart accounts. The goal is to make accounts customizable for users and allow developers to build context-rich and self-contained account features.
Social Recovery - Allow a trusted device or friends to help you recover your account in case you lose access
Spending Limits - Allow dapps to spend tokens on behalf of you up to a specified limit
Passkey Support - Login with your biometrics like FaceID
By standardizing modularity counter-party risk can be greatly reduced, leading to simple and secure web3 user experiences.
The ERC-4337 standard lays out the infrastructure components and coding standards which when implemented enables users to have a primary account type of a smart contract over a private key. Historically, the primary account type was an EOA (End User Account), which, unlike SCAs doesn't have custom validation and execution logic.
This article aims to provide you with an overview of Modular Account Abstraction, what it enables, and the existing standards and implementations.
What are the different types of modular Smart Contract Accounts?
Smart contract accounts are fundamentally smart contracts; they are upgradeable, extensible, and also inheritable. Depending on the SCA implementation it can either allow or disallow adding plugins/modules. There are two different concepts of modular AA this article will explore are: ERC-6900 and SAFE Modules.
1. ERC-6900: Modular Smart Contract Accounts and Plugins
The objective of ERC-6900 is to define a set of interfaces between a standard Account and Module implementation. The proposal hopes to improve the developer experience, Module interoperability, and data portability when switching between account implementations.
The standard is inspired by ERC-2535, however, it does not require developers to follow the Diamond pattern.
What types of plugins does ERC-6900 define?
According to the standard, plugins can be of three types:
Validation Schemes - Define the circumstances under which the modular smart contract account (MSCA) will approve the transactions on its behalf
Execution Logic - Any arbitrary logic to be performed during the execution
Hooks - Hooks can trigger any logic to be executed, pre- and post-execution of the user operation
ERC-6900 Module Diagram
The standard also defines:
How to implement Validation, Execution, and Hook plugins for a MSCA.
How compliant account implementations should add, remove, update, and inspect plugins.
Helper types like FunctionReference.
Diagram of how a transaction flows through the entry point to an ERC-6900 SCA
What types of interfaces does ERC-6900 define?
The ERC-6900 specification defines three main interfaces: IPluginUpdate, IPluginLoupe and IStandardExecutor.
1. IPluginUpdate
The IPluginUpdate interface defines:
Plugin actions ADD, REMOVE, and REPLACE
Validator types and Hook types
User defined structs to update various plugins types
A standardized updatePlugins function to be called when updating plugins and the ExecutionPluginUpdate event to be emitted post update
2. IPluginLoupe
The IPluginLoupe is inspired by ERC-2535, and ERC-6900 defines how a dapp or other contracts can read the supported plugins by the MSCA.
3. IStandardExecutor
The IStandardExecutor interface modular smart contract accounts should implement to allow for open-ended execution.
2. SAFE Modules
All SAFE-based accounts have support for SAFE Modules. To maintain high-security standards, the SAFE team followed the separation of concerns pattern and implemented different module types.
Modules - Whitelisted addresses that can execute transactions in the name of the Safe Smart Account.
Guard - A contract that can be set to perform additional checks on transactions to be executed.
Fallback Handler - A contract that can be set to handle arbitrary incoming (read) calls.
SAFE's Modules are individual smart contracts that have permission to execute transactions on the user's SAFE smart contract account. Modules can execute arbitrary transactions on the SAFE account via the execTransactionFromModule function. Since the SAFE team decides how the SAFE accounts are implemented, the plugin developers must comply with the rules and guidelines. SAFE modules are only compatible with SAFE accounts.
There are major trust assumptions between the module developer and the user, and as such, modules that are battle-tested are more likely to continue being adopted.
Diagram of SAFE Account Module
What are SAFE SCA Guards?
Guards are smart contracts that can be set for a SAFE account to perform additional security checks on incoming transactions. Before the execution of a transaction, a
Guard is called with all the transaction parameters, and if the Guard does not revert then the transaction proceeds to execution.
The Guard is called again after execution to perform state change checks or execute arbitrary logic.
Guards can also be thought of as hooks as they are appropriate for pre and post-transaction state checks.
How SAFE SCA Guards Can Protect Accounts
What is the SAFE SCA Fallback Handler?
The Fallback Handler executes all calls made to the SAFE account which can be handled by it. This can be useful to comply with industry-wide standards like contract signatures (EIP-1271). According to SAFE, “plugins are completely independent of the core SAFE contracts and maintain their own storage”.
Diagram of how the SAFE SCA Fallback Handler works
Conclusion
Modular Account Abstraction as described by ERC-6900 and designed by Safe Modules aims to extend the capabilities of Smart Contract Accounts through plugins, which can be built by developers, and safely installed by smart contract wallet users.
Modular AA is a movement aimed at evangelizing modularized smart accounts. The goal is to make accounts customizable for users and allow developers to build context-rich and self-contained account features.
Social Recovery - Allow a trusted device or friends to help you recover your account in case you lose access
Spending Limits - Allow dapps to spend tokens on behalf of you up to a specified limit
Passkey Support - Login with your biometrics like FaceID
By standardizing modularity counter-party risk can be greatly reduced, leading to simple and secure web3 user experiences.
The ERC-4337 standard lays out the infrastructure components and coding standards which when implemented enables users to have a primary account type of a smart contract over a private key. Historically, the primary account type was an EOA (End User Account), which, unlike SCAs doesn't have custom validation and execution logic.
This article aims to provide you with an overview of Modular Account Abstraction, what it enables, and the existing standards and implementations.
What are the different types of modular Smart Contract Accounts?
Smart contract accounts are fundamentally smart contracts; they are upgradeable, extensible, and also inheritable. Depending on the SCA implementation it can either allow or disallow adding plugins/modules. There are two different concepts of modular AA this article will explore are: ERC-6900 and SAFE Modules.
1. ERC-6900: Modular Smart Contract Accounts and Plugins
The objective of ERC-6900 is to define a set of interfaces between a standard Account and Module implementation. The proposal hopes to improve the developer experience, Module interoperability, and data portability when switching between account implementations.
The standard is inspired by ERC-2535, however, it does not require developers to follow the Diamond pattern.
What types of plugins does ERC-6900 define?
According to the standard, plugins can be of three types:
Validation Schemes - Define the circumstances under which the modular smart contract account (MSCA) will approve the transactions on its behalf
Execution Logic - Any arbitrary logic to be performed during the execution
Hooks - Hooks can trigger any logic to be executed, pre- and post-execution of the user operation
ERC-6900 Module Diagram
The standard also defines:
How to implement Validation, Execution, and Hook plugins for a MSCA.
How compliant account implementations should add, remove, update, and inspect plugins.
Helper types like FunctionReference.
Diagram of how a transaction flows through the entry point to an ERC-6900 SCA
What types of interfaces does ERC-6900 define?
The ERC-6900 specification defines three main interfaces: IPluginUpdate, IPluginLoupe and IStandardExecutor.
1. IPluginUpdate
The IPluginUpdate interface defines:
Plugin actions ADD, REMOVE, and REPLACE
Validator types and Hook types
User defined structs to update various plugins types
A standardized updatePlugins function to be called when updating plugins and the ExecutionPluginUpdate event to be emitted post update
2. IPluginLoupe
The IPluginLoupe is inspired by ERC-2535, and ERC-6900 defines how a dapp or other contracts can read the supported plugins by the MSCA.
3. IStandardExecutor
The IStandardExecutor interface modular smart contract accounts should implement to allow for open-ended execution.
2. SAFE Modules
All SAFE-based accounts have support for SAFE Modules. To maintain high-security standards, the SAFE team followed the separation of concerns pattern and implemented different module types.
Modules - Whitelisted addresses that can execute transactions in the name of the Safe Smart Account.
Guard - A contract that can be set to perform additional checks on transactions to be executed.
Fallback Handler - A contract that can be set to handle arbitrary incoming (read) calls.
SAFE's Modules are individual smart contracts that have permission to execute transactions on the user's SAFE smart contract account. Modules can execute arbitrary transactions on the SAFE account via the execTransactionFromModule function. Since the SAFE team decides how the SAFE accounts are implemented, the plugin developers must comply with the rules and guidelines. SAFE modules are only compatible with SAFE accounts.
There are major trust assumptions between the module developer and the user, and as such, modules that are battle-tested are more likely to continue being adopted.
Diagram of SAFE Account Module
What are SAFE SCA Guards?
Guards are smart contracts that can be set for a SAFE account to perform additional security checks on incoming transactions. Before the execution of a transaction, a
Guard is called with all the transaction parameters, and if the Guard does not revert then the transaction proceeds to execution.
The Guard is called again after execution to perform state change checks or execute arbitrary logic.
Guards can also be thought of as hooks as they are appropriate for pre and post-transaction state checks.
How SAFE SCA Guards Can Protect Accounts
What is the SAFE SCA Fallback Handler?
The Fallback Handler executes all calls made to the SAFE account which can be handled by it. This can be useful to comply with industry-wide standards like contract signatures (EIP-1271). According to SAFE, “plugins are completely independent of the core SAFE contracts and maintain their own storage”.
Diagram of how the SAFE SCA Fallback Handler works
Conclusion
Modular Account Abstraction as described by ERC-6900 and designed by Safe Modules aims to extend the capabilities of Smart Contract Accounts through plugins, which can be built by developers, and safely installed by smart contract wallet users.
Modular AA is a movement aimed at evangelizing modularized smart accounts. The goal is to make accounts customizable for users and allow developers to build context-rich and self-contained account features.
Social Recovery - Allow a trusted device or friends to help you recover your account in case you lose access
Spending Limits - Allow dapps to spend tokens on behalf of you up to a specified limit
Passkey Support - Login with your biometrics like FaceID
By standardizing modularity counter-party risk can be greatly reduced, leading to simple and secure web3 user experiences.
The ERC-4337 standard lays out the infrastructure components and coding standards which when implemented enables users to have a primary account type of a smart contract over a private key. Historically, the primary account type was an EOA (End User Account), which, unlike SCAs doesn't have custom validation and execution logic.
This article aims to provide you with an overview of Modular Account Abstraction, what it enables, and the existing standards and implementations.
What are the different types of modular Smart Contract Accounts?
Smart contract accounts are fundamentally smart contracts; they are upgradeable, extensible, and also inheritable. Depending on the SCA implementation it can either allow or disallow adding plugins/modules. There are two different concepts of modular AA this article will explore are: ERC-6900 and SAFE Modules.
1. ERC-6900: Modular Smart Contract Accounts and Plugins
The objective of ERC-6900 is to define a set of interfaces between a standard Account and Module implementation. The proposal hopes to improve the developer experience, Module interoperability, and data portability when switching between account implementations.
The standard is inspired by ERC-2535, however, it does not require developers to follow the Diamond pattern.
What types of plugins does ERC-6900 define?
According to the standard, plugins can be of three types:
Validation Schemes - Define the circumstances under which the modular smart contract account (MSCA) will approve the transactions on its behalf
Execution Logic - Any arbitrary logic to be performed during the execution
Hooks - Hooks can trigger any logic to be executed, pre- and post-execution of the user operation
ERC-6900 Module Diagram
The standard also defines:
How to implement Validation, Execution, and Hook plugins for a MSCA.
How compliant account implementations should add, remove, update, and inspect plugins.
Helper types like FunctionReference.
Diagram of how a transaction flows through the entry point to an ERC-6900 SCA
What types of interfaces does ERC-6900 define?
The ERC-6900 specification defines three main interfaces: IPluginUpdate, IPluginLoupe and IStandardExecutor.
1. IPluginUpdate
The IPluginUpdate interface defines:
Plugin actions ADD, REMOVE, and REPLACE
Validator types and Hook types
User defined structs to update various plugins types
A standardized updatePlugins function to be called when updating plugins and the ExecutionPluginUpdate event to be emitted post update
2. IPluginLoupe
The IPluginLoupe is inspired by ERC-2535, and ERC-6900 defines how a dapp or other contracts can read the supported plugins by the MSCA.
3. IStandardExecutor
The IStandardExecutor interface modular smart contract accounts should implement to allow for open-ended execution.
2. SAFE Modules
All SAFE-based accounts have support for SAFE Modules. To maintain high-security standards, the SAFE team followed the separation of concerns pattern and implemented different module types.
Modules - Whitelisted addresses that can execute transactions in the name of the Safe Smart Account.
Guard - A contract that can be set to perform additional checks on transactions to be executed.
Fallback Handler - A contract that can be set to handle arbitrary incoming (read) calls.
SAFE's Modules are individual smart contracts that have permission to execute transactions on the user's SAFE smart contract account. Modules can execute arbitrary transactions on the SAFE account via the execTransactionFromModule function. Since the SAFE team decides how the SAFE accounts are implemented, the plugin developers must comply with the rules and guidelines. SAFE modules are only compatible with SAFE accounts.
There are major trust assumptions between the module developer and the user, and as such, modules that are battle-tested are more likely to continue being adopted.
Diagram of SAFE Account Module
What are SAFE SCA Guards?
Guards are smart contracts that can be set for a SAFE account to perform additional security checks on incoming transactions. Before the execution of a transaction, a
Guard is called with all the transaction parameters, and if the Guard does not revert then the transaction proceeds to execution.
The Guard is called again after execution to perform state change checks or execute arbitrary logic.
Guards can also be thought of as hooks as they are appropriate for pre and post-transaction state checks.
How SAFE SCA Guards Can Protect Accounts
What is the SAFE SCA Fallback Handler?
The Fallback Handler executes all calls made to the SAFE account which can be handled by it. This can be useful to comply with industry-wide standards like contract signatures (EIP-1271). According to SAFE, “plugins are completely independent of the core SAFE contracts and maintain their own storage”.
Diagram of how the SAFE SCA Fallback Handler works
Conclusion
Modular Account Abstraction as described by ERC-6900 and designed by Safe Modules aims to extend the capabilities of Smart Contract Accounts through plugins, which can be built by developers, and safely installed by smart contract wallet users.
Oops! Something went wrong while submitting the form.
Interested in reading more?
There are five main benefits of running an Ethereum node: privacy and security, censorship resistance, decentralization, distributed control, and sovereignty.
%201.svg)
