What is ERC4337 on Solana?
ERC-4337 is a standard designed to bring Account Abstraction (AA) to Ethereum. Under Ethereum’s existing account model, user accounts (externally owned accounts, or EOAs) and contract accounts (CAs) are strictly separated, and a CA cannot issue transactions on its own. This means that whenever developers want to implement advanced features such as multisig or social recovery they typically have to rely on an EOA to trigger those contract functions and pay transaction fees, which can lead to a less streamlined user experience.
To address this, ERC-4337 introduces a separate mempool and “bundler” (block producer) mechanism that does not require major protocol-layer changes. Through this system, contract accounts (CAs) can directly initiate and sign transactions. In doing so, developers gain the flexibility to implement features like social recovery, fee sponsorship, session keys, and other custom security models, ultimately making Account Abstraction a reality on Ethereum.
How Has Solana Already Solved the Same Problem?
In contrast to Ethereum’s approach, Solana was designed from the outset to support account abstraction at a protocol level. Below are the main reasons why Solana inherently addresses many of the issues that ERC-4337 seeks to solve:
All Accounts as Flexible Data Storage
Solana treats every account as a flexible “storage bucket,” capable of holding arbitrary data. In other words, an account on Solana is not limited to storing a simple balance or nonce:
- Data Persistence: Each account can store state and metadata for various use cases, similar to how a file in a filesystem can contain different types of content.
- Ownership: An account on Solana specifies which program (smart contract) owns it. That ownership determines how the account’s stored data is controlled, updated, or validated.
This design naturally allows for much broader state management compared to traditional EOAs on Ethereum, which are restricted to storing only balances and nonces.
Programs as Executable Accounts
Solana smart contracts are called programs, and each program is also an account, specifically, an executable account. By contrast, a non-executable (data) account is used to store actual state (e.g., user balances, configuration data, or other custom info):
- Program Account: Contains compiled code that the Solana runtime can execute.
- Data Account: Holds data and assets that a program manages.
Because programs exist as dedicated accounts, developers can easily separate a contract’s logic from the storage of user or application data. In many ways, this is more modular than Ethereum’s approach, where code and state reside within the same contract account.
Program Derived Addresses (PDA) - 솔라나 네이티브 AA의 핵심
ERC-4337의 "트랜잭션 발신자로서의 컨트랙트 계정"과 밀접하게 유사한 것이 솔라나의 Program Derived Address (PDA) 기능입니다. PDA는 개인 키에서 파생된 주소가 아니라 솔라나 프로그램 자체에서 생성된 주소입니다. 이는 다음과 같은 중요한 의미를 갖습니다:
개인 키 불필요
- PDA는 개인 키 없이도 온체인 명령에 효과적으로 "서명"할 수 있습니다. 솔라나 런타임은 특정 프로그램이 이 주소를 대신하여 작업할 권한이 있음을 인식합니다.
맞춤형 규칙 및 로직
- PDA는 특정 프로그램에 연결되어 있기 때문에, 개발자는 지출 한도, 화이트리스트/블랙리스트, 소셜 복구 메커니즘 또는 세션형 권한과 같은 규칙을 온체인 로직에 직접 내장할 수 있습니다.
자체 실행 컨트랙트
- 이더리움에서는 일반적으로 컨트랙트가 작업을 수행하려면 외부 호출(EOA 또는 ERC-4337 번들러를 통해)이 필요합니다. 솔라나에서는 PDA를 제어하는 프로그램이 솔라나 런타임의 제약 조건 하에서 자율적으로 상태 전환을 관리할 수 있습니다.
사용자를 대신하여 트랜잭션 수수료를 지불하는 것부터 고급 멀티시그 플로우를 활성화하거나 DeFi 프로토콜에서 자동 리밸런싱을 수행하는 것까지, PDA는 솔라나에 네이티브로 제공되는 다양한 가능성을 제공합니다.
Built-In Support for Complex Interactions (CPI)
Solana also supports Cross-Program Invocation (CPI), which allows programs, and by extension their PDAs, to interact directly with one another. This is essential for composability:
- A program can call another program using CPI, while retaining control over its PDAs and adhering to the Solana runtime’s security model.
- Developers do not need external bundlers or specialized “entry points” to chain multiple contract calls. Instead, they orchestrate everything via straightforward CPI calls within a single transaction flow.
For account abstraction, CPI means seamless composability among different programs and PDAs precisely the kind of flexibility ERC-4337 is designed to enable on Ethereum.
A Comparison with ERC-4337
When viewed side by side, Solana’s account model and Ethereum’s ERC-4337 solution both aim to provide more dynamic, programmable user accounts. However:
- Ethereum (ERC-4337): Relies on a bundler and a specialized mempool to let contract accounts originate transactions without deep protocol changes.
- Solana: Naturally supports an environment where any account can store custom data, and where programs can own PDAs that operate without private keys.
| Category | Ethereum (ERC-4337) | Solana |
|---|---|---|
| Architecture | Uses bundlers and a specialized mempool | Natively supported via PDAs at the protocol level |
| Transaction Origination | Contract accounts can’t initiate transactions directly - rely on bundlers | Programs can initiate transactions directly through PDAs |
| State Storage | EOAs can only store balances and nonces | All accounts can store arbitrary custom data |
| Logic – Data Structure | Logic and state are combined in a single contract account | Logic (program) and data (account) are separated |
| Flexibility | Extended via a Layer-2-like structure | Built-in as a native feature of the core design |
두 접근 방식 모두 사용자 경험을 향상시키고 온체인 애플리케이션의 범위를 확장하는 것을 목표로 합니다. 그러나 솔라나의 설계는 네이티브 방식이며 유사한 기능을 달성하기 위해 추가적인 표준이나 제안이 필요하지 않습니다.
