Portfolio Insights: Aptos
Bixin Ventures is thrilled to announce our strategic investment into Aptos as part of a broader fundraising round announced by the team in late July, led by FTX Ventures and Jump Crypto, with further participation from Apollo, Griffin Gaming Partners, Franklin Templeton, Superscrypt, Circle Ventures and continued support from a16z crypto and Multicoin. We look forward to a fruitful partnership in fostering ecosystem growth and supporting the developer community, to bring mass market use cases to the Aptos ecosystem.
“At Aptos, we are bringing upgradeability and usability to web3, enabling developers to build future-proof and consumer-ready applications that accelerate mass adoption. The support and deep expertise of Bixin allows us to further grow our rich ecosystem and cultivate the best home for deploying Move-based applications. We’re excited to partner with Bixin across several strategic initiatives that will continue to strengthen the Move community on Aptos.”
— Mo Shaikh, Co-Founder & CEO of Aptos
The Blockchain for the People
Aptos is a layer 1 blockchain with a mission to create universal and fair access to decentralised assets for billions of people. It has been touted as one of the heirs to the Diem blockchain, with Solana co-founder Anatoly even admitting that they see Aptos more as direct competitors versus other EVM chains.
Aptos is co-founded by CEO Mo Shaikh, who formerly led Partnerships for Novi and Libra and CTO Avery Ching, formerly Tech lead of Meta’s blockchain efforts — most notably the Diem blockchain. Prior to Meta, Mo was with Consensys, BlackRock and Boston Consulting Group while Avery was with Yahoo. The rest of the Aptos team consists of PhDs, researchers, engineers, designers and strategists with work experience across Meta, Novi, Amazon, VMware etc.
In this article below, we look into what gives Aptos its fast throughput, the security features it possesses and what the upcoming roadmap looks like, going into their highly anticipated mainnet launch.
Performance
The Aptos blockchain is designed to fully utilise any hardware available to it and has demonstrated parallel transaction execution-only benchmarks with over 160k TPS and sub-second latency. Key to Aptos’ throughput is the ability to separate the transaction layer from the consensus protocol using batched transactions to modularise transaction lifecycle, the parallel execution engine Block-STM, and a novel state synchronisation mechanism to reduce latency.
Batched Transactions with Proof of Availability
Transactions within Aptos are grouped into batches by each validator during transaction dissemination and combined into blocks during consensus. Execution, storage and ledger certification are all processed in batches to optimise reordering, operations and parallel execution.
Transactions batches are streamed continuously between validators. Validators will sign on each batch digest and a Proof of Availability (PoAv) is formed when signatures from >⅔ of validators are collected. The PoAv then ensures that the transaction batch is stored locally by at least ⅓ honest validators who can then retrieve the transaction batch before execution. Therefore, each block does not require the actual transaction given PoAV ensures the transactions will be available on execution after ordering is done. Validators then vote on a block by verifying the proof and block metadata.
However, continuous batched transaction dissemination can open up a DDoS attack vector that can cause validators to run out of memory and crash. As a countermeasure, each batch of transactions will come with a timestamp to help validators with garbage collection (which helps to free up memory).
Read here to find out more about batched transactions, transactions dissemination and block ordering.
Parallel Execution Engine: Block-STM
Block-STM is a highly efficient, multi-threaded, in-memory parallel execution engine that boasts a theoretical throughput of 160k TPS. In contrast to other parallel execution techniques which involve declaring all dependencies up front, thereby creating limitations to the transaction or forcing it to be broken up in parts, Block-STM looks to extract the maximum inherent speed up required through an algorithm which can detect access conflicts within a preset order of transactions.
Below are the key features of Block-STM:
- Optimistic Concurrency Control — Transactions are executed optimistically and validation is done post-execution. If validation is unsuccessful, the transaction will be re-executed, and all associated transactions will need to be revalidated before being committed.
- Multi-version Data Structure — All writes to the same location are stored along with their associated versions to avoid write-write conflicts whenever there is a new transaction.
- Validation — During execution, transactions are split into a read-set and write-set. During validation, all memory locations in the read-set are read and returned versions are compared to the corresponding versions in the write-set.
- Collaborative Schedule — Coordinates the validation and execution tasks among threads via a counting based approach.
- Dynamic Dependency Estimation — All failed validations will result in an “ESTIMATION” value recorded in the multi-version data structure for associated write-sets. This will ensure all future transactions will wait for any dependencies to be resolved before proceeding.
Pulling it altogether, Block-STM uses the collaborative scheduler along with the multi-version data structure to estimate dependencies from a preset order of transactions and reduce abort situations. Block-STM then uses a series of atomic counters to ensure an entire block can be committed.
Read here for a technical explanation of Block-STM.
State Synchronisation
State synchronisation is key to Aptos’ architecture design, by achieving the following outcomes:
- Low time to finality — through fast propagation of data between nodes and hence less transaction processing delays.
- Up to date consensus — by bringing crashed or new validators up to the latest blockchain state.
- Data correctness — which prevents malicious actors from modifying or censoring data in the network; and
- Greater decentralisation — through faster rotations of active validator set, and allows more nodes to come online in a shorter period of time.
- Upgradeability — validator management and configuration is managed with on-chain state to quickly execute upgrades.
In order to build this state sync protocol, Aptos had to ensure that there is:
- Persistent storage — to prevent machine failures and enable data distribution through RocksDB
- A verifiable blockchain — to prevent malicious modification of the blockchain data through validators authenticating merkle roots of committed transactions and resulting states and
- A root of trust — to allow validators to sync to the blockchain at anytime through the genesis blob (first validator set + initial blockchain state) and a trusted waypoint (hash of current validator set + blockchain state).
Since then, Aptos has made the following optimisations, and can state synch with other nodes (e.g. full nodes or other validators) at rates over 10k TPS with sub-second latency and modest hardware requirements.
- Data Prefetching — To reduce network latencies by prefetching transaction data (transactions + state deltas) prior to processing them
- Pipelined Execution and Storage — To increase throughput syncing by separating transaction execution and storage persistence.
- Peer monitoring and Reputation — To optimise peer selection when requesting new blockchain data through peer monitoring for behaviour, distance from validator set and local scoring.
- Data Caching — To reduce read load on storage by storing commonly requesting data items and responses in memory
- Storage Pruning — To prevent storage from bloating over time by pruning unnecessary transaction and blockchain data from storage
Going forward, the Aptos team has already identified optimisations below to achieve 100k+ TPS to match up to the throughput of Block-STM.
- Transaction Batching — To reduce expensive verification and storage by verifying proofs over batches of transactions vs individual transactions
- Network Compression — To optimise bandwidth for scalability by compressing transmitted data vs serialised data distribution
- Faster Storage Writes — To reduce time taken to persist blockchain data to storage by using more efficient data structures and storage configurations or alternate storage engines
- Parallel Data Processing — To enable parallel data processing vs sequential state syncing through sharding or other approaches
Read here to find out more about state synchronisation on Aptos.
Security
Smart Contract Programming Language — Move
Move was initially developed at Facebook for writing safe smart contracts. It is platform-agnostic and enables shared libraries, tooling and developer communities across blockchains. The language design places emphasis on safety, preventing issues such as re-entrancy vulnerabilities, poison tokens and spoofed token approvals where many Web3.0 users have fallen victim to.
To provide additional protection, Move was co-developed with the Move Prover verification tool which allows developers to write formal specifications for the key correctness properties of their application, and use the prover to check for correct execution of the code, all within 30 seconds.
The biggest advantage of Move is the data model for its assets which allows for high composability. Move assets are arbitrary user-defined types; this means that assets can be passed as arguments, stored inside other assets and more importantly, move freely across contract boundaries without losing their integrity. This is a stark contrast to EVM assets written in Solidity, where they are forever trapped within the contract that defines it.
Aptos extends core MoveVM with additional features via an adapter layer which includes parallelism via Block-STM that enables concurrent execution of transactions without any input from the user, among others.
While not a perfect indication of developer adoption, the Move Github repository has a total of 264 stars, compared to Solidity (38.4k), Rust (68.9k), Ink! (950), Cairo (786). It will be worthwhile monitoring the usage and uptake of the language as Aptos progresses.
Read here to find out more about Move on Aptos.
Consensus Mechanism — AptosBFT
Aptos’ consensus mechanism is derived from the HotStuff (similar to tendermint an advancement over tendermint) protocol designed originally for Diem and the team is already onto the 4th iteration of it.
Below are some key features of AptosBFT:
- Byzantine Fault Tolerant — where there is ⅓ fault tolerance of malicious validators before network is compromised and a transaction is guaranteed to have been completed once it has confirmation from >⅔ of validators
- Protocol separates liveness from safety — where the network will not fork as long as Aptos’ BFT integrity guarantees are maintained and also prevents DDoS attacks on the network
- Reputation based leader system — where active validators are tracked using the last committed state and on-chain state is analysed so leader nodes are automatically rotated to adjust for unresponsive validators. This helps minimise the impacts of downtime [See appendix for validator requirements]
Read here for a deeper technical understanding of AptosBFT.
Moreover, the Aptos team is also testing its next-generation protocols alongside the line of work from its research team — including Narwhal & Tusk, Bullshark, and even more advanced derivatives.
Key recovery and rotation protocols
Aptos will support the ability for any account to rotate its private keys, which includes a validator’s consensus key, in order to reduce the likelihood of key theft. The team is also looking into key recovery methods that can be directly integrated into the blockchain account model. This will ensure that any monetary value will not be lost due to a key loss, which should reduce friction when it comes to onboarding new crypto users.
Pre-signing Transaction Transparency
Aptos will provide services that enable a precautionary measure to users when it comes to transaction signing. Prior to signing a transaction, the outcomes of the transaction will be displayed in human-readable form, allowing users to understand what permissions they are granting. Coupled with a repository of previous malicious attacks and smart contracts, it will help to reduce instances of fraud.
Roadmap
Incentivised Testnets
Aptos has laid out their incentivised testnet roadmap in preparation for a robust mainnet launch. The table below covers the key goals and important timelines:
These incentivised testnets have provided many insights which gives us further confidence that the mainnet launch will be robust. Below are a few takeaways and mitigations that the team has come up from the past testnets:
Read here for a summary of IT1 and here for IT2.
At the time of writing, the snapshot for participants’ performance in AIT3 has been recorded and the nodes were free to leave the test settings. AIT3 has since been converted into a long-running testnet, which provides a stable environment for developers to build on. The long-running testnet signals the developers confidence in the stabilised software stack which is a huge step towards a successful mainnet launch. Post-mainnet, the team will continue to run AIT4 going into Q4, to further stress test and open the network up to more validators. We will be monitoring these updates as they come along.
Aptos Grant Program
The Aptos grant program was announced towards the end of June and to offer non-dilutive funding to accelerate the growth of the Aptos dApp ecosystem. The non-exhaustive grant categories include:
- Developer tooling, SDKs, libraries, documentation, guides, tutorials
- Tools and frameworks for development, governance, DeFi, and NFTs
- Core protocol contributions: token standards, libraries, protocol upgrades, etc.
- Open source & public goods
- Education initiatives
Read here for more information on the application criteria, guidelines and review process.
Ecosystem Traction
Since Aptos is a non-EVM chain, there might be questions about how it can bootstrap liquidity within the ecosystem. On top of any help from its financial backers, it was announced that LayerZero, an omnichain interoperability protocol, will be available on the mainnet launch. This will provide the ability for cross-chain liquidity for Aptos, from supported blockchains such as Ethereum, Optimism, Arbitrum, Binance Smart Chain, Avalanche etc.
On the project front, there have been more than 2,100 forks and 3,800 stars on the Aptos-core repository and now over 200 projects across DeFi, NFTs, gaming etc. looking to deploy on mainnet estimated around the end of September.
Below are a few interesting projects:
Pontem is one of the early projects building in the Aptos ecosystem which includes a wallet and an AMM which is live today. As part of their roadmap, they intend to build a Move VM (for cross-chain deployment) and a potential Ethereum VM that will be compatible with the Move VM (for interoperability with other blockchains).
Martian Wallet is a crypto wallet that can manage digital assets and access dApps on the Aptos blockchain. They are available as a Chrome extension and an iOS app in the future. They recently crossed over 100,000 downloads by the end of August.
Switchboard is a permissionless, customisable, multi-chain oracle protocol for general purpose data feeds and verifiable randomness. They are live on Solana and recently announced their devnet on Aptos. Some notable projects on Aptos integrating with them include Tusnami Finance, Houston Swap and Econia Labs.
Econia is a hyper-parallelised on-chain order book that leverages Aptos’ parallel execution engine Block-STM and is live on DevNet.
Topaz is the first NFT marketplace on the Aptos network, with a launchpad for NFT creators and artists. They are currently in private beta mode.
Ditto Finance is a secure decentralised liquid staking platform for Aptos. It looks to provide staking yields to users who do not want to run a validator, given the lack of native delegation on Aptos at the moment.
Hippo Labs is building an aggregation layer for the Aptos ecosystem, starting with a trade aggregator, swap implementations, Move to typescript transpiler, transaction simulation APIs etc.
Closing Thoughts
Aptos is focused on building a Layer 1 blockchain that is fast, safe, scalable and upgradable. While the safety merits of the Move programming language are well documented, the developer ecosystem remains nascent which could impact the growth of the dApp ecosystem on Aptos.
On a broader level, the L1 landscape is highly competitive and with the emergence of performant L2s, they will continue to challenge projects like Aptos in terms of attracting developers which will impact ecosystem building and subsequent market adoption.
However, early indications on the Aptos Devnet that launched in March have been promising, with over 200 projects across DeFi, NFTs, gaming etc. looking to deploy on mainnet. Moreover, we should see greater acceleration in developer growth and dApp activity through the Aptos grant program launched in June.
Overall, we think that the team is well equipped to deliver on their vision. They have proven to be very proactive in resolving issues, evidenced by the recent incentivised tesnets. Going forward, we will continue to keep track of any information surrounding their economic model.
If you are a founder building on the Aptos network, feel free to reach out if you’d like to have a chat!
Written By Allen Zhao, Mustafa Yilham, Henry Ang & Jermaine Wong
Appendix 1: Full Node & Validator Requirements
Full Nodes do not participate in consensus. Instead, they re-execute all transactions in the history of the Aptos blockchain and store the results locally which they use to challenge and provide evidence if they detect any foul-play by validators.
Validator nodes run a distributed consensus protocol, execute transactions and store the results locally. They can decide which transactions are included and in which order. The BFT consensus protocol is then used for validator nodes to agree on the ledger of finalised transactions and the execution results. This is then disseminated to Full Nodes that can then carry out their verification role.
