Introduction: why Solana limits transactions to 64 accounts

Solana is a high-performance blockchain known for its ability to process thousands of transactions per second. This impressive speed is achieved through a unique design choice: limiting each transaction to a maximum of 64 writable accounts.

This constraint reduces computational overhead and allows Solana to manage state changes in a predictable, efficient manner. While it achieves superior performance, this limit shapes how developers structure state and logic within their apps.This research dives deep into how to break past through it, making more space for modular design.

‍

Solana's account model explained

On Solana, an "account" is essentially a storage location on the blockchain, capable of holding data such as balances, smart contract code, or arbitrary state information. Every transaction must explicitly list all accounts it will read from or write to.

To maintain performance, Solana enforces a strict 64 writable accounts per transaction rule.

This limitation serves two primary purposes:

1. Resource management: By restricting the number of writable accounts, Solana significantly reduces the overhead associated with account state lookups, updates, and data management.
2. Performance guarantees**:** Fewer writable accounts per transaction translate into simpler, faster, and more deterministic transaction processing, essential for maintaining high throughput and low latency.
   ‍

Ethereum's modular account architecture

In contrast, Ethereum adopts a highly modular account management model, where every component of an application - smart contract code, storage slots, user balances - can occupy separate, individually managed accounts.

There’s no hard limit on how many accounts a transaction can interact with. Instead, it treats each account independently, using a large sparse storage structure allowing extensive flexibility.

This modularity makes Ethereum ideal for complex dApps, allowing developers to freely expand the state management required by sophisticated applications.
‍

The builder's challenge

These differences lead developers aiming to build on Solana to face a different set of design decisions - often rethinking their entire approach. This creates a gap in expectations when applying modular design patterns, and limits the options for builders working on more stateful architectures.

Rather than working around the 64-account limit, we asked ourselves how to expand Solana's design space - bringing modularity while staying true to its performance-first the design space, developing models that preserve modular logic while preserving the execution model that makes Solana the most performant blockchain yet.
‍

A potential solution: Container Accounts

The theoretical framework we identified to reconcile these differences is the concept of Container Accounts.

A Container Account bundles multiple Ethereum-style accounts into a single Solana account.

Here’s the basic idea:

• Aggregation of accounts: Instead of spreading application state across many separate accounts (such as balances, smart contract data, and storage), Container Accounts would combine everything into one unified Solana account.
• Structured data management: Each Container would include a header that organizes and describes the data inside - like a directory or index.
  ‍

Mechanics of Container Accounts: hypothetical overview

Imagine each Container Account as a structured database. It would contain:

• A registry mapping Ethereum-style addresses to data offsets within the container.
• Serialized data from many accounts, stored within a single Solana account’s data blob.
• Logical isolation between accounts to preserve EVM transaction semantics.
  ‍

To keep performance high, account lookups could use binary search or similar efficient methods.

This approach could reduce the overall number of writable accounts involved in a transaction, thus remaining within Solana’s constraints.

Role of Reference Accounts

To make this system more usable, developers could introduce Reference Accounts. These would act as pointers located at the original Ethereum-style addresses. Each one would redirect Solana’s transaction processor to the relevant Container Account and data offset.

This could:

• Simplify data lookups, preserving Ethereum's modular account addressing semantics.
• Prevent data mismanagement or fraudulent referencing by ensuring integrity checks within the referencing system.
  ‍

Performance and cost considerations

While this model adds a layer of indirection, initial conceptual assessments suggest manageable performance overhead:

• The efficiency of structured data lookups (e.g., binary searches) could keep additional computational costs minimal.
• Significant theoretical cost savings might arise from reduced storage and management overhead, as fewer individual accounts would be maintained.
  ‍

Implications and future research directions

Understanding and theoretically addressing the differences between Ethereum’s modular account architecture and Solana’s account restrictions opens valuable research directions:

• Further exploration of alternative containerization techniques.
• Development of optimized lookup algorithms within aggregated account structures.
• Economic modeling of potential cost efficiencies from theoretical account aggregation.
  ‍

Pushing Solana forward

The 64-account limitation is integral to Solana’s design, essential for maintaining high performance and efficiency.

But as applications grow more complex, there's value in exploring models that stretch what Solana can support - without compromising its core strengths.

Container Accounts are an early-stage research in this direction: an attempt to make Solana as flexible for developers as it is performant for users - further expanding our ecosystem.

With  continued exploration, this approach could unlock new ways to combine the performance of Solana with modularity at scale - moving us closer to a truly interoperable  future.

‍