Solana Co-founder: Decoding Solana's Ultimate Architecture
TechFlow Selected TechFlow Selected
Solana Co-founder: Decoding Solana's Ultimate Architecture
All non-voting transactions can be calculated asynchronously.
Navigating Web3 tides with focused insightsAuthor: Anatoly Yakovenko, Solana CEO (Co-founder and CEO)
Translation: 1912212.eth, Foresight News
Solana's goal is to synchronize a single, permissionless global state machine as quickly as physics allows. I believe the architecture capable of achieving this will look like the following:
-
A large number of full nodes, more than 10,000 (N > 10,000)
For the network to operate as a global state machine, it must support a large number of full nodes. Turbine has already demonstrated that rapid replication across very large networks is scalable on modern hardware and networks.
-
A large number of block-producing leaders, more than 10,000 (N > 10,000)
-
Concurrent leaders producing blocks simultaneously, randomly selected in a range from 4 to 16.
Concurrent leaders allow the network to have multiple locations globally for ordering user transactions. This reduces the distance between users and the network, eliminating the need for full-node validation before transactions are added to the chain.
-
Block time of 120 milliseconds
Short block times create fast finality points, enhance censorship resistance, improve user experience, reduce the window for transaction reordering, and accelerate the network overall.
-
A subset of voting consensus nodes in an approval committee, numbering between 200 and 400, with randomly selected leaders rotating every 4 to 8 hours per epoch.
Consensus is critical for selecting forks, which occur due to network partitions. A sample of 200 or more nodes will statistically represent all major partitions in the network and closely match their actual distribution. Therefore, it is unnecessary for all full nodes to vote—200 is sufficient. Limiting approval to a committee reduces the memory and network bandwidth required to support 120-millisecond blocks. Reducing block time naturally increases the number of votes sent per second, placing pressure on resources allocated for consensus.
The real challenge in 120-millisecond blocks is replaying all user transactions. Since the network is permissionless, guaranteeing a homogeneous execution environment with reliable timing for arbitrary user code is extremely difficult. While possible, it can only be achieved by limiting computational resources available to user transactions and ensuring each node is over-provisioned for worst-case scenarios.
However, there is no reason for consensus nodes voting on forks or leaders building on forks to execute full state. To keep consensus nodes and leader approvals synchronized, state only needs to be computed once per period.
Asynchronous Execution
Motivation
Synchronous execution requires all voting and block-producing nodes to be massively over-provisioned for any block to determine worst-case execution time. Asynchronous execution is one of the rare cases with almost no trade-offs. Consensus nodes can do less work before voting. Work can be aggregated and batched, making it efficient during execution without any cache misses. It could even be executed on machines entirely different from consensus nodes or leaders. Users who desire synchronous execution can allocate sufficient hardware resources to execute each state transition in real time without waiting for the entire network.
Given the diversity of applications and core developers, planning one major protocol change per year would be worthwhile. If I had to choose one, my pick would be asynchronous execution.
Overview
Currently, validators rapidly replay all transactions in every block and only vote after computing the full state for that block. The goal of this proposal is to decouple fork choice voting decisions from computing complete state transitions for blocks.
Validators voting in the quorum only need to select a fork; they do not need to execute any state at all. They only require state at the end of each epoch to compute the next quorum.
The voting program is modified so it can be executed independently. Nodes execute only the voting program prior to voting. Since validators don’t consume much space, memory requirements should be relatively small. Because voting has highly predictable execution time, executing the voting program should introduce almost no jitter.
All non-voting transactions can be computed asynchronously. This allows replaying batches of all non-voting transactions, pre-fetching and JIT-compiling all programs in advance, nearly eliminating all cache misses. The long-term goal is that only machines requiring real-time, low-latency full-state computation will be configured for this task. Presumably, users will pay extra for such hardware.
Once fork choice and state execution are separated, moving forward becomes easier:
-
Asynchronous execution
-
Fixed-size voting committee rotated every epoch
-
200-millisecond block time
Since user transaction replay no longer blocks fork selection, variability ceases to be an issue when reducing block time. The only consideration is that validator voting rates double at 200 milliseconds. A fairly straightforward modification to how quotas are calculated for quorums will allow us to fix the quorum size at 200, 400, or any other suitable number.
Completely separating execution from consensus also becomes natural. Restarts will be faster, requiring only consensus nodes checking voting program accounts within a fixed-size quorum.
In practice, I believe confirmation times will improve because the vast majority of the quorum will vote as quickly as possible, while nodes providing full-state execution results to users can simultaneously replay transactions. Thus, any replay jitter we see today should occur concurrently with the propagation of voting messages.
Voting
-
A voting account must hold enough SOL to cover voting for 2 epochs.
-
Voting transactions must be simple. Non-simple votes will inevitably fail execution. Block producers should discard complex votes.
-
Withdrawing SOL from a voting account is allowed as long as the balance does not drop below the amount needed for 1 epoch of voting.
-
To zero out all lamports, the Vote CLOSE instruction requires a full epoch to pass. A voting account marked CLOSE in epoch 1 can only be closed in epoch 2. CLOSE allows withdrawal of all SOL and deletion of the voting account. Once marked CLOSE, an account can only be fully deleted and cannot be reopened.
-
Votes include a VoteBankHash instead of a regular BankHash.
Leader Scheduling and Quorum
Only validators meeting the following conditions:
-
Stake amount > X
-
And SOL > voting requirement for 2 epochs
-
And not marked as CLOSE
can enter leader scheduling and count toward the quorum. For version 2, we can separate LeaderSchedule from Quorum, allowing them to have different requirements.
VoteBankHash Calculation
Unlike calculating BankHash over all transactions, validators compute VoteBankHash only over simple voting transactions associated with validators in the LeaderScheduler. All other transactions are ignored. After replaying all votes, VoteBankHash is computed in the same format as the current BankHash.
VoteBankHash should accumulate previous VoteBankHashes, not full BankHashes.
BankHash Calculation
For all optimistically confirmed blocks (configurable to all blocks), validators begin computing UserBankHash, which includes all state transitions except those already accounted for in VoteBankHash calculation.
Then, BankHash is derived from the accumulation of (VoteBankHash, UserBankHash). The top 99.5% of validators submit BankHash as part of their vote every 100 slots. Although submitted every 100 slots, it is computed every slot. Notably, having a small subset of nodes consistently submit BankHash via gossip as a soft signal indicating no observed non-determinism may be worthwhile.
If fewer than 67% of validators submit complete BankHash calculations, leaders should reduce available block space for user transactions and writable accounts by 50%. This measure protects the chain from abuse that could excessively increase replay time.
BankHash should accumulate previous BankHashes.
Bankless Leaders
During block creation, leaders likely won't have access to the state required to build the block, and executing all transactions during block creation isn't ideal.
-
Leaders maintain a cache of payer account balances.
-
If a payer account is used as the source for a system transfer, or passed with the system program as a writable account to another program, its balance is set to 0.
-
Blocks are packed by local fee priority based on declared compute units (CUs) until full.
-
Fees are deducted from the payer account balance cache.
-
The payer account balance cache is replenished by BankHash computation.
The cost to the network from failed spam transactions is relatively small, including only bytes stored in archives and bandwidth needed to propagate transactions within blocks.
Given that validators already seek to maximize their own revenue, they have strong incentives to maintain an accurate payer account cache. Additionally, without penalty mechanisms, anyone on the network could easily serve this cache over time. In case of server failure, bankless leader operators should be able to easily switch or sample from multiple sources.
This means that driven by validators' incentive to maximize revenue, they will strive to maintain accurate payer account caches. Without penalty mechanisms, this cache could long-term be served by any node in the network. Moreover, if a server fails, bankless leader operators should be able to easily switch or sample from multiple sources.
Trade-offs
The main trade-off is that full nodes serving user state lack confirmed signatures proving their provided state exactly matches the rest of the quorum. The authoritative interpretation of state should remain unchanged, even if each transaction is replayed sequentially in the ledger. No performance optimization should alter the outcome. Therefore, once a fork is finalized, only one correct state remains computable, assuming no bugs in the runtime implementation.
Nodes aiming to reliably serve state should run multiple machines and clients and halt operations if discrepancies arise during state execution. This is essentially what operators should do today, since relying solely on the rest of the network introduces an honest-majority assumption.
Users can also sign transactions asserting BankHash or triggering aborts. These transactions are only executed by the rest of the network if the exact computed BankHash matches the BankHash provided to users by RPC providers.
Long-Term Stateless Consensus Node Roadmap
A network with fixed-size quorums requires only a very small amount of state to start. The quorum itself, its stake weights, and all voting account balances. This is a tiny memory footprint and a minuscule snapshot file that can be quickly distributed and initialized upon restart.
Full nodes simultaneously tracking both quorum and state will halt if the quorum diverges from state. This means exchanges, fiat gateways, RPC services, bridges, etc., will all stop operating if quorum and state disagree. This requires only a minimal fraction of faulty stateless consensus nodes.
Bankless leaders can rely on samples from multiple full nodes to provide initial payer account balance caches. Even if flawed, the result would be spam in blocks rather than consensus failure. Operators should be able to monitor their leader health and the percentage of spam injected into blocks, responding swiftly to failures.
Join TechFlow official community to stay tuned
Telegram:https://t.me/TechFlowDaily
X (Twitter):https://x.com/TechFlowPost
X (Twitter) EN:https://x.com/BlockFlow_News
@anatolyakovenko
