Solana vs Polkadot

Solana and Polkadot are two popular blockchain ecosystems focused on scalability, low cost of transactions and a smooth developer experience. Solana is a Layer-1(L1) blockchain that uses a monolithic approach, while Polkadot is a Layer-0(L0) blockchain that uses a modular approach, but both rely on a modified version of Proof-of-Stake for consensus. Polkadot is considered a Layer-0 blockchain because it serves as the foundational security layer for other blockchains, enabling them to operate and interconnect securely within its ecosystem.

Solana uses a monolithic state machine of nodes that route messages quickly to achieve a 400ms block time. In contrast, Polkadot uses the concept of parachains and a relay chain, similar to a hub and spoke system. In this setup, the relay chain acts as the hub, connecting all the parachains together..

Solana’s Monolithic Architecture

Polkadot Modular architecture

Accounts Model

Solana and Polkadot use accounts to persist state changes onchain. Digital signatures are used to authenticate and authorize these changes, with both blockchains employing fast digital signature algorithms to ensure scalability and efficiency.

Digital Signature Algorithms

Solana and Polkadot use digital signatures to verify authenticity of transactions in order to mutate state on the blockchain. Solana uses Ed25519 for signing and verification of transactions while also supporting the verification of secp256r1 and secp256k1 signatures. Ed25519 is based on EdDSA digital signature scheme and Curve25519 elliptic curve cryptography which are designed for high speed signature signing and verification while offering 128 bits of security meaning that brute force operations would require at least 2¹²⁸ operations.

Polkadot's default signature of choice for accounts is sr25519 which is based on Curve25519, same as Ed25519 but swaps EdDSA for Schnorr signatures, which is more efficient while offering the same 128 bits of security. sr25519 supports native multi-signatures aggregation and hierarchical key derivation (HDKD) while offering the same benefits as Ed25519 like strong side-channel resistance, fast key generation, fast signing, faster batch verification and collision resistance. Polkadot also supports Ed25519 and secp256k1 signature schemes.

Solana Ed25519 addresses use Base58 format to identify all accounts while the SS58 address format is used in Polkadot ecosystem. SS58 is an enhanced version of Bitcoin's Base58Check encoding, with key improvements including a network-specific address prefix (e.g., Polkadot starts with 1, Kusama (Polkadot’s testnet chain) with capital letters, and generic Substrate parachains with 5). These prefixes help clearly identify the network an address belongs to while remaining compatibility across parachains, since all SS58 addresses are different encodings of the same underlying public key. Compared to Base58Check, SS58 offers better network identification, stronger address validation, and seamless interoperability across Substrate ecosystems.

Solana Key & address generation:

Polkadot seed, key hierarchical key and address generation

Solana accounts model

Solana native token is denominated in SOL which is divisible into 1 billion units called lamports. In Solana an account is a contiguous region of memory storing the account data as bytes. An account holds these lamports in the lamports sequence of this region of memory. Solana accounts need to be rent exempt by paying two years worth of rent to remain active. Rent is required to prevent denial-of-service attacks against the validators securing the network. In a nutshell, it is the storage cost for the account to remain active in a validator’s memory, therefore, the more storage you need, the more SOL you have to lockup.

Accounts can store a maximum of 10MiB of data in it’s data field within the region of memory storing the account as illustrated in the figure below. The stored data contains either the account state or executable code in eBPF bytecode that can be executed by the Solana Virtual Machine (SVM).

A solana account structure as bytes in memory

The owner is a program ID (32 byte public key) that identifies the program that owns the account, and only this owner program can change the account's data or reduce its lamports balance.

The executable field of an account containing executable data (a program) is marked true. The rent_epoch field contains an 8 byte field describing when the rent is due, however, this field is a legacy deprecated field since accounts are required to be rent exempt.

Solana accounts can be categorized into 4 types:

User Accounts: An account contains a private and public key on the Ed25519 curve. This account can sign transactions and is usually created and stored by a wallet. It can be converted into a BIP-39 mnemonic word list for recovery purposes.
Data Account: Stores the state of an account. This state can include information such as the whether and account is initialized (account state), metadata of a mint, or the number of tokens an account holds.
Program Accounts: They store executable code in eBPF format, which can be run by the Solana Virtual Machine. Solana programs are mainly written in Rust, with SDKs available for Python and TypeScript. Since Solana separates logic from programs, an executable program needs to change the state of data accounts to update the program state. User-defined state is often stored in Program-Derived Accounts (PDAs), which are addresses derived from a known seed and assigned to a program that can sign transactions performed on the PDA. Only the keypair used to deploy the program can modify an executable program to make updates.
Native Programs accounts: These are special program accounts that are pre-deployed on-chain to offer a standard interface for various operations like voting and signature validation. They provide built-in functionality for handling instructions for common tasks like creating mints or token accounts. All new accounts belong to the system program, which is responsible for creating new accounts, allocating space for the bytes specified in the data field of each account, and transferring ownership of the account to another program.

Accounts, except for native program accounts, can be closed, and the lamports reserved as rent can be sent to an address specified during the account closure instruction within a transaction.

Polkadot Account Model

Polkadot's native token is DOT. It can be used for staking, governance, and bonding. DOT holders can:

Act as a network participant who can be a validator, collator, nominator.
Participate in the governance of Polkadot and in making changes to the Polkadot infrastructure, such as upgrades.
Make bids for block inclusion as a collator for a parathread.

The AccountInfo defines the structure of how an account is stored. This structure manages an account's state and prevents its early removal while it is still referenced by other onchain data or modules.

Polkadot Account In fo

The account contains:

nonce - the number of transactions this account has sent.
consumers - the number of other modules that currently depends on this account's existence. This account cannot be reaped until the number of dependent modules is zero.
providers - the number of other modules that allow this account to exist and may not be reaped unless it is zero.
sufficients - the number of modules that allow this account to exist for their own purposes only. It can only be reaped if consumers and providers field is zero.
data - A flexible data structure, customizable in the runtime configuration, typically contains balances or other user-specific data. It contains the fields:
- free - The non-reserved is the DOT balance that the account holder can control.
- reserved - funds that are temporarily reserved or locked and cannot be freely transferred or spent. This concept is used within the network to manage certain operations and ensure commitments by users.
- frozen - The total amount ( free + reserved) that should not fall below a certain level when reducing the balance, except in cases where the account owner doesn't gain from the balance reduction, like slashing.
- flags - Extra information about this account.

In Polkadot, account addresses are generated using the SS58 format, which is a modified version of Bitcoin’s BIP-13 Base58 Check algorithm. Examples of Address types in Polkadot:

0x00: Polkadot mainnet
0x02: Kusama (Polkadot Testnet)
0x2A: Generic substrate address
0x30: Raw sr25519 key
0x31: Raw Ed25519 key

These addresses are derived from a public key, which can be either SR25519 or Ed25519. Ed25519 has better hardware support, but SR25519 is more efficient because it uses Schnorr signatures. This allows for safer complex cryptographic operations on top of this scheme such as HDKD, MuSig, and a verifiable random function (VRF).

Both SR25519 and Ed25519 can be used for addresses that are intended to hold DOT and participate in governance.

Polkadot accounts can be grouped into four types:

Stash accounts: used for long-term storage of DOT tokens, also known as a stash.
Multi-signature accounts: Multi-signature accounts are used to secure a stash with multiple signatories, for group participation in governance, and for board decision entities to manage a treasury. Once created, multi-signature accounts cannot be changed. You cannot change the members or the threshold; you must dissolve the current multi-signature configuration and create a new one. Because of this, multi-signature account addresses are deterministic, meaning you can always determine the address by knowing the members and the threshold, even if the account doesn't exist yet. This allows you to send tokens to an address that hasn't been created yet, and if the designated members form a new multi-signature with the same threshold, they can access the tokens immediately.
Proxy account - Proxy accounts offer a more flexible and secure way to delegate specific permissions, such as staking, governance, or transfers, to another account. A proxy can be assigned precise permissions with time limits, delayed execution, or restricted scopes. This makes it a more powerful and customizable system for managing account actions without compromising security.
Session keys: technically not an account, but a combination of account keys in hot storage used by validators to perform network operations like block production and finalization. They are not used for holding funds and can be rotated regularly for security. These keys are typically generated by the client and registered via a certificate signed by a staking proxy. Polkadot currently uses six session keys, each with a specific cryptographic scheme:
- Authority Discovery: Polkadot's parachain logic that retrieves the current and next set of validators (authorities). It uses the sr25519 scheme.
- BABE (block production): sr25519 - BABE consensus mechanism which uses sr25519 for both signatures and VRFs. There are future plans to adopt BLS keys for GRANDPA to support more efficient signature aggregation.
- BEEFY: (Bridge Efficiency Enabling Finality Yielder) is a secondary protocol to GRANDPA that supports efficient bridging between relay chains like Polkadot and Kusama and remote, separate blockchains such as Ethereum, which were not designed with Polkadot's native interoperability. This protocol enables participants of the remote network to efficiently verify finality proofs created by validators on the relay chain, allowing clients in the Ethereum network to verify that the Polkadot network is at a specific state. It uses ecdsa scheme for signatures.
- GRANDPA (finality): consensus mechanism that achieves finality. It uses ed25519 keys.
- Parachain Assignment: This key is used by validators to signal their availability and intent to validate parachains. It helps in the assignment process, where validators are selected to work on specific parachain blocks. It uses sr25519 scheme.
- Parachain Validator: Once assigned, this key is used during the actual validation of parachain blocks. Validators use this key to sign their validation results, ensuring the block they checked is correct. ed25519 is the scheme chosen for its speed and simplicity in verification during the execution of these tasks.

Transactions

Transactions are used to change the state of an account, whether it's for sending tokens between users, voting, or governance. Solana and Polkadot have different methods for updating on-chain state because of their monolithic and modular architectures.

Solana Transactions

Transactions on Solana are optimized for efficiency and speed of execution with a maximum transaction size of 1232 bytes. The transaction structure consists of two major parts, the Message containing all the instructions to execute and metadata to validate the transaction and the second part which is a list of Ed25519 Signatures that signed the transaction. The signatures field is just a list of 64 bytes Ed25519 signatures with the maximum number of signatures limited to the maximum transaction size.

Instruction execution is an indivisible and irreducible process executing in order, such that either all occur, or none occur and the transaction fails. Transactions are serialized into bytes before being forwarded to a Solana validator. The byte format used for serialization of instruction data between onchain programs and client applications is Binary Object Representation Serializer for Hashing (Borsh) since it is lightweight, fast and deterministic.

Transactions in Polkadot

Polkadot transactions, also called extrinsics, are how users, parachains, and other entities interact with the runtime of a Substrate-based blockchain. These extrinsics are encoded using the SCALE (Simple Concatenated Aggregate Little-Endian) codec, which ensures compact and efficient serialization of transaction data. Each extrinsic contains essential metadata and call information and must conform to the expected structure for execution within the runtime.

Polkadot extrinsics are handled by pallets. A pallet is basically a modular, pluggable piece of logic — like a mini-app or plugin — that adds specific functionality to your blockchain.

A standard Polkadot transaction includes:

Sender Address: Typically an SS58-encoded Ed25519 or Sr25519 public key.
Signature: Proves the transaction was authorized by the account owner.
Nonce: A sequential counter ensuring the transaction is only processed once and in order.
Era: Defines the transaction's lifetime. Transactions can be mortal (expire after a range of blocks) or immortal if the era is 0.
Tip (optional): A fee bonus to incentivize prioritization by block producers.
Call (Method): The action to perform, such as transferring funds or calling a smart contract. This includes:
- Pallet index
- Function index
- Arguments for the function
MetadataHash: Optional, the metadata hash which should match the RUNTIME_METADATA_HASH environment variable.
Mode: The flag indicating whether to verify the metadata hash or not.

Types of Extrinsics:

Polkadot supports three types of extrinsics:

Signed extrinsics: The standard transaction format used by most users. These require the sender's signature and pay transaction fees.
Unsigned extrinsics: Do not include sender information or fees. Used in special contexts such as validator session key announcements.
Inherents: System-level transactions like timestamps or consensus info. These are added by block authors and are not user-submitted.

Polkadot employs a weight-based fee model, computed as:
fee = base_fee + (length_in_bytes * length_fee) + weight_fee

The fee multiplier adjusts dynamically based on block saturation. High-demand periods increase fees to prevent spam and prioritize meaningful transactions. Fees are paid up-front and are burned or distributed according to chain logic.

Transactions can also be used to:

Submit proposals or votes in on-chain governance.
Trigger runtime upgrades, where the entire chain logic (Wasm blob) is replaced without forks.
Enact referenda or execute root-origin privileged operations.
Send messages across parachains.
Transfer assets cross-chain.
Open/close XCM channels.
Renew core assignments on the relay chain.

Interoperability of transactions from parachain to another parachain is achieved via XCM (Cross-Consensus Messaging) format which is delivered using the Cross-Consensus Message Passing (XCMP) protocol.

Parachains have accounts on the relay chain (L0) and can use these to submit transactions (e.g., runtime upgrades, staking operations, or crowdloans). Users on parachains often do not require DOT, as economic models are parachain-specific.

Architecture

Solana’s monolithic architecture ensures that all nodes within the network that are participating in consensus act as one unified state machine. Polkadot allows partial independence of nodes through it’s modular design by providing building blocks for a shared security, consensus model and inter-parachain message passing of transaction.

In Solana RPC (Remote Procedure Call) providers nodes act as access points for interacting with the network. They run similar software to validators but don't help produce blocks or take part in consensus since they don't have any stake. Instead, they simulate transactions and offer real-time data for users and developers. Unlike other blockchains where RPC and validator roles are often combined, Solana keeps them distinct. Transactions submitted to RPC nodes are forwarded to the current leader responsible for producing blocks.

Polkadot’s modular architecture is composed of four main roles: the relay chain, collators, nominators, and validators.

The relay chain is the heart of the network, responsible for consensus, shared security, and communication between blockchains.
Validators secure the relay chain by validating proofs from parachains and participating in consensus.
Nominators support validators by staking DOT and selecting trustworthy validators to help maintain the network.
Collators operate parachains by collecting transactions, producing blocks, and submitting them to validators for inclusion on the relay chain.

Each parachain is a specialized blockchain that connects to the relay chain via a parachain slot, which is obtained through an auction. For chains that don’t need constant access, on-demand parachains provide a flexible, pay-per-block alternative and are scheduled through the parathread pool.

External networks like Ethereum or Bitcoin can connect to Polkadot through parachains called bridges using dedicated bridge slots making the external chain appear as a parachain to the relay chain (meeting the network host's parachain requirements). Bridges enable interaction with other blockchains that aren't naturally compatible with the relay chain. This model is better for cross-chain interaction than Solana which does not natively support connections to other blockchains.

Relay chain and parachain blocks impose limits on:

Maximum block size (in bytes)
Maximum block weight (execution time complexity)

25% of the block space is reserved for operational transactions (e.g., misbehavior reports, validator heartbeats). Remaining space is allocated based on transaction priority, which is determined by total fees. High-fee transactions are favored by block producers seeking higher rewards.

Leader Election

Solana uses a leader schedule where each leader is a validator responsible for creating blocks and propagating those blocks to other validators in the network. Each block is part of a 400ms timeframe called a slot, during which a leader collects transactions and creates a block. Each slot is part of an epoch that consists of 432,000 slots, which lasts about 2 days at 400ms per slot. A leader schedule is generated before each epoch with each leader being assigned to a particular slot.

Solana introduced Stake-Weighted Quality of Service (SWQoS) to improve transaction reliability and resist spam or Sybil attacks. SWQoS prioritizes transactions relayed through staked validators. In this system, a validator’s share of stake directly determines how much transaction traffic it can forward to the current leader—e.g., a validator with 1% stake can transmit up to 1% of the packets. This ensures that participants with more stake, and thus more trust in the network, have a proportional share of transaction bandwidth, helping prevent spam and denial-of-service attacks from unstaked or low-stake nodes.

Currently, SWQoS reserves 80% of a leader's transaction processing capacity for stake-weighted traffic. The remaining 20% is left for general traffic from unstaked nodes. While stake-weighted access is normally exclusive to validators, Solana allows for trusted RPC nodes to "borrow" virtual stake by peering with validators. This setup lets RPCs benefit from prioritized access to the leader without needing to hold stake themselves. Network operators can customize the stake-weight behavior through configuration options, even assigning virtual stake to specific peers to fine-tune traffic control. Validators with higher stake stand a better chance of being elected as leaders.

Polkadot uses a hybrid consensus mechanism composed of two protocols, BABE and GRANDPA, to handle validator scheduling, block production, and finality. BABE (Blind Assignment for Blockchain Extension) is in charge of block production and assigns slots to validators probabilistically using a verifiable random function (VRF), with a fallback round-robin method to ensure each slot has an author. This slot-based system runs on a predictable cadence—roughly every six seconds—with the possibility that multiple validators are eligible per slot, providing built-in redundancy and enhancing liveness. Validators are selected based on stake, reinforcing the security of the system.

Once blocks are produced and validated through BABE consensus, finalization of blocks by the network is done through GRANDPA (GHOST-based Recursive Ancestor Deriving Prefix Agreement) consensus. Rather than finalizing blocks one by one, GRANDPA votes on entire chains of blocks, allowing it to finalize large batches efficiently—potentially thousands at a time. This separation of duties reduces network complexity: BABE’s linear complexity supports scalable block production with low overhead, while GRANDPA’s quadratic complexity is offset by its ability to quickly finalize many blocks in one round. Together, they enable Polkadot to maintain consistent block times, high throughput, and strong security guarantees.

In Polkadot, leader (validator) selection is driven by a system called Nominated Proof of Stake (NPoS), which is designed to maximize both security and decentralization. Instead of allowing anyone with stake to become a block producer, NPoS introduces a nominator–validator relationship.

Here's how it works:

Validators are responsible for producing blocks and securing the network.
Nominators are regular token holders who don't want to run validator nodes themselves but still want to participate in securing the network. They do this by backing (nominating) trustworthy validator candidates with their stake.
The election mechanism, run every era (usually 24 hours), selects a fixed number of validators (e.g. 297 on Polkadot as of now) from a larger pool of candidates, using an algorithm that aims to maximize the overall stake distribution while ensuring fairness.

This means validators are not selected solely based on their own stake, but on the total amount of stake backing them—both their own and their nominators’. This pooled stake increases their chance of being elected to the validator set and thus participating in block production via BABE, Polkadot’s block authoring protocol.

The system encourages decentralization by favoring validators who receive stake from many different nominators rather than a few large ones. In this way, NPoS ensures that leaders (validators) are economically incentivized and socially trusted, resulting in a more robust and sybil-resistant network.

Like Solana, validator election in Polkadot is divided into timeframes called an era. An era lasts 24 hours (or 6 hours on Kusama) and determines the active validators. The set of active validators changes with each era. Each era is split into 6 sessions, where validators are assigned specific slots to produce blocks. Validators know their assigned slots for each session but not for the whole era.

Transaction Creation & Block Propagation

Solana transaction creation and propagation is simpler since it relies on Ed25519 signatures for signing transactions and consensus nodes update a shared global state. A transaction is constructed by a user’s wallet and then sent to RPC providers which let users interact with the network and simulate transactions. They run the same software as validators but don't hold stake, so they can't vote or build blocks. Solana doesn't use a mempool. Instead, it uses a solution called Gulf Stream. In this system, RPCs receive transactions over HTTP, find the current leader's IP address and port using the leader schedule for the current epoch, and then forward the transactions over the QUIC transport protocol to validators based on Stake-Weighted Quality of Service (SWQoS).

Polkadot transactions are submitted to a collator. The collator includes it in a parachain block and forwards it to a relay chain validator. Validators verify the block's correctness and include a "proof" of the parachain state transition in the next relay chain block. This is how the transaction becomes finalized in the network. On-demand parachain transactions go through the same process but share limited block inclusion slots, so they may experience some delay depending on competition in the parathread pool. Polkadot relay chain blocks are produced approximately every 6 seconds, and parachains are expected to submit a new block in each relay chain block cycle. This enables secure parallel execution while keeping finality relatively quick and consistent across the ecosystem.

A Solana leader validator streams blocks using continuous block building, while Polkadot uses discrete block building, which creates a complete block before sending it to the network. Continuous-block building lowers latency by streaming blocks in chunks as they are sent through the network using Solana’s Turbine protocol for block propagation. Turbine is a peer-to-peer protocol for block propagation, similar to BitTorrent. When a block is created, it is divided into smaller packets with Reed-Solomon erasure codes to correct errors if packets are lost. These packets are sent to a random group of peers, who then pass them on to other peers, continuing the process to ensure efficient block propagation.

Smart Contract Execution on the Virtual Machine

Solana’s execution environment, known as the Solana Virtual Machine (SVM), is built for high throughput and low latency by allowing parallel transaction execution, which significantly boosts efficiency and scalability. Each validator operates an isolated instance of the Solana Virtual Machine. Sealevel is the parallelization virtual machine that schedules transactions to run simultaneously, as long as they don't modify the same state. Each transaction must declare in advance which parts of the state it will read or write. The Sealevel VM then examines a block's transactions to find those that can safely run in parallel and distributes them across the system's CPU threads, GPUs, and SSDs for execution. This method is inspired by "scatter-gather" patterns in operating systems and enables Solana to scale with hardware improvements.

The SVM ensures strict isolation using pessimistic concurrency control and keeps multiple versions of state in memory (MVCC) for concurrent access. Its use of eBPF allows for near-native execution speeds. Together with Solana’s account-based model and deterministic ordering through Proof of History (PoH), the system can handle thousands of transactions per second with very low fees.

Polkadot uses WebAssembly (Wasm) for running smart contracts through the pallet-contracts module, which is part of the Polkadot SDK. This module allows developers to deploy and run smart contracts on a parachain using Wasm as the execution environment. Wasm offers a secure and efficient sandboxed runtime, enabling it to work well with Polkadot’s parachain setup. Smart contracts written in high-level languages like Rust can be compiled into Wasm bytecode, making them portable and compatible across different parachains. The pallet-contracts module also includes features like gas metering and storage deposits, which track and manage resource use to prevent network abuse.

The upcoming Polkadot Virtual Machine (PVM) builds on these foundations by introducing a new execution environment specifically designed for Polkadot’s needs. Unlike Wasm, PVM uses the RISC-V binary specification, which is lightweight, efficient, and flexible. PVM integrates smoothly with Polkadot’s parachain architecture, offering better scalability and compatibility for executing RISC-V-based smart contracts. A key innovation in PVM is the pallet-revive module, which improves smart contract lifecycle management by allowing dynamic pausing, resuming, and updating of contracts. This feature gives developers and users more control over contract states, ensuring adaptability and resource optimization. The Revive pallet also supports executing Solidity smart contracts and running smart contracts on the relay chain (L0).

Smart contract scheduling and execution in Polkadot are improved through its shared security model and parachain infrastructure. However, true asynchronous parallel execution is unique to PVM, which uses Polkadot’s multi-chain setup to reduce congestion and ensure fair access to computing resources. By spreading workloads across parachains, PVM lowers latency and boosts throughput, solving a major limitation of traditional blockchain systems. The pallet-revive enhances this by allowing detailed state management, ensuring that inactive or underused contracts don't waste resources.

The Solana Virtual Machine (SVM) and the Polkadot Virtual Machine (PVM) both offer efficient execution for smart contracts. SVM's strength lies in its Sealevel parallel execution runtime, which runs smart contracts in parallel across CPUs, GPUs, and SSDs. In contrast, Polkadot's WASM runtime is not build for high speed execution but has the advantage of enabling parachains to add custom configurations. However, PVM provide asynchronous and parallel execution and also supports executing Solidity smart contracts.

Timekeeping

Consensus requires a reliable sequence of events for transaction execution. Solana addresses timekeeping with Proof-of-History (PoH) to synchronize events across all validators. PoH functions as a verifiable delay function (VDF), which takes a fixed amount of time to generate a unique proof but less time to verify it. Solana's solution uses SHA256 as a sequential hash, cycling with the previous hash and a count to create a new hash as the next PoH output. This links the hashes in a chain, proving that the current PoH timestamp results from all the hashes of events up to the current block.

cycle( hash = previous_hash(hash || count) )

SHA-256 provides a fixed 256-bit output, strong avalanche effect, pre-image resistance, deterministic results, high efficiency with hardware acceleration, and resistance to brute-force attacks, needing impractical parallelization of about 2¹²⁸ cores for success.

Polkadot uses a verifiable random function (VRF) for it’s BABE consensus mechanism. Like Solana’s VDF, it does not rely on a central clock to synchronize time, but rather it uses slots and past results to determine current and future results. A slot is part of a Polkadot epoch which lasts about 4 hours and is made up of 2400 slots. A validator executes a VRF which accepts three inputs:

The current slot number
A secret key specific to the validator
A hash derived from the hash of VRF outputs based on blocks from two epochs ago (8 hours)

The output of the VRF is a random number and a proof verifying the random number was generated correctly.

(RESULT, PROOF) = VRF(VALIDATOR_SECRET, HASH_OF_BLOCKS_2_EPOCHS_AGO, CURRENT_RELAY_CHAIN_SLOT_NUMBER)

After running the VRF, a validator can propose a block if the RESULT from the VRF is below a threshold set by the protocol. Multiple validators might qualify in the same slot, but only the block accepted by most nodes will be chosen, as determined by the GRANDPA finality consensus mechanism. If no validator's VRF RESULT is below the threshold, the slot remains empty, and then the AURA backup consensus mechanism steps in. AURA runs alongside BABE and randomly selects a validator to produce a block, but it only activates when no block producers are available for a slot. Since validators operate independently, some slots may have no block proposals at all.

The VRF threshold is calculated by multiplying a fixed constant (which controls how often blocks are produced) with the validator’s share of the total stake. So, the more stake a validator has, the higher their threshold and the better their chances of being selected.

Solana’s PoH VDF method is superior to Polkadot’s VRF because:

Polkadot time is split into slots and consensus must determine block authorship per slot, not per event
PoH acts a cryptographic timestamp where validators verify the PoH sequence eliminating the need for validators to agree on when events happen.
PoH continously runs and does not need to wait for randomness or slot boundaries. In Polkadot blocks are produces based on slot timing where there is no cryptographic proof between events in a block.
PoH moves forward at hardware speed which can be bound by the features of a CPU’s SHA256 hardware acceleration capabilities or GPU availability.
PoH enforces the correct leader schedule, even if a validator goes offline (becomes “delinquent”). It prevents malicious validators from producing blocks out of turn by cryptographically anchoring the order of events.

Block Propagation & Consensus

Solana RPC forwards transactions to the leader or to paired validators using SWQoS, who then forward the transactions to the current leader. The leader processes the transactions and creates a block. The block is shredded and then sent to other validators using the peer-to-peer block propagation protocol, Turbine. Validators are organized in a tree structure called the Turbine tree, which has a depth of 200. Once a validator receives the blocks, they validate each shred and pass them to other peers based on their position in the Turbine tree. Each validator replays each transaction (replay stage), computes, and validates PoH hashes in parallel before voting on the block.

In Polkadot, a user sends a transaction to their parachain node, where the collator gathers and groups transactions into a parachain block. The collator then submits this block candidate to one of the assigned Relay Chain validators for that parachain. The validator checks the block's validity and includes a state transition proof on the Relay Chain. If approved, this block becomes part of the main chain for that parachain. Cross-chain messages are managed using XCM (Cross-Consensus Messaging) and are passed between parachains through XCMP (Cross-Chain Message Passing), which uses a shared message queue system and the Relay Chain to ensure delivery. Finality is provided by GRANDPA once the block is confirmed on the Relay Chain.

If the transaction involves a cross-chain operation, it is wrapped as an XCM (Cross-Consensus Message) and placed into an outbound message queue. The XCMP (Cross-Chain Message Passing) protocol handles the transport of these messages between parachains, moving them from the sender's outbound queue to the recipient parachain's inbound queue. There, the collator includes the message in a new block, where it is executed according to its XCM instructions.

To achieve consensus, Solana uses Tower BFT (TBFT), a delegated proof of stake mechanism and a variation of the Practical Byzantine Fault Tolerance (PBFT) consensus mechanism, where PoH is used as the clock. TBFT uses the PoH clock to greatly reduce overhead since the clock is computed internally, unlike PBFT, which requires multiple rounds of communication to synchronize the clock. In delegated proof of stake, stakers delegate their stake to validators, who use that stake in vote transactions to decide which blocks are valid. For block production to be halted, a third of Solana's staked validators would need to act maliciously or go offline.

Polkadot uses BABE (Blind Assignment for Blockchain Extension), GRANDPA (GHOST-based Recursive ANcestor Deriving Prefix Agreement), and AURA (Authority-based round-robin scheduling) as its main consensus algorithms. BABE is used for block production, while GRANDPA is used for finality. AURA serves as a backup consensus in case empty blocks are produced or the threshold set by the VRF is not met. Nominators delegate their stake to validators through the Nominated Proof-of-Stake (NPoS), which distributes stake equally among validators. This gives Polkadot an advantage in decentralization over Solana because NPoS ensures validators receive a similar amount of support, preventing the “rich-get-richer” scenario common in Proof-of-Stake blockchains.

BABE assigns time slots to validators based on stake and randomness. It operates in epochs, each divided into slots of approximately 6 seconds. At the start of every epoch, validators run a lottery using the epoch's randomness to determine which slots they are eligible to produce blocks in. The authority list and randomness are included in the first block of each epoch, and validators gossip their block proposals to peers.

Because slot assignments are randomized:

Multiple validators may win the same slot, leading to temporary forks as each one produces a block. Validators use a chain selection rule (e.g., longest chain) to decide which fork to build on, and finality is later ensured by GRANDPA.
No validator may win a slot, resulting in an empty slot with no block produced. This simply causes a delay and doesn't impact network security or continuity.

This design introduces natural variance in block production while maintaining decentralization and probabilistic fairness.

GRANDPA (GHOST-based Recursive ANcestor Deriving Prefix Agreement) is Polkadot’s finality protocol for the relay chain. Validators vote in rounds to finalize blocks, running GRANDPA alongside block production. Unlike typical block-by-block finality, GRANDPA finalizes entire chains of blocks at once when over ⅔ of validators agree. This allows fast and resilient finality, even after network disruptions. It operates reliably in partially synchronous conditions and can tolerate up to 20% Byzantine nodes in asynchronous settings.

Scalability

Solana doesn't need the entire historical ledger to find the current account state. Validators and RPCs only keep the current state of accounts and usually store 1 or 2 epochs (2-4 days) of transaction data. Archive data is handled by warehouse nodes run by RPC providers, the Solana Foundation, and other participants in the ecosystem.

Polkadot uses an efficient state model that allows validators to determine the current state of an account without needing to replay the entire history of transactions. Polkadot's parachains rely on a state transition model, where the current state is derived from the latest block or state snapshot, and validators only need to validate the state transitions since the last finalized block.

Solana's monolithic architecture, PoH clock, Gulf Stream protocol, Sealevel protocol, and <400ms block times enable it to scale to potentially millions of transactions per second. Meanwhile, Polkadot's modular architecture allows it to potentially achieve thousands of transactions per second. While Solana's computing needs are significant, Polkadot also demands substantial computing resources to maintain its network of relay chains, bridges, collators, and validators.

Governance

Solana’s governance model doesn't quite match the trust level of Polkadot’s OpenGov governance model. OpenGov is a big step forward in decentralized governance, fixing the issues of the old system that depended on centralized groups like the Council and Technical Committee. OpenGov makes decision-making fully decentralized, allowing stakeholders to propose, vote on, and implement changes directly. It includes multi-role delegation, where token holders can delegate their voting power across different governance areas based on expertise. Conviction Voting lets participants increase their influence by locking tokens for longer periods. OpenGov allows for simultaneous referenda, so multiple proposals can move forward at the same time, each adjusted to its importance level through Origins and Tracks. This setup ensures that high-risk proposals are reviewed more carefully, while low-risk ones proceed faster, balancing security and efficiency.

Key features of OpenGov include greater inclusivity, scalability, and flexibility. By removing barriers like the public proposal queue and introducing tools such as the Polkadot Fellowship and Whitelist, OpenGov uses expert opinions without losing decentralization. The Fellowship, a wide, merit-based group, offers technical insights to improve decision-making, while the Whitelist allows urgent, safe proposals to skip long timelines. Additionally, OpenGov includes safeguards like Cancellation and Referendum Killer to quickly address harmful or flawed proposals. These innovations ensure Polkadot’s governance stays dynamic, secure, and in line with community needs, encouraging wider participation and long-term ecosystem growth.

Solana’s governance decisions are non-binding and advisory signals from the Solana community, made off-chain on various social channels. Validators act as elected representatives, making the final decisions based on the validator software they choose to run. These representatives make decisions for delegators who have delegated their stake. Solana's governance voting uses SPL tokens, with validators receiving tokens proportional to their active stake. These tokens are assigned to addresses representing different voting options, and validators can split their votes among multiple choices. Once votes are cast, they cannot be changed.

A major issue in Solana's governance is that there are no formal ways for delegators to express their preferences or influence decisions. This means they cannot override the choices made by validators, which can lead to conflicts if validators vote against what the delegators want.

Solana's Feature Gate Activations manage consensus-breaking updates, such as new syscalls, native programs, and economic changes, through a structured process. These updates are initially disabled by default and tracked as accounts in the Feature Gate Program. Each feature gate is associated with a private key owned by the core contributor responsible for that feature. Validators must upgrade to the new client software release before activation. Once stability is achieved and sufficient stake is on the updated version, the feature is manually activated at the start of the next epoch, going live across all nodes cluster-wide.

The activation process follows a schedule, progressing from Testnet to Devnet, and finally to Mainnet, ensuring confidence in the update before full deployment. The version floor, representing the minimum supported software version, is raised with each feature activation. Validators failing to upgrade will diverge from the network, as they cannot validate the global state post-activation. Unlike Bitcoin or Ethereum, where hard forks risk permanent chain splits, Solana’s design ensures cluster-wide activation at a specific slot, preventing chain splits. Additionally, new client versions include non-consensus-breaking updates like code optimizations and efficiency improvements, which do not require feature gating.

Summary

Solana excels in efficiency and scalability, while Polkadot is better at supporting custom blockchains with its parachain model and decentralization through its Nominated-Proof-of-Stake consensus. Polkadot's OpenGov governance model is also more advanced than Solana's governance model.

References

Solana References

Solana website
https://solana.com/
Solana Docs
https://solana.com/docs
Anza Docs
https://docs.anza.xyz/
Solana How it works An executive overview of the Solana protocol
Lostin, Technical Writer, Helius
https://report.helius.dev/
Solana Stack Exchange: Ed25519 over Secp256k1 and Secp256r1
448-OG & Aseneca https://solana.stackexchange.com/questions/21429/ed25519-over-secp256k1-and-secp256r1/21430#21430
Solana documentation: Cryptography and the Solana Network
https://solana.com/developers/courses/intro-to-solana/intro-to-cryptography
Ed25519: high-speed high-security signatures
D. J. Bernstein https://ed25519.cr.yp.to/
Accounts
https://solana.com/docs/core/accounts
Terminology
https://solana.com/docs/references/terminology
The Solana eBPF Virtual Machine
https://www.anza.xyz/blog/the-solana-ebpf-virtual-machine
Solana Transactions
https://solana.com/docs/core/transactions
Serialize Custom Instruction Data for Native Program Development
https://solana.com/developers/courses/native-onchain-development/serialize-instruction-data-frontend
Solana’s Gulf Stream: Mo Mempool, Mo problems
Lostin, Helius Blog
https://www.helius.dev/blog/solana-gulf-stream
8 Innovations that Make Solana the First Web-Scale Blockchain
Anatoly Yakovenko
https://medium.com/solana-labs/7-innovations-that-make-solana-the-first-web-scale-blockchain-ddc50b1defda
Solana & SVM
https://docs.solayer.org/infinisvm/system_architecture/solana&svm
What Is SVM - The Solana Virtual Machine
https://squads.so/blog/solana-svm-sealevel-virtual-machine
Solana Governance: A Comprehensive Analysis
Lostin, Technical Writer for Helius
https://www.helius.dev/blog/solana-governance--a-comprehensive-analysis
Solana Whitepaper
Anatoly Yakovenko
https://solana.com/solana-whitepaper.pdf

Polkadot References

Polkadot Website https://polkadot.com/
Polkadot Architecture
https://wiki.polkadot.network/learn/learn-architecture/
Understanding Accounts & Keys in Polkadot with Bill Laboon and Chinmay Patel
https://www.youtube.com/watch?v=zhfccevPqWI
Parachains
https://wiki.polkadot.network/learn/learn-parachains/
Account Keys
https://wiki.polkadot.network/learn/learn-cryptography/#account-keys
Learn Crypotography
https://wiki.polkadot.network/learn/learn-cryptography/
Accounts
https://wiki.polkadot.network/learn/learn-account-advanced/
Glossary
https://wiki.polkadot.network/general/glossary
Transactions
https://docs.polkadot.com/polkadot-protocol/basics/blocks-transactions-fees/transactions/
Parachains
https://docs.polkadot.com/polkadot-protocol/architecture/parachains/overview/
Parathreads: Pay-as-you-go Parachains
https://polkadot.com/blog/parathreads-parathreads-pay-as-you-go-parachains/
Polkadot Consensus Part 3: BABE
Joe Petrowski
https://polkadot.com/blog/polkadot-consensus-part-3-babe/
Polkadot Consensus Part 2: GRANDPA
Joe Petrowski
https://polkadot.com/blog/polkadot-consensus-part-2-grandpa/
Polkadot Smart Contracts: How It Works
https://use.ink/docs/v5/how-it-works
Comparing Blockchain Virtual Machines (VMs): EVM, WASM, SVM, and CKB-VM
Nervos
https://www.nervos.org/knowledge-base/comparing_blockchain_virtual_machines
Polkadot Docs: Randomness
https://docs.polkadot.com/polkadot-protocol/basics/randomness/
Polkadot's Exceptional Nakamoto Coefficient: The Hidden Value of True Decentralization
The Crypto Professor

https://x.com/TheCryptoProfes/status/1910258315306717339
Gov2: Polkadot’s Next Generation of Decentralised Governance
Gavin Wood
https://medium.com/polkadot-network/gov2-polkadots-next-generation-of-decentralised-governance-4d9ef657d11b