Deep Dive: The Aptos Ecosystem

Table of Contents

• Abstract
• Introduction to the Aptos Ecosystem
• Pipelining, batching & parallel transaction processing
• Practical Functionality and Philosophy
• Conclusion

Abstract

The Aptos vision is to develop a layer-1 that can bring mainstream adoption to web3. They want to create an ecosystem on the backbone of decentralized applications. Achieving wide adoption of anything in the web3 space requires overcoming certain bottlenecks that exist in the pre-existing implementations of layer-1 protocols. Aptos blockchain presents scalability, safety, reliability and upgradability as key principles to address these challenges.

Introduction to the Aptos Ecosystem.

MILESTONES AND HISTORY :

Diem (formerly Libra) was a permissioned blockchain-based stable coin payment system proposed by Facebook (Meta now). The Diem blockchain is a predecessor of the Aptos blockchain. Over the past years it has proven that a network can continually upgrade its protocols without disrupting the clients. Diem mainnet was deployed to more than a dozen node operators with multiple wallet providers in early 2020. Over the following year, the Aptos developer team pushed two major upgrades that changed the consensus protocol and the core framework. This was achieved without downtime for users. Aptos blockchain implements radical improvements to the technology stack while also incorporating safe, transparent and frequent upgrades as a core feature, as inspired by the Diem Blockchain.

KEY COMPONENTS OF THE ECOSYSTEM :

As shown in Figure 1 below, the Aptos ecosystem consists of a set of validators that jointly receive and process transactions from users using a byzantine fault-tolerant (BFT), proof-of-stake consensus mechanism. Token holders stake their tokens in their selected validators. The Consensus voting weight of each validator is proportionate to the amount staked to them. A validator can have an active or inactive status. An active validator can participate in consensus. On the other hand, an inactive validator who doesn’t have enough stake to participate isn’t included in the validator set; it elects itself to be offline as it syncs blockchain state, or is deemed not participating due to poor historical performance.

Any part of the system that requires the submission of a transaction, a query to know the state and history of the blockchain or verification of signed proofs for queried data. The ecosystem also consists of full nodes; they replicate transaction and blockchain state from validators or from other full nodes in the networks. Full nodes may elect to prune transaction history and blockchain state as desired to reclaim storage. Light clients only maintain the current set of validators and can query partial state securely, typically from full nodes. Wallets are light clients.

Architecture and Underlying Technologies :

MOVE:

Move is a new smart contract programming language providing memory safety, flexibility and concurrency. The Aptos blockchain uses Move’s object model to represent its ledger state along with Move modules to encode rules of state transitions. Using the object model allows users to submit transactions that are easily upgradable. It also allows the publishing of new modules, and for them to contain scripts that directly interact with the public interfaces of other modules.

Move leverages a bytecode verifier to guarantee type and memory safety even in the presence of untrusted code. To help write more trusted code, Move includes a formal verifier, the Move Prover capable of verifying the functional correctness of a Move program against a given specification, formulated in the specification language integrated into Move.

DATA MODEL:

Ledger state is the state of all accounts, versioned using an unsigned 64 bit integer that represents the number of transactions the system has executed. When a transaction gets executed a transaction output is generated which contains zero or more operations to manipulate the ledger state, these are called write sets., a vector of resulting events, the amount of gas and the executed transaction status.

A signed transaction contains:

• Transaction authenticator: Includes digital signatures to verify that a transaction is authenticated.
• Sender Address
• Payload: An existing entry function present on-chain or a function to be executed as inline bytecode (a script). A set of input arguments is encoded as byte arrays and is present in the payload.
• Gas Price: Amount the sender is willing to pay per unit of gas to execute the transaction.
• Maximum Gas Amount: The maximum gas amount a transaction can consume before aborting. The sender must have gas price × maximum gas price amount or the transaction will be discarded during the validation process.
• Sequence Number: The sequence number of the transaction. This must match with the sequence number stored in the sender’s account when the transaction executes. Sequence number is incremented after successful transactions to prevent replay attacks.
• Expiration time: Time after which the transaction is invalid.
• Chain id: This is used to identify the blockchain the transaction is valid for. This provides protection for users to prevent signing errors.

At each version i, the state change is represented by the tuple (Ti,Oi Si),containing the transaction, transaction output, and the resulting ledger state, respectively. Given a deterministic function Apply, the execution of transaction Ti with ledger state Si−1 produces the transaction output Oi and a new ledger state Si . That is, Apply (Si-1,Ti)-> <Oi,Si>.

ACCOUNTS:

An account is represented by a 256-bit address known as the account address. A new account is created in the ledger state when a transaction sent from an existing account invokes the create_account(addr) Move function. Basically this occurs when a transaction attempts to send tokens to an account address that has not yet been created.

To create an account a user must generate a key pair: (vk, sk). The new address for this account is generated based on the signature scheme using a cryptographic hash H of the public verification key vk that is concatenated with the ssid: where addr = H(vk, ssid). The user can now sends transaction from addr by signing transaction by their private key sk. The user can rotate sk, to proactively change the key from time to time or in response to a compromise. Accounts are not linked to real life identities and hence allows users to own multiple addresses. Multiple accounts can however be managed in one wallet application for simplicity.

MOVE MODULES:

Move modules contain bytecode that declares data types (structs) and procedures. They are identified on-chain by the addresses that declared them and a name for the module. A module can depend on other on-chain modules, this means code reusability is possibly creating great opportunities for developers to easily deploy newer modules by writing lesser code

LEDGER STATE:

Data model provided by the Move VM on the Aptos blockchain is such that each account consists of a set of values and key-value data structures. These are stored in Binary Canonical Serialization (BCS) format. Such a data model provides the ability to efficiently smart contracts that operate well on small amounts of data that is replicated across a large number of accounts as well as on large amounts of data stored in a small number of accounts. At launch, the Aptos blockchain will be represented by a single ledger state. However, as adoption increases and technology develops, Aptos will scale up the number of shards to increase throughput (i.e., enable multiple ledger states) and support transactions that move or access assets across shards. Each ledger state will maintain all on-chain assets for the specific shard and provide the same account model with a fine-grained, key-value data store offering near-fixed costs for storage access.

SECURITY: A DISTINGUISHING CHARACTERISTIC OF APTOS

Aptos aims to make web3 accessible to billions of users, and hence aims to make it bulletproof. It should be safe and reliable at all times for users and developers alike. Innovations made to implement such security:

• Transaction viability: Signing of transactions can occasionally be unintentional, when users have not considered all the ways in which their transaction can be manipulated. To overcome this Aptos provides constraints to the viability of transactions and protects the signer from unbounded validity. They do this by providing protection in the form of the sender’s sequence number as mentioned earlier, a transaction expiration time, and a designated chain id.
• Move-based key management: Aptos provides key rotation for users to be able to respond to compromise of their private or to allow them to intentionally rotate it for privacy concerns and security intentionally. This provides protection from long range attacks, and future advances to break existing cryptographic algorithms. Aptos accounts have the flexibility to enable hybrid models of custody. A move module can define a policy that empowers trusted entities to rotate the key under specific circumstances.
• Key Management: Aptos blockchain layer provides full transparency of all key-related operations and makes it simpler to implement a wallet with rich key management.
• Pre-signing transparency: Wallet applications provide little transparency about the signed transactions, this causes users to make mistakes and sign malicious transactions that may steal funds and have devastating consequences. Aptos provides services for transaction pre-execution: a precaution mechanism that describes the outcomes of the transactions before they sign them. This will greatly help reduce fraudulent transactions.
• Light Client Protocols: Clients cannot be protected just by relying on TLS/SSL certificates of API providers to establish trust between blockchain clients and servers. Even in the presence of a valid certificate, wallets and clients have no guarantees as to the authenticity and integrity of the data being presented to them. As a result, API providers may return incorrect or malicious blockchain data, deceiving third parties and performing double-spend attacks. To prevent this Aptos provides state proofs and light client verification protocols that can be used by wallets and clients to verify the validity of data being presented by an untrusted third-party-server. In addition, Aptos nodes also expose rich, high-performance storage interfaces that can be further fine-tuned to allow subscriptions to proofs targeting specific data and accounts on-chain. This can be leveraged by light clients to retain minimal verifiable data without the need to run a full node or process a substantial number of transactions.

Pipelining, batching, and parallel transaction processing :

OPTIMIZATION TECHNIQUES:

Maximization of throughput, increase in concurrent processing and reduced complexity in transaction processing is achieved by Aptos by dividing the processing into three stages. Each stage is independent and parallelizable. This allows the blockchain to offer new modes of validator-client interaction.

Modes of validator-client interaction:

• Notifying clients when specific transactions have been included in a batch of persisted transactions.
• Informing clients when a batch of persisted transactions has been ordered, reduces latency of determining the executed transaction outputs; clients can select to execute transactions locally rather than wait for the validators to complete execution remotely.
• Clients can elect to wait for certified transaction execution by the validators and perform state synchronization on the attested results

The modular design of Aptos provides rapid development speed and supports faster release cycles since changes can be targeted to individual modules instead of monolithic architecture that take significant time to edit, audit and test. This provides a structured path to scaling validators beyond a single machine, providing access to additional compute, network and storage resources.

OPTIMIZATIONS THROUGH BATCH PROCESSING:

Batch processing provides optimization in every phase of operation in the Aptos blockchain. Transactions are grouped into batches by each validator during transaction disseminations and batches are combined into blocks during consensus. The execution, storage and ledger certification phases also function in batches to provide opportunities for reordering, reduction of operation and parallel processing. Batching also allows for efficient fee markets to prioritize transactions and avoid unintended denial-of-service (DoS) attacks from overzealous clients.

TRANSACTION DISSEMINATION:

Transaction dissemination in Aptos is decoupled from consensus. Validators stream batches of transactions to each other, utilizing network resources concurrently. Each batch that is distributed by a validator v is persisted, and a signature on the batch digest is sent back to v. This must follow the consensus mechanism in place, any 2f + 1 stake weighted signatures on the batch digest form a proof of availability (PoAv). This guarantees that at least f + 1 stake weighted honest validators have stored the batch, and thus all honest validators will be able to retrieve it prior to execution.

Each batch has an associated timestamp to prevent DoS attack vectors by causing validators to run out of storage and crash.
One of the key innovations of the Aptos blockchain is to decouple non-agreement related tasks out of the consensus phase, such as transaction dissemination, transaction execution/storage, and ledger certification. By decoupling transaction dissemination from the consensus phase, ordering can occur with very low bandwidth (block metadata and proofs only), resulting in high transaction throughput and minimized latency

BLOCKCHAIN TIME:

The Aptos blockchain adopts an approximate, agreed-upon, physical timestamp for every proposed block, and correspondingly, all transactions within that block. This timestamp enables many important use cases like:

• Time-dependent logic in smart contracts
• Correlation of events and handling delays from real-world data
• High-precision timestamp access to clients
• Strong correlation to off-chain events
• Clients can select expiration time for transactions

PARALLEL TRANSACTION EXECUTION:

After consensus block metadata ordering, transactions can be executed by any validator, full node, or client though at least 2f + 1 stake weighted validators have veritably persisted transactions for the proposed batches. Due to the continuous property of dissemination of transactions the honest validators will receive the transaction batches over time. If an honest validator has not received the transactions for the ordered batches by the time it reaches the execution stage, it can download them from the 2f +1 stake weighted validators, knowing that at least f + 1 stake weighted validators ( ≥ half of the stake weighted PoAV signers) are honest.

PARALLEL EXECUTION ENGINE:

The Block-STM parallel execution engine detects and manages the conflicts for an ordered set of transactions along with optimistic concurrency control to allow for maximum parallelism given a particular ordering. Block-STM uses a multi-version data structure to avoid write-write conflicts.

Under low contention, Block-STM achieves 16x speedup over sequential execution with 32 threads, while under high contention, Block-STM achieves over 8x speedup. Unique to other parallel execution engines in the blockchain space, Block-STM is able to dynamically and transparently (without any hints from the user) extract the inherent parallelism from any workload. In comparison to parallel execution environments that require upfront knowledge of data locations to be read or written, Block-STM can support more complex transactions concurrently. This property leads to fewer yet more efficient transactions, decreases cost, and provides lower latency for users.

Certification and Synchronization :

LEDGER CERTIFICATION:

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. 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 part of transaction processing and can even be run completely out-of-band if desired.

PERIODIC STATE CERTIFICATION:

The entirety of the global state accessible by Move can be summarized to a short authenticator at any point in history, similar to a summary of the ledger history. Due to the random access nature of the global state (unlike the ledger history which is append-only), the cost of maintaining this authentication is significant. Nevertheless, when updating the data structure in a large batch, we can compute the update in parallel and also exploit any overlap among the parts that must be updated when each individual state value changes. The Aptos blockchain deliberately only periodically certifies the global state to reduce duplicate shared updates.

STATE SYNCHRONIZATION:

the ecosystem. As a result, the blockchain must offer an efficient state synchronization protocol to disseminate, verify, and persist blockchain data to light clients, full nodes, and validators. In addition, the synchronization protocol must also be tolerant of resource constraints and heterogeneity within the network, accounting for different users and use cases. For example, it must allow archival full nodes to verify and persist the entire blockchain history and state, while also enabling light clients to efficiently track only a small subset of the Aptos blockchain state.

To achieve this property, the Aptos blockchain leverages the authenticated ledger history and certified state proofs offered by the validators, full nodes, and other replicators to provide a flexible and configurable synchronization protocol. Specifically, participants in the network can select different synchronization strategies to optimize for their use cases and requirements. For example, in the case of full nodes, Aptos allows multiple synchronization strategies, including the ability to process all transactions since the beginning of time or skip the blockchain history entirely and synchronize only the latest blockchain state using waypoints. In the case of light clients, strategies include synchronizing partial blockchain states, e.g., specific accounts or data values, and enabling 14verified state reads, e.g., verified account balance fetching. In all cases, Aptos allows participants to configure the amount and age of the data to fetch, process, and retain. By adopting a flexible and configurable approach to state synchronization, Aptos can adapt to a variety of client requirements and continue to offer new and more efficient synchronization strategies in the future.

Practical Functioning and Philosophy :

COMMUNITY OWNERSHIP:

The Aptos blockchain will be owned, operated, and governed by a broad and diverse community. A native Aptos token will be used for transaction and network fees, governance voting on protocol upgrades and on-chain/off-chain processes, and securing the blockchain via a proof-of-stake model.

APTOS TOKEN:

All Aptos transactions have a gas unit price (specified in Aptos tokens) that allows validators to prioritize the highest value transactions in the network. Moreover, at every stage of the pipelined model, there are multiple opportunities to discard low-value transactions (allowing the blockchain to operate efficiently when at system capacity). Over time, network fees will be deployed to ensure that the costs of using the Aptos blockchain are proportionate to the real-world costs of hardware deployment, maintenance, and node operation. Furthermore, developers will have the opportunity to design applications with different cost trade-offs between compute, storage, and networking.

CONSENSUS MECHANISM: POS

To participate in transaction validation on the Aptos blockchain, validators must have a minimum required amount of staked Aptos tokens. The staked amounts proportionately affect the 2f + 1 stake weighted PoAv during transaction dissemination as well as vote weights and leader selection during block metadata ordering. Validators decide on the split of rewards between themselves and their respective stakers. Stakers can select any number of validators in which to stake their tokens for a pre- agreed reward split. At the end of every epoch, validators and their respective stakers will receive their rewards via the relevant on-chain Move modules

PERFORMANCE:

Aptos blockchain is able to achieve optimal throughput and hardware efficiency via its parallel, batch-optimized, and modular transaction processing pipeline. Additional performance initiatives, such as consensus upgrades, delta writes, transaction hints, and critical path caching, will continue to increase throughput and improve efficiency over time.
Systems require a priori knowledge of transaction inputs and outputs that forces the splitting of logical transactions into smaller less complex transactions. Splitting a transaction results in poor user experiences and artificially impacts latency and throughput, without considering what the developer is trying to accomplish. In contrast, the Aptos approach is to enable developers the freedom to build without limits and to measure throughput and latency with respect to real-world use cases rather than synthetic transactions.
The blockchain aims to keep improving validator performance as well as experiments with scaling techniques that allow the addition of more validators to the network. Both approaches have distinct trade-offs.

HOMOGENOUS STATE SHARDING:

Homogeneous state sharding provides the potential for horizontal throughput scalability and allows developers to program with a single universal state across shards, and enables wallets to easily incorporate sharded data for their users easily. This provides significant performance benefits as well as the simplicity of a single unified Move smart contracts platform.

Summary and Opinion :

Aptos is backed by major players and has a well-funded team with organizational maturity and continuity to carry out its vision. The efficiency of Move and the other features like scalability and upgradability provided by Aptos make it a suitable platform for users. Every technical decision taken by the team is done with users in the back of their mind, which is a core value based on their philosophy: “to reach the masses”. We believe that Aptos has the ability to spread widely across the web3 space because the team puts in massive effort to make the process of development as user friendly as possible. We also believe that nothing in the web3 space remains constant, the only constant is change and that is where our ideas coincide with Aptos. Aptos provisions upgradability through its data-model and technical architecture, which will allow it to adapt in the future and compete with the ecosystems that are yet to be born.

APTOS IN CONTRAST WITH MYSTEN ECOSYSTEM :

Smart Contract Language

Aptos and Sui (the blockchain infrastructure provided by MystenLabs) are based on the move programming language, developed at Meta for the Diem Project. However, Sui uses its own version of Move called Sui Move.

Consensus

Aptos and Sui both implement a consensus concept called BFT, or Byzantine Fault Tolerance. It provides a safety net for the ecosystem by allowing the operation of the network even if one-third of the validators go offline or are malicious.

Aptos employs parallelization by dynamically detecting dependencies and scheduling execution tasks using BlockSTM as discussed earlier. This is achieved by an extension to the existing BFT consensus mechanism called HotStuff. This was modified by Diem and later again by Aptos under the name AptosBFT.
In HotStuff a leader is responsible for suggesting a new block while the remaining network of validators vote on its addition. In the mechanism, all the validators communicate directly with the leader instead of with each other and as a result this dramatically reduces the total number of messages sent out in every round.

Upon agreement of validators that a block is valid, it becomes final — this fast finality is a crucial advantage of Aptos over other blockchains. Leaders change with every round of voting; a new leader is chosen in a random way (verifiably). By the virtue of pipelining the leader can work on several blocks simultaneously. Sui’s consensus protocol is a derivative of HotStuff as well, it implements Narwhal and Tusk as their consensus algorithm (A DAG-based mempool used for parallelization at the execution layer).

Scalability and Upgradability

Aptos and Sui prioritize scalability by increasing the network capacity rather than supporting the home validator case or adopting widespread decentralization; these are necessary steps taken to provide scalability, though Aptos emphasizes on heterogenous validators to deal with the state growth bottleneck, while Sui intends to shard data storage efficiently and scale just horizontally.

Upgradability is a core feature of Aptos, frequent upgrades on whichever level of abstraction can be done without any worry of downtime for users and developers who are deploying on the ecosystem. This is a excellent advantage for Aptos since it is able to change with time rather than being stuck in a bottleneck like the pioneering projects in the web3 space.

Funding

FTX Ventures, Jump Crypto, a16z, Tiger Global, Multicoin Capital, and many more investors have contributed to Aptos Labs’ $350 million funding round. At the moment, there are 28 investors in Aptos Labs. This is a huge increase from Sui’s Series A fundraising round of $36 million.

REFERENCES:

[1] ^Aptoslabs (2022, September). — https://aptos.dev/concepts/aptos-concepts

[2] ^Wikipedia (Diem) (2022, August). — https://en.wikipedia.org/wiki/Diem_(digital_currency)

[3] ^Aptoslabs (2022, August). — https://github.com/aptos-labs/aptos-core/blob/main/developer-docs-site/static/papers/whitepaper.pdf

[4] ^Boxmining (2022, August). — https://boxmining.com/aptos-vs-sui/

[5] ^State io, Medium (2022, July). — https://medium.com/@state_xyz/mysten-labs-sui-vs-aptos-other-l1s-d046b598a914

[6] ^Pontem Network, Medium (2022, August). — https://blog.pontem.network/aptos-vs-sui-a-detailed-comparison-120b2873ca58

[7] ^BTTC (2022, August). — https://www.btcc.com/en-US/academy/research-analysis/aptos-vs-sui-blockchain-which-layer-1