Summary : Solana vs. Ethereum: A Technical Comparison
This discussion provides a technical comparison between Solana and Ethereum, focusing on key architectural differences and their implications. The speaker shares insights gleaned from research, including documentation, ChatGPT interactions, and code analysis using Cloud sonnet.
Gulf Stream and Mempool Management
The discussion begins by examining Solana’s Gulf Stream transaction forwarding system. Unlike Ethereum, which uses a mempool, Solana bypasses this due to its high transaction throughput (50,000 TPS) and rapid block production rate (approximately 2 blocks per second). A traditional mempool would be quickly overwhelmed. Gulf Stream leverages the predictable leader schedule in Solana’s consensus mechanism. Validators know who will propose the next block (the “leader”) an epoch (2-3 days) in advance. This allows for efficient transaction forwarding directly to the upcoming leader, eliminating the need for a mempool. The direction of data flow within the validator network constantly shifts towards the next leader.
While efficient, questions remain about how Solana handles spam transactions. The speaker speculates that a validator scoring system based on stake might be used, but the exact mechanism remains unclear.
Virtual Machine and Execution Environment
Solana’s execution environment differs from Ethereum’s EVM. It employs two layers: the Sealevel scheduler and the eBPF virtual machine. The Sealevel schedules transactions for sequential or parallel execution based on declared read and write access to accounts. This pre-declaration enables efficient parallelization, a challenge for Ethereum due to the fact that read and write accesses of transactions are generally unpredictable, as well as its transaction fee mechanism, which necessitates a write to the block proposer’s account. Solana handles transaction fees outside the Sealevel, simplifying parallel scheduling. The second layer, eBPF (Extended Berkeley Packet Filter), is a pre-existing, compact virtual machine similar to Assembly and WASM. Unlike EVM, eBPF (and WASM) doesn’t allow dynamic (indirect) jumps, where the destination is computed at runtime. This aligns with post-1960s computer science theory and simplifies execution. eBPF is register-based, while WASM is stack-based and includes floating-point arithmetic for JavaScript interoperability. eBPF’s pre-existing compilers and compact nature contribute to efficient execution.
State Organization and Hashing
The discussion then shifts to state organization and hashing. In Ethereum, Solidity’s use of Keccak hashing to scatter data structures across storage leads to state incomprehensibility without retracing. Solana avoids this by representing the state as a weak hash map of byte blobs. Accounts in Solana have variable sizes (up to 10MB) and are subject to rent, meaning they can be deleted if their SOL balance falls below a threshold. This weak hash map structure exists in garbage collected language runtimes, and is relatively easy to work with. Solana’s use of Rust and C compilers, which don’t scatter data structures like Solidity, further enhances state comprehensibility. This eliminates the need for extensive retracing and explains why Solana doesn’t require archive nodes like Ethereum.
State Commitment and Snapshots
Solana’s state commitment mechanism differs significantly from Ethereum’s Merkle tree approach. Solana generates periodic state snapshots, which are hashed every epoch (2-3 days). Each account is hashed individually, and the hashes are concatenated and hashed as a stream. Between epochs, a mini tree of changes (append vectors) is maintained. This allows for verification of downloaded snapshots without requiring the full history. The absence of a Merkle tree means no Merkle proofs, impacting trustless bridges. Solana’s approach seems to prioritize practicality over this feature.
Cloud Break and Append-Only Storage
Solana’s Cloud Break system manages state updates using append-only files and an in-memory index. Changes are appended to new files (append vectors), and the index tracks the location of the latest version of each account. This append-only approach, combined with memory mapping, offers efficiency but requires restarts for switching to new snapshots. Cloud Break also supports distributing files across multiple disks for improved concurrent performance.
Turbine Block Propagation
Solana uses the Turbine protocol for block propagation. Blocks are divided into small shreds (around 1KB) and distributed using a BitTorrent-like protocol. → Erasure coding allows for block reconstruction even with missing shreds. This parallel distribution and redundancy contribute to Solana’s high throughput.
Proof of History and Tower BFT
Solana’s consensus mechanism, Tower BFT, a variant of Practical Byzantine Fault Tolerance (pBFT), utilizes Proof of History. Proof of History is an ever-growing hash chain that embeds transactions, establishing their relative order. This chain is maintained by the current leader and handed over to the next. → Transactions must be added to the Proof of History chain before inclusion in a block. This mechanism aims to prevent transaction reordering and enhance security.
Pipelining and Archivers
Solana employs pipelining for efficient transaction processing, similar to staged sync in earlier versions of Ethereum clients. The discussion concludes with skepticism about Solana’s archiver system for historical data. The speaker argues that archive nodes are less crucial for Solana due to its state comprehensibility. The sheer data volume and lack of clear incentives further raise doubts about the practicality of archivers.
Key Takeaways
This comparison highlights Solana’s focus on high throughput and efficient execution. Key design choices include the Gulf Stream transaction forwarding, the Sealevel scheduler and eBPF virtual machine, the append-only state storage with Cloud Break, and the Turbine block propagation protocol. While Solana’s approach offers performance advantages, it also involves trade-offs, such as the absence of Merkle proofs and the reliance on a predictable leader schedule. The discussion raises questions about the practicality of certain features like archivers and the long-term implications of Solana’s design choices.
Original video on the Akexey Akunov Monoblunt channel on Telegram: https://t.me/monoblunt/123
