Disclaimer: This article is intended to convey more market information and does not constitute any investment advice. The article only represents the author's views and does not represent the official position of MarsBit.
Editor: Remember to pay attention to
Source: Aptos
Original title: The Aptos Blockchain: Safe, Scalable, and Upgradeable Web3 Infrastructure
The rise of blockchain as a new Internet infrastructure has led to developers deploying it at a rapid growth rate Tens of thousands of decentralized applications. Unfortunately, blockchain use is not yet widespread due to frequent outages, high costs, low throughput limitations, and numerous security issues. To achieve mass adoption in the web3 era, blockchain infrastructure needs to follow the path of cloud infrastructure as a trusted, scalable, cost-effective, and constantly improving platform for building widely used applications.
We propose the Aptos blockchain, designed with scalability, security, reliability and upgradability as key principles, to address these challenges. The Aptos blockchain was developed over the past three years by over 350+ developers worldwide[1]. It provides new innovations in consensus, smart contract design, system security, performance and decentralization. The combination of these technologies will provide a basic base module for web3 to the masses:
First, the Aptos blockchain is natively integrated and uses the Move language internally for fast and secure transaction execution [2]. Mobile provers are formal verifiers of smart contracts written in the mobile language that provide additional safeguards for contract invariants and behavior. This focus on security allows developers to better protect their software from malicious entities.
Secondly, the Aptos data model enables flexible key management and hybrid hosting options. This, along with transaction transparency before signing and an actual light client protocol, provides a more secure and trustworthy user experience.
Third, to achieve high throughput and low latency, Aptos Blockchain utilizes a pipelined and modular approach to
critical stages of transaction processing. Specifically, transaction propagation, block metadata ordering, parallel transaction execution, batch storage, and ledger authentication all operate in parallel. This approach makes full use of all available physical resources, improves hardware efficiency, and enables highly parallel execution.
Fourth, unlike other parallel execution engines, the Aptos blockchain breaks the atomicity of transactions. The Aptos blockchain does not impose such restrictions on developers. It can effectively support atomicity of arbitrarily complex transactions, provide higher throughput and lower latency for real-world applications, and simplify development.
Fifth, Aptos modular architecture design supports customer flexibility and optimizes frequent and immediate upgrades. Additionally, to quickly deploy new technological innovations and support new web3 use cases, the Aptos blockchain provides an embedded on-chain change management protocol.
1 Legal Disclaimer: This whitepaper and its contents are not an offer to sell or a solicitation of an offer to buy any token. We publish this white paper solely to receive feedback and comments from the public. Nothing in this document should be read or construed as a guarantee or commitment as to how the Aptos blockchain or its tokens (if any) will be developed, utilized or accumulated in value.
Aptos has only outlined its current plans, which are subject to change on their own and their success will depend on many factors outside of its control. These future statements necessarily involve known and unknown risks, which may cause actual performance and results in future periods to differ materially from those described or implied by us in the white paper. Aptos undertakes no obligation to update its programs. There can be no guarantee that any statements in the White Paper will prove to be accurate, as actual results and future events may differ materially. Please do not place undue reliance on future statements.
Finally, Aptos Blockchain is experimenting with future initiatives to scale the performance of a single validator: its modular design and parallel execution engines support internal sharding of validators, and isomorphic state sharding provides horizontal throughput Scalability potential without adding additional complexity to node operators.
1. Introduction
In the web2 version of the internet, services such as information, social media, finance, gaming, shopping, and audio/video streaming are provided by centralized companies that control direct access to user data (e.g., Google , Amazon , apple and Meta). These companies use application-specific software development infrastructure optimized for target use cases and deploy these applications to users using cloud infrastructure. Cloud infrastructure provides access to virtualized and/or physical infrastructure services such as rented virtual machines (VMs) and bare metal hardware running in data centers around the world (e.g., , AWS, Azure, and Google Cloud) . As a result, building web2 Internet services that scale to billions of users has never been easier. However, web2 requires users to explicitly trust centralized entities, a requirement that has increasingly attracted social attention.
To address this concern, a new Internet era has begun: web3. In the web3 version of the Internet, blockchain has emerged, providing a decentralized, immutable ledger that enables users to interact with each other safely and reliably, all without the need for trust in a controlling intermediary or centralized entity. Similar to how web2 internet services and applications rely on cloud infrastructure as building blocks, decentralized applications can use blockchain as a decentralized infrastructure layer to reach billions of users around the world.
However, despite the many blockchains currently in existence, widespread adoption of web3 has not yet occurred [3]. While technology continues to drive industry growth, existing blockchains are unreliable, charge users higher transaction fees for and , have low throughput limitations, suffer regular asset losses due to security issues, and cannot support real-time responses. While cloud infrastructure has enabled web2 services to reach billions, blockchain has yet to enable web3 applications to do the same.
2.Aptos Vision
Aptos’ vision is to provide a blockchain that can bring web3 into the mainstream and empower an ecosystem of decentralized applications to solve real-world user problems. Our mission is to advance the state-of-the-art in reliability, security, and performance of blockchain by providing a flexible and modular blockchain architecture. The architecture should support frequent upgrades, rapid adoption of the latest technological advances, and best-in-class support for new and emerging use cases. At
we envision a decentralized, secure, scalable network that is managed and operated by the community that uses it. When global infrastructure needs grow, blockchain's computing resources will expand horizontally and vertically to meet these needs. As new use cases and technology advancements emerge, the network should be upgraded frequently and seamlessly without disrupting users. Infrastructure concerns should fade away. Developers and users will have access to many different options, including critical recovery, data modeling, smart contract standards, resource usage trade-offs, privacy, and composability. Users know their assets are safe, always available, and accessible at virtually no cost. Anyone can safely, easily and inevitably transact with untrustworthy parties around the world. Blockchain is as ubiquitous as cloud infrastructure.
In order to realize this vision, significant technological advancements must be made. Our experience over the past three years building, developing, advancing and deploying the Diem Blockchain (the predecessor to the Aptos Blockchain) has proven that a network can continuously upgrade its protocol without disrupting its customers[4]. In early 2020, the Daily News mainnet was deployed to more than a dozen node operators and multiple wallet providers. Over the next year, our team released two major upgrades that changed the consensus protocol and core framework. Both upgrades were completed with no downtime for users. With Aptos Blockchain, we have made a series of radical improvements to the technology stack while also incorporating security, transparency and frequent upgrades as core features, inspired by the Diem Blockchain. In particular, we highlight new approaches to transaction processing (as discussed in Section 7) as well as new approaches to decentralization and network governance.
Aptos ecological components
3.Aptos overview
As shown in Figure 1, the Aptos blockchain consists of a group of validators that use Byzantine Fault Tolerance (BFT) and the Proof of Stake consensus mechanism to jointly receive and process transactions from users. Token holders lock or hold tokens in their chosen validator. Each validator's consensus voting weight is proportional to the amount invested in it. Validators can actively participate and participate in the consensus. Likewise, a validator may also be inactive if it does not have enough stake to participate, rotates out of the validator set, chooses to go offline while syncing the blockchain state, or is deemed non-participating by the consensus protocol due to historical poor performance. state. The
client is any part of the system that needs to submit transactions or query the status and history of the blockchain. Clients can optionally download and verify a validator signature proof of the query data. Full nodes are clients that replicate transactions and blockchain state from validators or from other full nodes in the network. They can choose to delete transaction history and blockchain state as needed to reclaim storage. Light clients only maintain the current set of validators and can safely query parts of the blockchain state, typically from full nodes. Wallets are a common example of light clients.
To meet the demand for widespread adoption of secure, fast, reliable, and scalable web3 infrastructure, the Aptos blockchain is built on the following core design principles:
Through a new smart contract programming language, Move[5], Fast and secure execution, as well as simple auditability and mechanical analyzeability. Move originated from the predecessor of the Aptos blockchain and has continued to evolve with the development of this project.
achieves extremely high throughput and low latency through batch processing, pipeline and parallel transaction processing methods. Novel parallel transaction processing effectively supports the atomicity of arbitrarily complex transactions through block-stm, which is different from existing parallel execution engines, which require prior knowledge of read and write data locations. Optimize performance and decentralization with fast, stub-heavy validator set rotation and reputation tracking.
is scalable and configurable as first-class design principles to embrace new use cases and the latest technologies. The modular design supports rigorous component-level testing, as well as appropriate threat modeling and seamless deployment, all of which ensures highly secure and reliable operations.
achieves horizontal throughput scalability while maintaining decentralization, where sharding is a first-class concept exposed to users and native to programming and data models.
Section 4 explains how developers can interact with Move in the Aptos blockchain. Section 5 describes the logical data model. Section 6 details how the Aptos blockchain enables a secure user experience through strong verification methods. Section 7 describes key performance innovations regarding pipelining, batching, and parallelization. Section 8 details the various options for different clients to synchronize state with other nodes. Section 9 describes our community ownership and governance plans. Finally, Section 10 discusses future performance directions while maintaining decentralization.
4.Move language
Move is a new smart contract programming language that emphasizes security and flexibility. The Aptos blockchain uses Move's object model to represent its ledger state (see Section 5.5), and Move code (modules) to encode the rules for state transitions. User-submitted transactions can publish new modules, upgrade existing modules, execute entry-point functions defined in the module, or contain scripts that can interact directly with the module's public interface. The
Move ecosystem includes a compiler, a virtual machine and many other developer tools. Move is inspired by the Rust programming language, which makes data ownership clear in the language through concepts such as linear types. Move emphasizes resource scarcity, preservation and access control. The
mobile module defines the life cycle, storage and access modes of each resource. This ensures that resources like coins are not generated without the appropriate credentials, cannot be reused, and cannot disappear.
Move leverages the bytecode validator to ensure type and memory safety, even in the presence of untrusted code.To help write more trustworthy code, Move includes a formal validator, the Move Validator [6], capable of verifying the functional correctness of a mobile program against a given specification, formulated in the specification language integrated into Move .
In addition to user accounts and corresponding account contents, the ledger state also contains the on-chain configuration of the Aptos blockchain. This network configuration includes a set of active validators, token properties, and configuration of various services in the Aptos blockchain. Move’s support for module upgradeability and full programmability enables seamless configuration changes and supports upgrades to the Aptos blockchain itself (both sets of upgrades are performed multiple times on the private mainnet with no downtime). The
Aptos team has further enhanced Move to support a wider range of web3 use cases. As mentioned later in Section 5.5, the Aptos blockchain supports fine-grained resource control. This not only enables parallelization of execution, but also enables near-fixed costs associated with accessing and modifying data. In addition, the Aptos blockchain provides table support built on top of fine-grained storage, which allows large-scale data sets (e.g., large nft collections) in a single account. Additionally, Aptos supports shared or autonomous accounts represented entirely on-chain. This allows complex decentralized autonomous organizations (DAOs) to collaboratively share accounts and use those accounts as containers for heterogeneous collections of resources.
5. Logical Data Model
The ledger state of the Aptos blockchain represents the state of all accounts. The ledger state is versioned using an unsigned 64-bit integer corresponding to the number of transactions the system has performed. Anyone can submit a transaction to the Aptos blockchain to modify the ledger state. When a transaction is executed, transaction output is generated. The transaction output contains zero or more operations to manipulate the ledger state (called the write set), a vector of resulting events (see Section 5), the amount of gas consumed, and the executed transaction status. .1.14.15 Transaction Signed transaction contains the following information:
Transaction Authenticator: The sender uses a transaction authenticator that contains one or more digital signatures to verify that the transaction is authenticated.
sender address: The sender's account address.
payload: The payload either references an existing input function on the chain or contains a function to be executed as inline bytecode (called a script). Additionally, a set of input parameters is encoded in a byte array. For peer-to-peer transactions, the input contains the recipient's information and the amount transferred to them.
Gas price (in specified currency/gas unit): This is the amount the sender is willing to pay per unit of gas to execute the transaction. Gas is a way to pay for compute, network and storage costs. A gas unit is an abstract calculated measurement with no inherent real-world value.
maximum gas amount: The maximum gas amount is the maximum gas unit a transaction is allowed to consume before being aborted. The account must have at least the gas price multiplied by the maximum gas amount, otherwise the transaction will be discarded during verification.
serial number: the serial number of the transaction record. This must match the sequence number stored in the sender's account when the transaction was executed. After a successful transaction execution, the account sequence number is incremented to prevent replay attacks.
expiration time: the timestamp when the transaction stops being valid.
chain id: Identifies the blockchain on which this transaction is valid, providing users with further protection against signing errors.
In each version i, the state changes are represented by tuples (T represents i, Oi, Si), containing the transaction, transaction output and generated ledger state respectively. Given a deterministic function application, the execution of transaction i with ledger state Si − 1 produces transaction output Oi and a new ledger state Si. That is, application i − 1,Ti) → ⟨ Oi,Si
event
event will be emitted during the execution of the transaction. Each mobile module can define its own events and choose when to emit these events at execution time. For example, during a coin transfer process, the sender's and receiver's accounts will emit send events and receive events respectively. This data is stored in the ledger and can be queried through an Aptos node.Each registered event has a unique key that can be used to query the event details. Multiple events emitted by
to the same event key produce an event stream, a list of events, each entry containing a sequentially increasing number starting from 0, a type and data. Every event must be defined by some type. There may be multiple events defined by the same or similar types, especially when using generics . Events have associated data. For Move module developers, the general principle is to include all data necessary to understand changes to the underlying resource before and after executing the transactions that change the data and emit events. Transactions can only generate events, not read events. This design allows transaction execution to be only a function of the current state and transaction inputs, rather than historical information (e.g., previously generated events).
accounts
Each account is identified by a unique 256-bit value. When the creat_account(addr)Move function is called with a transaction sent from an existing account, a new account is created in the ledger state (see Section 5.5). This usually occurs when a transaction attempts to send Aptos tokens to an account address that has not been created yet. For convenience, Aptos also supports a transfer (from, to amount) function that implicitly creates an account if it does not exist before the transfer.
On-chain mobile module example
To create a new account, the user first generates a signing key pair: (vk, sk). Next, the new account address for the given signature scheme is derived using the cryptographic hash H of the public verification key vk concatenated with the signature scheme identifier (ssid): where addr = H(vk, ssid). After
creates a new account at address addr, the user can use the private signing key sk to sign transactions sent from addr. Users can also rotate the sk to proactively change the sk or respond to possible compromises. This does not change the account address, as the account address is derived from the public verification key only once during creation.
The Aptos blockchain does not tie accounts to real-world identities. Users can create multiple accounts by generating multiple key pairs.
Accounts controlled by the same user are not intrinsically linked to each other. However, a user can still manage multiple accounts within a single wallet for simple asset management. This flexibility provides users with pseudonyms, while we provide privacy-preserving primitives for future releases. As described in Section 7.4, multiple accounts are also provided to increase execution concurrency.
mobile module
mobile module contains mobile bytecode that declares data types (structures) and procedures. It is identified by the address of the account that declares the module and the module name. For example, the identifier for the first currency module in Figure 2 is 0x1::coin. A module can depend on modules on other chains, as shown in the wallet module in Figure 2, thereby achieving code reuse.
A module must be named uniquely within an account. e., Each account can declare at most one module with any name. For example, the account at address 0x1 in Figure 2 cannot claim another module named coin. On the other hand, the account at address 0x3 can declare a module named coin with the identifier 0x3::coin. Please note that 0x1::coin::coin and 0x3::coin::coin are different types and cannot be used interchangeably or share common module code. In contrast, 0x1::coin::coin and 0x1::coin::coin are different instances of the same generic type and cannot be used interchangeably, but can share common module code with
. The
modules are grouped into packages located at the same address. The owner of this address publishes the package on-chain as a whole, including bytecode and package metadata. This package metadata determines whether a package is upgradeable or immutable. For upgradeable packages, a compatibility check is performed before the upgrade is allowed: existing entry point functions must not be changed, nor in-memory resources must be stored. However, new features and resources can be added.The
Aptos framework consists of the core libraries and configurations of the Aptos blockchain and is defined as a regular upgradeable module package (see Section 9.2)
On-chain data case
Resource
Similar to modules, account addresses can also have associated data value. Within each account address, values are keyed by their type, with at most one value of each type belonging to that account. Figure 3 provides an example. Address 0x50 contains a value, 0x3::coin::coin is a fully qualified type. 0x3 is the address where the coin module is stored, coin is the name of the module, and coin is the name of the data type. Generic typed values are also allowed, whereas different instantiations of will be treated as different types. This is crucial for scalability because it allows different instantiations to share the same functional code. The rules for modifying, deleting, and publishing values are encoded in the modules that define the data types. Move's security and validation rules prevent other code or entities from directly creating, modifying, or deleting instances of data types defined in other modules. With at most one top-level value of each type under an address, sound restrictions can be made first. However, this is not a problem in practice because programmers can define other data as internal fields, thus avoiding any restrictions. The Wallet structure in Figure 3 is an example of how to use wrapper types. It should also be noted that not all data types can be stored on-chain. For a data instance to qualify as a top-level value, the data type must have key capabilities. Likewise, storage capabilities are required for nested values. Data types with these two capabilities are also called resources.
Ledger State
From the perspective of the Move Virtual Machine (MoveVM), each account consists of a set of value and key-value data structures. These data structures are called table entries and are stored in the Binary Canonical Serialization Format (BCS). This data layout enables developers to write smart contracts that can efficiently operate on small amounts of data replicated across a large number of accounts, as well as large amounts of data stored in a small number of accounts. The mobile module stores account data similarly, but under a separate namespace. The origin ledger state defines the initial set of accounts and their associated states when the blockchain is initialized. At launch, the Aptos blockchain will be represented by a single ledger state. However, as adoption increases and the technology evolves, Aptos will expand 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 a specific shard and provide the same account model and fine-grained key-value data storage, providing near-fixed storage access costs for storage.
6. Provide a secure user experience
In order to reach billions of Internet users, the web3 user experience must be secure and accessible. In the following sections, we will describe several innovations offered by the Aptos blockchain that aim to achieve this goal. 0x600x2::wallet::Wallet {coins: 0x1 coins: wallet: USD {value: 0, } coins: :coins {value: 10, }} module MyCoin {struct MyCoin{}}
Transaction Viability Protection
Signing a transaction means that the signer authorizes the blockchain to submit and execute the transaction. Occasionally, users may sign transactions unintentionally or without fully considering all the ways their transactions could be manipulated. To reduce this risk, the Aptos blockchain limits the feasibility of each transaction and protects signers from unlimited validity. Currently, the Aptos blockchain offers three different protection measures – the sender’s sequence number, a transaction expiration time and a designated chain identifier. A transaction's sequence number can only be committed exactly once per sender's account. Therefore, the sender can observe that if the current account sequence number is ≥ the sequence number of transaction t, then t has already committed or t will never commit (because the sequence number used by t has already been consumed by another transaction).
blockchain time has high precision and frequency (usually sub-second), see section 7.3.1 for details.If the blockchain time exceeds the expiration time of transaction t, then likewise, t has either already committed, or t will never commit. Each transaction has a designated chain identifier to prevent malicious entities from replaying transactions between different blockchain environments (e.g., through a testnet and a mainnet).
Mobile-based key management
As discussed in Section 5.2, Aptos accounts support key rotation, which is an important feature that can help reduce exposure to private keys, remote attacks, and possible compromise of existing passwords. Risks associated with future progress of the algorithm . In addition, Aptos accounts are flexible enough to support new hybrid hosting models. In one such model, users can delegate the ability to rotate an account's private keys to one or more custodians and other trusted entities. The mobility module can then define a policy that authorizes these trusted entities to rotate keys under specific circumstances. For example, entities might be represented by k-out-n multi-site keys held by many trusted parties, with key recovery services provided to prevent user key loss (e.g., 20% of Bitcoins are currently locked in Non-recoverable accounts[7]).
Additionally, while many wallets support various critical recovery scenarios, such as backing up private keys to cloud infrastructure, multi-party computation, and social recovery, they generally do not require blockchain support (i.e., off-chain). Therefore, each wallet needs to implement its own key management infrastructure, and related operations become opaque to users. In contrast, supporting key management functionality at the Aptos blockchain layer provides full transparency of all key-related operations and makes it simpler to implement wallets with rich key management.
Transparency in Pre-Signed Book Transactions
Today, wallets offer little to no transparency into the transactions they sign. As a result, users are often easily tricked into signing malicious transactions, which can steal funds and have devastating consequences. This is true even for blockchains that require enumeration of all on-chain data accessed by each transaction. As a result, there are currently few existing user protection measures, leaving users vulnerable to a wide variety of attacks. To solve this problem, the Aptos ecosystem provides services for transaction pre-execution: a preventive measure that describes to users (in human-readable form) the outcome of their transaction before signing. Combining this with a known history of previous attacks and malicious smart contracts will help reduce fraud. Additionally, Aptos allows wallets to impose limits on transactions during execution. Violation of these constraints will cause the transaction to be aborted to further protect users from malicious applications or social engineering attacks on .
The practical light client protocol
relies solely on the API provider's TLS/SSL certificate to establish trust between the blockchain client and server, which does not fully protect the client. Even with a valid certificate, the wallet and the client cannot guarantee the authenticity and integrity of the data presented.
[Transaction life cycle. All stages are completely independent and individually parallelizable](https://images.mirror-media.xyz/publication-images/elyd9RVduR0wwiIhJEYMN.png?height=454width=1640)
Therefore, the API provides Vendors may return incorrect or malicious blockchain data, deceive third parties and perform repeat attacks. To prevent this from happening, Aptos provides proof-of-state and light client verification protocols that wallets and clients can use to verify the validity of data provided by untrusted third-party servers.
Furthermore, by leveraging the timestamp-based state attestation in Section 7.6.2, light clients can always ensure freshness of account state (e.g., within seconds) and only need to keep track of the network changes in the configuration (epoch changes) or use current trusted checkpoints (waypoints) to stay up to date [8]. By combining high-frequency timestamping and cheap state proofs, the Aptos blockchain provides customers with additional security guarantees.
In addition, Aptos nodes expose a rich high-performance storage interface that can be further fine-tuned to allow subscriptions to be verified against specific data and accounts on the chain.Light clients can take advantage of this to retain minimal verifiable data without needing to run a full node or process a large number of transactions.
7. Pipeline processing, batch processing 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 independently parallelizable, similar to the modern oversized processor architecture . Not only does this provide significant performance benefits, but it also enables the Aptos blockchain to offer new validator-client interaction models. For example: Clients can be notified when a specific transaction is included in a batch of durable transactions. Durable and valid transactions are most likely to be committed immediately. Clients can be notified when a batch of durable transactions is ordered. Therefore, to reduce the delay in determining the output of executed transactions, clients can choose to execute transactions locally rather than waiting for the validator to complete execution remotely. The client may choose to wait for the authenticator's authenticated transaction execution and perform state synchronization on the authenticated result (e.g., see Section 8).
Aptos modular design contributes to development speed and supports faster release cycles because changes can be targeted to individual modules rather than a single monolithic architecture. Similarly, the modular design also provides a structured path to extend the validator beyond a single machine, providing access to additional compute, network, and storage resources. Figure 4 shows the transaction life cycle across various processing stages.
batching
batching is an important efficiency optimization that is part of every operational stage in the Aptos blockchain. During transaction propagation, each validator groups transactions into batches, and during consensus the batches are merged into blocks. Execution, storage and 910 block timestamp=9 t annsacitoionn ( digest_0 , timestamp_0 , PoAV_0 ) t annsacitoionn ( digest_2 , timestamp_2 , PoAV_2 ) t annsacitoionn ( digest_7 , timestamp_7 , PoAV_7 ) t annsacitoionn ( digest_3 , timestamp_3 , PoAV_ 3 ) t annsacitoionn ( digest_1 , timestamp_1 , PoAV_1 ) t annsacitoionn ( digest_4 , timestamp_4 , PoAV_4 ) Figure 5: Block metadata ordering occurs independently of transaction propagation. The ledger authentication phase also works in batches, providing opportunities for reordering, reduction of operations (e.g., repeated calculations or signature verification), and parallel execution. Grouping transactions into batches may result in a small amount of delay, such as waiting 200 milliseconds for a batch of transactions to accumulate before performing propagation. However, batching is easily configurable for maximum latency and maximum batch size, allowing decentralized networks to be automatically optimized across latency and efficiency. Batch processing also allows efficient charging markets to prioritize transactions and avoid accidental denial of service (DoS) attacks from overzealous customers.
Continuous transaction propagation
According to the main insights of Narwhal and Tusk [9], transaction propagation in the Aptos blockchain is decoupled from consensus. Validators continuously stream available transactions while utilizing all available network resources. Each batch distributed by validator v is persisted and the signature on the batch digest is sent back to v.
Any 2f+1 stake-weighted signatures on the batch digest will form a Proof of Availability (PoAv) according to the consensus requirements defined in Section 7.3. Such a proof guarantees that at least f+1 stake-weighted honest validators store the batch, so all honest validators will be able to retrieve it before execution. Infinitely durable transaction batches can open up DoS attack vectors by causing validators to run out of storage and crash. To prevent this from happening, each batch of transactions has an associated timestamp. Timestamps on batches allow efficient garbage collection on each validator.
In addition, a separate per-validator quota mechanism is designed to protect validators even in the most extreme situations, such as under potential Byzantine attacks. There is also a size limit on batches, which are verified before the protocol continues to stable storage. Finally, several optimizations to eliminate duplicate transactions and cache transactions reduce storage costs and ensure performance integration with parallel execution engines.
Block Metadata Ordering
A common misconception is that consensus is slow and therefore the main bottleneck in blockchain throughput and latency. One of the key innovations of the Aptos blockchain is the separation of non-protocol related tasks from the consensus phase, such as transaction propagation, transaction execution/storage, and ledger authentication. By decoupling transaction propagation from the consensus phase, ordering can occur at very low bandwidth (block metadata and proofs only), resulting in high transaction throughput and minimized latency.
Today, the Aptos blockchain leverages the latest version of DiemBFTv4[10], a responsive BFT consensus protocol. Under common circumstances, consensus requires only two network round-trips (round-trip times are typically less than 300 milliseconds globally), dynamically adjusting to erroneous validators via the leader reputation mechanism [11]. The reputation of the chain leader's transaction mechanism promotes validators that have successfully submitted blocks in the window, and demotes validators that have not participated. This new mechanism significantly improves performance in decentralized environments, accordingly provides the infrastructure for appropriate incentives, and quickly minimizes the impact of failed validators on throughput and latency.
DiemBFTv4 guarantees liveness under partial synchronization and ensures security under asynchrony, with a total validator stake of ≥3f+1 and at most f-stake weighted error validators. DiemBFTv4 has been extensively tested in multiple iterations since 2019 with dozens of node operators and a multi-wallet ecosystem. We are also experimenting with our recent research (e.g., Basha [12]) and other protocols that rely on block history and associated communication to determine block metadata ordering and finality. A consensus block and a proposal timestamp are proposed by a leader and agreed upon by other validators, as shown in Figure 5. Note that each consensus block only contains batch metadata and proofs. No actual transactions are required in this block, as PoAV ensures that batches of transactions will be available during the post-order execution phase (see Section 7.2).
validators can vote on the leader's proposals after validating proofs and meeting block metadata standards. g., proposal timestamp ≤ block expiration time).
Blockchain Time The
Aptos blockchain adopts an approximate, agreed-upon physical timestamp for each proposed block and, accordingly, all transactions within that block. This timestamp enables many important use cases. For example: Time-dependent logic in smart contracts. For example, if a developer wishes to code, all bids for the auction must be received by noon on Thursday. When an oracle publishes on-chain data, an accurate and trusted on-chain timestamp is needed to correlate events and handle delays from real-world data.
customers can identify their latest updates on the blockchain. For security reasons, and to avoid stale data and remote attacks, clients should have access to high-precision timestamps when account status is updated. Auditing the blockchain with a highly trusted timestamp can provide strong correlation with off-chain events, such as ensuring that legally enforceable payments meet expected requirements. Transaction expiration is based on the most recent commit timestamp.
As an additional protection guarantee for client-side transactions, the client can set the expiration time for the transaction, as described in Section 6.1. The Aptos blockchain provides the following guarantees for the timestamps of all transactions within a block: Time is monotonically increasing in the blockchain. That is, if block B1
is a transaction block with a quorum signature number consistent with timestamp T, then an honest validator will not give that block to other validators until its own clock ≥ timestamp T. The timestamp of each committed block is updated and used as the timestamp for all transactions in that block. When the network is synchronized, a block of transactions is committed on every network round trip, providing a fast-updating and highly reliable clock. If desired, finer-grained ordering within transaction blocks can be determined. 11 Figure 6: Block-STM (component-only) benchmark comparing the number of physical cores with different contention levels.
Execution of parallel transaction processing
Once consistent block metadata is ordered, transactions can be executed by any validator, full node or client. There are at least 2 +1 stake weighted validators that did last the proposed batch of transactions. Since transaction propagation is continuous, additional honest validators will receive batches of transactions over time. If an honest validator does not receive an order for a batch of transactions to reach the execution stage, it can learn from 2f+1 stake-weighted validators that at least f+1 stake-weighted validators (≥ half of the stake-weighted PoAV signers) are honest of. An important goal of any blockchain is to achieve as much parallel execution as possible. Aptos blockchain advances this direction from both the data model and execution engine.
Parallel Data Model The
mobile data model natively supports global addressing of data and modules. Transactions without overlapping conflicts in data and accounts can be executed in parallel. Given the pipeline design used by the Aptos blockchain, reordering a set of transactions can reduce the number of conflicts and thus improve concurrency. Even if a transaction modifies values on the same set of chains, most transaction execution can still be parallelized. The Aptos blockchain introduces a new concept, writes delta, which describes modifications to an account's state rather than the modified account state (e.g., increasing an integer rather than simply determining the final value). All transaction processing can be completed in parallel, and incremental writes are then applied to conflicting values in the correct order to ensure deterministic results.
Over time, the Aptos blockchain will continue to enhance the data model in ways that improve concurrency (e.g., leverage read/write hints) and improve ergonomics to make creating, modifying, and editing more natural for developers. and the value on the combined chain. Move provides the flexibility to make these improvements at the language level and through platform-specific features. The
parallel execution engine
Block-STM parallel execution engine detects and manages conflicts in a set of ordered transactions, as well as optimistic concurrency control to allow maximum parallelism given a specific ordering [13]. Batch transactions are executed optimistically in parallel and are verified after execution. Validation failure will result in re-execution. Block-STM uses multi-version data structures to avoid write-write conflicts. All writes to the same location are stored with their versions containing their transaction id and the number of times the write transaction was optimistically re-executed. When transaction tx reads a memory location, it obtains from the multi-version data structure the value written to that location by the highest transaction that occurred before tx, and the associated version.
12 Block-STM has been integrated into the Aptos blockchain. To fully understand the performance potential of Block-STM, we use non-trivial point-to-point move transactions (i.e., 8 reads and 5 writes per transaction) as an isolated, execution-only (not end-to-end) benchmark. In Figure 6, we show our block-stm execution results. Each block contains 10k transactions, and the number of accounts determines the level of conflicts and contention. In
, under low contention, Block-STM achieves 16 times acceleration through the sequential execution of 32 threads, while under high contention, Block-STM achieves over 8 times acceleration. Unlike other parallel execution engines in the blockchain space, Block-STM is able to dynamically and transparently (without any prompts from the user) extract the inherent parallelism from any workload. Compared to parallel execution environments that require advance knowledge of the location of data to be read or written, BlockSTM can support more complex transactions simultaneously.
This property will result in fewer but more efficient transactions, reducing costs and providing lower latency to users. Perhaps most importantly, splitting an atomic transaction into multiple smaller transactions breaks the all-or-none semantics of a single transaction with complex state outcomes. Combining the expressive transaction semantics in Block-STM with parallel execution gives developers the best of both worlds. Note that the block metadata ordering step does not preclude reordering transactions in the parallel execution phase. Transactions can be reordered across one or more blocks to optimize concurrency for parallel execution. The only requirement is that the reordering must be deterministic on all honest validators.Optimizing parallel execution and adding randomization to reordering can improve performance and potentially prevent profitable validators from using the Maximum Extractable Value (MEV) technique of transaction reordering. The "sequence then reveal" MEV resistance strategy can also be incorporated into this pipeline design.
block-stm and transaction reordering are complementary techniques to increase execution parallelism. They can be combined with transactional read/write access hints to obtain additional concurrency. .57 Batch Storage The parallel execution phase generates write sets for all transactions in the group. These write sets can be stored in memory for maximum execution speed and then used as a cache for the next block or set of blocks to be executed. Any overlapped writes only need to be written to stable memory once. If the validator fails before storing the write set in memory, it can simply resume parallel execution from the block metadata sorting phase. Decouple the batch storage of write sets in parallel execution steps to ensure that parallel execution can run efficiently.
In summary, batched write sets reduce the number of storage operations and take advantage of more efficient, larger I/O operations. The amount of memory reserved for the write set cache can be manually configured for each machine and provides a natural backpressure mechanism. If you need to tune for a specific I/O and memory environment, the granularity of batch processing may be different than the granularity of parallel execution blocks. .67 Ledger Certification In the pipeline, each validator computes the new state of the committed transaction block. However, to effectively support authenticated light clients and state synchronization, the Aptos blockchain implements ledger authentication for ledger history and ledger status. A key difference with the Aptos blockchain is that ledger authentication is not in the critical path of transaction processing and can even run completely out-of-band if desired.
Ledger History Authentication The
validator appends transactions and their execution output to the global authenticated ledger data structure. Part of the transaction output is the state write set, which includes changes to the global state accessible to the mobile. The short authenticator for this data structure is a binding commitment to the ledger's history, which includes newly executed batches of transactions. Similar to transaction execution, the generation of this data structure is deterministic. Each authenticator signs a new version of the short authenticator to the resulting database. Authenticators share their nearest signature short authenticator set with each other, collectively aggregate quantitative signature short authenticators, and share their nearest quorum signature short authenticator with each other.
Using this collective signature, clients can trust that a database version represents a complete, valid, and irreversible ledger history according to the protocol's BFT properties. Clients can query any validator (or any third-party copy of the database, such as a full node) to read the database value and verify the result using the authenticator and a proof of the required data.
Periodic State Authentication The entire global state accessible to
Move can be summarized into a short authenticator at any moment in history, similar to a summary of the ledger history. Due to the random access nature of global state (unlike append-only ledger history), the cost of maintaining this authentication is very high. However, when updating data structures in large batches, we can compute the updates in parallel or exploit any overlap between the parts that must be updated when each individual state value changes. The
Aptos blockchain intentionally only certifies global state periodically to reduce duplicate shared updates. During deterministic and configured intervals, the network emits stateful checkpoint transactions that include the global state authenticator as part of its output. These versions are represented as state checkpoints. The larger the gap between two checkpoints, the lower the amortized cost of updating the state authentication data structure for each transaction. Using state checkpoints, any state value can be read from it in a trustless manner without storing all global state. This feature is useful for applications such as incremental state synchronization, sharded storage across validators, stateless validator nodes, and storage-constrained light clients.
However, because state checkpoints are periodic, obtaining proof of a specific version of the ledger state requires performing additional transactions for missing state changes, or obtaining proof of their inclusion from the verified ledger history. State checkpoints are tied to a specific transaction version in the ledger history and therefore to the timestamp associated with the transaction batch mentioned in Section 7.
uses timestamps so that light clients can understand the recency of validated state values. Without timestamps, a light client proof can only ensure the validity of previous states, which provides little guarantee of relevance. Additionally, the timestamp of the state proof is necessary for tracking historical access and auditing purposes, such as calculating the average hourly balance of tokens in the token reserve. State checkpoints can be derived from previous state checkpoints and state changes in subsequent transaction outputs. Therefore, persistent state checkpoints to stable storage do not need to be on the critical path of transaction processing. Additionally, there are beneficial batching effects when using state checkpoints continuously. Caching recent state checkpoints (or rather deltas between them) in memory, and only dumping periodic state checkpoints to stable storage, can significantly reduce storage bandwidth consumption. The way you choose checkpoints to persist does not affect the computation of authenticated data structures. Therefore, it is a per-node choice: node operators can configure the appropriate trade-off between memory capacity and storage bandwidth.
8. State synchronization
The Aptos blockchain aims to provide a high-throughput, low-latency system for all participants in the ecosystem. Therefore, the blockchain must provide an effective state synchronization protocol to propagate, verify and persist blockchain data to light clients, full nodes and validators [14]. Additionally, synchronization protocols must tolerate resource constraints and heterogeneity within the network and take into account different users and use cases. For example, it must allow archiving full nodes to verify and persist the entire blockchain history and state, while also allowing light clients to efficiently track only a small set of Aptos blockchain state. To achieve this property, the Aptos blockchain leverages verified ledger history and certified state proofs (see Section 7.6.1) provided by validators, full nodes, and other replicators to provide a flexible and configurable synchronization protocol. Specifically, participants in the network can optimize their use cases and needs based on different synchronization strategies.
For example, in the case of a full node, Aptos allows for multiple synchronization strategies, including the ability to process all transactions since the beginning of time, or skip the blockchain history entirely and use waypoints to synchronize only the latest blockchain state . In the case of light clients, the strategy consists of synchronizing partial blockchain state, e. g., a specific account or data value, and enable 14 verification status reads, e. g., Verified account balances are being fetched. In all cases, Aptos allows participants to configure the amount and age of data to be captured, processed and retained. By adopting a flexible and configurable approach to state synchronization, Aptos can adapt to a variety of client needs and continue to provide new, more efficient synchronization strategies in the future.
9. Community Ownership
The Aptos blockchain will be owned, operated and managed by a broad and diverse community. The native Aptos token will be used for transaction and network fees, governance voting for protocol upgrades and on-chain/off-chain processes, and for securing the blockchain through a proof-of-stake model. A full description of Aptos tagging economics will be published in a future publication.
Transactions and Network Fees
All Aptos transactions have a gas unit price (specified in the Aptos token), allowing validators to prioritize the highest value transactions in the network. Additionally, at each stage of the pipeline model, there are multiple opportunities to discard low-value transactions (allowing the blockchain to operate efficiently at system capacity). Network fees will be deployed over time to ensure that the cost of using the Aptos blockchain is proportional to the actual cost of hardware deployment, maintenance and node operation.Additionally, developers will have the opportunity to design applications with different cost tradeoffs among compute, storage, and networking.
Network Governance
Every important feature change and improvement on the Aptos blockchain will go through several stages, including proposal, implementation, testing and deployment. This structure provides interested parties and stakeholders with the opportunity to provide feedback, share concerns and provide suggestions. The final phase, deployment, can usually be achieved in two steps. First, a software version with the new feature will be,deployed to each node, and second, the feature will be enabled,e. g., via a feature flag or an on-chain configuration variable. Every software deployment by a node operator must be backwards compatible to ensure new software is interoperable with supported versions. The process of deploying new software versions may span multiple days to account for operators in different time zones and any external issues.
Once a sufficient number of nodes have been upgraded, the enabling of new features can be triggered by a synchronization point, such as an agreed-upon block height or epoch change. In emergency situations (e.g., when downtime is unavoidable), enablement can occur through manual and forced changes by node operators or, in the worst case, through a hard fork in the network. Compared to other blockchains, the Aptos blockchain encodes its configuration on-chain.
Each validator is able to synchronize the current state of the blockchain and automatically select the correct configuration (e.g., consensus protocol and Aptos framework version) based on current on-chain values. Thanks to this feature, upgrades to the Aptos blockchain are seamless and instant. To provide flexibility and configurability to the support process, the Aptos blockchain will support on-chain governance, whereby token holders can vote based on the weight of the tokens they hold. The on-chain voting protocol is public, verifiable, and can be instant. On-chain governance can also enable non-binary outcomes without deploying software. For example, on-chain leader election protocol parameters can be modified through on-chain governance, whereas a pre-known synchronization point will not be able to handle dynamic modifications because all changes must be known in advance. Over time, on-chain governance can be deployed throughout the upgrade management process.
Example:
1. Token holders will vote to transition to a new quantum-resistant signature scheme.
2. The developers implemented and verified the new signature scheme and created a new software version.
3. Validators will upgrade their software to new versions.
token holders vote on-chain to enable the new signing scheme, the on-chain configuration will be updated, and the changes will take effect. As an open source project, Aptos Blockchain will rely on strong community feedback and use on-chain governance to manage appropriate processes. Under certain conditions, off-chain upgrade support may still be required, but this will be minimized over time.
Proof of Stake Consensus
To participate in transaction verification on the Aptos blockchain, validators must have a minimum number of Aptos tokens. During the transaction propagation process, the stake amount proportionally affects the 2f+1 stake-weighted PoAv, as well as the voting weight and leadership selection during block metadata ordering. Validators decide the distribution of rewards between themselves and their respective holders. Claimants can select any number of validators to have their tokens split by a pre-agreed reward. At the end of each epoch, validators and their respective scaffolds will receive their rewards via the relevant on-chain movement module. Any validator operator with sufficient stake is free to join the Aptos blockchain. All parameters, including the required minimum staking rate, can be set through the on-chain enablement process described in Section 9.2.
10. Performance
As mentioned in Section 7, the Aptos blockchain is able to achieve optimal throughput and hardware efficiency through its parallel, batch-optimized and modular transaction processing pipeline. Additional performance initiatives, such as consistent upgrades, incremental writes, transaction hints, and critical path caching, will continue to improve throughput and improve efficiency over time.
Today, blockchain throughput is typically measured in transactions per second.However, given the wide range of costs and complexities across transactions and infrastructure, this is an imprecise way to compare systems. Transaction latency is also flawed because the start and end points of commits to finality vary across experiments. Additionally, some systems require a priori knowledge of transaction inputs and outputs and force logical transactions to be broken into smaller, less complex transactions. Splitting transactions results in a poor user experience and artificially affects latency and throughput without regard to what the developer is trying to accomplish. In contrast, the Aptos approach is to allow developers to build without constraints and measure throughput and latency based on real use cases rather than synthetic transactions. The
Aptos blockchain will continue to optimize the performance of individual validators and experiment with scaling technologies to add more validators to the network. There are obvious trade-offs in both directions. Any blockchain with parallel execution capabilities can support additional concurrency by requiring more powerful hardware or even a cluster of each validator built as a separate machine. However, there are practical limits on the number of global validators commensurate with the cost and complexity of the validator operators. The rise and popularity of serverless databases in cloud services demonstrates that few entities can effectively deploy and maintain these types of complex distributed systems.
Uniform state sharding
Initially, the Aptos blockchain will launch with a single ledger state. Over time, the Aptos network will take a unique approach to achieving horizontal scalability while still remaining decentralized. This will happen via multiple sharded ledger states, each providing a homogeneous API and sharding as a first-class concept. The
Aptos token will be used for transaction fees, staking and governance on all shards. Data can be transferred between shards via homogeneous bridges. Users and developers can choose their own sharding scheme according to their needs. For example, developers can propose a new shard or cluster users within an existing shard to achieve high intra-shard connectivity. Furthermore, fragments may have different system characteristics. One fragment can be optimized for compute 16 17 ssds and the other can be optimized for large hard drives with low compute characteristics. By providing hardware flexibility between different shards, developers can take advantage of the appropriate system features for their applications.
In summary, homogeneous state sharding offers the potential for horizontal throughput scalability, allowing developers to program with a single common state across shards, and allowing wallets to easily merge sharded data for their users. This provides significant performance advantages, as well as the simplicity of a single unified mobile smart contract platform.
References
[1] "Aptos Core", 2022. Available online: https://github. com/aptos-labs/aptos-core
[2] "Mobile", 2022. Available online: https://github. com/move-language/move
[3] D. Matsuoka, C. Dixon, E. Lazarin and R. Hackett (2022) presents the 2022 State of Cryptozoology Report. Available online: https://a16z. com/tags/cryptostate2022/
[4] Z. Amsden, R. Arora, S. Barno, M. Baudette, S. Black Shear, A. Bosra, G. Cabrera, C. Catalini, K. Chalkias, E. Cheng, A. Qing, A. Chursin, G. Danezis, G. D. Giacomo, D. L. Dill, H. Ding, N. Doudchenko, V. Gao, Z. High, F. Garillot, M. Gorven, P. Hayes, J. M.Hou, Y.Hou,K. Hurley, K. Lewi, C. Li, Z. Liechtenstein D.Malkhi, S. Malgulis, B. Maurer, P. Mohassel, L. Denois, V. Nikolaenko, T. Novak, OH. Orlov D. Perelman. Porter, B. ProctorS. Kadir, Rain, D. Russi, B. Schwab, S. Sezer. Sonino, H. Venter, L. Wei, N. Wernerfelt, B. Williams, Q. Wu, X. Yan, T. Zakian and R. Zhou, "Libra Blockchain", 2019. Available online: https://developers. diem. Daily News, Blockchain/2020-0526. pdf
[5] S. Blackshear, E. Cheng, D. L. Diehl, V. High, B. Maurer, T. Novac. Porter, S. Kadir, D. R. Rain, S. Setzer, T. Zakian and R.Zhou, "Mobile: A Language with Programmable Resources," 2019. Online availability: https://developers. diem. com/papers/diem-move-a-language-with-programmableresources/2019-0618.pdf
[6] D. Diehl, W. Grieskamp, J. Park, S. Kadir, M. Xu and E. Chung, “Fast and Reliable Formal Verification,” in Tools and Algorithms for the Construction and Analysis of Systems, D. FismandG. Rosu, Eds. Signet: Springer International, 2022, pp. 183 – 200.
[7] N. The Man Who Boomed (2021) Lost password locks up millionaire’s Bitcoin fortune. Available online: https://www.nytimes.co m / 2 0 2 1 / 0 1 / 1 2 / t e c h n o l o g y / b i t c o i n - p a s s w o r d s - w a l l e t s - f o r t u n e s . html
[8] Daily Team, "Status Synchronization and Submission Information" Verification Systems and Reconfiguration, "2020" Available online: https://github.com/aptos-labs/aptoscore/blob/main/documentation/tech-papers/lbft-verification/lbft-verification.pdf
[9] G . Danezis, L. Kokoris-Korgias, A. "Narwhals and Tusks: An Animal Based on Darkness." Proceedings of the 17th European Conference on Computer Systems. New York, New York, USA: Association for Computing Machinery, 2022, p. 34–50. Available online: https://doi.org/10.1145/3492321.3519594
[10] Diem Team, “Diary v4: State Machine Replication in Diary Blockchains” ”, 2021. Available online: https://dev.diem.com/papers/diem-consensus-state-machine-replication-in-the-diemblockchain/2021-0817.pdf
[11] S. Cohen, R . Gelashvili, L. Kokoris-Kogias, D. Marchi, A. Spiegelman, "Notes to Cole," Vol. abs/2110.00960, 2021. Available online: https://arxiv. org/abs/2110.00960
[12] A. Spiegelman, N. Giridharan. Sonino and L. "Basha: The Making of Dagbft Protocol" In the 20th Computer and Communications Security Conference (Chinese Chemical Society). Chinese Chemical Society '22. Los Angeles, CA, USA: Society for Computing Machinery, 2022.
[13] R. Glashvili. Spiegelman, Z. Xiang, G. Danezis, Z. Li, Y. Xia, R. Zhou and D. Malkhi, “Block-stm: Scaling blockchain execution by turning command curses into performance blessings,” 2022. Available online: https://arxiv.org/abs/2203.06871
[14] J. State Synchronization Evolution: Latency on the path to 100k+ transactions per second in aptos, 2022. Available online: https://media.com/aptoslabs/52e25a2c6f10
Editor: Felix
