At The Edge Of Determinism: Transaction Lifecycle in Solana Sealevel and Sui Object Runtime

Solana and Sui are prominent high-performance Layer 1 blockchains capable of handling high transaction volumes at very low cost without sacrificing scalability, speed, or decentralization.

Both protocols have gained recognition within the industry as cutting-edge blockchains that address many of the limitations of older blockchains such as Ethereum and Bitcoin.

These protocols are designed to handle tens of thousands of transactions in parallel, enabling exceptionally high throughput both in theory and in practice. Solana, for example, can reach up to 65,000 transactions per second (TPS) under ideal conditions and consistently achieves around 4,000 TPS in real-world scenarios.

Sui, on the other hand, has demonstrated a theoretical maximum TPS of 297,000, but since its inception has processed a maximum of 3,500 TPS, averaging around 400 TPS of user transactions daily combined with 600 TPS of system transactions for checkpoint construction.

Today, Solana achieves optimistic confirmation in 400ms, reaches full finality in ~12.8 seconds, and is expected to achieve full finality in 100-130ms with the upcoming Alpenglow consensus upgrade. Sui achieves sub-second finality at the 90th percentile (P90) latency as a result of its robust optimistic design.

In this research article, we examine the underlying mechanisms that drive high transaction performance by analyzing the transaction lifecycle of both chains, and provide a comprehensive side-by-side comparison of how their differing execution models enable them to achieve high throughputs with low time to finality.

What is the lifecycle of a blockchain transaction?

Blockchains process transactions. Transactions impact state (i.e, the updated view of accounts on a blockchain). Understanding the lifecycle of a transaction can be the clearest expression of a blockchain’s design philosophy, providing important insights to technical stakeholders on how the chain is optimized for throughput and safety, determinism guarantees, relative engineering costs, and potential pain points that may arise under real-world conditions.

In subsequent sections, we will examine the different stages transactions undergo from submission to finalization and how this process affects execution at various levels within these chains.

Solana Transaction Lifecycle

The Solana blockchain is built on a unique design that utilizes Proof-of-Stake (PoS) as its consensus mechanism and Proof-of-History (PoH) as its time-keeping mechanism to order transactions efficiently.

Solana’s design model is account-centric, which is another way of saying, “everything on Solana is an account”.

Accounts are used to store data, which includes state and executable binaries (i.e., program code). Transactions contain instructions that modify the state of accounts. Nodes participating in consensus on the network that involve processing transactions are called validators. The process through which transactions are processed to modify an account is referred to as pipelining, and the points at which the transaction is at different stages in its lifecycle are referred to as stages.

A Solana Transaction

On Solana, a transaction is a set of signatures of serialized messages signed by the first key of the Message’s account key.

The message in a transaction is a data structure containing a header, account keys, recent blockhash, and instructions. The header contains the MessageHeader, which describes the organization of the Message’s account keys.

Each instruction explicitly defines which accounts it can access and the permissions required for each. These permissions indicate whether an account is read-only or read-write, and whether it must have signed the transaction that includes the instruction.

pub struct Message {
pub header: MessageHeader,
pub account_keys: Vec<Pubkey>,
pub recent_blockhash: Hash,
pub instructions: Vec<CompiledInstruction>,
}

Individual instructions contain a list of all accounts they may access, along with the required permissions for each account.

A Message contains a single shared flat list of all accounts required by all instructions within the transaction. This flat list is created when building a Message, and instructions are converted to a set of CompiledInstructions. These CompiledInstructions then reference by index the accounts they require from the single shared account list.

The shared account list is ordered by the permissions required of the accounts:

• Accounts that are writable and signers.
• Accounts that are read-only and signers.
• Accounts that are writable and not signers.
• Accounts that are read-only and not signers.

Given this ordering, the fields of the MessageHeader describe which accounts in a transaction require which permissions.

pub struct MessageHeader { 
pub num_required_signatures: u8,
pub num_readonly_signed_accounts: u8,
pub num_readonly_unsigned_accounts: u8,
}

When multiple transactions access the same read-only accounts, the runtime may process them in parallel in a single PoH entry. Transactions that access the same read-write accounts are processed sequentially.

Transactions are submitted to the client through Gulf Stream, Solana’s transaction forwarding protocol, and processed through two multi-stage, pipelined processes in the validator called the Transaction Processing Unit (TPU) and the Transaction Validation Unit (TVU).

These processes work together with the runtime to ensure transactions that modify different account states are processed in parallel while transactions that modify the same account state are processed sequentially.

The TPU runs when the validator is in leader mode (i.e., producing blocks), and the TVU runs when the validator is in validator mode (i.e., validating blocks). In both cases, the pipelined hardware is similar: the network input, writes to disks, network output, etc. However, what it does with that hardware is different. Simply put, the TPU is used to create ledger entries, while the TVU exists to validate entries.

From a high-level overview, transactions are submitted via a client and processed through Gulf Stream via QUIC to a leader’s TPU. The transaction undergoes verification checks and is then scheduled by the banking stage for execution. State updates are written back into the bank’s in-memory state. Validators vote on blocks through gossip, and blocks are finalised using Tower BFT, a PBFT variant with stake-weighted lockout mechanisms.

Gulf Stream

In most blockchains, transactions submitted by users are “queued” in a mempool (literally a “memory pool”), waiting to be processed by the network. Signed transactions can remain in the mempool for an extended period, potentially indefinitely, waiting to be executed if the network is not in an optimal state or the execution conditions are not met, resulting in these transactions never being included in any block.

Solana eliminates the need for a global mempool by relying on a deterministic leader schedule influenced by a stake-weighted algorithm, known as Stake-Weighted Quality of Service (SWQoS), to prioritize transaction messages routed through staked validators.

Since the leader schedule is known by all active nodes ahead of time, transaction messages can be distributed efficiently, ensuring upcoming leaders already have sufficient transactions to process before they are scheduled to produce a block. This mechanism enables validators to pre-process transactions by verifying signatures and eliminating duplicates or malformed transactions beforehand.

Another advantage of the Gulf Stream is that, compared to traditional chains that use a mempool, block producers also have to re-transmit the same transactions in a block, which means that every transaction is propagated at least twice through the network. Solana does not need to overload gossip to synchronize pending transactions, and transactions do not need to compete for block space through gas auctions; instead, they are distributed based on scheduling.

Transaction Processing Unit (TPU)

The TPU is the core logic of the validator responsible for block production. Transactions are fetched from the client and forwarded in data packets through a component called the QUIC streamer, which allocates the packet memory and reads the data from the QUIC endpoint (known as the “Fetch Stage”). Each stream transmits a packet within a QUIC transmission constraint identified by the client (IP address, Node pubkey) and the server.

Packets are then transmitted to the Sigverify Stage, where they are deduplicated with a special load-shedding mechanism to remove excessive packets. The deduplicated packets are now filtered to remove those with invalid signatures and forwarded to the banking stage.

The banking stage is a key component of Solana’s runtime execution. It schedules incoming packets, filters them further for conflicts, and evaluates their eligibility to be processed, held, or forwarded in batches. If it detects that the node is the block producer, it processes the held and newly received packets with the Bank component. The bank component is an in-memory representation of the full state of the ledger at a given slot.

Within the banking stage and the scheduler component, the transaction is tracked in two states:

• An unprocessed state where the transaction is available for scheduling
• A pending state where the transaction is currently being scheduled or being processed

When a transaction finishes processing, it may be retryable. If the transaction is retryable, it is transitioned back to the unprocessed state; otherwise, the state should be dropped. The valid processed transactions are formed into an “Entry” via PoH ticks, bundled into blocks, and broadcast as shreds to network peers through Turbine, Solana’s block propagation protocol, which generates erasure codes for “regenerating” lost data packets before transmitting the packets to the appropriate network peer in the Broadcast Stage.

Transaction Validation Unit (TVU)

The TVU is the logic within non-leader validator nodes responsible for validating and propagating blocks. In the TVU, data packets are processed in multi-threaded stages before being finalized. This includes shred fetch, signature verification, retransmit, and replay stages.

In the Shred Fetch Stage and the Shred Verify Leader signature stage, non-leaders receive the shreds from other nodes via UDP and perform batch signature verification. Valid shreds are retransmitted to peer nodes in the Retransmit Stage, and each transaction is replayed in order in the Replay Stage.

In the replay stage, the runtime is invoked to deterministically re-execute all transactions, ensuring that all state changes, program attributes, and bank hashes match exactly with the leader's output.

If a block is evaluated as valid, the validator signs a vote transaction and sends this vote to the leader to be included in subsequent blocks.

Runtime

The runtime is Solana’s concurrent transaction processor shared between the TPU and the TVU. Transactions specify their data dependencies (i.e., the accounts they wish to read from and/or write to) upfront to enable explicit dynamic memory execution. As a result, reading state can be well isolated from program execution, allowing the runtime to choreograph concurrent access.

The Solana runtime uses an execution engine called Sealevel to ensure that transactions accessing read-only accounts are executed in parallel. In contrast, transactions accessing overlapping writable accounts are serialized and executed sequentially.

Within the runtime, transactions are executed atomically; all the instructions in a transaction must be executed successfully for that transaction to be committed to the bank, or else the transaction fails.

The runtime interacts with a given program through an entrypoint with a well-defined interface. This entrypoint is simply a Rust function that all on-chain programs cleanly expose as the starting point for execution and serves as an interface for the Solana runtime and programs. Its execution engine maps public keys to accounts and routes them to this entrypoint. However, it enforces some critical constraints to guide its execution logic, defined by the virtual machine instruction set architecture:

• Only the owner program may modify an account's contents.
• Total balances on all the accounts are equal before and after the execution of a transaction, but this only applies in aggregates. Lamports are not conserved for system transfers and burns.
• After the transaction is executed, read-only account balances must equal the balances before the transaction.
• All instructions in the transaction are executed atomically. If one fails, all account modifications are discarded.

The TPU and TVU pipelines follow slightly different pathways when interacting with the runtime. The TPU runtime ensures that “entries” are recorded (via PoH ticks) before memory is committed, while the TVU runtime ensures that “entries” are verified before the runtime processes any transactions.

Consensus

Consensus is one of the most fundamental mechanisms in complex distributed computing systems. In Solana’s transaction lifecycle, consensus comes after the block is executed and validated by the TVU, but before it is finalized. The core idea of consensus is a uniform agreement that ensures participants in the network agree on the same outcome, and once decided, cannot change their decision.

In a formal sense, a fault-tolerant consensus mechanism must satisfy the following properties:

• Uniform agreement: No two nodes decide differently.
• Integrity: No node decides more than once.
• Validity: If a node decides a value, then that value was proposed by some other node.
• Termination: Every node that does not crash eventually decides on some value.

From a surface point of view, the goal of consensus is to get nodes to agree on something. With Solana, there are several situations in which nodes need to agree. This is predominant in three scenarios:

Leader Rotation

All nodes must agree on who the leader is because network faults can disrupt communication and lead to a split-brain scenario, where multiple nodes mistakenly believe they are the leader at the same time.

The leader schedule is generated using a predefined seed with the following algorithm: the PoH tick height (i.e., a monotonically increasing counter) is periodically used to seed a stable pseudo-random algorithm.

At that height, the bank is sampled for all the staked accounts with leader identities that have voted within a cluster-configured number of ticks. The sample is referred to as the active set, which is sorted by stake weight. The random seed is then used to select nodes weighted by stake to create a stake-weighted ordering, which becomes valid after a cluster-configured number of ticks.

Synchronization

Without reliable timestamps, a validator cannot determine the order of incoming blocks. Solana uses a mechanism called Proof-of-History as its cryptographic clock to order transactions before they undergo consensus. According to the Anza documentation on synchronization:

“Leader nodes "timestamp" blocks with cryptographic proofs that some duration of time has passed since the last proof. All data hashed into the proof most certainly has occurred before the proof was generated. The node then shares the new block with validator nodes, which are able to verify those proofs. The blocks can arrive at validators in any order or could even be replayed years later. With such reliable synchronization guarantees, Solana can break blocks into smaller batches of transactions called entries. Entries are then streamed to validators in real time, before any notion of block consensus”.

It is important to remember that while Proof-of-History is not a consensus mechanism, it has a significant impact on the performance of Solana’s Proof-of-Stake consensus.

Atomic Commit

Another necessary process that nodes need to agree on is atomic commits. In a high-performance system like Solana, a transaction may fail on some nodes and succeed on others.

To avoid partial execution, Solana ensures atomicity within the runtime, in the sense of ACID, and also ensures that all nodes agree on the outcome of a transaction: either they rollback (if anything goes wrong) or they commit (if nothing goes wrong).

Commitment in Solana measures the finality of a block (slot) based on the number of validators who have voted for it and the depth of their votes in the Tower BFT lockout mechanism. It reflects how strongly the network has agreed on the given slot based on the votes cast by validators. Each validator votes on slots (specifically, block heights) and commits to not voting on conflicting forks; lockouts in Tower BFT ensure this mechanism is enforced.

Solana has three commitment statuses: processed, confirmed, and finalized. A block is said to be confirmed when a supermajority of staked validators (≥66%) votes on it, and it is finalized when at least 32 confirmed blocks are built atop it.

As a direct consequence of its optimistic parallel execution and asynchronous leader schedule, Solana follows a “execute first, vote later” model: the protocol does not wait for all validators to agree on a newly produced block before producing the next block. This may also lead to forks (i.e., a scenario where two or more competing chains exist simultaneously). Once a slot becomes finalized, all competing forks are abandoned, and that fork becomes the canonical chain.

Alpenglow

As of this article, Solana uses Tower BFT and PoH ledger to ensure the network reaches a state of consensus even when some participants fail.

Recently, the research team at Anza proposed a new design for a simpler and more performant consensus protocol called Alpenglow. Alpenglow aims to overhaul the legacy components of the current consensus design including Proof of History, Tower BFT, and the use of gossip for vote propagation.

At its core, Alpenglow uses Votor and Rotor to accelerate Solana's consensus:

Votor is a two-tiered voting mechanism designed to achieve block finality in a single-round if 80% of stake is responsive and in double-rounds if a minimum of 60% of stake is responsive.

Rotor refines the existing turbine protocol by employing a single layer of relay nodes to handle shred dissemination. Rotor also leverages the bandwidth of participating nodes proportional to their stake to reduce hops and optimize Solana's throughput. 

Sui

Unlike Solana, which uses an account-centric model, Sui blockchain utilizes an object-oriented data model, representing state data as objects with unique identifiers, properties, and methods.

In Sui, a smart contract is also an object called a Sui Move package with a unique identifier that manipulates objects. These Sui Move packages comprise a set of Sui Move bytecode modules. Every module is unique by its name and the combination of a package’s on-chain ID and the name of a module that uniquely identifies the module.

While the intricacies of object design and metadata are beyond the scope of this article, it is crucial to remember that every object has an owner that dictates how that object can be used in transactions.

Objects can have the following ownership models:

• Address-Owned Objects: An address-owned object is owned by a specific 32-byte address, either an account address or an object ID. It is accessible only to its owner.
• Immutable Objects: An immutable object cannot be mutated, transferred, or deleted. They have no owner and are globally accessible to be used by anyone.
• Shared Objects: A shared object is an object that is shared and is also accessible to everyone.
• Wrapped Objects: This involves wrapping an object inside another object. Wrapped objects have no independence and can only be accessed through the wrapping object.

A Sui Transaction

On Sui, transactions are composed of a group of commands that execute on inputs to define the result of the transaction. These groups of commands are called programmable transaction blocks (PTB), and they define all user transactions on Sui. PTBs allow a user to call multiple Move functions, manage their objects, and manage their “coins” in a single transaction, without having to publish a new Move package.

The structure of a PTB is defined as:

{
    inputs: [Input],
    commands: [Command],
}

inputs is a vector of arguments that are either objects or pure values. These objects can be owned by the sender, or can be shared or immutable. The commands field is a vector of high-level transaction instructions.

During the execution of PTBs, the input vector is populated by the input objects or pure value bytes. The transaction commands are then executed in order, and the results are stored in a result vector, which is an array of values, where each value can be any arbitrary Move type, specific to each command; unlike inputs, the values are not limited to objects or pure values.. Finally, the effects of the transaction are applied atomically. 

While we will not discuss the internals of the Sui PTBs, as that is another intricate topic, one thing to note is that at the beginning of execution, the PTB runtime takes the already loaded input objects and loads them into the input array. The objects are already verified by the network, checking rules like existence and valid ownership. The pure value bytes are also loaded into the array, but not validated until usage.

At this stage is the effects on the gas coin are of utmost importance. Here, the maximum gas budget is withdrawn from the gas coin. The maximum gas budget is usually specified by the transaction sender when a transaction is submitted, representing the maximum amount of gas that can be consumed by that transaction. Any unused gas is returned to the gas coin at the end of execution, even if the coin has changed owners. Each transaction command is then executed in order.

After submission, the Full node certifies all provided metadata by sending the transaction to a validator node (Certification stage). The validator node performs all necessary validity checks on the transaction and signs it to confirm its validity if the checks pass. For the transaction to be regarded as a valid transaction by a validator node, it must:

• Have a valid user signature.
• Ensure that the transaction initiator has access to all the owned input objects that the transaction uses.
• Ensure the shared input objects used by the transaction exist.
• Contains at least as much gas as specified in the transaction's gas budget.

If all the checks pass, the validator attempts to lock all the owned inputs objects to the given “transaction digest” to ensure that each owned input can only be used once at a time.

If the locking process is successful, the validator signs the transaction and returns the signature to the Full node.

A Sui full node is essentially a read-only view of the network state. Unlike validator nodes, full nodes cannot sign transactions, although they can validate the integrity of the chain by re-executing transactions that a quorum of validators previously committed. The full node does not just collect a single validator signature, but as many validator signatures as possible in parallel; however, only a supermajority (⅔+ of stake) is needed to form a transaction certificate.

Execution and Checkpoints

Once transactions have been issued a certificate, they are sent to a committee of validators (i.e., a set of independent validators, fixed for each epoch) for execution. The validator doesn’t need to re-verify the transactions: all it has to do is verify the signatures on the certificate. If the signature on the certificate is valid, the validator can be sure that the transaction is valid.

During execution, transactions are categorized into two categories: owned object transactions and shared object transactions:

Owned Object Transactions

Owned Object Transactions do not access any shared input object, and are executed immediately. These transactions are also known as fastpath transactions, i.e, they are executed after validation and committed to the canonical chain. These transactions do not “pass” through consensus (fastpath transactions eventually go through consensus, but only to produce a canonical ordering for inclusion in checkpoints). Technically, this is possible because there is no risk of conflicting writes because only the owner can modify the object. 

Shared Object Transactions

Shared object transactions access shared objects and therefore require ordering through consensus with respect to other transactions using the same shared objects and executing them. These are also known as slowpath transactions. They must go through the full consensus process to ensure consistency, as the objects involved can be accessed and modified by multiple users. 

Previously, Sui’s mempool, Narwhal, avoided typical congestion by decoupling transaction dissemination from ordering, holding certified, signed transactions in a Directed Acyclic Graph (DAG) without ordering them itself. Bullshark then provided the consensus ordering.

To further improve performance and resilience, the HammerHead protocol was introduced as an enhancement to Bullshark, implementing dynamic, score-based leader selection. This significantly reduced latency and improved throughput, especially in the presence of faulty or crashed leaders.

Building on these advances, Mysticeti now replaces both Narwhal and Bullshark, unifying transaction dissemination and ordering into a single protocol. Mysticeti sequences transactions in a total order, further streamlining the process and achieving even lower latency and higher throughput. Additionally, due to Sui’s object-centric ownership model, most transactions remain independent and do not require competing for a global ordering slot.

After the transactions are executed, the validator signs the effects of the transaction and returns them to the full node. Transaction effects are essentially a list of all of the actions that the transaction took, such as all objects that were mutated, the gas that was spent, and the execution status of the transaction.

The effect signatures constitute a collection of effect certificates collected by the full node from a supermajority of validators, guaranteeing that a transaction was finalized.

By the time a transaction is included in a checkpoint, indicating its final stage in its life cycle, the state changes resulting from that transaction have already been finalized and applied to the network.

For transactions involving only owned input objects, validators execute and finalize these transactions before submitting them to the consensus layer for ordering.

In contrast, transactions involving shared input objects are submitted to consensus for ordering before execution and are not resubmitted for checkpoint inclusion.

The validator collects causally ordered and complete chunks of transactions from the consensus layer and constructs a checkpoint, which contains both the list of transaction digests and the corresponding digests of each transaction’s effects. As a result, checkpoints serve as an immutable record of all finalized state transitions in the network.

Finality

A transaction on Sui achieves finality as soon as a supermajority (2𝑓 + 1) of validators accept and counter-sign a transaction certificate, even before the certificate is sequenced by consensus or executed. At this point, no conflicting transaction can occur, and the transaction cannot be revoked. For transactions involving only owned objects, the outcome of execution is known immediately upon finality; for shared object transactions, the result is determined only after the certificate is sequenced by consensus. Transaction finality is reached within two network round trips.

Settlement occurs when the transaction is executed by a supermajority of validators and an effects certificate is formed. For owned object transactions, this execution happens immediately, without waiting for consensus. For shared object transactions, execution and settlement occur just after the certificate is ordered by consensus. In both cases, settlement is not delayed by checkpoint creation, resulting in lower latency than the checkpointing process.

While a transaction certificate strongly indicates finality, only an effects certificate or inclusion in a certified checkpoint provides an absolute guarantee, as these require a supermajority of validators to execute and commit the transaction effects.

At a high level, the Sui transaction lifecycle leverages an object-centric model to maximize parallelism and efficiency. When a transaction is submitted for certification, validators attempt to lock the specific versions of the input objects it references.

For owned objects, these locks are acquired immediately during certification, ensuring exclusive access and preventing double-spending. For shared objects, locks are only established after the transaction is ordered via Sui’s consensus protocol.

Once all required locks are obtained, the transaction is scheduled for execution. This design allows transactions that operate on disjoint sets of objects to be executed independently and in parallel, significantly reducing contention and congestion across unrelated parts of the state.

After successful execution, validators sign the transaction effects, and once a supermajority of signatures is collected, an effects certificate is formed. This certificate serves as a guarantee of settlement finality, indicating that the transaction is now irreversible and its effects are permanent.

Checkpoints are not part of the critical path for transaction execution or finality. Instead, they are constructed after execution to provide a canonical ordering of transactions and to facilitate state synchronization for nodes that were not directly involved in execution.

Sui’s object model enables precise dependency tracking at the object level, eliminating the need for global state synchronization. This architecture supports scalable, distributed execution on commodity hardware, rather than relying on advances in hardware performance to achieve higher throughput.

Insights into Execution, Scalability, and Design-Tradeoffs

As stated earlier, understanding a transaction's lifecycle can be the clearest expression of a blockchain’s design philosophy. The differences in the transaction lifecycle between Solana and Sui expose deep execution model philosophies across three critical vectors: execution efficiency, scalability thresholds, and design trade-offs.

Execution

Solana, as an account-centric chain, detects account conflicts dynamically through account locking during the Banking Stage, ensuring transactions that do not modify the same account are processed in parallel while conflicting transactions are processed sequentially.

Even though this sort of account detection mechanism can introduce extra runtime costs in heavy DeFi situations especially where programs need to execute logic found in other programs (a mechanism called Cross-Program Invocation), Solana’s execution engine is still able to achieve massive parallelism as a result of its dynamic conflict detection thereby giving the chain ability to execute transactions almost instantaneously at incredibly low fees.

Sui, on the other hand, does not need to worry about conflicting transactions, as its parallelism is inferred at compile time due to its object-centric ownership model. The shared object and owned objects model makes it possible to statically infer conflicts and achieve nearly zero runtime cost for owned-object transactions.

Scalability Thresholds

In terms of scaling, Sui achieves horizontal scalability and can scale linearly with object partitions by processing owned-object transactions without global consensus, enabling near-instant, sub-second finality and throughput limited only by available hardware. Shared-object transactions require consensus, but with the Mysticeti upgrade, they now also achieve sub-second finality and high throughput. Sui’s architecture allows both block dissemination and execution to scale elastically by adding more resources, making the system capable of handling increased workloads efficiently, though the consensus path is not as unbounded as the fast path for owned objects.

Solana, by virtue of its single-leader approach and execution fanout, which is limited by account contention, does appear to hit some sort of horizontal scaling threshold due to the global single-sharded state model and its leader-centric transaction ingestion per slot but aggressively optimizes within this threshold via its well-defined pipelining, which is complemented by PoH. Transactions can be ordered accurately, processed in less than 400ms, and achieve optimistic confirmation in less than a second. In terms of vertical scaling, Solana scales massively with validator hardware (especially CPU cores and RAM) as this aligns perfectly with its inherent design.

It is important to delineate that Solana chooses vertical over horizontal scaling and hits a ceiling because of design trade-offs, not architectural failure. Some horizontal approaches (e.g., local fee markets, virtual subnets, and state minimization via CMTs) are currently in development.

Design Trade-offs

Solana guarantees determinism via strict runtime constraints, account isolation, and deterministic leader scheduling. Its dynamic account contention resolution and well-defined pipelining favor deep inter-program interaction, enabling it to achieve strong composability.

Sui achieves determinism guarantees through built-in execution paths determined by object ownership analysis. At the same time, Sui’s object-centric model enables composability via shared objects and programmable transaction blocks (PTBs), allowing for complex interactions and atomic operations across multiple contracts and users. This is possible because the owner of an object can be another object, enabling object-level interoperability and the organization of objects into ownership trees. Such structures are especially useful when objects are frequently used together or when runtime lookups are needed to determine which object to operate on during execution.

Summary

The mechanism through which transactions are processed from submission to finality underlies Solana and Sui's incredible high performance. By examining the transaction life cycle, we can gain insight into the carefully engineered pipelines that ensure low latency and high throughput for both chains.

Solana is designed on an account-centric model, and transactions undergo a series of multi-threaded processes and pipelines to ensure their validity. Transactions are submitted to the leader, which runs the TPU pipeline to ensure transactions are verified and scheduled accordingly; parallel if they do not conflict and sequential if they do. When a validator is not producing blocks, it runs the TVU pipeline to replicate and validate transactions. Both the TPU and TVU use the runtime. As a result, Solana processes thousands of transactions in very short periods because the runtime can infer upfront and deterministically, non-overlapping accounts and execute transactions that do not conflict in parallel, making Solana ideal for real-world cases like high-frequency trading, deep composable DeFi, infrastructure-heavy dApps, and low-latency consumer dApps.

Sui, on the other hand, uses an object-centric model where a unique identifier tracks each object. By inferring object ownership, it can determine statically whether a transaction can be executed in parallel if it touches disjoint sets of objects. Through its dual execution path model (i.e., separating transactions into owned-object transactions and shared-object transactions, and using signed checkpoints to keep Full nodes in sync), it can process lightweight transactions without burdening the consensus layer, while still achieving reliable, fast finality and efficient synchronization for new nodes. This enables it to scale horizontally with increasing load and is very useful for applications with massive object interactions, such as DeFi, gaming, asset-centric exchanges, and programmable assets.

References

• Solana Official Docs
• Anza Official Docs
• Sui Official Docs
• Gulf Stream: Solana’s Mempool-less Transaction Forwarding Protocol
• Sealevel — Parallel Processing Thousands of Smart Contracts
• Cross-Program Invocations and PDAs- the combination of two powerful mechanism on Anchor
• Narwhal and Tusk: A DAG-based Mempool and Efficient BFT Consensus
• Scaling Out Sui Execution with Pilotfish
• SUI vs Solana - TrustWallet
• Tower BFT: Solana’s High Performance Implementation of PBFT
• David J DeWitt and Jim N Gray: “Parallel database systems: The future of high performance database systems,” Communications of the ACM, volume 35, number 6, pages 85–98, June 1992. doi:10.1145/129888.129894
• Jim N Gray and Leslie Lamport: “Consensus on Transaction Commit,” ACM Transactions on Database Systems (TODS), volume 31, number 1, pages 133–160, March 2006. doi:10.1145/1132863.1132867
• Leslie Lamport: “Time, Clocks, and the Ordering of Events in a Distributed System,” Communications of the ACM, volume 21, number 7, pages 558–565, July 1978.
• Michael J Fischer, Nancy Lynch, and Michael S Paterson: “Impossibility of Distributed Consensus with One Faulty Process,” Journal of the ACM, volume 32, number 2, pages 374–382, April 1985. doi:10.1145/3149.214121
• Kushal Babel, Andrey Chursin, George Danezis, Anastasios Kichidis, Lefteris Kokoris-Kogias, Arun Koshy, Alberto Sonnino, Mingwei Tian: “MYSTICETI: Reaching the Latency Limits with Uncertified DAGs”, [cs.DC], July 2024.
• Giorgos Tsimos, Anastasios Kichidis, Alberto Sonnino, Lefteris Kokoris-Kogias: “HammerHead: Leader Reputation for Dynamic Scheduling”, [cs.CR], September 2023.