Introduction

Over the past two years, there has been an explosion of new smart-contract-enabled distributed ledgers which aim to address the perceived shortcomings of Bitcoin and Ethereum. These “alt layer 1s,” or “alt L1s,” as they’re commonly referred to, typically offer new architectures and make different design trade-offs to increase the scalability and usability of distributed ledgers. A number of these alt layer 1s, such as Solana and Avalanche, have garnered much attention for their growing user bases, expanding ecosystems, and (mostly) high-quality user experiences. As a result, Solana, Avalanche, Near, and others have all raised hundreds of millions of dollars from prominent investors to become the core infrastructure of a next-generation internet.

Recently, there has been increasing discussion about two highly anticipated distributed ledgers: Aptos and Sui. Aptos and Sui have not yet launched their mainnets, and few people other than developers have used their networks. Even so, they have still managed to generate excitement from crypto enthusiasts and raise substantial capital from investors, making their upcoming releases feel like the arrival of two new top-tier L1s.

At least part of the excitement surrounding Aptos and Sui comes from the fact that they were both founded by former members of Facebook’s distributed ledger division, Diem, a.k.a. Libra. Given the impressive professional backgrounds of both teams and the relevance of major L1s within the broader crypto industry, it’s no surprise that both Aptos and Sui have gotten so much attention.

Both of these layer 1s trace their origins to Facebook, and both use the new smart contract programming language, Move, so you may think they are just two versions of a similar design. However, despite these similarities, their underlying architectures are actually quite different from one another. This post will cover the mechanics of how each of these new distributed ledgers works at a high level and discuss what it means for the future of these two new entrants to the layer 1 landscape.

Aptos’ Blockchain Architecture vs. Sui’s DAG Architecture

You may have noticed that we’ve been using the phrase “distributed ledger” instead of “blockchain” throughout this post. That is because Sui’s distributed ledger is actually an “object store”, the data of which is recorded as a directed acyclic graph, or DAG. Nearly all of the mechanical differences between Aptos and Sui boil down to the fact that Aptos records its ledger as a blockchain, while Sui records it as a DAG. These are simply two different flavors of distributed ledger technology (DLT), but their differences have important implications for their consensus mechanisms, transaction ordering, transaction execution, and overall scalability.

We will first describe Aptos’ architecture, which contains many common design elements of a typical blockchain, and then we’ll describe how Sui’s DAG operates differently from Aptos and most blockchain architectures.

Address-centric vs. object-centric

Arguably the most important difference between these two designs has to do with being address-centric vs. object-centric.

As is the case with most blockchains, almost all activity on Aptos involves changing data associated with addresses. The overwhelming majority of transactions simply update the balances of assets held by a given set of addresses. One implication of this design is that each simple transfer (i.e. Alice pays Bob) requires two updates to the ledger: one for the sending account and one for the recipient account.

“Alice pays Bob 1 USDC” would look something like this on Aptos. The ledger updates both Alice’s USDC balance and Bob’s USDC balance.

Zooming out, we can visualize how a large number of these transactions appear in a traditional blockchain ledger. Alice’s and Bob’s transaction is one of many transactions inside of one block within the universal ledger which contains all historical transactions for all assets, as shown below:

In contrast, almost all activity on Sui involves changing the data associated with specific “objects”, which can be a token, smart contract, or other on-chain entity. Each object on Sui has a list of attributes, including the address of its owner (or shared ownership attributes), read/write properties, transferability properties, functionality within a dapp/game, etc. In this design, most simple transfers (e.g. Alice pays Bob) require only one update to the ledger: a change to the “owner” attribute of a specific object.

“Alice pays Bob 1 USDC” would look something like this on Sui. The ledger makes one update: a 1 USDC object with Alice listed as its owner would have its owner attribute changed to Bob.

However, certain simple transfers may need to divide an existing object into two objects prior to processing the transfer. “Alice pays Bob 0.5 USDC” might require a transaction splitting a 1-USDC object into two 0.5-USDC objects with an owner attribute of “Alice” (green arrows), and a subsequent transaction to change the owner attribute of one of the 0.5-USDC objects from “Alice” to “Bob”.

If we zoom out and try to visualize many Sui transactions, it becomes much easier to understand exactly what Sui’s directed acyclic graph actually is.

Every row in the diagram represents the full transaction history of a specific object. For example, the gray row shows the entire transaction history of one specific USDC token, with the most recent transaction being “Alice paid Bob 1 USDC”. Each arrow in the diagram represents a transaction - a change to the metadata of a specific instance of an object. For most simple transactions, the change will be to the “owner” attribute of a specific token, but the Move programming language allows objects to have many other attributes which can also be changed. Additionally, objects can create other objects (e.g. a smart contract object can issue an NFT object), and new objects can be created and even deleted by transactions. The ability to delete objects can help alleviate “state bloat”, where the ledger becomes too large to easily store on a computer. Notice that the transaction histories move in one direction only and do not return to previous states - this is where the “directed” and “acyclic(al)” part comes into play. The “graph” part refers to the overall diagram that results from performing many transactions on many objects. Sui’s DAG is also referred to as a global “object store” or “object pool”.

This object-centric method of recording transactions in a DAG rather than in a blockchain results in significant downstream differences in transaction processing for Sui and Aptos. Why? Because transactions in a DAG are not inherently linked to one another - each asset essentially has its own separate ledger which can be updated independently from every other asset’s ledger. In a blockchain, every transaction must update one universal ledger which contains every asset’s entire transaction history, and this difference has important implications for transaction ordering and batching.

Transaction ordering and batching

Aptos’ design follows another defining characteristic of blockchains: all transactions must be ordered and batched into blocks by validators before being written to the single universal ledger. This dual process of ordering and batching requires momentarily pausing the state of the universal ledger to record groups (i.e. blocks) of transactions. It also requires that validators achieve consensus on the ordering of every transaction written to the ledger, which can introduce additional latency relative to a design which does not require the ordering of every transaction. Having said that, transaction execution and dissemination on Aptos are performed continuously by validators in the background, even if the written state of the ledger is momentarily paused.

In Sui’s design, because each object essentially has its own independent ledger, a significant portion of transactions submitted at any given time do not need to be sequenced at all. The only transactions which require ordering are those which view or alter attributes of the same object(s) as another transaction. If two or more transactions are sent to a validator at exactly the same time and don’t touch any of the same objects, they can be written to the ledger simultaneously. Additionally, writing one of these transactions to the ledger does not require pausing the entire ledger state - it only requires pausing the ledger of the specific object being impacted by the transaction.

The way this works in Sui is through “shared objects”, objects which can be viewed and/or altered by any Sui address. If an object is designated as a shared object, then any transaction which reads/writes to this object must pass through the Narwhal mempool protocol to be sequenced and then be processed by Tusk, a high-performance BFT consensus protocol, to finalize this sequencing. For objects which are not shared, known as “single owner objects'' or “uniquely owned objects,” transactions do not need to be sequenced by validators and sometimes do not to be sequenced at all. This would apply to many simple transfers between addresses. We can visualize this using our diagram from before:

The green and orange transactions highlighted on the right side of the chart are not related to one another, so they do not need to be sequenced at all. They can simply be written to the ledger without achieving consensus on the order in which they occurred. Conversely, the blue and green transactions highlighted at the top center of the chart interacted with the same object (the fifth version of the blue object) so they would need to be sequenced. If the blue object happens to be a “shared object”, the transactions would need to undergo sequencing via Narwhal and consensus via Tusk.

In contrast, Aptos’ blockchain architecture requires all transactions to undergo sequencing, even if they do not interact with the same asset(s), as shown above. The written state of ledger will pause momentarily so all four transactions can be written to the ledger in the same batch (block) of transactions. Transaction execution and dissemination, however, are performed continuously in the background.

On Sui, because it uses an object-centric model, assets owned by the same person are independent of one another - each one is a separate object, even if they are the same type of token. Therefore, many (but not all) transactions involving the same type of token from the same owner do not need to be sequenced.

For example, if Alice owns 2 USDC, what she actually owns are two separate 1-USDC objects which each have an owner attribute of “Alice”. If she sends 1 USDC to two separate people (e.g. Bob and Frank), these transactions do not need to be sequenced. In an address-centric model, these transactions must be sequenced in order to confirm that Alice has a sufficient USDC balance to pay for both of her requested transactions.

We can visualize different examples of related and unrelated transactions on Aptos and Sui to better understand how they each handle sequencing differently.

In an address-centric blockchain, the two transactions above are considered related and must be sequenced because they interact with the same address (Alice’s). One of the transactions must be written to the ledger after the other to make sure that Alice’s address has a sufficient USDC balance to pay both Bob and Frank. The order in which Bob and Frank get paid (or don’t get paid, if Alice’s balance is too low) is determined by the validators of the blockchain via its mempool and consensus protocols.

In an object-centric blockchain, the transactions from the previous diagram (Alice pays 1 USDC each to Bob and Frank) are considered unrelated and do not require sequencing. There is no “balance check” required of Alice’s address - she simply requests to change the owner attribute of two independent objects she currently owns, so both of her requested transactions can be written to the ledger in parallel.

However, let’s say that Alice wants to send 0.5 USDC to both Bob and Frank. In this case, Alice will need to divide a 1-USDC object into two 0.5-USDC objects and change the owner attribute of each of them, for a total of three transactions. In Sui’s object-centric model, the “split” transaction (red arrows) is considered related to the two “send” transactions (green arrows) because the split must be written to the ledger prior to her payments to Bob and Frank, so sequencing is required. However, after the split occurs, the two “send” transactions to Bob and Frank can be written to the ledger simultaneously, as in the previous example. Additionally, there is no need to sequence any of these three transactions via the mempool and consensus protocols because at no point are two transactions interacting with a shared object.

Looking at a different object-centric example, let’s say Alice and Jill both want to send a transaction to a shared object: a liquidity pool, for example. In this case, because Alice’s and Jill’s transactions interact with the same shared object, they do need to be sequenced by validators via the ledger’s mempool and consensus protocols.

Finally, we can consider two transactions which are unrelated in both an object-centric and address-centric model: Alice pays Bob and Jill pays Frank. In an address-centric model, these unrelated transactions still need to be sequenced before they are written to the ledger. In an object-centric model, they do not need to be sequenced and can be written to the ledger simultaneously.

Aptos’ design does include optimizations to more efficiently sequence transactions. Indeed, Alexander Spiegelman, who works as a Blockchain Researcher for Aptos Labs, was a co-author of the original paper describing the Narwhal mempool protocol and Tusk consensus protocol. Aptos’ current ordering mechanism, DiemBFTv4, follows very similar principles as Narwhal & Tusk: simply put, it separates transaction sequencing from the consensus process to increase throughput and decrease latency. The way this works is that both Narwhal and DiemBFTv4 require the leading validator at any given time (the leader) to send only metadata of a group of transactions as a proposed block to other validators. This metadata is just a hash or “digest” of the group of transactions. The metadata also contains the ordering of the transactions within the proposed block. In most existing layer 1s, the leading validator proposes transactions themselves to other validators. Sending only metadata of transactions makes blocks far smaller and faster to download and process for the other validators in the network, improving throughput and latency.

To be clear, all validators continuously create blocks in parallel and broadcast them to other validators, but they are handled and stored separately from the metadata and not used during the actual sequencing process. After sequencing has been agreed upon, validators can access the actual transaction data to execute their associated code.

Based on their respective designs, Aptos and Sui should perform comparably in terms of transaction sequencing. However, Sui’s design offers the advantage that a portion of transactions do not need to be sequenced at all. If Sui manages to avoid ordering, say, 20-30% of activity on its ledger, it could result in a considerable improvement in throughput and latency. That said, it is important to note that all transactions in Sui, including unsequenced transactions, still require signatures from a sufficient majority of validators in order for the lead validator to write it to Sui’s ledger. The collection of these signatures on a transaction-by-transaction basis introduces additional workload for leading validators compared to Aptos, whose leading validators only collect signatures for each proposed block of transactions. The additional workload may at least partially offset the throughput and latency advantage of skipping the mempool and consensus protocols. Additionally, frequent division of objects in Sui could potentially create complications in transaction processing. We discuss object splitting in more detail below.

Using the characters from our prior examples, let’s say Bob, Frank, and Alice continue exchanging fractions of USDC with one another over a period of time. After just three rounds of these transactions (represented in the diagram below by the different colored arrows), the original single object of 1 USDC may end up split into as many as eight separate objects. Obviously, this can quickly complicate Sui’s object pool and its associated transactions.

Sui transactions which do not “spend” the entire object require splitting the object in two. This can quickly result in a large number of objects. Eventually, Alice, Frank, or Bob may need to request a large number of transactions in order to transfer ownership of a given type of token. In the diagram above, after three rounds of splitting objects, Frank owns four separate USDC objects (highlighted in yellow squares): one with denomination of 0.05 and three with denomination of 0.1. He would need to request four transactions to transfer all of the USDC he owns, instead of just one.

Currently, Sui plans to offer a native wallet API which will allow users to “join” these small-denomination objects into a single larger-denomination object. This should help clean up the object pool. Still, the need to divide and rejoin objects adds a layer of complexity to the ledger’s design and is one disadvantage of Sui’s object-centric approach.

Transaction execution

With respect to the actual execution of transactions (i.e. running the actual code), both Aptos and Sui can execute non-overlapping transactions in parallel. Aptos uses a novel execution engine called BlockSTM (Block Software Transactional Memory) to parallelize execution. As on some other blockchains, if two transactions on Aptos do not touch the same addresses, the code for each one can be run at the same time on different processing cores within a single computer. However, unlike most other blockchains, BlockSTM does not require a transaction’s dependencies to be declared upfront, which enables greater flexibility in the types of transactions that users can request.

At a very high level, BlockSTM takes a list of sequenced transactions and executes all of them in parallel as if none of them touch the same addresses. For transactions which do happen to touch the same addresses or have the same dependencies, BlockSTM will re-execute them until it does so in the correct order to arrive at the correct output. Very importantly, BlockSTM can continuously estimate the dependencies of a given transaction in order to minimize the amount of time and effort spent on re-execution of transactions. This approach allows Aptos to parallelize transaction execution as much as possible without requiring detailed data about the effects and dependencies of transactions.

On Sui, the code of two transactions can also be executed in parallel as long as they don’t touch the same object. However, it does require applications such as a user’s wallet to declare dependencies and/or objects impacted by a given transaction. The advantage of this approach is that Sui’s execution engine will spend much less time and effort re-executing overlapping transactions, but this comes at the cost of increasing complexity of the data included in transaction requests.

Other typical blockchains, including Ethereum, execute all transactions sequentially, one-by-one. Obviously, parallelizing execution as much as possible increases the potential throughput of a given blockchain, so it’s unsurprising that both Aptos and Sui have made this a key part of their respective architectures. Once again, we can visualize a few scenarios to better understand which transactions can or cannot be parallelized on Aptos and Sui.

On Aptos’ blockchain, the code for the two transactions above cannot be executed in parallel because they interact with the same address (Alice’s). One of the transactions must ultimately be executed after the other to make sure that Alice has a sufficient balance to pay both Bob and Frank. The order in which Bob and Frank get paid (or don’t get paid, if Alice’s balance is too low) is determined by the validators of the blockchain.

In Sui’s object-centric DAG, the above two transactions can be executed in parallel because they do not interact with the same object(s), even though they both come from Alice. Alice is changing the owner attribute of two separate USDC objects which she currently owns. There is no “balance check” required during the execution of these two payments.

However, as before, Sui transactions which require splitting a single object into two are considered related and cannot be executed in parallel. Validators must first execute the split, and then execute any remaining transactions on the resulting object(s).

Both Aptos and Sui can execute the above transactions fully in parallel because they do not touch any of the same addresses or objects.

In Aptos’ blockchain architecture, each validator must execute every transaction in proposed blocks and vote whether or not to accept the new block, requiring a momentary freeze of the universal ledger’s state. Again though, transaction execution and dissemination are performed continuously in the background, even if the written state of the ledger is momentarily paused.

From the “Ledger Certification” section of Aptos’ whitepaper (emphasis added):

“At this point in the pipeline, every individual validator has computed the new state for a committed block of transactions. However, to efficiently support verified light clients and state synchronization, the Aptos blockchain implements ledger certification for the ledger history as well as the ledger state. One key difference for the Aptos blockchain is that ledger certification is not on the critical path of transaction processing and can even be run completely out-of-band if desired.

A validator appends the transactions together with their execution output to a global authenticated ledger data structure. Part of the transaction output is the state write set, consisting of the alterations made to the global state accessible by Move. The short authenticator of this data structure is a binding commitment to a ledger history, which includes the newly executed batch of transactions. Similar to transaction execution, the generation of this data structure is deterministic. Each validator signs the short authenticator to the new version of the resulting database. Validators share their recent set of signed short authenticators with each other, collectively aggregate quorum-signed short authenticators, and also share the recent quorum-signed short authenticators with one another.”

Validators on Sui will also generally execute every transaction on their own computer(s), but due to Sui’s DAG-based architecture, the state of the ledger does not need to be frozen in order to write a given transaction to the ledger. Instead, Sui validators will construct their view of the DAG using the publicly available transaction data (code) and use a checkpoint system to periodically verify that their constructed DAG matches the DAG of a sufficient number of validators in the network. These checkpoints which Sui creates are analogous to blocks in a traditional blockchain architecture. However, unlike in a traditional blockchain, if a transaction happens to move slowly through the consensus process, other transactions can still be written to the ledger without waiting for the slow transaction to be confirmed. Again, the ability to update the independent ledger of each object may provide Sui with a latency advantage in certain cases. One potential disadvantage of Sui is that validators are responsible for tracking and constructing their own view of the object pool. As such, if there are a high number of complex transactions between checkpoints, it could become challenging for some validators to synchronize the state of their object pool with other validators.

Transaction storage

The last difference we want to highlight has to do with how Aptos and Sui handle data storage. In a typical blockchain architecture, all executed transactions remain in the ledger forever. Over a long period of time, this can lead to state bloat and material memory requirements for validators. That said, the Aptos blockchain is represented as a Merkle tree, greatly reducing the storage requirements of validator nodes. Additionally, nodes can prune certain transaction and event data to reduce storage requirements. Both of these optimizations should reduce the storage burden for validators and other nodes.

As mentioned previously, one disadvantage of Sui’s object-centric design is that divided objects can quickly accumulate and take up valuable storage space on validators and other nodes. However, Sui’s economic model includes incentives and penalties designed to alleviate this issue. First, users must pay separate gas fees for execution and storage. Storage fees, which are set by Sui’s governance, are deposited into a storage fund which is used to adjust the stake of future validators and increase their rewards as their real-world storage requirements grow. Basically, the storage fund accumulates an increasingly large stake of SUI tokens and can delegate this stake to validators to pay them more as their storage costs grow. Additionally, Sui allows users to actually delete objects from the ledger. If an object is not specified as “read-only”, then its owner(s) can choose to delete it, if desired. Users who delete objects receive a storage fee rebate, providing an incentive to combat state bloat. Sui’s programming model also includes a native function to wrap objects. When an object is wrapped, it is embedded into another object and essentially becomes an attribute of that object. From a memory and storage perspective, this has a similar effect to deleting the object completely. Finally, the ability to join certain objects using Sui’s wallet API may help reduce memory usage as well. Deleting, wrapping, and joining objects can be used to alleviate state bloat if and when it becomes an issue.

It’s important to note that because Aptos and Sui are both brand new layer 1s, state bloat is unlikely to become a high-priority problem for either of them in the near future.

Our takeaway

Both Aptos and Sui represent the culmination of years of distributed ledger scalability research, and their new mempool and consensus protocols provide a material performance boost over existing architectures. As with any layer 1, the actual implementation of Aptos’ and Sui’s respective designs will be a major determinant of their real-world performance. Fortunately, both of these new entrants to the layer 1 landscape have the expertise and capital to execute well on their vision. In our view, Sui’s object-centric DAG appears to provide certain advantages over traditional blockchains in terms of throughput and latency, at least in theory. However, this may come at the cost of easy divisibility of assets and additional workload placed on validators. Either way, both protocols are still in their early stages of development, so we may see their respective performance advantages shrink over time as each one improves. Either way, both of these new layer 1s are highly ambitious undertakings which we expect to push layer 1 capabilities and our industry forward.

Acknowledgments

Special thanks to Jian Wang, Ross Liang, Larry Liu, Andres Acevedo, and others for offering their insight into the research.

About the author

Austin Muñoz is an Investment Partner for Amber Group's Eco Fund, the company's early stage crypto venture fund. Prior to joining Amber, he spent five years building automation tools and covering video games at a large family office hedge fund. It was there that he learned about existing financial infrastructure and markets and became interested in crypto both as a technology and as an asset class. He holds a master's degree in quantitative finance from Yale University and is a CFA charterholder.

Disclaimer

The information contained in this post (the “Information”) has been prepared solely for informational purposes, is in summary form, and does not purport to be complete. The Information is not, and is not intended to be, an offer to sell, or a solicitation of an offer to purchase, any securities. The Information does not provide and should not be treated as giving investment advice. The Information does not take into account specific investment objectives, financial situation or the particular needs of any prospective investor. No representation or warranty is made, expressed or implied, with respect to the fairness, correctness, accuracy, reasonableness or completeness of the Information. We do not undertake to update the Information. It should not be regarded by prospective investors as a substitute for the exercise of their own judgment or research. Prospective investors should consult with their own legal, regulatory, tax, business, investment, financial and accounting advisers to the extent that they deem it necessary, and make any investment decisions based upon their own judgment and advice from such advisers as they deem necessary and not upon any view expressed herein.