The rise of blockchains as a new Internet infrastructure has led to developers deploying tens ofthousands of decentralized applications at rapidly growing rates. Unfortunately, blockchain usageis not yet ubiquitous due to frequent outages, high costs, low throughput limits, and numeroussecurity concerns. To enable mass adoption in the web3 era, blockchain infrastructure needsto follow the path of cloud infrastructure as a trusted, scalable, cost-efficient, and continuallyimproving platform for building widely-used applications.We present the Aptos blockchain, designed with scalability, safety, reliability, and upgradeabilityas key principles, to address these challenges. The Aptos blockchain has been developed over thepast three years by over 350+ developers across the globe [1]. It offers new and novel innovationsin consensus, smart contract design, system security, performance, and decentralization. Thecombination of these technologies will provide a fundamental building block to bring web3 to themasses:1
7 Pipelining, batching, and parallel transaction processing To maximize throughput, increase concurrency, and reduce engineering complexity, transaction processing on the Aptos blockchain is divided into separate stages. Each stage is completely independent and individually parallelizable, resembling modern, superscalar processor architectures. Not only does this provide significant performance benefits, but also enables the Aptos blockchain to offer new modes of validator-client interaction. For example: Clients can be notified when specific transactions have been included in a batch of persisted transactions. Persisted and valid transactions are highly likely to be committed imminently. Clients can be informed when a batch of persisted transactions has been ordered. Thus, to reduce the latency of determining the executed transaction outputs, clients can select to execute transactions locally rather than wait for the validators to complete execution remotely.
id: b5ae1477b7860460cb2f7557e8cd8092 - page: 9
Clients can elect to wait for certified transaction execution by the validators and perform state synchronization on the attested results (e.g., see section 8). The Aptos modular design aids development speed and supports faster release cycles, as changes can be targeted to individual modules, instead of a single monolithic architecture. Similarly, the modular design also provides a structured path to scaling validators beyond a single machine, providing access to additional compute, network, and storage resources. Figure 4 shows the transaction life cycle across the various processing stages. 7.1 Batch processing Batch processing is an important efficiency optimization that is part of every phase of operation in the Aptos blockchain. Transactions are grouped into batches by each validator during transaction dissemination, and batches are combined into blocks during consensus. The execution, storage, and 9 (digest_7, timestamp_7, PoAV_7) transaction transaction transaction
id: 5b715fd6c91c0363d881b789bba281f2 - page: 9
ledger certification phases also work in batches to provide opportunities for reordering, reduction of operations (e.g., duplicate computation or signature verification), and parallel execution. Grouping transactions into batches can induce small amounts of latency, for example, waiting 200 milliseconds to accumulate a batch of transactions before performing dissemination. However, batching is easily configurable with respect to a maximum waiting period and maximum batch size, enabling a decentralized network to automatically optimize across latency and efficiency. Batching also allows for efficient fee markets to prioritize transactions and avoid unintended denial-of-service (DoS) attacks from overzealous clients.
id: 7c0ddea80c55c4a2886cfd3780c6e173 - page: 10
7.2 Continuous transaction dissemination Following the primary insight of Narwhal & Tusk , transaction dissemination in the Aptos blockchain is decoupled from consensus. Validators continuously stream batches of transactions to each other, utilizing all available network resources concurrently. Each batch distributed by a validator v is persisted, and a signature on the batch digest is sent back to v. Following the consensus requirements defined in Section 7.3, any 2f + 1 stake weighted signatures on the batch digest form a proof of availability (PoAv). Such a proof 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.
id: 66b1791c014afcf4b978ebd37596f10c - page: 10