diff --git a/developer-docs-site/docs/basics/basics-accounts.md b/developer-docs-site/docs/basics/basics-accounts.md index d14a3ccfe6e6b..09fe2c8c93f45 100755 --- a/developer-docs-site/docs/basics/basics-accounts.md +++ b/developer-docs-site/docs/basics/basics-accounts.md @@ -3,7 +3,7 @@ title: "Accounts" id: "basics-accounts" hidden: false --- -An account represents a resource on the Diem Blockchain that can send transactions. Each account is identified by a particular 16-byte account address and is a container for Move modules and Move resources. +An account represents a resource on the Aptos Blockchain that can send transactions. Each account is identified by a particular 16-byte account address and is a container for Move modules and Move resources. ## Introduction @@ -12,11 +12,11 @@ The state of each account comprises both code and data: - **Code**: Move modules contain code (type and procedure declarations), but they do not contain data. The module's procedures encode the rules for updating the blockchain's global state. - **Data**: Move resources contain data but no code. Every resource value has a type that is declared in a module published in the blockchain's distributed database. -An account may contain an arbitrary number of Move resources and Move modules. The Diem Payment Network (DPN) supports accounts created for Regulated Virtual Asset Service Providers [Regulated VASP](/reference/glossary#regulated-vasp) and Designated Dealers. +An account may contain an arbitrary number of Move resources and Move modules. The Aptos Payment Network (DPN) supports accounts created for Regulated Virtual Asset Service Providers [Regulated VASP](/reference/glossary#regulated-vasp) and Designated Dealers. ## Account address -A Diem account address is a 16-byte value. The account address is derived from a cryptographic hash of its public verification key concatenated with a signature scheme identifier byte. The Diem Blockchain supports two signature schemes:[Ed25519](/reference/glossary#ed25519) and MultiEd25519 (for multi-signature transactions). You will need the account's private key to sign a transaction. +A Aptos account address is a 16-byte value. The account address is derived from a cryptographic hash of its public verification key concatenated with a signature scheme identifier byte. The Aptos Blockchain supports two signature schemes:[Ed25519](/reference/glossary#ed25519) and MultiEd25519 (for multi-signature transactions). You will need the account's private key to sign a transaction. An account address is derived from its initial authentication key. @@ -39,30 +39,30 @@ Creating a K-of-N multisig authentication key is similar to creating a single si Every account on the DPN is created with at least two resources: -* [RoleId](https://github.com/diem/diem/blob/main/aptos-move/diem-framework/core/doc/Roles.md#resource-roleid), which grants the account a single, immutable [role](basics-accounts.md#account-roles) for [access control](https://github.com/diem/dip/blob/main/dips/dip-2.md). -* [DiemAccount](https://github.com/diem/diem/blob/main/aptos-move/diem-framework/core/doc/DiemAccount.md#resource-diemaccount), which holds the account’s [sequence number](/reference/glossary#sequence-number), authentication key, and event handles. +* [RoleId](https://github.com/aptos/aptos/blob/main/aptos-move/aptos-framework/core/doc/Roles.md#resource-roleid), which grants the account a single, immutable [role](basics-accounts.md#account-roles) for [access control](https://github.com/aptos/dip/blob/main/dips/dip-2.md). +* [AptosAccount](https://github.com/aptos/aptos/blob/main/aptos-move/aptos-framework/core/doc/AptosAccount.md#resource-aptosaccount), which holds the account’s [sequence number](/reference/glossary#sequence-number), authentication key, and event handles. ### Currencies The DPN supports an account transacting in different currencies. -From a standards perspective, [`Diem`](https://github.com/diem/diem/blob/main/aptos-move/diem-framework/core/doc/Diem.md#resource-diem) is the Diem Blockchain equivalent of [ERC20](https://eips.ethereum.org/EIPS/eip-20). At the Move level, these are different generic instantiations of the same Diem resource type (e.g., `Diem`, `Diem`). +From a standards perspective, [`Aptos`](https://github.com/aptos/aptos/blob/main/aptos-move/aptos-framework/core/doc/Aptos.md#resource-aptos) is the Aptos Blockchain equivalent of [ERC20](https://eips.ethereum.org/EIPS/eip-20). At the Move level, these are different generic instantiations of the same Aptos resource type (e.g., `Aptos`, `Aptos`). -`Diem` will be the currency type available at launch. +`Aptos` will be the currency type available at launch. ### Balances -A zero balance of `Diem` is added whenever `Diem` currency is authorized for an account. +A zero balance of `Aptos` is added whenever `Aptos` currency is authorized for an account. -Each non-administrative account stores one or more [Balance``](https://github.com/diem/diem/blob/main/aptos-move/diem-framework/core/doc/DiemAccount.md#resource-balance) resources. For each currency type that the account holds such as `Diem` or `Diem`, there will be a separate Balance resource such as Balance`>` or Balance`>`. +Each non-administrative account stores one or more [Balance``](https://github.com/aptos/aptos/blob/main/aptos-move/aptos-framework/core/doc/AptosAccount.md#resource-balance) resources. For each currency type that the account holds such as `Aptos` or `Aptos`, there will be a separate Balance resource such as Balance`>` or Balance`>`. When a client sends funds of type CoinType to an account, they should: * check if the account address exists * ensure that the account address has a balance in CoinType, even if that balance is zero. -To send and receive `Diem`, an account must have a balance in `Diem`. A transaction that sends `Diem` to an account without a balance in `Diem` will abort. +To send and receive `Aptos`, an account must have a balance in `Aptos`. A transaction that sends `Aptos` to an account without a balance in `Aptos` will abort. -Balances can be added either at account creation or subsequently via the [add_currency script](../transactions/txns-types/txns-manage-accounts.md#add-a-currency-to-an-account). Only the account owner can add new balances after account creation. Once you add a balance to an account, it cannot be removed. For example, an account that accepts `Diem` will always accept `Diem`. +Balances can be added either at account creation or subsequently via the [add_currency script](../transactions/txns-types/txns-manage-accounts.md#add-a-currency-to-an-account). Only the account owner can add new balances after account creation. Once you add a balance to an account, it cannot be removed. For example, an account that accepts `Aptos` will always accept `Aptos`. ## Account roles @@ -79,7 +79,7 @@ A ChildVASP knows the address of its ParentVASP. If off-chain communication is r ## Create accounts -When the Diem main network (mainnet) is launched, only the [TreasuryCompliance account](https://github.com/diem/dip/blob/main/dips/dip-2.md#roles) can create ParentVASP accounts. Once a ParentVASP account is created, the Regulated VASP can then create ChildVASP accounts. +When the Aptos main network (mainnet) is launched, only the [TreasuryCompliance account](https://github.com/aptos/dip/blob/main/dips/dip-2.md#roles) can create ParentVASP accounts. Once a ParentVASP account is created, the Regulated VASP can then create ChildVASP accounts. To create a new account, the creator must specify * the address of the new account diff --git a/developer-docs-site/docs/basics/basics-events.md b/developer-docs-site/docs/basics/basics-events.md index 1b82486419a09..6e766ed258a39 100755 --- a/developer-docs-site/docs/basics/basics-events.md +++ b/developer-docs-site/docs/basics/basics-events.md @@ -3,13 +3,13 @@ title: "Events" slug: "basics-events" hidden: false --- -Events are Move data that are emitted during the execution of a transaction on the Diem Blockchain. +Events are Move data that are emitted during the execution of a transaction on the Aptos Blockchain. -For example, whenever a payment transaction is sent or received on-chain, the transaction will emit the relevant data using the `SentPaymentEvent` and `ReceivedPaymentEvent`. This data is stored in the EventStore, which is part of the Diem Blockchain’s ledger state. You can query the EventStore to get proof of executed transactions on-chain. +For example, whenever a payment transaction is sent or received on-chain, the transaction will emit the relevant data using the `SentPaymentEvent` and `ReceivedPaymentEvent`. This data is stored in the EventStore, which is part of the Aptos Blockchain’s ledger state. You can query the EventStore to get proof of executed transactions on-chain. ## Introduction -Events are grouped into **event streams** based on event type. The Diem Framework uses different types of events for payments, minting/burning, and system operations. A detailed list of the event types accessible from JSON-RPC is available in the [JSON-RPC documentation](https://github.com/diem/diem/blob/main/json-rpc/docs/type_event.md). +Events are grouped into **event streams** based on event type. The Aptos Framework uses different types of events for payments, minting/burning, and system operations. A detailed list of the event types accessible from JSON-RPC is available in the [JSON-RPC documentation](https://github.com/aptos/aptos/blob/main/json-rpc/docs/type_event.md). ### Payment transaction events @@ -22,7 +22,7 @@ Both `SentPaymentEvent` and `ReceivedPaymentEvent` have the same structure: | Field Name | Type | Description | | ---------- | ------------------------------------------------------------ | ------------------------------------------------------------ | -| amount | [Amount](https://github.com/diem/diem/blob/main/json-rpc/docs/type_amount.md) | Amount received from the sender of the transaction | +| amount | [Amount](https://github.com/aptos/aptos/blob/main/json-rpc/docs/type_amount.md) | Amount received from the sender of the transaction | | sender | string | Hex-encoded address of the account whose balance was debited to perform this deposit. If the deposited funds came from a mint transaction, the sender address will be 0x0...0. | | receiver | string | Hex-encoded address of the account whose balance was credited by this deposit.
| | metadata | string | An optional field that can contain extra metadata for the event. This information can be used by an off-chain API to implement a sub-addressing scheme for a wallet. | @@ -42,18 +42,18 @@ There are also several events related to system-level operations, for example: * `UpgradeEvent` — when a special system maintenance WriteSet transaction is applied * `NewEpochEvent` — when an on-chain configuration is modified -* `NewBlockEvent` — when a new block of transactions is added to the Diem Blockchain +* `NewBlockEvent` — when a new block of transactions is added to the Aptos Blockchain ## Event concepts -![Figure 1.0 EventHandle and event streams in the Diem Framework](/img/docs/events-fig1.svg) -Figure 1.0 EventHandle and event streams in the Diem Framework +![Figure 1.0 EventHandle and event streams in the Aptos Framework](/img/docs/events-fig1.svg) +Figure 1.0 EventHandle and event streams in the Aptos Framework * **Event stream**: Events are grouped into “**event streams,**” which are append-only vectors of ContractEvent payloads. For example, an account can have a SentPaymentEvent stream and a ReceivePaymentEvent stream. The entries in an event stream are assigned sequence numbers beginning from zero. * **Event key**: Each event stream is associated with a key value, which is a globally unique 40-byte array that is defined when the stream is created. The event key for an account’s event stream will never be modified. -* **EventHandle**: An EventHandle contains the event key and the number of events in the stream. This count is always equal to the biggest sequence number for the events in the stream. An EventHandle resource is typically embedded inside other Move resources to record related events. For example, every DiemAccount resource contains a `sent_events` EventHandle for a SentPaymentEvents stream and also a `received_events` EventHandle for a ReceivedPaymentEvents stream. Event streams are referenced from the StateStore via EventHandle Move resources. +* **EventHandle**: An EventHandle contains the event key and the number of events in the stream. This count is always equal to the biggest sequence number for the events in the stream. An EventHandle resource is typically embedded inside other Move resources to record related events. For example, every AptosAccount resource contains a `sent_events` EventHandle for a SentPaymentEvents stream and also a `received_events` EventHandle for a ReceivedPaymentEvents stream. Event streams are referenced from the StateStore via EventHandle Move resources. * **ContractEvent**: A ContractEvent payload contains the event key, the sequence number, and a serialized Move value, along with a tag to identify the type of that value. Different kinds of events are distinguished by the Move value types, such as `SentPaymentEvent` or `ReceivedPaymentEvent`, which are emitted to the event streams. -The Event module in the Diem Framework specifies the details of event implementation in Move. The views of event information from JSON-RPC are often presented somewhat differently than the underlying implementation. For example, EventHandles are typically displayed as only the key values, e.g., `sent_events_key` instead of a `sent_events` EventHandle structure containing the key. This rest of this page shows examples of events as they are viewed through the JSON-RPC interface. +The Event module in the Aptos Framework specifies the details of event implementation in Move. The views of event information from JSON-RPC are often presented somewhat differently than the underlying implementation. For example, EventHandles are typically displayed as only the key values, e.g., `sent_events_key` instead of a `sent_events` EventHandle structure containing the key. This rest of this page shows examples of events as they are viewed through the JSON-RPC interface. ## How to query events @@ -65,31 +65,31 @@ There are several JSON-RPC API methods associated with events: ### Get `SentPaymentEvent` for an account This example demonstrates how to query a `SentPaymentEvent` for an account. In this example, account 0x996b67d has two event streams, with 3 sent payments and 2 received payments: -![Figure 1.1 Example event streams for a Diem Account](/img/docs/events-fig2.svg) -Figure 1.1 Example event streams for a Diem Account +![Figure 1.1 Example event streams for a Aptos Account](/img/docs/events-fig2.svg) +Figure 1.1 Example event streams for a Aptos Account -1. The first step is to find the event key for the account’s `SentPaymentEvent` stream. We can send a [`get_account`](https://github.com/diem/diem/blob/main/json-rpc/docs/method_get_account.md) -query to the JSON-RPC endpoint to get the state of that [`account`](https://github.com/diem/diem/blob/main/json-rpc/docs/type_account.md), including two event keys: one for the `SentPaymentEvent` stream (the `sent_events_key` field) and one for the `ReceivedPaymentEvent` stream (the `received_events_key` field). The response will look like the following: +1. The first step is to find the event key for the account’s `SentPaymentEvent` stream. We can send a [`get_account`](https://github.com/aptos/aptos/blob/main/json-rpc/docs/method_get_account.md) +query to the JSON-RPC endpoint to get the state of that [`account`](https://github.com/aptos/aptos/blob/main/json-rpc/docs/type_account.md), including two event keys: one for the `SentPaymentEvent` stream (the `sent_events_key` field) and one for the `ReceivedPaymentEvent` stream (the `received_events_key` field). The response will look like the following: ```json { - "diem_chain_id" : 2, + "aptos_chain_id" : 2, "jsonrpc" : "2.0", - "diem_ledger_timestampusec" : 1597084681499780, + "aptos_ledger_timestampusec" : 1597084681499780, "result": { "received_events_key": "00000000000000001668f6be25668c1a17cd8caf6b8d2f25", "sent_events_key": "01000000000000001668f6be25668c1a17cd8caf6b8d2f25", ... }, "id" : 1, - "diem_ledger_version" : 1303433 + "aptos_ledger_version" : 1303433 } ``` -2. The next step is to use the [`get_events`](https://github.com/diem/diem/blob/main/json-rpc/docs/method_get_events.md) API method to fetch the event details. In the JSON-RPC query, we can specify to fetch one event beginning with sequence number 2 from the `sent_events_key` event stream. The response will look like the following: +2. The next step is to use the [`get_events`](https://github.com/aptos/aptos/blob/main/json-rpc/docs/method_get_events.md) API method to fetch the event details. In the JSON-RPC query, we can specify to fetch one event beginning with sequence number 2 from the `sent_events_key` event stream. The response will look like the following: ```json { "id": 1, "jsonrpc": "2.0", - "diem_chain_id": 2, + "aptos_chain_id": 2, "result": [ { "data": { diff --git a/developer-docs-site/docs/basics/basics-fullnodes.md b/developer-docs-site/docs/basics/basics-fullnodes.md index bcd244b4fc696..755380bce2e6f 100755 --- a/developer-docs-site/docs/basics/basics-fullnodes.md +++ b/developer-docs-site/docs/basics/basics-fullnodes.md @@ -3,11 +3,11 @@ title: "FullNodes" slug: "basics-fullnodes" hidden: false --- -A Diem node is a peer entity of the Diem ecosystem that tracks the [state](/reference/glossary#state) of the Diem Blockchain. Clients interact with the blockchain via Diem nodes. There are two types of nodes: +A Aptos node is a peer entity of the Aptos ecosystem that tracks the [state](/reference/glossary#state) of the Aptos Blockchain. Clients interact with the blockchain via Aptos nodes. There are two types of nodes: * [Validator nodes](basics-validator-nodes.md) * FullNodes -Each Diem node comprises several logical components: +Each Aptos node comprises several logical components: * [JSON-RPC service](/reference/glossary#json-rpc-service) (disabled in validator nodes) * [Mempool](basics-validator-nodes.md#mempool) * [Consensus](basics-validator-nodes.md#consensus) @@ -16,22 +16,22 @@ Each Diem node comprises several logical components: * [Storage](basics-validator-nodes.md#storage) * [State synchronizer](basics-validator-nodes.md#state-synchronizer) -The [Diem Core](/reference/glossary#diem-core) software can be configured to run as a validator node or as a FullNode. +The [Aptos Core](/reference/glossary#aptos-core) software can be configured to run as a validator node or as a FullNode. ## Introduction -FullNodes can be run by anyone who wants to verify the state of the Diem Blockchain and synchronize to it. FullNodes replicate the full state of the blockchain by querying each other or by querying the validator nodes directly. They can also accept transactions submitted by Diem clients and forward them to validator nodes. +FullNodes can be run by anyone who wants to verify the state of the Aptos Blockchain and synchronize to it. FullNodes replicate the full state of the blockchain by querying each other or by querying the validator nodes directly. They can also accept transactions submitted by Aptos clients and forward them to validator nodes. Additionally, FullNodes are an external validation resource for finalized transaction history. They receive transactions from upstream nodes and then re-execute them locally (the same way a validator node executes transactions). FullNodes store the results of the re-execution to local storage. In doing so, they will notice and can provide evidence if there is any attempt to rewrite history. This helps to ensure that the validator nodes are not colluding on arbitrary transaction execution. ## Public FullNodes -A public FullNode uses the same software as a validator node and connects directly to one or more validator nodes to submit transactions and synchronize to the [state](/reference/glossary#state) of the Diem Blockchain. +A public FullNode uses the same software as a validator node and connects directly to one or more validator nodes to submit transactions and synchronize to the [state](/reference/glossary#state) of the Aptos Blockchain. -A public FullNode has all Diem node components, with the consensus component being disabled. +A public FullNode has all Aptos node components, with the consensus component being disabled. Third-party blockchain explorers, wallets, exchanges, and DApps may run a local FullNode to: * Leverage the JSON-RPC protocol for richer blockchain interactions. -* Get a consistent view of the Diem Payment Network. +* Get a consistent view of the Aptos Payment Network. * Avoid rate limitations on read traffic. * Run custom analytics on historical data. * Get notifications about particular on-chain events. diff --git a/developer-docs-site/docs/basics/basics-gas-txn-fee.md b/developer-docs-site/docs/basics/basics-gas-txn-fee.md index 5d040a2f285ae..780c2a0b0582d 100755 --- a/developer-docs-site/docs/basics/basics-gas-txn-fee.md +++ b/developer-docs-site/docs/basics/basics-gas-txn-fee.md @@ -5,13 +5,13 @@ hidden: false --- import BlockQuote from "@site/src/components/BlockQuote"; -When a transaction is executed in the Diem Payment Network (DPN), the network resources used are tracked and measured using gas. +When a transaction is executed in the Aptos Payment Network (DPN), the network resources used are tracked and measured using gas. ## Introduction -Gas ensures that all Move programs running on the Diem Blockchain terminate. This bounds the computational resources used. Gas also provides the ability to charge a transaction fee, partly based on consumed resources during execution. +Gas ensures that all Move programs running on the Aptos Blockchain terminate. This bounds the computational resources used. Gas also provides the ability to charge a transaction fee, partly based on consumed resources during execution. -When a client submits a transaction for execution to the Diem Blockchain, it contains a specified: +When a client submits a transaction for execution to the Aptos Blockchain, it contains a specified: * `max_gas_amount`: The maximum amount of gas units that can be used to execute a transaction. This bounds the computational resources that can be consumed by a transaction. * `gas_price`: The number of gas units used in the specified gas currency. Gas price is a way to move from gas units, the abstract units of resource consumption the virtual machine (VM) uses, into a transaction fee in the specified gas currency. @@ -28,7 +28,7 @@ For the VM to execute a transaction, the gas system needs to track the primary r 1. The computational cost of executing the transaction. 2. The network cost of sending the transaction over the DPN. -3. The storage cost of data created and read during the transaction on the Diem Blockchain. +3. The storage cost of data created and read during the transaction on the Aptos Blockchain. The first two of these resources (computational and network) are ephemeral. On the other hand, storage is long lived. Once data is allocated, that data persists until it is deleted. In the case of accounts, the data lives indefinitely. @@ -55,20 +55,20 @@ After the prologue has run, and we've checked in part that the account can cover * The transaction execution is complete, after which the cost of storing the transaction data is charged, and the epilogue is run and the execution fee deducted, or * The "gas tank" becomes empty, in which case an `OutOfGas` error is raised. -In the former, the fee is collected and the result of the transaction is persisted on the Diem Blockchain. The latter causes the execution of the transaction to stop when the error is raised, following which the total gas liability of the transaction is collected. No other remnants of the execution are committed other than the deduction in this case. +In the former, the fee is collected and the result of the transaction is persisted on the Aptos Blockchain. The latter causes the execution of the transaction to stop when the error is raised, following which the total gas liability of the transaction is collected. No other remnants of the execution are committed other than the deduction in this case. ## Using gas to prioritize a transaction When you send a transaction, it is prioritized based on different criteria. One of these is the normalized gas price for the transaction. -For transactions that are subject to ordering by gas price (i.e., non-governance transactions) these prices are first normalized to Diem Coins. This is done by using the current gas currency to Diem Coin conversion rate that is stored on-chain. Transactions are then ranked (in part) based upon this normalized gas price. +For transactions that are subject to ordering by gas price (i.e., non-governance transactions) these prices are first normalized to Aptos Coins. This is done by using the current gas currency to Aptos Coin conversion rate that is stored on-chain. Transactions are then ranked (in part) based upon this normalized gas price. For example: * Bob sends a transaction with `gas_price` 10 and `gas_currency` of “BobCoins”. * Alice sends a transaction at the same time with `gas_price` 20 and `gas_currency` of “AliceCoins”. -If the on-chain “BobCoins” to Diem Coins exchange rate is 2.1 and the on-chain “AliceCoins” to Diem Coins exchange rate is 1, +If the on-chain “BobCoins” to Aptos Coins exchange rate is 2.1 and the on-chain “AliceCoins” to Aptos Coins exchange rate is 1, * Bob’s transaction has a normalized gas price of `10 * 2.1 = 21`. * Alice’s transaction has a normalized gas price of `20 * 1 = 20`. diff --git a/developer-docs-site/docs/basics/basics-merkle-proof.md b/developer-docs-site/docs/basics/basics-merkle-proof.md index df905eda7933c..05ffd90593a47 100755 --- a/developer-docs-site/docs/basics/basics-merkle-proof.md +++ b/developer-docs-site/docs/basics/basics-merkle-proof.md @@ -4,9 +4,9 @@ slug: "basics-merkle-proof" hidden: false --- -A proof is a way to verify the truth of data in the Diem Blockchain. +A proof is a way to verify the truth of data in the Aptos Blockchain. -All data in the Diem Blockchain is stored in a single-version distributed database. A validator node's [storage component](basics-validator-nodes.md#storage) is used to persist agreed upon blocks of transactions and their execution results. The blockchain is represented as an ever-growing [Merkle tree](/reference/glossary#merkle-trees). A “leaf” is appended to the tree for each transaction executed on the blockchain. +All data in the Aptos Blockchain is stored in a single-version distributed database. A validator node's [storage component](basics-validator-nodes.md#storage) is used to persist agreed upon blocks of transactions and their execution results. The blockchain is represented as an ever-growing [Merkle tree](/reference/glossary#merkle-trees). A “leaf” is appended to the tree for each transaction executed on the blockchain. Every operation stored on the blockchain can be verified cryptographically. The resultant proof also proves that the validator nodes all agreed on the state at that time. For example, if the client queried the latest _n_ transactions from an account, the proof verifies that no transactions are added, omitted, or modified from the query response. diff --git a/developer-docs-site/docs/basics/basics-node-networks-sync.md b/developer-docs-site/docs/basics/basics-node-networks-sync.md index 2406ea77c19f0..a75bb285e738e 100755 --- a/developer-docs-site/docs/basics/basics-node-networks-sync.md +++ b/developer-docs-site/docs/basics/basics-node-networks-sync.md @@ -5,10 +5,10 @@ hidden: false --- In this page, you will learn about: * Types of node networks -* How and when a Diem node synchronizes to the latest state of the Diem Blockchain +* How and when a Aptos node synchronizes to the latest state of the Aptos Blockchain ## Node networks -Depending on their configuration, Diem nodes can form different peer-to-peer state synchronization networks. Each Diem node can participate in multiple networks as shown in the figure below. +Depending on their configuration, Aptos nodes can form different peer-to-peer state synchronization networks. Each Aptos node can participate in multiple networks as shown in the figure below. * Validator node network * Public FullNode network @@ -16,13 +16,13 @@ Validator nodes and public FullNodes form a two-tiered architecture. A public Fu ![v-fn-network.svg](/img/docs/v-fn-network.svg) ### Separate network stacks -For each type of Diem node, the Diem Payment Network (DPN) has a separate network stack. The advantages of having separate network stacks include: +For each type of Aptos node, the Aptos Payment Network (DPN) has a separate network stack. The advantages of having separate network stacks include: * Clean separation between the different networks. * Better support for security preferences (bidirectional vs server authentication). * Allowance for isolated discovery protocols (on-chain discovery for validator node's public endpoint vs manual configuration for private organizations). ## Node synchronization -A Diem node synchronizes to the latest state of the Diem Blockchain when: +A Aptos node synchronizes to the latest state of the Aptos Blockchain when: * It comes online for the first time (bootstrap). * It restarts. * It comes online after being offline for some time. @@ -30,11 +30,11 @@ A Diem node synchronizes to the latest state of the Diem Blockchain when: * FullNodes synchronize with their upstream nodes continuously during a normal workload. ### State synchronizer -Each Diem node contains a State Synchronizer (SS) component which is used to synchronize the state of a node to its upstream peers. This component has the same function for all types of Diem nodes. It utilizes the dedicated peer-to-peer network stack to perform synchronization and it uses a long-polling API. +Each Aptos node contains a State Synchronizer (SS) component which is used to synchronize the state of a node to its upstream peers. This component has the same function for all types of Aptos nodes. It utilizes the dedicated peer-to-peer network stack to perform synchronization and it uses a long-polling API. The upstream peers that are used for synchronizing to the latest state of the blockchain are different for each type of node: * Validator nodes use the validator node network. * Public FullNodes can either use the initial set of peers or the validator nodes that are open for public access. ### Synchronization API -The Diem node's state synchronizer communicates with the upstream nodes' state synchronizers to get chunks of transactions to synchronize with the current state of the Diem Blockchain. Learn more about how this works in the specifications [here](https://github.com/diem/diem/tree/main/specifications/state_sync). +The Aptos node's state synchronizer communicates with the upstream nodes' state synchronizers to get chunks of transactions to synchronize with the current state of the Aptos Blockchain. Learn more about how this works in the specifications [here](https://github.com/aptos/aptos/tree/main/specifications/state_sync). diff --git a/developer-docs-site/docs/basics/basics-txns-states.md b/developer-docs-site/docs/basics/basics-txns-states.md index 038b842c7f5ad..d623dc9f3dead 100755 --- a/developer-docs-site/docs/basics/basics-txns-states.md +++ b/developer-docs-site/docs/basics/basics-txns-states.md @@ -3,17 +3,17 @@ title: "Transactions and states" slug: "basics-txns-states" hidden: false --- -The two fundamental concepts at the heart of the Diem Blockchain are +The two fundamental concepts at the heart of the Aptos Blockchain are -* [Transactions](#transactions): Transactions represent the exchange of data and Diem Coins between any two accounts on the Diem Blockchain. +* [Transactions](#transactions): Transactions represent the exchange of data and Aptos Coins between any two accounts on the Aptos Blockchain. * [States](#ledger-state): The ledger state (state) represents the current snapshot of data on the blockchain. At any point in time, the blockchain has a ledger state. -When a submitted transaction is executed, the state of the Diem Blockchain changes. +When a submitted transaction is executed, the state of the Aptos Blockchain changes. ## Transactions -When a Diem Blockchain participant submits a transaction, they are requesting the ledger state to be updated with their transaction information. +When a Aptos Blockchain participant submits a transaction, they are requesting the ledger state to be updated with their transaction information. A [signed transaction](/reference/glossary#transaction) on the blockchain contains the following information: @@ -34,11 +34,11 @@ A [signed transaction](/reference/glossary#transaction) on the blockchain contai ## Ledger state -The Diem Blockchain's ledger state or global [state](/reference/glossary#state) comprises the state of all accounts in the blockchain. Each validator node in the blockchain must know the global state of the latest version of the blockchain's distributed database (versioned database) to execute any transaction. +The Aptos Blockchain's ledger state or global [state](/reference/glossary#state) comprises the state of all accounts in the blockchain. Each validator node in the blockchain must know the global state of the latest version of the blockchain's distributed database (versioned database) to execute any transaction. ### Versioned database -All of the data in the Diem Blockchain is persisted in a single-versioned distributed database. A version number is an unsigned 64-bit integer that corresponds to the number of transactions the system has executed. +All of the data in the Aptos Blockchain is persisted in a single-versioned distributed database. A version number is an unsigned 64-bit integer that corresponds to the number of transactions the system has executed. This versioned database allows validator nodes to: @@ -52,14 +52,14 @@ This versioned database allows validator nodes to: ![FIGURE 1.0 TRANSACTIONS CHANGE STATE](/img/docs/transactions.svg) FIGURE 1.0 TRANSACTIONS CHANGE STATE -Figure 1.0 represents how executing transaction TN changes the state of the Diem Blockchain from SN-1 to SN. +Figure 1.0 represents how executing transaction TN changes the state of the Aptos Blockchain from SN-1 to SN. In the figure: | Name | Description | | ---- | ----------- | -| Accounts **A** and **B** | Represent Alice's and Bob's accounts on the Diem Blockchain | -| SN-1 | Represents the (N-1)th state of the blockchain. In this state, Alice's account A has a balance of 110 Diem Coins, and Bob's account B has a balance of 52 Diem Coins. | -| TN | This is the n-th transaction executed on the blockchain. In this example, it represents Alice sending 10 Diem Coins to Bob. | -| **F** | It is a deterministic function. F always returns the same final state for a specific initial state and a specific transaction. If the current state of the blockchain is SN-1, and transaction TN is executed on state SN-1, the new state of the blockchain is always SN. The Diem Blockchain uses the [Move language](https://diem.github.io/move) to implement the deterministic execution function F. | -| **SN** | This is the n-th state of the blockchain. When the transaction TN is applied to the blockchain, it generates the new state SN (an outcome of applying F to SN-1 and TN). This causes Alice’s account balance to be reduced by 10 to 100 Diem Coins and Bob’s account balance to be increased by 10 to 62 Diem Coins. The new state SN shows these updated balances. | +| Accounts **A** and **B** | Represent Alice's and Bob's accounts on the Aptos Blockchain | +| SN-1 | Represents the (N-1)th state of the blockchain. In this state, Alice's account A has a balance of 110 Aptos Coins, and Bob's account B has a balance of 52 Aptos Coins. | +| TN | This is the n-th transaction executed on the blockchain. In this example, it represents Alice sending 10 Aptos Coins to Bob. | +| **F** | It is a deterministic function. F always returns the same final state for a specific initial state and a specific transaction. If the current state of the blockchain is SN-1, and transaction TN is executed on state SN-1, the new state of the blockchain is always SN. The Aptos Blockchain uses the [Move language](https://aptos.github.io/move) to implement the deterministic execution function F. | +| **SN** | This is the n-th state of the blockchain. When the transaction TN is applied to the blockchain, it generates the new state SN (an outcome of applying F to SN-1 and TN). This causes Alice’s account balance to be reduced by 10 to 100 Aptos Coins and Bob’s account balance to be increased by 10 to 62 Aptos Coins. The new state SN shows these updated balances. | diff --git a/developer-docs-site/docs/basics/basics-validator-nodes.md b/developer-docs-site/docs/basics/basics-validator-nodes.md index 79015dd7ddd23..90c629e734f09 100755 --- a/developer-docs-site/docs/basics/basics-validator-nodes.md +++ b/developer-docs-site/docs/basics/basics-validator-nodes.md @@ -5,11 +5,11 @@ hidden: false --- import BlockQuote from "@site/src/components/BlockQuote"; -A Diem node is a peer entity of the Diem ecosystem that tracks the [state](/reference/glossary#state) of the Diem Blockchain. Clients interact with the blockchain via Diem nodes. There are two types of nodes: +A Aptos node is a peer entity of the Aptos ecosystem that tracks the [state](/reference/glossary#state) of the Aptos Blockchain. Clients interact with the blockchain via Aptos nodes. There are two types of nodes: * Validator nodes * [FullNodes](basics-fullnodes.md) -Each Diem node comprises several logical components: +Each Aptos node comprises several logical components: * [JSON-RPC service](/reference/glossary#json-rpc-service) (disabled in validator nodes) * [Mempool](#mempool) * [Consensus (disabled in FullNodes)](#consensus) @@ -18,23 +18,23 @@ Each Diem node comprises several logical components: * [Storage](#storage) * [State synchronizer](#state-synchronizer) -The [Diem Core](/reference/glossary#diem-core) software can be configured to run as a validator node or as a FullNode. +The [Aptos Core](/reference/glossary#aptos-core) software can be configured to run as a validator node or as a FullNode. ## Introduction -When a transaction is submitted to the Diem Blockchain, validator nodes run a distributed [consensus protocol](/reference/glossary#consensus-protocol), execute the transaction, and store the transaction and the execution results on the blockchain. Validator nodes decide which transactions will be added to the blockchain and in which order. +When a transaction is submitted to the Aptos Blockchain, validator nodes run a distributed [consensus protocol](/reference/glossary#consensus-protocol), execute the transaction, and store the transaction and the execution results on the blockchain. Validator nodes decide which transactions will be added to the blockchain and in which order. -The Diem Payment Network uses a Byzantine Fault Tolerance (BFT) consensus protocol for validator nodes to agree on the ledger of finalized transactions and their execution. Validator nodes process these transactions to include them in the blockchain’s database, which they maintain. This means that validator nodes always have the current [state](/reference/glossary#state) of the blockchain. +The Aptos Payment Network uses a Byzantine Fault Tolerance (BFT) consensus protocol for validator nodes to agree on the ledger of finalized transactions and their execution. Validator nodes process these transactions to include them in the blockchain’s database, which they maintain. This means that validator nodes always have the current [state](/reference/glossary#state) of the blockchain. -A validator node communicates directly with other validator nodes over a hidden network. It may be configured to store either all or part of the historical data from the Diem Blockchain. [FullNodes](basics-fullnodes.md) are an external validation resource for finalized transaction history. They receive transactions from upstream nodes and then re-execute them locally (the same way a validator node executes transactions). FullNodes store the results of the re-execution to local storage. In doing so, they will notice and can provide evidence if there is any attempt to rewrite history. This helps to ensure that the validator nodes are not colluding on arbitrary transaction execution. +A validator node communicates directly with other validator nodes over a hidden network. It may be configured to store either all or part of the historical data from the Aptos Blockchain. [FullNodes](basics-fullnodes.md) are an external validation resource for finalized transaction history. They receive transactions from upstream nodes and then re-execute them locally (the same way a validator node executes transactions). FullNodes store the results of the re-execution to local storage. In doing so, they will notice and can provide evidence if there is any attempt to rewrite history. This helps to ensure that the validator nodes are not colluding on arbitrary transaction execution.
-The DiemBFT consensus protocol provides fault tolerance of up to one-third of malicious validator nodes. +The AptosBFT consensus protocol provides fault tolerance of up to one-third of malicious validator nodes.
## Validator node components -Each Diem node comprises several logical components: +Each Aptos node comprises several logical components: * [JSON-RPC service](/reference/glossary#json-rpc-service) (disabled in validator nodes) * [Mempool](#mempool) * [Consensus (disabled in FullNodes)](#consensus) @@ -49,7 +49,7 @@ Each Diem node comprises several logical components: Mempool is a validator node component that holds an in-memory buffer of transactions that have been submitted but not yet agreed upon and executed. This buffer is replicated between validator nodes. -The JSON-RPC service of a FullNode sends transactions to a validator node's mempool. Mempool performs initial checks on the requests to protect the other parts of the validator node from corrupt or high volume input. When a new transaction passes the initial checks and is added to the mempool, it is then shared to the mempools of other validator nodes in the Diem Payment Network. +The JSON-RPC service of a FullNode sends transactions to a validator node's mempool. Mempool performs initial checks on the requests to protect the other parts of the validator node from corrupt or high volume input. When a new transaction passes the initial checks and is added to the mempool, it is then shared to the mempools of other validator nodes in the Aptos Payment Network. When a validator node is the leader, its consensus component pulls the transactions from its mempool and proposes the order of the transactions that form a block. The validator quorum then votes on the proposal. diff --git a/developer-docs-site/docs/intro.md b/developer-docs-site/docs/intro.md index 4b75225ef8cd5..d0bbf89eae158 100644 --- a/developer-docs-site/docs/intro.md +++ b/developer-docs-site/docs/intro.md @@ -10,6 +10,6 @@ sidebar_position: 1 TODO: Let's put things here *that highlight some stuff* ```bash -git clone diem or something +git clone aptos or something ``` You can type this command into Command Prompt, Powershell, Terminal, or any other integrated terminal of your code editor. diff --git a/developer-docs-site/docs/reference/glossary.md b/developer-docs-site/docs/reference/glossary.md index 744c4f66ba59f..229fa760378f0 100755 --- a/developer-docs-site/docs/reference/glossary.md +++ b/developer-docs-site/docs/reference/glossary.md @@ -13,17 +13,17 @@ hidden: false ### Access path - An **access path** specifies the location of a resource or Move module within a specific account. -- In a state of the Diem Blockchain, an account is represented as a map of access paths to values. The Move VM deserializes this representation into modules and resources. +- In a state of the Aptos Blockchain, an account is represented as a map of access paths to values. The Move VM deserializes this representation into modules and resources. - Clients can use access paths to request a resource or a specific piece of data stored inside a resource. ### Account -- An **account** in the Diem Blockchain is a container for an arbitrary number of [Move modules](#move-module) and [Move resources](#move-resources). This essentially means that the state of each account is comprised of both code and data. +- An **account** in the Aptos Blockchain is a container for an arbitrary number of [Move modules](#move-module) and [Move resources](#move-resources). This essentially means that the state of each account is comprised of both code and data. - The account is identified by an [account address](#account-address). ### Account Address -- The address of a Diem payment system account is a 16-byte value. Users can claim addresses using digital signatures. The account address is derived from a cryptographic hash of a user’s public verification key concatenated with a signature scheme identifier byte. The Diem payment system supports two signature schemes: Ed25519 (for single-signature transactions) and MultiEd25519 (for multi-signature transactions). To sign a transaction sent from an account address, the user, or the custodial client representing the user, must use the private key that corresponds to that account. +- The address of a Aptos payment system account is a 16-byte value. Users can claim addresses using digital signatures. The account address is derived from a cryptographic hash of a user’s public verification key concatenated with a signature scheme identifier byte. The Aptos payment system supports two signature schemes: Ed25519 (for single-signature transactions) and MultiEd25519 (for multi-signature transactions). To sign a transaction sent from an account address, the user, or the custodial client representing the user, must use the private key that corresponds to that account. ### Authentication Key @@ -36,13 +36,13 @@ hidden: false ### Block -- A **proposed block** on the Diem Blockchain is an ordered list of zero or more transactions proposed by the consensus leader for validators to reach agreement on execution through consensus. -- A **committed block** is an ordered list of zero or more transactions from a proposed block for which agreement on execution has been reached through consensus and which is recorded to the Diem Blockchain. +- A **proposed block** on the Aptos Blockchain is an ordered list of zero or more transactions proposed by the consensus leader for validators to reach agreement on execution through consensus. +- A **committed block** is an ordered list of zero or more transactions from a proposed block for which agreement on execution has been reached through consensus and which is recorded to the Aptos Blockchain. ### Blockchain - A **blockchain** is a distributed public ledger. -- The Diem Blockchain is a single data structure that records the history of transactions and states over time. +- The Aptos Blockchain is a single data structure that records the history of transactions and states over time. ### Byzantine (Validator) @@ -52,8 +52,8 @@ hidden: false ### Byzantine Fault Tolerance (BFT) - **Byzantine Fault Tolerance** (BFT) is the ability of a distributed system to provide safety and liveness guarantees in the presence of faulty, or “[Byzantine](#byzantine-validator),” validators below a certain threshold. -- The Diem Blockchain uses DiemBFT, a consensus protocol based on [HotStuff.](#hotstuff) -- BFT algorithms typically operate with a number of entities, collectively holding N votes (which are called “validators” in the Diem network’s application of the system). +- The Aptos Blockchain uses AptosBFT, a consensus protocol based on [HotStuff.](#hotstuff) +- BFT algorithms typically operate with a number of entities, collectively holding N votes (which are called “validators” in the Aptos network’s application of the system). - N is chosen to withstand some number of validators holding f votes, which might be malicious. - In this configuration, N is typically set to 3f+1. Validators holding up to f votes will be allowed to be faulty — offline, malicious, slow, etc. As long as 2f+1 votes are held by [honest](#honest-validator) validators, they will be able to reach consensus on consistent decisions. - This implies that BFT consensus protocols can function correctly, even if up to one-third of the voting power is held by validators that are compromised or fail. @@ -66,17 +66,17 @@ The ChildVASP account is the child of your ParentVASP account. A ChildVASP accou ### Client -A **client** is a piece of software that has the capability to interact with the Diem Blockchain. +A **client** is a piece of software that has the capability to interact with the Aptos Blockchain. -- It can allow the user to construct, sign, and submit new transactions to the JSON-RPC service component of a Diem node. -- It can issue queries to the Diem Blockchain and request the status of a transaction or account. +- It can allow the user to construct, sign, and submit new transactions to the JSON-RPC service component of a Aptos node. +- It can issue queries to the Aptos Blockchain and request the status of a transaction or account. - Currently, a client can be run on behalf of the end user (for example, for a custodial wallet). ### Consensus - **Consensus** is a component of a validator. - The consensus component is responsible for coordination and agreement amongst all validators on the block of transactions to be executed, their order, and the execution results. -- The Diem Blockchain is formed with these agreed-upon transactions and their corresponding execution results. +- The Aptos Blockchain is formed with these agreed-upon transactions and their corresponding execution results. ### Consensus Protocol @@ -92,48 +92,48 @@ A **client** is a piece of software that has the capability to interact with the ### Designated Dealer -A Designated Dealer is a regulated, well-capitalized financial institution that has the right, pursuant to a contract with Diem Networks, to purchase Diem Coins from, and to sell them to, Diem Networks in minting and burning transactions. Designated Dealers facilitate liquidity in Diem Coins for other DPN participants, such that Diem Coins are readily available to [Regulated VASP](#regulated-vasp) participants and through Regulated VASP participants to end users. +A Designated Dealer is a regulated, well-capitalized financial institution that has the right, pursuant to a contract with Aptos Networks, to purchase Aptos Coins from, and to sell them to, Aptos Networks in minting and burning transactions. Designated Dealers facilitate liquidity in Aptos Coins for other DPN participants, such that Aptos Coins are readily available to [Regulated VASP](#regulated-vasp) participants and through Regulated VASP participants to end users. -### DiemBFT +### AptosBFT -- DiemBFT is the Diem protocol's BFT consensus algorithm. -- DiemBFT is based on HotStuff. +- AptosBFT is the Aptos protocol's BFT consensus algorithm. +- AptosBFT is based on HotStuff. -### Diem Blockchain +### Aptos Blockchain -- The **Diem Blockchain** is a ledger of immutable transactions agreed upon by the validators on the Diem network (the network of validators). +- The **Aptos Blockchain** is a ledger of immutable transactions agreed upon by the validators on the Aptos network (the network of validators). -### Diem Core +### Aptos Core -Diem Core is the open source technology on which the Diem Payment Network runs. Diem Core contains software for +Aptos Core is the open source technology on which the Aptos Payment Network runs. Aptos Core contains software for -* the Diem Blockchain itself, which generates and stores the immutable ledger of confirmed transactions and -* the validation process, which implements the consensus algorithm to validate transactions and add them to the Diem Blockchain immutable ledger. +* the Aptos Blockchain itself, which generates and stores the immutable ledger of confirmed transactions and +* the validation process, which implements the consensus algorithm to validate transactions and add them to the Aptos Blockchain immutable ledger. -### Diem Framework -The Diem Framework defines the public API for blockchain updates and the structure of on-chain data. It defines the business logic and access control for the three key pillars of Diem functionality: payments, treasury, and on-chain governance. It is implemented as a set of modules written in the Move programming language and stored on-chain as Move bytecode. +### Aptos Framework +The Aptos Framework defines the public API for blockchain updates and the structure of on-chain data. It defines the business logic and access control for the three key pillars of Aptos functionality: payments, treasury, and on-chain governance. It is implemented as a set of modules written in the Move programming language and stored on-chain as Move bytecode. -### Diem node -A Diem node is a peer entity of the Diem network that tracks the state of the Diem Blockchain. There are two types of Diem nodes, [validators](#validator) and [FullNodes](#fullnode)). +### Aptos node +A Aptos node is a peer entity of the Aptos network that tracks the state of the Aptos Blockchain. There are two types of Aptos nodes, [validators](#validator) and [FullNodes](#fullnode)). -### Diem Protocol +### Aptos Protocol -- **Diem protocol** is the specification of how transactions are submitted, ordered, executed, and recorded within the Diem network. +- **Aptos protocol** is the specification of how transactions are submitted, ordered, executed, and recorded within the Aptos network. -### DiemAccount.T +### AptosAccount.T -- A **`DiemAccount.T`** is a Move resource that holds all the administrative data associated with an account, such as sequence number, balance, and authentication key. -- A **`DiemAccount.T`** is the only resource that every account is guaranteed to contain. +- A **`AptosAccount.T`** is a Move resource that holds all the administrative data associated with an account, such as sequence number, balance, and authentication key. +- A **`AptosAccount.T`** is the only resource that every account is guaranteed to contain. -### DiemAccount module +### AptosAccount module -- **The DiemAccount module** is a Move module that contains the code for manipulating the administrative data held in a particular `DiemAccount.T` resource. -- Code for checking or incrementing sequence numbers, withdrawing or depositing currency, and extracting gas deposits is included in the DiemAccount module. +- **The AptosAccount module** is a Move module that contains the code for manipulating the administrative data held in a particular `AptosAccount.T` resource. +- Code for checking or incrementing sequence numbers, withdrawing or depositing currency, and extracting gas deposits is included in the AptosAccount module. -### Diem testnet +### Aptos testnet - See [testnet](#testnet). @@ -143,7 +143,7 @@ A Diem node is a peer entity of the Diem network that tracks the state of the Di ### Ed25519 - **Ed25519** is our supported digital signature scheme. -- More specifically, the Diem network uses the PureEdDSA scheme over the Ed25519 curve, as defined in RFC 8032. +- More specifically, the Aptos network uses the PureEdDSA scheme over the Ed25519 curve, as defined in RFC 8032. ### Epoch @@ -154,7 +154,7 @@ A Diem node is a peer entity of the Diem network that tracks the state of the Di - An **event** is the user-facing representation of the effects of executing a transaction. - A transaction may be designed to emit any number of events as a list. For example, a peer-to-peer payment transaction emits a `SentPaymentEvent` for the sender account and a `ReceivedPaymentEvent` for the recipient account. -- In the Diem protocol, events provide evidence that the successful execution of a transaction resulted in a specific effect. The `ReceivedPaymentEvent` (in the above example) allows the recipient to confirm that a payment was received into their account. +- In the Aptos protocol, events provide evidence that the successful execution of a transaction resulted in a specific effect. The `ReceivedPaymentEvent` (in the above example) allows the recipient to confirm that a payment was received into their account. - Events are persisted on the blockchain and are used to answer queries by [clients](#client). ### Execution Result @@ -179,7 +179,7 @@ then there is a guarantee that T_N will never be included in the blockchain. ### Faucet -- **Faucet** is the way to create Diem currency with no real-world value, only on our testnet. +- **Faucet** is the way to create Aptos currency with no real-world value, only on our testnet. - The Faucet is a service running along with the testnet. This service only exists to facilitate minting coins for the testnet. - You can use the Faucet by sending a request to create coins and transfer them into a given account on your behalf. @@ -199,7 +199,7 @@ These are FullNodes used by DPN Participants to forward transactions to the vali ### Gas -- **Gas** is a way to pay for computation and storage on a blockchain network. All transactions on the Diem network cost a certain amount of gas. +- **Gas** is a way to pay for computation and storage on a blockchain network. All transactions on the Aptos network cost a certain amount of gas. - The gas required for a transaction depends on the size of the transaction, the computational cost of executing the transaction, and the amount of additional global state created by the transaction (e.g., if new accounts are created). - The purpose of gas is regulating demand for the limited computational and storage resources of the validators, including preventing denial of service (DoS) attacks. @@ -218,14 +218,14 @@ These are FullNodes used by DPN Participants to forward transactions to the vali ### HotStuff - **HotStuff** is a recent proposal for a [BFT](#byzantine-fault-tolerance-bft) consensus protocol. -- DiemBFT, the Diem network's consensus algorithm, is based on HotStuff. +- AptosBFT, the Aptos network's consensus algorithm, is based on HotStuff. - It simplifies the reasoning about safety, and it addresses some performance limitations of previous consensus protocols. ## J ### JSON-RPC Service -- The JSON-RPC Service component is the external interface of a Diem node. Any incoming client request, such as submitted transactions or queries, must first go through the JSON-RPC Service. A client needs to go through the JSON-RPC Service component to access storage or any other component in the system. This filters requests and protects the system. +- The JSON-RPC Service component is the external interface of a Aptos node. Any incoming client request, such as submitted transactions or queries, must first go through the JSON-RPC Service. A client needs to go through the JSON-RPC Service component to access storage or any other component in the system. This filters requests and protects the system. - Whenever a client submits a new transaction, the JSON-RPC Service passes it to [mempool](#mempool). @@ -242,7 +242,7 @@ These are FullNodes used by DPN Participants to forward transactions to the vali ## M ### Mainnet -The production network for the Diem Payment Network. +The production network for the Aptos Payment Network. ### Maximum Gas Amount @@ -254,26 +254,26 @@ The production network for the Diem Payment Network. ### Mempool - **Mempool** is one of the components of the validator. It holds an in-memory buffer of transactions that have been submitted but not yet agreed upon and executed. Mempool receives transactions from [JSON-RPC Service](#json-rpc-service). -- Transactions in the mempool of a validator are added from the JSON-RPC Service of the current node and from the mempool of other Diem nodes. +- Transactions in the mempool of a validator are added from the JSON-RPC Service of the current node and from the mempool of other Aptos nodes. - When the current validator is the leader, its consensus component pulls the transactions from its mempool and proposes the order of the transactions that form a block. The validator quorum then votes on the proposal. ### Merkle Trees - **Merkle tree** is a type of authenticated data structure that allows for efficient verification of data integrity and updates. -- The Diem network treats the entire blockchain as a single data structure that records the history of transactions and states over time. +- The Aptos network treats the entire blockchain as a single data structure that records the history of transactions and states over time. - The Merkle tree implementation simplifies the work of apps accessing the blockchain. It allows apps to: - Read any data from any point in time. - Verify the integrity of the data using a unified framework. ### Merkle Accumulator -- The [Merkle Accumulator](https://www.usenix.org/legacy/event/sec09/tech/full_papers/crosby.pdf) is an _append-only_ Merkle tree that the Diem Blockchain uses to store the ledger. +- The [Merkle Accumulator](https://www.usenix.org/legacy/event/sec09/tech/full_papers/crosby.pdf) is an _append-only_ Merkle tree that the Aptos Blockchain uses to store the ledger. - Merkle accumulators can provide proofs that a transaction was included in the chain (“proof of inclusion”). - They are also called ["history trees"](http://people.cs.vt.edu/danfeng/courses/cs6204/sp10-papers/crosby.pdf) in literature. ### Move -- **Move** is a new programming language that implements all the transactions on the Diem Blockchain. +- **Move** is a new programming language that implements all the transactions on the Aptos Blockchain. - It has two different kinds of code — [transaction scripts](#transaction-script) and [Move modules](#move-module). - For further information on Move, refer to the [Move technical paper](/technical-papers/move-paper) @@ -284,8 +284,8 @@ The production network for the Diem Payment Network. ### Move Module -- A **Move module** defines the rules for updating the global state of the Diem Blockchain. -- In the Diem protocol, a Move module is a **smart contract**. +- A **Move module** defines the rules for updating the global state of the Aptos Blockchain. +- In the Aptos protocol, a Move module is a **smart contract**. - Each user-submitted transaction includes a transaction script. The transaction script invokes procedures of one or more Move modules to update the global state of the blockchain according to the rules. ### Move Resources @@ -302,40 +302,40 @@ The production network for the Diem Payment Network. ### Node -- A **node** is a peer entity of the Diem network that tracks the state of the Diem Blockchain. -- A Diem node consists of logical components. [Mempool](#mempool), [consensus](#consensus), and the [virtual machine](#virtual-machine) are examples of node components. +- A **node** is a peer entity of the Aptos network that tracks the state of the Aptos Blockchain. +- A Aptos node consists of logical components. [Mempool](#mempool), [consensus](#consensus), and the [virtual machine](#virtual-machine) are examples of node components. ## O ### Open-Source Community -- **Open-source community** is a term used for a group of developers who work on open-source software. If you're reading this glossary, then you are part of the Diem project's developer community. +- **Open-source community** is a term used for a group of developers who work on open-source software. If you're reading this glossary, then you are part of the Aptos project's developer community. ## P ### ParentVASP account -The ParentVASP account is your unique root account. You can have only one parent account per Regulated VASP. Diem Networks will create a ParentVASP account on your behalf with your authentication key. +The ParentVASP account is your unique root account. You can have only one parent account per Regulated VASP. Aptos Networks will create a ParentVASP account on your behalf with your authentication key. ### Proof - A **proof** is a way to verify the accuracy of data in the blockchain. -- Every operation in the Diem Blockchain can be verified cryptographically that it is indeed correct and that data has not been omitted. +- Every operation in the Aptos Blockchain can be verified cryptographically that it is indeed correct and that data has not been omitted. - For example, if a user queries the information within a particular executed transaction, they will be provided with a cryptographic proof that the data returned to them is correct. ## R ### Regulated VASP -A Regulated VASP is a VASP that is registered or licensed in a Financial Action Task Force ("FATF") member jurisdiction and permitted to perform VASP activities under such license or registration. A Regulated VASP must be authorized by Diem Networks to operate as a VASP participant on the Diem Payment Network. +A Regulated VASP is a VASP that is registered or licensed in a Financial Action Task Force ("FATF") member jurisdiction and permitted to perform VASP activities under such license or registration. A Regulated VASP must be authorized by Aptos Networks to operate as a VASP participant on the Aptos Payment Network. Under the DPN Rules, a VASP is defined as a natural or legal person that as a business conducts one or more of the following activities or operations for or on behalf of another natural or legal person: -- Exchanges between Diem Coins and fiat currencies; -- Exchanges between Diem Coins and other virtual assets; -- Transfers of Diem Coins; -- Engages in safekeeping or administration of Diem Coins; and -- Otherwise provides financial services related to Diem Coins. +- Exchanges between Aptos Coins and fiat currencies; +- Exchanges between Aptos Coins and other virtual assets; +- Transfers of Aptos Coins; +- Engages in safekeeping or administration of Aptos Coins; and +- Otherwise provides financial services related to Aptos Coins. ### Round @@ -367,19 +367,19 @@ Under the DPN Rules, a VASP is defined as a natural or legal person that as a bu ### State -- A **state** in the Diem protocol is a snapshot of the distributed database. +- A **state** in the Aptos protocol is a snapshot of the distributed database. - A transaction modifies the database and produces a new and updated state. ### State Root Hash -- **State root hash** is a [Merkle hash](https://en.wikipedia.org/wiki/Merkle_tree) over all keys and values the state of the Diem Blockchain at a given version. +- **State root hash** is a [Merkle hash](https://en.wikipedia.org/wiki/Merkle_tree) over all keys and values the state of the Aptos Blockchain at a given version. ## T ### testnet -- The **testnet** is a publicly deployed instance of the Diem network that runs using a set of validator test nodes. -- The testnet is a demonstration of the Diem network that is built for experimenting with new ideas +- The **testnet** is a publicly deployed instance of the Aptos network that runs using a set of validator test nodes. +- The testnet is a demonstration of the Aptos network that is built for experimenting with new ideas - The testnet simulates a digital payment system and the coins on the testnet have _no real world value_. ### Transaction @@ -392,14 +392,14 @@ Under the DPN Rules, a VASP is defined as a natural or legal person that as a bu - [Sequence number](#sequence-number) - [Expiration time](#expiration-time) - A signed transaction is a raw transaction with the digital signature. -- An executed transaction changes the state of the Diem Blockchain. +- An executed transaction changes the state of the Aptos Blockchain. ### Transaction Script - Each transaction submitted by a user includes a **transaction script**. - It represents the operation a client submits to a validator. - The operation could be a request to move coins from user A to user B, or it could involve interactions with published [Move modules](#move-modules)/smart contracts. -- The transaction script is an arbitrary program that interacts with resources published in the global storage of the Diem Blockchain by calling the procedures of a module. It encodes the logic for a transaction. +- The transaction script is an arbitrary program that interacts with resources published in the global storage of the Aptos Blockchain by calling the procedures of a module. It encodes the logic for a transaction. - A single transaction script can send funds to multiple recipients and invoke procedures from several different modules. - A transaction script **is not** stored in the global state and cannot be invoked by other transaction scripts. It is a single-use program. @@ -408,21 +408,21 @@ Under the DPN Rules, a VASP is defined as a natural or legal person that as a bu ### Validator - _Alternate name_: Validators. -- A **validator** is an entity of the Diem ecosystem that validates on the Diem Blockchain. It receives requests from clients and runs consensus, execution, and storage. +- A **validator** is an entity of the Aptos ecosystem that validates on the Aptos Blockchain. It receives requests from clients and runs consensus, execution, and storage. - A validator maintains the history of all the transactions on the blockchain. - Internally, a validator needs to keep the current state, to execute transactions, and to calculate the next state. ### Version - A **version** is also called “height” in blockchain literature. -- The Diem Blockchain doesn't have an explicit notion of a block — it only uses blocks for batching and executing transactions. +- The Aptos Blockchain doesn't have an explicit notion of a block — it only uses blocks for batching and executing transactions. - A transaction at height 0 is the first transaction (genesis transaction), and a transaction at height 100 is the 101st transaction in the transaction store. ## W ### Well-Formed Transaction -A Diem transaction is **well formed** if each of the following conditions are true for the transaction: +A Aptos transaction is **well formed** if each of the following conditions are true for the transaction: - The transaction has a valid signature. - An account exists at the sender address. diff --git a/developer-docs-site/docs/reference/security.md b/developer-docs-site/docs/reference/security.md index bec9dd4c01d45..2c3cd66e34093 100755 --- a/developer-docs-site/docs/reference/security.md +++ b/developer-docs-site/docs/reference/security.md @@ -5,19 +5,19 @@ hidden: false --- import BlockQuote from "@site/src/components/BlockQuote"; -This document outlines security procedures and general policies for the Diem project. +This document outlines security procedures and general policies for the Aptos project.
-As Diem Core is currently in the prototype stage and does not power a blockchain with a cryptocurrency that has real-world value, our security procedures are not fully in place. +As Aptos Core is currently in the prototype stage and does not power a blockchain with a cryptocurrency that has real-world value, our security procedures are not fully in place. We will release a more complete disclosure policy prior to the launch of the mainnet.
## Reporting a Bug -The Diem team and community take all security bugs in the Diem project seriously to ensure the security of the Diem +The Aptos team and community take all security bugs in the Aptos project seriously to ensure the security of the Aptos Blockchain. -You can also report security bugs by emailing us directly at [security@diem.com](mailto:security@diem.com). +You can also report security bugs by emailing us directly at [security@aptos.com](mailto:security@aptos.com). -Thank you for improving the security of the Diem Blockchain! Your efforts and responsible disclosure are appreciated, +Thank you for improving the security of the Aptos Blockchain! Your efforts and responsible disclosure are appreciated, and every effort will be made to acknowledge your contributions in a timely manner. \ No newline at end of file diff --git a/developer-docs-site/docs/technical-papers/jellyfish-merkle-tree-paper.md b/developer-docs-site/docs/technical-papers/jellyfish-merkle-tree-paper.md index 1b31affa1d72b..f978a93cd8c5c 100755 --- a/developer-docs-site/docs/technical-papers/jellyfish-merkle-tree-paper.md +++ b/developer-docs-site/docs/technical-papers/jellyfish-merkle-tree-paper.md @@ -8,7 +8,7 @@ import PublicationLink from "@site/src/components/PublicationLink"; ## Abstract -This paper presents Jellyfish Merkle Tree (JMT), a space-and-computation-efficient sparse Merkle tree optimized for Log-Structured Merge-tree (LSM-tree) based key-value storage, which is designed specially for the Diem Blockchain. JMT was inspired by Patricia Merkle Tree (PMT), a sparse Merkle tree structure that powers the widely known Ethereum network. JMT further makes quite a few optimizations in node key, node types and proof format to find the ideal balance between the complexity of data structure, storage, I/O overhead and computation efficiency, to cater to the needs of the Diem Blockchain. JMT has been implemented in Rust, but it is language-independent such that it could be implemented in other programming languages. Also, the JMT structure presented is of great flexibility in implementation details for fitting various practical use cases. +This paper presents Jellyfish Merkle Tree (JMT), a space-and-computation-efficient sparse Merkle tree optimized for Log-Structured Merge-tree (LSM-tree) based key-value storage, which is designed specially for the Aptos Blockchain. JMT was inspired by Patricia Merkle Tree (PMT), a sparse Merkle tree structure that powers the widely known Ethereum network. JMT further makes quite a few optimizations in node key, node types and proof format to find the ideal balance between the complexity of data structure, storage, I/O overhead and computation efficiency, to cater to the needs of the Aptos Blockchain. JMT has been implemented in Rust, but it is language-independent such that it could be implemented in other programming languages. Also, the JMT structure presented is of great flexibility in implementation details for fitting various practical use cases. ### Downloads diff --git a/developer-docs-site/docs/technical-papers/move-paper.md b/developer-docs-site/docs/technical-papers/move-paper.md index 0b4ca2909736a..8531e218fc3ec 100755 --- a/developer-docs-site/docs/technical-papers/move-paper.md +++ b/developer-docs-site/docs/technical-papers/move-paper.md @@ -6,7 +6,7 @@ sidebar_position: 1 --- import PublicationLink from "@site/src/components/PublicationLink"; -***Note to readers: On December 1, 2020, the Libra Association was renamed to Diem Association. This report was +***Note to readers: On December 1, 2020, the Libra Association was renamed to Aptos Association. This report was published before the Association released White Paper v2.0 in April 2020, which included a number of key updates to the Libra payment system. Outdated links have been removed, but otherwise, this report has not been modified to incorporate the updates and should be read in that context. Features of the project as implemented may differ based on regulatory @@ -14,15 +14,15 @@ approvals or other considerations, and may evolve over time.*** ## Abstract -We present _Move_, a safe and flexible programming language for the Diem Blockchain. Move is an executable bytecode +We present _Move_, a safe and flexible programming language for the Aptos Blockchain. Move is an executable bytecode language used to implement custom transactions and smart contracts. The key feature of Move is the ability to define custom _resource types_ with semantics inspired by linear logic: a resource can never be copied or implicitly discarded, only moved between program storage locations. These safety guarantees are enforced statically by Move’s type system. Despite these special protections, resources are ordinary program values — they can be stored in data structures, passed as arguments to procedures, and so on. First-class resources are a very general concept that programmers can use not only to implement safe digital assets but also to write correct business logic for wrapping assets and enforcing access -control policies. The safety and expressivity of Move have enabled us to implement significant parts of the Diem -protocol in Move, including Diem coin, transaction processing, and validator management. +control policies. The safety and expressivity of Move have enabled us to implement significant parts of the Aptos +protocol in Move, including Aptos coin, transaction processing, and validator management. ### Downloads Z @@ -35,13 +35,13 @@ Z title="State Machine Replication" doc_link="/technical-papers/state-machine-replication-paper" versions={[ - ["2021-08-17", "/papers/diem-consensus-state-machine-replication-in-the-diem-blockchain/2021-08-17.pdf"], - ["2020-05-26", "/papers/diem-consensus-state-machine-replication-in-the-diem-blockchain/2020-05-26.pdf"], - ["2020-04-09", "/papers/diem-consensus-state-machine-replication-in-the-diem-blockchain/2020-04-09.pdf"], - ["2019-11-08", "/papers/diem-consensus-state-machine-replication-in-the-diem-blockchain/2019-11-08.pdf"], - ["2019-09-26", "/papers/diem-consensus-state-machine-replication-in-the-diem-blockchain/2019-09-26.pdf"], - ["2019-09-19", "/papers/diem-consensus-state-machine-replication-in-the-diem-blockchain/2019-09-19.pdf"], - ["2019-06-28", "/papers/diem-consensus-state-machine-replication-in-the-diem-blockchain/2019-06-28.pdf"], + ["2021-08-17", "/papers/aptos-consensus-state-machine-replication-in-the-aptos-blockchain/2021-08-17.pdf"], + ["2020-05-26", "/papers/aptos-consensus-state-machine-replication-in-the-aptos-blockchain/2020-05-26.pdf"], + ["2020-04-09", "/papers/aptos-consensus-state-machine-replication-in-the-aptos-blockchain/2020-04-09.pdf"], + ["2019-11-08", "/papers/aptos-consensus-state-machine-replication-in-the-aptos-blockchain/2019-11-08.pdf"], + ["2019-09-26", "/papers/aptos-consensus-state-machine-replication-in-the-aptos-blockchain/2019-09-26.pdf"], + ["2019-09-19", "/papers/aptos-consensus-state-machine-replication-in-the-aptos-blockchain/2019-09-19.pdf"], + ["2019-06-28", "/papers/aptos-consensus-state-machine-replication-in-the-aptos-blockchain/2019-06-28.pdf"], ]} /> diff --git a/developer-docs-site/docs/technical-papers/state-machine-replication-paper.md b/developer-docs-site/docs/technical-papers/state-machine-replication-paper.md index c1081434f81d3..2e3b9e6a8ac61 100755 --- a/developer-docs-site/docs/technical-papers/state-machine-replication-paper.md +++ b/developer-docs-site/docs/technical-papers/state-machine-replication-paper.md @@ -6,30 +6,30 @@ sidebar_position: 1 --- import PublicationLink from "@site/src/components/PublicationLink"; -***Note to readers: On December 1, 2020, the Libra Association was renamed to Diem Association. This report was modified +***Note to readers: On December 1, 2020, the Libra Association was renamed to Aptos Association. This report was modified in April 2020 to incorporate updates to the Libra payment system as found in the White Paper v2.0. Features of the project as implemented may differ based on regulatory approvals or other considerations, and may evolve over time.*** ## Abstract -This report describes the Diem Byzantine Fault Tolerance (DiemBFT) algorithmic core and discusses next steps in its +This report describes the Aptos Byzantine Fault Tolerance (AptosBFT) algorithmic core and discusses next steps in its production. The consensus protocol is responsible for forming agreement on ordering and finalizing transactions among a -configurable set of validators. DiemBFT maintains safety against network asynchrony and even if at any particular +configurable set of validators. AptosBFT maintains safety against network asynchrony and even if at any particular configuration epoch, a threshold of the participants are Byzantine. -DiemBFT is based on HotStuff, a recent protocol that leverages several decades of scientific advances in Byzantine Fault +AptosBFT is based on HotStuff, a recent protocol that leverages several decades of scientific advances in Byzantine Fault Tolerance (BFT) and achieves the strong scalability and security properties required by internet settings. Several novel -features distinguish DiemBFT from HotStuff. DiemBFT incorporates a novel round synchronization mechanism that provides +features distinguish AptosBFT from HotStuff. AptosBFT incorporates a novel round synchronization mechanism that provides bounded commit latency under synchrony. It introduces a nil-block vote that allows proposals to commit despite having faulty leaders. It encapsulates the correct behavior by participants in a “tcb”-able module, allowing it to run within a secure hardware enclave that reduces the attack surface on participants. -DiemBFT can reconfigure itself, by embedding configuration-change commands in the sequence. A new configuration epoch +AptosBFT can reconfigure itself, by embedding configuration-change commands in the sequence. A new configuration epoch may change everything from the validator set to the protocol itself. ### Downloads diff --git a/developer-docs-site/docs/technical-papers/technical-papers-overview.mdx b/developer-docs-site/docs/technical-papers/technical-papers-overview.mdx index fb4e1e1ca2adc..9555322de0eee 100755 --- a/developer-docs-site/docs/technical-papers/technical-papers-overview.mdx +++ b/developer-docs-site/docs/technical-papers/technical-papers-overview.mdx @@ -4,7 +4,7 @@ slug: "technical-papers-overview" hidden: false sidebar_position: 0 --- -Our technical papers take a closer look at some of Diem’s core components. Choose a paper below to view and download: +Our technical papers take a closer look at some of Aptos’s core components. Choose a paper below to view and download: diff --git a/developer-docs-site/docs/technical-papers/the-aptos-blockchain-paper.md b/developer-docs-site/docs/technical-papers/the-aptos-blockchain-paper.md index 6a8a4a5a6edcf..d21849a3ca81f 100755 --- a/developer-docs-site/docs/technical-papers/the-aptos-blockchain-paper.md +++ b/developer-docs-site/docs/technical-papers/the-aptos-blockchain-paper.md @@ -1,24 +1,24 @@ --- -title: "The Diem Blockchain" -slug: "the-diem-blockchain-paper" +title: "The Aptos Blockchain" +slug: "the-aptos-blockchain-paper" hidden: false sidebar_position: 1 --- import PublicationLink from "@site/src/components/PublicationLink"; -***Note to readers: On December 1, 2020, the Libra Association was renamed to Diem Association. This report was published before the Association released White Paper v2.0 in April 2020, which included a number of key updates to the Libra payment system. Outdated links have been removed, but otherwise, this report has not been modified to incorporate the updates and should be read in that context. Features of the project as implemented may differ based on regulatory approvals or other considerations, and may evolve over time.*** +***Note to readers: On December 1, 2020, the Libra Association was renamed to Aptos Association. This report was published before the Association released White Paper v2.0 in April 2020, which included a number of key updates to the Libra payment system. Outdated links have been removed, but otherwise, this report has not been modified to incorporate the updates and should be read in that context. Features of the project as implemented may differ based on regulatory approvals or other considerations, and may evolve over time.*** ## Abstract -The Diem Blockchain is a decentralized, programmable database designed to support a low-volatility cryptocurrency that will have the ability to serve as an efficient medium of exchange for billions of people around the world. We present a proposal for the Diem protocol, which implements the Diem Blockchain and aims to create a financial infrastructure that can foster innovation, lower barriers to entry, and improve access to financial services. To validate the design of the Diem protocol, we have built an open-source prototype implementation — _Diem Core_ — in anticipation of a global collaborative effort to advance this new ecosystem. +The Aptos Blockchain is a decentralized, programmable database designed to support a low-volatility cryptocurrency that will have the ability to serve as an efficient medium of exchange for billions of people around the world. We present a proposal for the Aptos protocol, which implements the Aptos Blockchain and aims to create a financial infrastructure that can foster innovation, lower barriers to entry, and improve access to financial services. To validate the design of the Aptos protocol, we have built an open-source prototype implementation — _Aptos Core_ — in anticipation of a global collaborative effort to advance this new ecosystem. -The Diem protocol allows a set of replicas — referred to as validators — from different authorities to jointly maintain a database of programmable resources. These resources are owned by different user accounts authenticated by public key cryptography and adhere to custom rules specified by the developers of these resources. Validators process transactions and interact with each other to reach consensus on the state of the database. Transactions are based on predefined and, in future versions, user-defined smart contracts in a new programming language called _Move_. +The Aptos protocol allows a set of replicas — referred to as validators — from different authorities to jointly maintain a database of programmable resources. These resources are owned by different user accounts authenticated by public key cryptography and adhere to custom rules specified by the developers of these resources. Validators process transactions and interact with each other to reach consensus on the state of the database. Transactions are based on predefined and, in future versions, user-defined smart contracts in a new programming language called _Move_. We use Move to define the core mechanisms of the blockchain, such as the currency and validator membership. These core mechanisms enable the creation of a unique governance mechanism that builds on the stability and reputation of existing institutions in the early days but transitions to a fully open system over time. ### Downloads \ No newline at end of file diff --git a/developer-docs-site/docs/tools/cli-reference.md b/developer-docs-site/docs/tools/cli-reference.md index ce0457684fbe9..a555f121c022c 100755 --- a/developer-docs-site/docs/tools/cli-reference.md +++ b/developer-docs-site/docs/tools/cli-reference.md @@ -5,25 +5,25 @@ hidden: false --- import BlockQuote from "@site/src/components/BlockQuote"; -This guide describes how to use the Diem command line interface (CLI) client to interact with the Diem Blockchain’s testnet. +This guide describes how to use the Aptos command line interface (CLI) client to interact with the Aptos Blockchain’s testnet. -The CLI is invoked as an interactive shell. It provides basic commands to simulate the creation of accounts, the minting of Diem Coins, performing transfers, and querying the blockchain. You can use the CLI client to interact with a validator node in different types of networks such as testnet, a local test validator network, or on a remote blockchain by specifying the node's hostname. +The CLI is invoked as an interactive shell. It provides basic commands to simulate the creation of accounts, the minting of Aptos Coins, performing transfers, and querying the blockchain. You can use the CLI client to interact with a validator node in different types of networks such as testnet, a local test validator network, or on a remote blockchain by specifying the node's hostname. -## Invoke the Diem CLI client -There are two ways to invoke the Diem CLI client: +## Invoke the Aptos CLI client +There are two ways to invoke the Aptos CLI client: * Connect to testnet via the CLI client -* Run a CLI client to connect to any Diem network +* Run a CLI client to connect to any Aptos network ### Connect to the Testnet via the CLI Client -To connect to the testnet through the CLI, a convenience script can be used to invoke the CLI without needing to specify parameters. To invoke this, change to the `diem` directory and run: +To connect to the testnet through the CLI, a convenience script can be used to invoke the CLI without needing to specify parameters. To invoke this, change to the `aptos` directory and run: ```bash ./scripts/cli/start_cli_testnet.sh ``` -### Run a CLI Client to Connect to Any Diem Network +### Run a CLI Client to Connect to Any Aptos Network To invoke the CLI client and configure it yourself, run: ```bash @@ -32,12 +32,12 @@ cargo run -p cli --bin cli -- [OPTIONS] --host --validator_set_file `. | +|`-m | --faucet_key_file_path` |Path to the generated key-pair for the faucet account. The faucet account can be used to simulate the minting of fake Aptos Coins. If not passed, a new key-pair will be generated for you and placed in a temporary directory. To manually generate a keypair, use generate_keypair: `cargo run -p generate_keypair -- -o `. | |`-f | --faucet-url` |The full URL of the host that operates a faucet service. If not passed, this will be derived from the URL parameter under the strict assumption that the URL parameter is under the (sub)domain name `client` and the corresponding faucet service is under the (sub)domain name `faucet`. | | `-u | —-url` | The full URL of the destination host for the CLI to connect to. If applicable, this should include the port number of the host’s JSON RPC server. | | `-n | --mnemonic_file` | The file location from which to load the mnemonic word for user account address/key generation. If not passed, a new mnemonic file is generated by aptos_wallet in the current directory.| @@ -77,7 +77,7 @@ If you enter only the major command, it will show the help information for that Arguments: file_path - File path from which to load mnemonic recover seed. Must have been written via `account write`. - `write | w` — Save Diem wallet mnemonic recovery seed to disk. This will allow accounts to be recovered via `account recover`. + `write | w` — Save Aptos wallet mnemonic recovery seed to disk. This will allow accounts to be recovered via `account recover`. Usage: write|w @@ -109,7 +109,7 @@ If you enter only the major command, it will show the help information for that #### ` | ` — Transfer coins from one account to another. Suffix 'b' is for blocking. Usage: - transfer|transferb|t|tb | | [gas_unit_price_in_micro_diems (default=0)] [max_gas_amount_in_micro_diems (default 10000)] + transfer|transferb|t|tb | | [gas_unit_price_in_micro_aptoss (default=0)] [max_gas_amount_in_micro_aptoss (default 10000)] Arguments: sender_account_address|sender_account_ref_id - The account from which this transfer transaction is sent. The sender account pays for the gas. @@ -118,8 +118,8 @@ If you enter only the major command, it will show the help information for that gas required for both account creation and coin transfer. number_of_coins - The number of coins transferred to receiver account. currency_code - Which currency to transfer. For example, `Coin1`. - gas_unit_price_in_micro_diems - The unit price to pay for gas. - max_gas_amount_in_micro_diems - Max units of gas user is willing to pay for this transaction.--- + gas_unit_price_in_micro_aptoss - The unit price to pay for gas. + max_gas_amount_in_micro_aptoss - Max units of gas user is willing to pay for this transaction.--- #### `query | q` — Query data from destination chain. All query operations are blocking. Subcommands include: @@ -226,12 +226,12 @@ Subcommands include: Usage: gen_waypoint|g -`change_diem_version | v` — Change the diem_version stored on chain. +`change_aptos_version | v` — Change the aptos_version stored on chain. Usage: - change_diem_version|v + change_aptos_version|v Arguments: - new_diem_version - New major version for the VM, must be strictly incrementing. + new_aptos_version - New major version for the VM, must be strictly incrementing. `enable_custom_script | s` — Allow executing arbitrary script in the network. This disables script hash verification. @@ -255,5 +255,5 @@ Subcommands include: Account creation provided by the CLI generates a local keypair, but nothing is created on the testnet blockchain. To create an account on tesnet: -* Transfer fake Diem Coins to the address you wish to create. If the recipient account does not exist, you must create the recipient account first, and then add the specific currency into the account in order for it to receive fake Diem Coins. The sender pays a transaction fee (gas) for both account creation and transfer. -* Send a mint transaction to simulate the minting of Diem Coins to an account. If the account does not exist, the account will be created first and the fake Diem Coins will be minted later. Unlike other transactions, a nonexistent account itself can request a simulated mint transaction. \ No newline at end of file +* Transfer fake Aptos Coins to the address you wish to create. If the recipient account does not exist, you must create the recipient account first, and then add the specific currency into the account in order for it to receive fake Aptos Coins. The sender pays a transaction fee (gas) for both account creation and transfer. +* Send a mint transaction to simulate the minting of Aptos Coins to an account. If the account does not exist, the account will be created first and the fake Aptos Coins will be minted later. Unlike other transactions, a nonexistent account itself can request a simulated mint transaction. \ No newline at end of file diff --git a/developer-docs-site/docs/tools/github-projects.mdx b/developer-docs-site/docs/tools/github-projects.mdx index 9d57a50dc01a5..2a33a0faa0847 100755 --- a/developer-docs-site/docs/tools/github-projects.mdx +++ b/developer-docs-site/docs/tools/github-projects.mdx @@ -12,16 +12,16 @@ import SimpleTextCard from "@site/src/components/Cards/SimpleTextCard"; @@ -32,7 +32,7 @@ import SimpleTextCard from "@site/src/components/Cards/SimpleTextCard"; iconDark="img/github-dark.svg" title="Python SDK" overlay="" - to="https://github.com/diem/client-sdk-python" + to="https://github.com/aptos/client-sdk-python" /> @@ -43,13 +43,13 @@ import SimpleTextCard from "@site/src/components/Cards/SimpleTextCard"; iconDark="img/github-dark.svg" title="Off-Chain Reference" overlay="" - to="https://github.com/diem/off-chain-reference" + to="https://github.com/aptos/off-chain-reference" /> diff --git a/developer-docs-site/docs/tools/sdks.mdx b/developer-docs-site/docs/tools/sdks.mdx index 4cdb5116531b7..f695e22fa5fb4 100644 --- a/developer-docs-site/docs/tools/sdks.mdx +++ b/developer-docs-site/docs/tools/sdks.mdx @@ -9,9 +9,9 @@ import CardsWrapper from "@site/src/components/Cards/CardsWrapper"; import SimpleTextCard from "@site/src/components/Cards/SimpleTextCard"; Our official SDKs are collections of development resources like libraries, code samples, and documentation curated to -help you build your own projects on the Diem platform. +help you build your own projects on the Aptos platform. -Select a language to access its approved Diem resource package on GitHub: +Select a language to access its approved Aptos resource package on GitHub: ### Select a language: @@ -21,6 +21,6 @@ Select a language to access its approved Diem resource package on GitHub: iconDark="img/github-dark.svg" title="Python SDK" overlay="" - to="https://github.com/diem/client-sdk-python" + to="https://github.com/aptos/client-sdk-python" /> \ No newline at end of file diff --git a/developer-docs-site/docs/transactions/basics-life-of-txn.md b/developer-docs-site/docs/transactions/basics-life-of-txn.md index 046cbc6f25955..8a2c423234ac8 100755 --- a/developer-docs-site/docs/transactions/basics-life-of-txn.md +++ b/developer-docs-site/docs/transactions/basics-life-of-txn.md @@ -6,25 +6,25 @@ sidebar_position: 1 --- import BlockQuote from "@site/src/components/BlockQuote"; -To get a deeper understanding of the lifecycle of a Diem transaction (from an operational perspective), we will follow a transaction on its journey from being submitted to a Diem node to being committed to the Diem Blockchain. We will then “zoom-in” on the logical components of Diem nodes and take a look at its interactions with other components. +To get a deeper understanding of the lifecycle of a Aptos transaction (from an operational perspective), we will follow a transaction on its journey from being submitted to a Aptos node to being committed to the Aptos Blockchain. We will then “zoom-in” on the logical components of Aptos nodes and take a look at its interactions with other components. #### Assumptions For the purpose of this doc, we will assume that: -* Alice and Bob are two users who each have an [account](/reference/glossary#account) on the Diem Blockchain. -* Alice's account has 110 Diem Coins. -* Alice is sending 10 Diem Coins to Bob. +* Alice and Bob are two users who each have an [account](/reference/glossary#account) on the Aptos Blockchain. +* Alice's account has 110 Aptos Coins. +* Alice is sending 10 Aptos Coins to Bob. * The current [sequence number](/reference/glossary#sequence-number) of Alice's account is 5 (which indicates that 5 transactions have already been sent from Alice's account). * There are a total of 100 validator nodes — V1 to V100 on the network. -* A Diem client submits Alice's transaction to JSON-RPC service on a Diem FullNode. The FullNode forwards this transaction to a validator FullNode which in turn forwards it to validator V1. +* A Aptos client submits Alice's transaction to JSON-RPC service on a Aptos FullNode. The FullNode forwards this transaction to a validator FullNode which in turn forwards it to validator V1. * Validator V1 is a proposer/leader for the current round. ## Client submits a transaction -A Diem **client constructs a raw transaction** (let's call it T5raw) to transfer 10 Diem Coins from Alice’s account to Bob’s account. The Diem client signs the transaction with Alice's private key. The signed transaction T5 includes the following: +A Aptos **client constructs a raw transaction** (let's call it T5raw) to transfer 10 Aptos Coins from Alice’s account to Bob’s account. The Aptos client signs the transaction with Alice's private key. The signed transaction T5 includes the following: * The raw transaction. * Alice's public key. @@ -35,18 +35,18 @@ The raw transaction includes the following fields: | Fields | Description | | ------ | ----------- | | [account address](/reference/glossary#account-address) | Alice's account address | -| Move Module | A module (or program) that indicates the actions to be performed on Alice's behalf. In this case, it contains:
- A Move bytecode peer-to-peer [transaction script](/reference/glossary#transaction-script)
- A list of inputs to the script (for this example the list would contain Bob's account address and the payment amount in Diem Coins). | +| Move Module | A module (or program) that indicates the actions to be performed on Alice's behalf. In this case, it contains:
- A Move bytecode peer-to-peer [transaction script](/reference/glossary#transaction-script)
- A list of inputs to the script (for this example the list would contain Bob's account address and the payment amount in Aptos Coins). | | [maximum gas amount](/reference/glossary#maximum-gas-amount) | The maximum gas amount Alice is willing to pay for this transaction. Gas is a way to pay for computation and storage. A gas unit is an abstract measurement of computation. | -| [gas price](/reference/glossary#gas-price) (in microdiem/gas units) | The amount in Diem Coins Alice is willing to pay per unit of gas, to execute the transaction. | +| [gas price](/reference/glossary#gas-price) (in microaptos/gas units) | The amount in Aptos Coins Alice is willing to pay per unit of gas, to execute the transaction. | | [expiration time](/reference/glossary#expiration-time) | Expiration time of the transaction. | | [sequence number](/reference/glossary#sequence-number) | The sequence number (5 for this example) for an account indicates the number of transactions that have been submitted and commited on chain from that account. In this case, 5 transactions have been submitted from Alice’s account, including T5raw). A transaction with sequence number 5 can only be committed on-chain if the account sequence number is 5. | -| [Chain ID](https://github.com/diem/diem/blob/main/types/src/chain_id.rs) | An identifier that distinguishes the Diem Mainnet from networks used for other purposes including test networks. | +| [Chain ID](https://github.com/aptos/aptos/blob/main/types/src/chain_id.rs) | An identifier that distinguishes the Aptos Mainnet from networks used for other purposes including test networks. | ## Lifecycle of the transaction -In this section, we will describe the lifecycle of transaction T5, from when the client submits it to when it is committed to the Diem Blockchain. +In this section, we will describe the lifecycle of transaction T5, from when the client submits it to when it is committed to the Aptos Blockchain. For the relevant steps, we've included a link to the corresponding inter-component interactions of the validator node. After you are familiar with all the steps in the lifecycle of the transaction, you may want to refer to the information on the corresponding inter-component interactions for each step. ![Figure 1.0 Lifecycle of a transaction](/img/docs/validator-sequence.svg) @@ -64,13 +64,13 @@ The lifecycle of a transaction has five stages: * Executing and Consensus: [Executing the block and reaching consensus](#executing-the-block-and-reaching-consensus) * Committing: [Committing the block](#committing-the-block) -We've described what happens in each stage below, along with links to the corresponding Diem node component interactions. +We've described what happens in each stage below, along with links to the corresponding Aptos node component interactions. ### Accepting the transaction -| Description | Diem Node Component Interactions | +| Description | Aptos Node Component Interactions | | ------------------------------------------------------------ | ---------------------------------------------------------- | -| 1. **Client → JSON-RPC service**: The client submits transaction T5 to the JSON-RPC service of a Diem FullNode. FullNodes use the JSON-RPC service to forward the transaction to their own mempools which forward the transaction to upstream mempool services running on validator FullNodes which in turn forward to the validator node V1. | [1. JSON-RPC](#1-client-→-json-rpc-service) | +| 1. **Client → JSON-RPC service**: The client submits transaction T5 to the JSON-RPC service of a Aptos FullNode. FullNodes use the JSON-RPC service to forward the transaction to their own mempools which forward the transaction to upstream mempool services running on validator FullNodes which in turn forward to the validator node V1. | [1. JSON-RPC](#1-client-→-json-rpc-service) | | 2. **JSON-RPC service → Mempool**: The FullNode's JSON-RPC service transmits transaction T5 to validator V1's mempool. | [2. JSON-RPC](#2-json-rpc-service-→-mempool), [1. Mempool](#1-json-rpc-service-→-mempool) | | 3. **Mempool → Virtual Machine**: Mempool will use the virtual machine (VM) component to perform validation checks, such as signature verification, checking that Alice's account has sufficient balance, checking that transaction T5 is not being replayed using the sequence number, and so on. | [4. Mempool](#4-mempool-→-vm), [3. Virtual Machine](#3-mempool-→-virtual-machine) | @@ -78,7 +78,7 @@ We've described what happens in each stage below, along with links to the corres ### Sharing the transaction with other validator nodes -| Description | Diem Node Component Interactions | +| Description | Aptos Node Component Interactions | | ------------------------------------------------------------ | -------------------------------- | | 4. **Mempool**: The mempool will hold T5 in an in-memory buffer. Mempool may already contain multiple transactions sent from Alice's address. | [Mempool](#mempool) | | 5. **Mempool → Other Validators**: Using the shared-mempool protocol, V1 will share the transactions (including T5) in its mempool with other validator nodes and place transactions received from them into its own (V1) mempool. | [2. Mempool](#2-mempool-→-other-validator-nodes) | @@ -87,16 +87,16 @@ We've described what happens in each stage below, along with links to the corres ### Proposing the block -| Description | Diem Node Component Interactions | +| Description | Aptos Node Component Interactions | | ------------------------------------------------------------ | ---------------------------------------- | | 6. **Consensus → Mempool**: — As validator V1 is a proposer/leader for this transaction, it will pull a block of transactions from its mempool and replicate this block as a proposal to other validator nodes via its consensus component. | [1. Consensus](#1-consensus-→-mempool), [3. Mempool](#3-consensus-→-mempool) | -| 7. **Consensus → Other Validators**: The consensus component of V1 is responsible for coordinating agreement among all validators on the order of transactions in the proposed block. Refer to our technical paper [State Machine Replication in the Diem Blockchain](/technical-papers/state-machine-replication-paper) for details of our proposed consensus protocol DiemBFT. | [2. Consensus](#2-consensus-→-other-validators) | +| 7. **Consensus → Other Validators**: The consensus component of V1 is responsible for coordinating agreement among all validators on the order of transactions in the proposed block. Refer to our technical paper [State Machine Replication in the Aptos Blockchain](/technical-papers/state-machine-replication-paper) for details of our proposed consensus protocol AptosBFT. | [2. Consensus](#2-consensus-→-other-validators) | ### Executing the block and reaching consensus -| Description | Diem Node Component Interactions | +| Description | Aptos Node Component Interactions | | ------------------------------------------------------------ | ------------------------------------------------ | | 8. **Consensus → Execution**: As part of reaching agreement, the block of transactions (containing T5) is shared with the execution component. | [3. Consensus](#3-consensus-→-execution-consensus-→-other-validators), [1. Execution](#1-consensus-→-execution) | | 9. **Execution → Virtual Machine**: The execution component manages the execution of transactions in the virtual machine (VM). Note that this execution happens speculatively before the transactions in the block have been agreed upon. | [2. Execution](#2-execution-→-vm), [3. Virtual Machine](#3-mempool-→-virtual-machine) | @@ -107,29 +107,29 @@ We've described what happens in each stage below, along with links to the corres ### Committing the block -| Description | Diem Node Component Interactions | +| Description | Aptos Node Component Interactions | | ------------------------------------------------------------ | ------------------------------------------------------------ | | 12. **Consensus → Execution**, **Execution → Storage **:If the proposed block's execution result is agreed upon and signed by a set of validators that have the quorum of votes, validator V1's execution component reads the full result of the proposed block execution from the speculative execution cache and commits all the transactions in the proposed block to persistent storage with their results. | [4. Consensus](#4-consensus-→-execution), [3. Execution](#3-consensus-→-execution), [4. Execution](#4-execution-→-storage), [3. Storage](#3-execution-→-storage) | -Alice's account will now have 100 Diem Coins, and its sequence number will be 6. If T5 is replayed by Bob, it will be rejected as the sequence number of Alice's account (6) is greater than the sequence number of the replayed transaction (5). +Alice's account will now have 100 Aptos Coins, and its sequence number will be 6. If T5 is replayed by Bob, it will be rejected as the sequence number of Alice's account (6) is greater than the sequence number of the replayed transaction (5). -## Diem node component interactions +## Aptos node component interactions -In the [previous section](#lifecycle-of-the-transaction), we described the typical lifecycle of a sample transaction from being submitted to being committed to the Diem Blockchain's distributed database. Now let's look in more depth at the inter-component interactions of Diem nodes as the blockchain processes transactions and responds to queries. This information will be most useful to those who: +In the [previous section](#lifecycle-of-the-transaction), we described the typical lifecycle of a sample transaction from being submitted to being committed to the Aptos Blockchain's distributed database. Now let's look in more depth at the inter-component interactions of Aptos nodes as the blockchain processes transactions and responds to queries. This information will be most useful to those who: * Would like to get an overall idea of how the system works under the covers. -* Are interested in eventually contributing to the Diem Core software. +* Are interested in eventually contributing to the Aptos Core software. -You can learn more about the different types of Diem nodes here: +You can learn more about the different types of Aptos nodes here: * [Validator nodes](/basics/basics-validator-nodes) * [FullNodes](/basics/basics-fullnodes) For our narrative, we will assume that a client submits a transaction TN to a validator VX. For each validator component, we will describe each of its inter-component interactions in subsections under the respective component's section. Note that subsections describing the inter-component interactions are not listed strictly in the order in which they are performed. Most of the interactions are relevant to the processing of a transaction, and some are relevant to clients querying the blockchain (queries for existing information on the blockchain). -The following are the core logical components of a Diem node used in the lifecycle of a transaction: +The following are the core logical components of a Aptos node used in the lifecycle of a transaction: **FullNode** @@ -152,7 +152,7 @@ Any request made by a client goes to the JSON-RPC Service of a FullNode first. T #### 1. Client → JSON-RPC Service -A client submits a transaction to the JSON-RPC service of a Diem FullNode. +A client submits a transaction to the JSON-RPC service of a Aptos FullNode. #### 2. JSON-RPC Service → Mempool @@ -160,7 +160,7 @@ The JSON-RPC service forwards the transaction to validator FullNode, which then #### 3. JSON-RPC Service → Storage -When a client performs a read query on the Diem Blockchain (for example, to get the balance of Alice's account), the JSON-RPC service interacts with the storage component directly to obtain the requested information. +When a client performs a read query on the Aptos Blockchain (for example, to get the balance of Alice's account), the JSON-RPC service interacts with the storage component directly to obtain the requested information. ### Virtual Machine (VM) @@ -171,7 +171,7 @@ The Move virtual machine (VM) verifies and executes transaction scripts written #### 1. Virtual Machine → Storage -When mempool requests the VM to validate a transaction via `VM::ValidateTransaction()`, the VM loads the transaction sender's account from storage and performs verifications, some of which have been described in the list below. View the entire list of verifications [here](https://github.com/diem/diem/tree/main/specifications/move_adapter#validation). +When mempool requests the VM to validate a transaction via `VM::ValidateTransaction()`, the VM loads the transaction sender's account from storage and performs verifications, some of which have been described in the list below. View the entire list of verifications [here](https://github.com/aptos/aptos/tree/main/specifications/move_adapter#validation). * Checks that the input signature on the signed transaction is correct (to reject incorrectly signed transactions). * Checks that the sender's account authentication key is the same as the hash of the public key (corresponding to the private key used to sign the transaction). @@ -189,7 +189,7 @@ It is important to understand that executing a transaction is different from upd When mempool receives a transaction from other validators via shared mempool or from the JSON-RPC service, mempool invokes `VM::ValidateTransaction()` on the VM to validate the transaction. -For implementation details refer to the [Virtual Machine README](https://github.com/diem/diem/tree/main/language/vm). +For implementation details refer to the [Virtual Machine README](https://github.com/aptos/aptos/tree/main/language/vm). ### Mempool @@ -212,15 +212,15 @@ Mempool is a shared buffer that holds the transactions that are “waiting” to #### 3. Consensus → Mempool * When the transaction is forwarded to a validator node and once the validator node becomes the leader, its consensus component will pull a block of transactions from its mempool and replicate the proposed block to other validators. It does this to arrive at a consensus on the ordering of transactions and the execution results of the transactions in the proposed block. -* Note that just because a transaction TN was included in a proposed consensus block, it does not guarantee that TN will eventually be persisted in the distributed database of the Diem Blockchain. +* Note that just because a transaction TN was included in a proposed consensus block, it does not guarantee that TN will eventually be persisted in the distributed database of the Aptos Blockchain. #### 4. Mempool → VM -When mempool receives a transaction from other validators, mempool invokes [VM::ValidateTransaction()](https://developers.diem.com/docs/life-of-a-transaction#action-b-1) on the VM to validate the transaction. +When mempool receives a transaction from other validators, mempool invokes [VM::ValidateTransaction()](https://developers.aptos.com/docs/life-of-a-transaction#action-b-1) on the VM to validate the transaction. -For implementation details refer to the [Mempool README](https://github.com/diem/diem/tree/main/mempool). +For implementation details refer to the [Mempool README](https://github.com/aptos/aptos/tree/main/mempool). ### Consensus ![Figure 1.4 Consensus](/img/docs/consensus.svg) @@ -249,7 +249,7 @@ If VX is a proposer/leader, its consensus component replicates the pr If enough validators vote for the same execution result, the consensus component of VX informs execution via `Execution::CommitBlock()` that this block is ready to be committed. -For implementation details refer to the [Consensus README](https://github.com/diem/diem/tree/main/consensus). +For implementation details refer to the [Consensus README](https://github.com/aptos/aptos/tree/main/consensus). ### Execution ![Figure 1.5 Execution](/img/docs/execution.svg) @@ -260,7 +260,7 @@ The execution component coordinates the execution of a block of transactions and #### 1. Consensus → Execution * Consensus requests execution to execute a block of transactions via: `Execution::ExecuteBlock()`. -* Execution maintains a “scratchpad,” which holds in-memory copies of the relevant portions of the [Merkle accumulator](/reference/glossary#merkle-accumulator). This information is used to calculate the root hash of the current state of the Diem Blockchain. +* Execution maintains a “scratchpad,” which holds in-memory copies of the relevant portions of the [Merkle accumulator](/reference/glossary#merkle-accumulator). This information is used to calculate the root hash of the current state of the Aptos Blockchain. * The root hash of the current state is combined with the information about the transactions in the proposed block to determine the new root hash of the accumulator. This is done prior to persisting any data, and to ensure that no state or transaction is stored until agreement is reached by a quorum of validators. * Execution computes the speculative root hash and then the consensus component of VX signs this root hash and attempts to reach agreement on this root hash with other validators. @@ -277,20 +277,20 @@ If a quorum of validators agrees on the block execution results, the consensus c Execution takes the values from its “scratchpad” and sends them to storage for persistence via `Storage::SaveTransactions()`. Execution then prunes the old values from the “scratchpad” that are no longer needed (for example, parallel blocks that cannot be committed). -For implementation details refer to the [Execution README](https://github.com/diem/diem/tree/main/execution). +For implementation details refer to the [Execution README](https://github.com/aptos/aptos/tree/main/execution). ### Storage ![Figure 1.6 Storage](/img/docs/storage.svg) Figure 1.6 Storage -The storage component persists agreed upon blocks of transactions and their execution results to the Diem Blockchain. A block of transactions (which includes transaction TN) will be saved via storage when: +The storage component persists agreed upon blocks of transactions and their execution results to the Aptos Blockchain. A block of transactions (which includes transaction TN) will be saved via storage when: * There is agreement between more than a quorum (2f+1) of the validators participating in consensus on all of the following: * The transactions to include in a block * The order of the transactions * The execution results of the transactions to be included in the block -Refer to [Merkle accumulator](/reference/glossary#merkle-accumulator) for information on how a transaction is appended to the data structure representing the Diem Blockchain. +Refer to [Merkle accumulator](/reference/glossary#merkle-accumulator) for information on how a transaction is appended to the data structure representing the Aptos Blockchain. #### 1. VM → Storage @@ -308,11 +308,11 @@ When the consensus component calls `Execution::ExecuteBlock()`, execution reads * Once consensus is reached on a block of transactions, execution calls storage via `Storage::SaveTransactions()` to save the block of transactions and permanently record them. This will also store the signatures from the validator nodes that agreed on this block of transactions. * The in-memory data in “scratchpad” for this block is passed to update storage and persist the transactions. * When the storage is updated, every account that was modified by these transactions will have its sequence number incremented by one. -* Note: The sequence number of an account on the Diem Blockchain increments by one for each committed transaction originating from that account. +* Note: The sequence number of an account on the Aptos Blockchain increments by one for each committed transaction originating from that account. #### 4. JSON-RPC Service → Storage For client queries that read information from the blockchain, the JSON-RPC service directly interacts with storage to read the requested information. -For implementation details refer to the [Storage README](https://github.com/diem/diem/tree/main/storage). +For implementation details refer to the [Storage README](https://github.com/aptos/aptos/tree/main/storage). diff --git a/developer-docs-site/docs/transactions/txns-types.md b/developer-docs-site/docs/transactions/txns-types.md index ec2167ee02e23..2147922a67600 100755 --- a/developer-docs-site/docs/transactions/txns-types.md +++ b/developer-docs-site/docs/transactions/txns-types.md @@ -7,5 +7,5 @@ sidebar_position: 2 In this section, we will be covering three types of transactions that can be sent by different types of accounts: * [Transactions that send payments to other accounts.](/transactions/txns-types/txns-send-payment) -* [Transactions that are sent to create accounts, and for minting and burning Diem Coins](/transactions/txns-types/txns-create-accounts-mint) +* [Transactions that are sent to create accounts, and for minting and burning Aptos Coins](/transactions/txns-types/txns-create-accounts-mint) * [Transactions to help with account recovery, key rotation, adding currencies and other account administration tasks](/transactions/txns-types/txns-manage-accounts) diff --git a/developer-docs-site/docs/transactions/txns-types/txns-create-accounts-mint.md b/developer-docs-site/docs/transactions/txns-types/txns-create-accounts-mint.md index 8dc3f8bb89d43..c6c634351df57 100755 --- a/developer-docs-site/docs/transactions/txns-types/txns-create-accounts-mint.md +++ b/developer-docs-site/docs/transactions/txns-types/txns-create-accounts-mint.md @@ -4,14 +4,14 @@ slug: "txns-create-accounts-mint" hidden: false --- Depending on the type of network you are using, you can use transactions to: -* [Create accounts and mint fake Diem Coins in testnet](/transactions/txns-types/txns-create-accounts-mint#create-accounts-mint-in-testnet) +* [Create accounts and mint fake Aptos Coins in testnet](/transactions/txns-types/txns-create-accounts-mint#create-accounts-mint-in-testnet) * [Create a ChildVASP account in mainnet and pre-mainnet](/transactions/txns-types/txns-create-accounts-mint#create-childvasp-accounts-in-mainnet-pre-mainnet) ## Create accounts, mint in testnet -If you are using [testnet](/reference/glossary#tesnet), you can use the [Faucet](/reference/glossary#faucet) service to perform certain actions that only by performed by the Diem Association on [mainnet](/reference/glossary#mainnet). You can do the following by sending requests to the faucet service endpoint: +If you are using [testnet](/reference/glossary#tesnet), you can use the [Faucet](/reference/glossary#faucet) service to perform certain actions that only by performed by the Aptos Association on [mainnet](/reference/glossary#mainnet). You can do the following by sending requests to the faucet service endpoint: * Create a [ParentVASP account](/reference/glossary#parentvasp-account). -* Mint and add fake Diem Coins to accounts for testing. +* Mint and add fake Aptos Coins to accounts for testing. To create a ParentVASP account in testnet, send a request like the code example below to the faucet server: ```http request @@ -24,18 +24,18 @@ In this example request, * `amount` is the amount of money available as the account balance. * `currency_code` is the specified currency for the amount. -This request first checks if there is an account available for the authorization key specified. If the account given by `auth_key` doesn’t exist, a ParentVASP account will be created with the balance of the `amount` in the `currency_code` specified. If the account already exists, this will simply give the account the specified amount of `currency_code` Diem Coins. +This request first checks if there is an account available for the authorization key specified. If the account given by `auth_key` doesn’t exist, a ParentVASP account will be created with the balance of the `amount` in the `currency_code` specified. If the account already exists, this will simply give the account the specified amount of `currency_code` Aptos Coins. ## Create ChildVASP accounts in mainnet, pre-mainnet -If you are a Regulated VASP, and have been approved by Diem Networks as a participant on the Diem Payment Network (DPN), you first need to complete an application with Diem Networks to have a ParentVASP account created on your behalf. +If you are a Regulated VASP, and have been approved by Aptos Networks as a participant on the Aptos Payment Network (DPN), you first need to complete an application with Aptos Networks to have a ParentVASP account created on your behalf. -Once Diem Networks creates your ParentVASP account (let’s call it Account **A**), you can create a [ChildVASP account](/reference/glossary#childvasp-account) if you wish. +Once Aptos Networks creates your ParentVASP account (let’s call it Account **A**), you can create a [ChildVASP account](/reference/glossary#childvasp-account) if you wish. -To create a ChildVASP account, send the [create_child_vasp_account](https://github.com/diem/diem/blob/main/aptos-move/diem-framework/script_documentation/script_documentation.md#script-create_child_vasp_account) transaction script from your **Account A** (your ParentVASP account). +To create a ChildVASP account, send the [create_child_vasp_account](https://github.com/aptos/aptos/blob/main/aptos-move/aptos-framework/script_documentation/script_documentation.md#script-create_child_vasp_account) transaction script from your **Account A** (your ParentVASP account). With a single ParentVASP account, you can create up to 256 ChildVASP accounts. This transaction script allows you to specify: * Which currency the new account should hold, or if it should hold all known currencies. * If you want to initialize the ChildVASP account with a specified amount of coins in a given currency. -A Regulated VASP can purchase Diem Coins from a Designated Dealer. +A Regulated VASP can purchase Aptos Coins from a Designated Dealer. diff --git a/developer-docs-site/docs/transactions/txns-types/txns-manage-accounts.md b/developer-docs-site/docs/transactions/txns-types/txns-manage-accounts.md index 7c4ace6a04d1a..a4ef9d500f748 100755 --- a/developer-docs-site/docs/transactions/txns-types/txns-manage-accounts.md +++ b/developer-docs-site/docs/transactions/txns-types/txns-manage-accounts.md @@ -12,21 +12,21 @@ Once an account has been created, you can use different types of transactions to If you are a Regulated VASP, you can designate one of your accounts as a recovery address account. The recovery address account should be a cold account (i.e., no transactions should be planned to be sent from that account). Use the recovery address account only for rotating the authentication key of an account that has registered itself with it and whose private key has been lost. -For this example, let's call this account **R**. To create recovery address account **R**, send a [create_recovery_address](https://github.com/diem/diem/blob/main/aptos-move/diem-framework/script_documentation/script_documentation.md#function-create_recovery_address) transaction from account **R**. +For this example, let's call this account **R**. To create recovery address account **R**, send a [create_recovery_address](https://github.com/aptos/aptos/blob/main/aptos-move/aptos-framework/script_documentation/script_documentation.md#function-create_recovery_address) transaction from account **R**. -After the recovery address **R** has been created, other accounts that belong to the VASP can register themselves with R by sending a [add_recovery_rotation_capability](https://github.com/diem/diem/blob/main/aptos-move/diem-framework/script_documentation/script_documentation.md#function-add_recovery_rotation_capability) transaction and specifying the recovery address as **R**. +After the recovery address **R** has been created, other accounts that belong to the VASP can register themselves with R by sending a [add_recovery_rotation_capability](https://github.com/aptos/aptos/blob/main/aptos-move/aptos-framework/script_documentation/script_documentation.md#function-add_recovery_rotation_capability) transaction and specifying the recovery address as **R**. ## Rotate authentication key If an account **A** wishes to update the authentication key needed to access it, it can do so by sending one of two transactions, depending on whether A has been registered with, or is, an account recovery address. -* If **A** has not registered itself with a recovery address, it can change its authentication key by sending a [rotate_authentication_key](https://github.com/diem/diem/blob/main/aptos-move/diem-framework/script_documentation/script_documentation.md#function-rotate_authentication_key) transaction with its new auth key. -* If **A** is part of a recovery address, then it can rotate its key by sending a [rotate_authentication_key_with_recovery_address](https://github.com/diem/diem/blob/main/aptos-move/diem-framework/script_documentation/script_documentation.md#function-rotate_authentication_key_with_recovery_address) transaction with its new authentication key, and itself as the `to_recover` address. +* If **A** has not registered itself with a recovery address, it can change its authentication key by sending a [rotate_authentication_key](https://github.com/aptos/aptos/blob/main/aptos-move/aptos-framework/script_documentation/script_documentation.md#function-rotate_authentication_key) transaction with its new auth key. +* If **A** is part of a recovery address, then it can rotate its key by sending a [rotate_authentication_key_with_recovery_address](https://github.com/aptos/aptos/blob/main/aptos-move/aptos-framework/script_documentation/script_documentation.md#function-rotate_authentication_key_with_recovery_address) transaction with its new authentication key, and itself as the `to_recover` address. ## Add a currency to an account -If an account **A** wants to hold a balance of Diem Coins in a currency **C** that it currently doesn’t hold, it can add a balance for **C** by sending an [add_currency_to_account](https://github.com/diem/diem/blob/main/aptos-move/diem-framework/script_documentation/script_documentation.md#0x1_AccountAdministrationScripts_add_currency_to_account) transaction specifying **C** as the currency, from **A**. +If an account **A** wants to hold a balance of Aptos Coins in a currency **C** that it currently doesn’t hold, it can add a balance for **C** by sending an [add_currency_to_account](https://github.com/aptos/aptos/blob/main/aptos-move/aptos-framework/script_documentation/script_documentation.md#0x1_AccountAdministrationScripts_add_currency_to_account) transaction specifying **C** as the currency, from **A**. It’s important to note that **C** must be a recognized currency on-chain, and **A** cannot hold a balance in **C** already; otherwise, this transaction will fail to execute. diff --git a/developer-docs-site/docs/transactions/txns-types/txns-send-payment.md b/developer-docs-site/docs/transactions/txns-types/txns-send-payment.md index 76be3c3bbe3fe..55146e4ff6ddc 100755 --- a/developer-docs-site/docs/transactions/txns-types/txns-send-payment.md +++ b/developer-docs-site/docs/transactions/txns-types/txns-send-payment.md @@ -7,14 +7,14 @@ An account can send a payment to another account by sending a transaction. ## Introduction -If an account **A** wishes to send a payment to another account **B,** it can do so by sending a [peer_to_peer_with_metadata](https://github.com/diem/diem/blob/main/aptos-move/diem-framework/script_documentation/script_documentation.md#script-peer_to_peer_with_metadata) script transaction. +If an account **A** wishes to send a payment to another account **B,** it can do so by sending a [peer_to_peer_with_metadata](https://github.com/aptos/aptos/blob/main/aptos-move/aptos-framework/script_documentation/script_documentation.md#script-peer_to_peer_with_metadata) script transaction. When a payment is made, the sender must specify: * The currency the payment is being made in * The amount to send * The account the payment is being made to, which in this example is account **B**. -When constructing a transaction, account **A** can also specify the metadata parameter. This parameter can be of any form as long as **A** and **B** agree on it, subject to certain rules specified in the agreement between a [Regulated VASP](/reference/glossary# and Diem Networks, and a `metadata_signature` used for dual attestation. +When constructing a transaction, account **A** can also specify the metadata parameter. This parameter can be of any form as long as **A** and **B** agree on it, subject to certain rules specified in the agreement between a [Regulated VASP](/reference/glossary# and Aptos Networks, and a `metadata_signature` used for dual attestation. ## Dual attestation @@ -28,6 +28,6 @@ Every transaction sending payments between two distinct Regulated VASP accounts ### Update dual attestation information -If a Regulated VASP wishes to update their `base_url` or `compliance_public_key`, it can do so by sending a [rotate_dual_attestation_info](https://github.com/diem/diem/blob/main/aptos-move/diem-framework/script_documentation/script_documentation.md#script-rotate_dual_attestation_info) transaction. The Regulated VASP has to send this transaction from their ParentVASP account (this is the account that holds dual attestation data). For example, if a Regulated VASP wishes to change the private key they use to sign metadata for dual attestation, they can send this transaction to do so. +If a Regulated VASP wishes to update their `base_url` or `compliance_public_key`, it can do so by sending a [rotate_dual_attestation_info](https://github.com/aptos/aptos/blob/main/aptos-move/aptos-framework/script_documentation/script_documentation.md#script-rotate_dual_attestation_info) transaction. The Regulated VASP has to send this transaction from their ParentVASP account (this is the account that holds dual attestation data). For example, if a Regulated VASP wishes to change the private key they use to sign metadata for dual attestation, they can send this transaction to do so. Once this transaction is executed, all transactions subject to dual attestation will be checked using the new `compliance_public_key`. Because of this, Regulated VASPs should be careful to communicate this change and ensure that there are no outstanding payment transactions that they have previously signed but that have not yet been committed on-chain, since these will be rejected if the `compliance_public_key` has changed. diff --git a/developer-docs-site/docs/tutorials/configure-run-public-fullnode.md b/developer-docs-site/docs/tutorials/configure-run-public-fullnode.md index 35f6751db3900..b8acc011a3cc4 100755 --- a/developer-docs-site/docs/tutorials/configure-run-public-fullnode.md +++ b/developer-docs-site/docs/tutorials/configure-run-public-fullnode.md @@ -3,9 +3,9 @@ title: "Configure and run a public FullNode" slug: "configure-run-public-fullnode" hidden: false --- -You can run [FullNodes](/basics/basics-fullnodes) to verify the state and synchronize to the Diem Blockchain. FullNodes can be run by anyone. FullNodes replicate the full state of the blockchain by querying each other, or by querying the validators directly. +You can run [FullNodes](/basics/basics-fullnodes) to verify the state and synchronize to the Aptos Blockchain. FullNodes can be run by anyone. FullNodes replicate the full state of the blockchain by querying each other, or by querying the validators directly. -This tutorial details how to configure a public FullNode to connect to *testnet*, the Diem Payment Network’s public test network.. +This tutorial details how to configure a public FullNode to connect to *testnet*, the Aptos Payment Network’s public test network.. > > **Note:** Your public FullNode will be connected to testnet with a JSON-RPC endpoint accessible on your computer at localhost:8080. @@ -15,18 +15,18 @@ This tutorial details how to configure a public FullNode to connect to *testnet* Before you get started with this tutorial, we recommend you familiarize yourself with the following: * [Validator node concepts](/basics/basics-validator-nodes) * [FullNode concepts](/basics/basics-fullnodes) -* [JSON-RPC specifications](https://github.com/diem/diem/blob/main/json-rpc/json-rpc-spec.md) +* [JSON-RPC specifications](https://github.com/aptos/aptos/blob/main/json-rpc/json-rpc-spec.md) * [CLI reference](/tools/cli-reference) ## Getting started -You can configure a public FullNode in two ways: using the Diem Core source code or Docker. +You can configure a public FullNode in two ways: using the Aptos Core source code or Docker. -### Using Diem Core source code -1. Download and clone the Diem Core repository from GitHub and prepare your developer environment by running the following commands: +### Using Aptos Core source code +1. Download and clone the Aptos Core repository from GitHub and prepare your developer environment by running the following commands: ``` - git clone https://github.com/diem/diem.git - cd diem + git clone https://github.com/aptos/aptos.git + cd aptos ./scripts/dev_setup.sh source ~/.cargo/env ``` @@ -37,7 +37,7 @@ You can configure a public FullNode in two ways: using the Diem Core source code * Copy `config/src/config/test_data/public_full_node.yaml` to your current working directory. - * Download [genesis](https://testnet.diem.com/genesis.blob) and [waypoint](https://testnet.diem.com/waypoint.txt) files for testnet. + * Download [genesis](https://testnet.aptos.com/genesis.blob) and [waypoint](https://testnet.aptos.com/waypoint.txt) files for testnet. * Update the public_full_node.yaml file in your current working directory by: @@ -51,7 +51,7 @@ You can configure a public FullNode in two ways: using the Diem Core source code ``` seed_addrs: D4C4FB4956D899E55289083F45AC5D84: - - "/dns4/fn.testnet.diem.com/tcp/6182/ln-noise-ik/d29d01bed8ab6c30921b327823f7e92c63f8371456fb110256e8c0e8911f4938/ln-handshake/0" + - "/dns4/fn.testnet.aptos.com/tcp/6182/ln-noise-ik/d29d01bed8ab6c30921b327823f7e92c63f8371456fb110256e8c0e8911f4938/ln-handshake/0" ``` * Disable on-chain discovery for the `discovery_method: "none"` (this is not required but it will limit log spew) * @@ -69,8 +69,8 @@ You can also use Docker to configure and run your PublicFullNode. 1. Install Docker and Docker-Compose. 2. Create a directory for your public FullNode composition. -3. Download the public FullNode [docker compose](https://github.com/diem/diem/tree/main/docker/compose/public_full_node/docker-compose.yaml) and [diem](https://github.com/diem/diem/tree/main/docker/compose/public_full_node/public_full_node.yaml) configuration files into this directory. -4. Download [genesis](https://testnet.diem.com/genesis.blob) and [waypoint](https://testnet.diem.com/waypoint.txt) files for testnet into that directory. +3. Download the public FullNode [docker compose](https://github.com/aptos/aptos/tree/main/docker/compose/public_full_node/docker-compose.yaml) and [aptos](https://github.com/aptos/aptos/tree/main/docker/compose/public_full_node/public_full_node.yaml) configuration files into this directory. +4. Download [genesis](https://testnet.aptos.com/genesis.blob) and [waypoint](https://testnet.aptos.com/waypoint.txt) files for testnet into that directory. 5. Run docker-compose: `docker-compose up`. ### Understand and verify the correctness of your FullNode @@ -78,11 +78,11 @@ You can also use Docker to configure and run your PublicFullNode. #### Initial synchronization During the initial synchronization of your FullNode, there may be a lot of data to transfer. -* Progress can be monitored by querying the metrics port `curl 127.0.0.1:9101/metrics 2> /dev/null | grep diem_state_sync_version | grep type`, which will print out several counters: - * `diem_state_sync_version{type="committed"}` -- the latest (blockchain) version that is backed by a signed commitment (ledger info) from the validators - * `diem_state_sync_version{type="highest"}` -- the highest or latest known version, typically the same as target - * `diem_state_sync_version{type="synced"}` -- the latest blockchain version available in storage, it might not be backed by a ledger info - * `diem_state_sync_version{type="target"}` -- the state sync's current target ledger info version +* Progress can be monitored by querying the metrics port `curl 127.0.0.1:9101/metrics 2> /dev/null | grep aptos_state_sync_version | grep type`, which will print out several counters: + * `aptos_state_sync_version{type="committed"}` -- the latest (blockchain) version that is backed by a signed commitment (ledger info) from the validators + * `aptos_state_sync_version{type="highest"}` -- the highest or latest known version, typically the same as target + * `aptos_state_sync_version{type="synced"}` -- the latest blockchain version available in storage, it might not be backed by a ledger info + * `aptos_state_sync_version{type="target"}` -- the state sync's current target ledger info version * The Executor component will update the output log by showing that 1000 blocks are committed at a time: ``` @@ -100,5 +100,5 @@ During the initial synchronization of your FullNode, there may be a lot of data # Enter the container: docker exec -it $id /bin/bash # Observe the volume (ledger) size: - du -cs -BM /opt/diem/data + du -cs -BM /opt/aptos/data ``` \ No newline at end of file diff --git a/developer-docs-site/docs/tutorials/tutorial-my-first-client.md b/developer-docs-site/docs/tutorials/tutorial-my-first-client.md index b650eb6dc0374..5c8b0873cf811 100755 --- a/developer-docs-site/docs/tutorials/tutorial-my-first-client.md +++ b/developer-docs-site/docs/tutorials/tutorial-my-first-client.md @@ -17,7 +17,7 @@ This tutorial is an introduction to client development on testnet using the offi ## Getting Started -In this tutorial, we demonstrate the key elements of a basic client using the official SDKs to interact with the Blockchain. The code for the tutorial is available here: [my-first-client](https://github.com/diem/my-first-client). The code in this project can be run from the root of the project directory by issuing the `make` command. +In this tutorial, we demonstrate the key elements of a basic client using the official SDKs to interact with the Blockchain. The code for the tutorial is available here: [my-first-client](https://github.com/aptos/my-first-client). The code in this project can be run from the root of the project directory by issuing the `make` command. The example code uses the official Client SDKs. Currently, Go, Java, and Python are available. These libraries are developed to simplify aspects of the development process. If your language is not currently supported, or on the upcoming roadmap (Rust), then you will want to refer to the low-level JSON-RPC API. To request additional functionality or to track when it is implemented, you can submit a GitHub issue on the corresponding project repository. @@ -26,12 +26,12 @@ To see advanced usage, refer to the Reference Wallet project. ## Setup -All code examples are shared in the [my-first-client](https://github.com/diem/my-first-client) repo on GitHub. +All code examples are shared in the [my-first-client](https://github.com/aptos/my-first-client) repo on GitHub. ### Clone the repo: ```text -git clone [https://github.com/diem/my-first-client.git](https://github.com/diem/my-first-client.git +git clone [https://github.com/aptos/my-first-client.git](https://github.com/aptos/my-first-client.git ``` Each SDK has the following system requirements: @@ -158,7 +158,7 @@ print(account) ```java //connect to testnet -DiemClient client = Testnet.createClient(); +AptosClient client = Testnet.createClient(); //generate private key for new account PrivateKey privateKey = new Ed25519PrivateKey(new Ed25519PrivateKeyParameters(new SecureRandom())); @@ -254,7 +254,7 @@ client.wait_for_transaction(signed_txn) ```java //connect to testnet -DiemClient client = Testnet.createClient(); +AptosClient client = Testnet.createClient(); //generate private key for sender account PrivateKey senderPrivateKey = new Ed25519PrivateKey(new Ed25519PrivateKeyParameters(new SecureRandom())); @@ -364,7 +364,7 @@ encoded_intent_identifier = identifier.encode_intent(account_identifier, "XUS", print(f"Encoded IntentIdentifier: {encoded_intent_identifier}") # deserialize IntentIdentifier -intent_identifier = diem.identifier.decode_intent(encoded_intent_identifier, identifier.TLB) +intent_identifier = aptos.identifier.decode_intent(encoded_intent_identifier, identifier.TLB) print(f"Account (HEX) from intent: {utils.account_address_hex(intent_identifier.account_address)}") print(f"Amount from intent: {intent_identifier.amount}") print(f"Currency from intent: {intent_identifier.currency_code}") @@ -382,12 +382,12 @@ In the example below, we will set up a wallet with 100 XUS and then call the min -```python title="https://github.com/diem/my-first-client/blob/master/python/src/get_events_example.py" +```python title="https://github.com/aptos/my-first-client/blob/master/python/src/get_events_example.py" import time from random import randrange from threading import Thread from cryptography.hazmat.primitives.asymmetric.ed25519 import Ed25519PrivateKey -from diem import testnet, AuthKey, utils +from aptos import testnet, AuthKey, utils CURRENCY = "XUS" @@ -450,13 +450,13 @@ if __name__ == "__main__": -```java title="https://github.com/diem/my-first-client/blob/master/java/src/main/java/example/GetEventsExample.java" +```java title="https://github.com/aptos/my-first-client/blob/master/java/src/main/java/example/GetEventsExample.java" package example; import org.bouncycastle.crypto.params.Ed25519PrivateKeyParameters; -import org.diem.*; -import org.diem.jsonrpctypes.JsonRpc.Account; -import org.diem.jsonrpctypes.JsonRpc.Event; +import org.aptos.*; +import org.aptos.jsonrpctypes.JsonRpc.Account; +import org.aptos.jsonrpctypes.JsonRpc.Event; import java.security.SecureRandom; import java.util.List; import java.util.concurrent.ThreadLocalRandom; @@ -467,9 +467,9 @@ import java.util.concurrent.ThreadLocalRandom; public class GetEventsExample { public static final String CURRENCY_CODE = "XUS"; - public static void main(String[] args) throws DiemException { + public static void main(String[] args) throws AptosException { //connect to testnet - DiemClient client = Testnet.createClient(); + AptosClient client = Testnet.createClient(); //create new account SecureRandom random = new SecureRandom(); Ed25519PrivateKeyParameters privateKeyParams = new Ed25519PrivateKeyParameters(random); @@ -484,14 +484,14 @@ public class GetEventsExample { //demonstrates events subscription subscribe(client, eventsKey); } - public static void subscribe(DiemClient client, String eventsKey) { + public static void subscribe(AptosClient client, String eventsKey) { Runnable listener = () -> { long start = 0; for (int i = 0; i < 15; i++) { List<Event> events; try { events = client.getEvents(eventsKey, start, 10); - } catch (DiemException e) { + } catch (AptosException e) { throw new RuntimeException(e); } start += events.size(); @@ -510,7 +510,7 @@ public class GetEventsExample { Thread listenerThread = new Thread(listener); listenerThread.start(); } - private static void startMinter(DiemClient client, AuthKey authKey) { + private static void startMinter(AptosClient client, AuthKey authKey) { Runnable minter = () -> { for (int i = 0; i < 10; i++) { int amount = 1000000; diff --git a/developer-docs-site/docs/tutorials/tutorial-my-first-transaction.md b/developer-docs-site/docs/tutorials/tutorial-my-first-transaction.md index e85ae49e4d941..c53c27600b1cb 100755 --- a/developer-docs-site/docs/tutorials/tutorial-my-first-transaction.md +++ b/developer-docs-site/docs/tutorials/tutorial-my-first-transaction.md @@ -5,13 +5,13 @@ hidden: false --- import BlockQuote from "@site/src/components/BlockQuote"; -This document will guide you through executing your first transaction on the Diem Blockchain's [testnet](/reference/glossary#testnet). Before you proceed, we recommend that you read the following to familiarize yourself with the key concepts: +This document will guide you through executing your first transaction on the Aptos Blockchain's [testnet](/reference/glossary#testnet). Before you proceed, we recommend that you read the following to familiarize yourself with the key concepts: * [Basics](/basics/basics-txns-states) * [Life of a transaction](/transactions/basics-life-of-txn) -We provide a command line interface (CLI) client to interact with the Diem Blockchain. +We provide a command line interface (CLI) client to interact with the Aptos Blockchain. #### Assumptions @@ -26,23 +26,23 @@ All commands in this document assume that: ## Steps to submit a transaction -In this example, we will download the necessary Diem components and execute a transaction between two users: Alice and Bob. +In this example, we will download the necessary Aptos components and execute a transaction between two users: Alice and Bob. -To submit a transaction to a validator node on the Diem testnet: +To submit a transaction to a validator node on the Aptos testnet: -1. [Clone and build Diem Core](#clone-and-build-diem-core). -2. [Build the Diem CLI client and connect to the testnet](#build-diem-cli-client-and-connect-to-the-testnet). +1. [Clone and build Aptos Core](#clone-and-build-aptos-core). +2. [Build the Aptos CLI client and connect to the testnet](#build-aptos-cli-client-and-connect-to-the-testnet). 3. [Create accounts for Alice and Bob](#create-accounts-for-alice-and-bob). -4. [Add Fake Diem Coins to Alice’s and Bob’s accounts](#add-fake-diem-coins-to-alices-and-bobs-accounts). +4. [Add Fake Aptos Coins to Alice’s and Bob’s accounts](#add-fake-aptos-coins-to-alices-and-bobs-accounts). 5. [Submit a transaction](#submit-a-transaction). -### Clone and build Diem Core +### Clone and build Aptos Core -1. Clone the Diem Core repository +1. Clone the Aptos Core repository ```bash - git clone https://github.com/diem/diem.git && cd diem + git clone https://github.com/aptos/aptos.git && cd aptos ``` 2. Checkout the `testnet` branch @@ -52,7 +52,7 @@ To submit a transaction to a validator node on the Diem testnet: ``` 3. Install dependencies - To setup Diem Core, change to the `diem` directory and run the setup script to install the dependencies, as shown below: + To setup Aptos Core, change to the `aptos` directory and run the setup script to install the dependencies, as shown below: ``` ./scripts/dev_setup.sh @@ -60,7 +60,7 @@ To submit a transaction to a validator node on the Diem testnet: The setup script performs these actions: - * Installs rustup, an installer for the Rust programming language, in which Diem Core is implemented. + * Installs rustup, an installer for the Rust programming language, in which Aptos Core is implemented. * Installs the required versions of the rust-toolchain. * Installs CMake to manage the build process. @@ -68,9 +68,9 @@ To submit a transaction to a validator node on the Diem testnet: If your setup fails, see [Troubleshooting](#setup) -### Build Diem CLI client and connect to the testnet +### Build Aptos CLI client and connect to the testnet -To connect to a validator node running on the Diem testnet, run the client as shown below. +To connect to a validator node running on the Aptos testnet, run the client as shown below. ```bash @@ -92,7 +92,7 @@ account | a query | q Query operations transfer | transferb | t | tb - | | [gas_unit_price_in_micro_diems (default=0)] [max_gas_amount_in_micro_diems (default 400_000)] Suffix 'b' is for blocking. + | | [gas_unit_price_in_micro_aptoss (default=0)] [max_gas_amount_in_micro_aptoss (default 400_000)] Suffix 'b' is for blocking. Transfer coins from one account to another. info | i Print cli config and client internal information @@ -104,7 +104,7 @@ quit | q! Please, input commands: -diem% +aptos% ``` @@ -120,10 +120,10 @@ Once your client is connected to the testnet, you can run CLI commands to create #### Step 1: Check if the CLI client Is running on your system -A `diem%` command line prompt indicates that your Diem CLI client is running. To see the help information for the `account` command enter “account” as shown below: +A `aptos%` command line prompt indicates that your Aptos CLI client is running. To see the help information for the `account` command enter “account” as shown below: ``` -diem% account +aptos% account usage: account Use the following args for this command: @@ -135,9 +135,9 @@ create | c list | la Print all accounts that were created or loaded recover | r - Recover Diem wallet from the file path + Recover Aptos wallet from the file path write | w - Save Diem wallet mnemonic recovery seed to disk + Save Aptos wallet mnemonic recovery seed to disk mint | mintb | m | mb | [use_base_units (default=false)] Send currency of the given type from the faucet address to the given recipient address. Creates an account at the recipient address if one does not already exist. addc | addcb | ac | acb @@ -148,12 +148,12 @@ addc | addcb | ac | acb #### Step 2: Create Alice’s account > ->**Note**: Creating an account using the CLI does not update the Diem Blockchain, it just creates a local key-pair. +>**Note**: Creating an account using the CLI does not update the Aptos Blockchain, it just creates a local key-pair. > To create Alice’s account, enter this command: -`diem% account create` +`aptos% account create` Sample output on success: @@ -165,14 +165,14 @@ Created/retrieved local account #0 address 9d02da2312d2687ca665ccf77f2435fc * 0 is the index of Alice’s account. * The hex string is the address of Alice’s account. -The index is just a way to refer to Alice’s account. Users can use the account index, a local CLI index, in other CLI commands to refer to the accounts they have created. The index is meaningless to the blockchain. Alice’s account will be created on the blockchain only when fake Diem Coins are added to Alice’s account or transferred to Alice’s account via a transfer from another user. Note that you may also use the hex address in CLI commands. The account index is just a convenience wrapper around the account address. +The index is just a way to refer to Alice’s account. Users can use the account index, a local CLI index, in other CLI commands to refer to the accounts they have created. The index is meaningless to the blockchain. Alice’s account will be created on the blockchain only when fake Aptos Coins are added to Alice’s account or transferred to Alice’s account via a transfer from another user. Note that you may also use the hex address in CLI commands. The account index is just a convenience wrapper around the account address. #### Step 3: Create Bob’s account To create Bob’s account, repeat the account creation command: -`diem% account create` +`aptos% account create` Sample output on success: @@ -189,7 +189,7 @@ Created/retrieved local account #1 address 3099d7230aa336f5dcfe13c1231454ce To list the accounts you have created, enter this command: -`diem% account list` +`aptos% account list` Sample output on success: ``` @@ -198,25 +198,25 @@ User account index: 1, address: 3099d7230aa336f5dcfe13c1231454ce, private_key: " ``` -The sequence number for an account indicates the number of transactions that have been sent from that account. It is incremented by one every time a transaction sent from that account is executed and stored in the Diem Blockchain. To learn more, refer to [sequence number](/reference/glossary#sequence-number). +The sequence number for an account indicates the number of transactions that have been sent from that account. It is incremented by one every time a transaction sent from that account is executed and stored in the Aptos Blockchain. To learn more, refer to [sequence number](/reference/glossary#sequence-number). -### Add Fake Diem Coins to Alice’s and Bob’s accounts +### Add Fake Aptos Coins to Alice’s and Bob’s accounts -Adding fake Diem Coins with no real-world value to accounts on testnet is done via Faucet. Faucet is a service that runs along with the testnet. This service only edocs/transactions/basics-life-of-txnxists to facilitate minting coins for testnet and will not exist for mainnet. Faucet creates Diem Coins with no real-world value. Assuming you’ve [created Alice’s and Bob’s account](#create-accounts-for-alice-and-bob), with index 0 and index 1 respectively, you can follow the steps below to add fake Diem Coins to both accounts. +Adding fake Aptos Coins with no real-world value to accounts on testnet is done via Faucet. Faucet is a service that runs along with the testnet. This service only edocs/transactions/basics-life-of-txnxists to facilitate minting coins for testnet and will not exist for mainnet. Faucet creates Aptos Coins with no real-world value. Assuming you’ve [created Alice’s and Bob’s account](#create-accounts-for-alice-and-bob), with index 0 and index 1 respectively, you can follow the steps below to add fake Aptos Coins to both accounts. -#### Step 1: Add 110 Diem Coins to Alice’s account +#### Step 1: Add 110 Aptos Coins to Alice’s account -To mint fake Diem Coins and add them to Alice’s account, enter this command: +To mint fake Aptos Coins and add them to Alice’s account, enter this command: -`diem% account mint 0 110 XUS` +`aptos% account mint 0 110 XUS` * 0 is the index of Alice’s account. -* 110 is the amount of fake Diem Coins to be added to Alice’s account. -* XUS is the currency code for the fake Diem Coins +* 110 is the amount of fake Aptos Coins to be added to Alice’s account. +* XUS is the currency code for the fake Aptos Coins -A successful account “mint” command will also create Alice’s account on the blockchain. Note that “minting” on Testnet means adding new fake Diem Coins to an account. +A successful account “mint” command will also create Alice’s account on the blockchain. Note that “minting” on Testnet means adding new fake Aptos Coins to an account. Sample output on success: @@ -232,16 +232,16 @@ When the request is submitted, it means that it has been added to the mempool (o If your account “mint” command did not submit your request successfully, refer to [Troubleshooting](#minting-and-adding-money-to-account) -#### Step 2: Add 52 Diem Coins to Bob’s account +#### Step 2: Add 52 Aptos Coins to Bob’s account -To mint fake Diem Coins and add them to Bob’s account, enter this command: +To mint fake Aptos Coins and add them to Bob’s account, enter this command: -`diem% account mint 1 52 XUS` +`aptos% account mint 1 52 XUS` * 1 is the index of Bob’s account. -* 52 is the amount of Diem to be added to Bob’s account. -* XUS is the currency code for the fake Diem Coins +* 52 is the amount of Aptos to be added to Bob’s account. +* XUS is the currency code for the fake Aptos Coins A successful account “mint” command can also create Bob’s account on the blockchain. Another way to create Bob’s account on the blockchain is to transfer money from Alice’s account to Bob’s account. @@ -261,7 +261,7 @@ If your account mint command did not submit your request successfully, refer to To check the balance in Alice’s account, enter this command: -`diem% query balance 0` +`aptos% query balance 0` Sample output on success: @@ -269,7 +269,7 @@ Sample output on success: To check the balance in Bob’s account, enter this command: -`diem% query balance 1` +`aptos% query balance 1` Sample output on success: @@ -277,15 +277,15 @@ Sample output on success: ### Submit a transaction -Before we submit a transaction to transfer Diem Coins from Alice’s account to Bob’s account, we will query the sequence number of each account. This will help us understand how executing a transaction changes the sequence number of each account. +Before we submit a transaction to transfer Aptos Coins from Alice’s account to Bob’s account, we will query the sequence number of each account. This will help us understand how executing a transaction changes the sequence number of each account. #### Query the accounts’ sequence numbers ```plaintext -diem% query sequence 0 +aptos% query sequence 0 >> Getting current sequence number Sequence number is: 0 -diem% query sequence 1 +aptos% query sequence 1 >> Getting current sequence number Sequence number is: 0 ``` @@ -294,14 +294,14 @@ In `query sequence 0`, 0 is the index of Alice’s account. A sequence number of #### Transfer money -To submit a transaction to transfer 10 Diem Coins from Alice’s account to Bob’s account, enter this command: +To submit a transaction to transfer 10 Aptos Coins from Alice’s account to Bob’s account, enter this command: -`diem% transfer 0 1 10 XUS` +`aptos% transfer 0 1 10 XUS` * 0 is the index of Alice’s account. * 1 is the index of Bob’s account. -* 10 is the number of fake Diem Coins to transfer from Alice’s account to Bob’s account. -* XUS is the currency code for the fake Diem Coins +* 10 is the number of fake Aptos Coins to transfer from Alice’s account to Bob’s account. +* XUS is the currency code for the fake Aptos Coins Sample output on success: @@ -320,17 +320,17 @@ To troubleshoot the transfer command, refer to [Troubleshooting](#the-transfer-c **The Blocking Transfer Command**: You can use the `transferb` command (as shown below), instead of the `transfer` command. `transferb` will submit the transaction and return to the client prompt only after the transaction has been committed to the blockchain. An example is shown below: -`diem% transferb 0 1 10 XUS` +`aptos% transferb 0 1 10 XUS` Refer to [Life of a transaction](/transactions/basics-life-of-txn) for an understanding of the lifecycle of a transaction from submission to execution and storage. #### Query sequence number after transfer ``` -diem% query sequence 0 +aptos% query sequence 0 >> Getting current sequence number Sequence number is: 1 -diem% query sequence 1 +aptos% query sequence 1 >> Getting current sequence number Sequence number is: 0 ``` @@ -339,18 +339,18 @@ The sequence number of 1 for Alice’s account (index 0) indicates that one tran #### Check the balance in both accounts after transfer -To check the final balance in both accounts, query the balance again for each account as you did in [this step](#step-3-check-the-balance). If your transaction (transfer) executed successfully, you should see 100 fake Diem Coins in Alice’s account and 62 fake Diem Coins in Bob’s account. +To check the final balance in both accounts, query the balance again for each account as you did in [this step](#step-3-check-the-balance). If your transaction (transfer) executed successfully, you should see 100 fake Aptos Coins in Alice’s account and 62 fake Aptos Coins in Bob’s account. ``` -diem% query balance 0 +aptos% query balance 0 Balance is: 100.000000XUS -diem% query balance 1 +aptos% query balance 1 Balance is: 62.000000XUS ``` ### Congratulations! -You have successfully executed your transaction on the Diem testnet and transferred 10 Diem Coins from Alice’s account to Bob’s account! +You have successfully executed your transaction on the Aptos testnet and transferred 10 Aptos Coins from Alice’s account to Bob’s account! ## Troubleshooting @@ -358,23 +358,23 @@ You have successfully executed your transaction on the Diem testnet and transfer ### Setup * Update Rust: - * Run `rustup update` from your diem directory. + * Run `rustup update` from your aptos directory. * Update protoc: * Update `protoc` to version 3.6.0 or above. -* Re-run setup script from your diem directory: +* Re-run setup script from your aptos directory: * `./scripts/dev_setup.sh` ### Client build and run -If you are experiencing build failures, try to remove the cargo lock file from the diem directory: +If you are experiencing build failures, try to remove the cargo lock file from the aptos directory: * `rm Cargo.lock` If your client did not connect to the testnet: * Check your internet connection. -* Ensure that you are using the latest version of the client. Pull the latest Diem Core and rerun the client: `./scripts/cli/start_cli_testnet.sh` +* Ensure that you are using the latest version of the client. Pull the latest Aptos Core and rerun the client: `./scripts/cli/start_cli_testnet.sh` ### Minting and adding money to account @@ -382,7 +382,7 @@ If your client did not connect to the testnet: * If the validator node you connected to on testnet is unavailable, you will get a “Server unavailable” message as shown below: ``` -diem% account mint 0 110 XUS +aptos% account mint 0 110 XUS >> Minting coins [ERROR] Error minting coins: Server unavailable, please retry and/or check **if** host passed to the client is running ``` @@ -391,14 +391,14 @@ diem% account mint 0 110 XUS * To check if an account exists, query the account state. For an account with index 0 enter this: - `diem% query account_state 0` + `aptos% query account_state 0` ### The transfer command If the testnet validator node (your client was connected to) is unavailable or your connection to the testnet has timed-out, you will see this error: ``` -diem% transfer 0 1 10 XUS +aptos% transfer 0 1 10 XUS >> Transferring [ERROR] Failed to perform transaction: Server unavailable, please retry and/or check if host passed to the client is running ``` @@ -406,7 +406,7 @@ To troubleshoot transfer errors: * Check the connection to testnet. * Query the sender account to make sure it exists. Use the following command for an account with index 0:`query account_state 0` -* You can try quitting the client using `quit` or `q!`, and rerun the following command to connect to the testnet: `./scripts/cli/start_cli_testnet.sh` from the diem directory +* You can try quitting the client using `quit` or `q!`, and rerun the following command to connect to the testnet: `./scripts/cli/start_cli_testnet.sh` from the aptos directory ## Sample outputs of additional query commands @@ -415,7 +415,7 @@ To troubleshoot transfer errors: This example will query for a single transaction's details using the account and sequence number. ``` -diem% query txn_acc_seq 0 0 true +aptos% query txn_acc_seq 0 0 true >>> Getting committed transaction by account and sequence number Committed transaction: Transaction { version: 51985530, @@ -549,7 +549,7 @@ Committed transaction: Transaction { In the following example, we will query for “sent” events from the account at reference index 0. You will notice there is a single event since we sent one transaction from this account. The proof of the current state is also returned so that verification can be performed that no events are missing - this is done when the query does not return “limit” events. ``` -diem% query event 0 sent 0 10 +aptos% query event 0 sent 0 10 >> Getting events by account and event type. Event { key: "03000000000000009d02da2312d2687ca665ccf77f2435fc", sequence_number: 0, transaction_version: 51985530, data: Some(EventData { r#type: "sentpayment", amount: Some(Amount { amount: 10000000, currency: "XUS" }), preburn_address: "", currency_code: "", new_to_xdx_exchange_rate: 0.0, sender: "9d02da2312d2687ca665ccf77f2435fc", receiver: "3099d7230aa336f5dcfe13c1231454ce", metadata: "", epoch: 0, round: 0, proposer: "", proposed_time: 0, destination_address: "", new_compliance_public_key: "", new_base_url: "", time_rotated_seconds: 0, created_address: "", role_id: 0, committed_timestamp_secs: 0 }) } Last event state: Account { @@ -591,7 +591,7 @@ Last event state: Account { In this example, we will query for the state of a single account. ```plaintext -diem% query account_state 0 +aptos% query account_state 0 >> Getting latest account state Latest account state is: Account: ( @@ -678,4 +678,4 @@ Latest account state is: Once you have executed your first transaction, you may refer to the document [Life of a transaction](/transactions/basics-life-of-txn) for: * A look "under the hood" at the lifecycle of a transaction from submission to execution. -* An understanding of the interactions between each logical component of a Diem validator as transactions get submitted and executed in the Diem ecosystem. +* An understanding of the interactions between each logical component of a Aptos validator as transactions get submitted and executed in the Aptos ecosystem. diff --git a/developer-docs-site/docs/tutorials/tutorial-query-the-blockchain.md b/developer-docs-site/docs/tutorials/tutorial-query-the-blockchain.md index f233e9e2a0057..8ded8aafdd359 100755 --- a/developer-docs-site/docs/tutorials/tutorial-query-the-blockchain.md +++ b/developer-docs-site/docs/tutorials/tutorial-query-the-blockchain.md @@ -3,7 +3,7 @@ title: "Query the blockchain" slug: "tutorial-query-the-blockchain" hidden: false --- -The JSON-RPC service provides APIs for clients to query the Diem Blockchain. This tutorial will guide you through the different methods you can use. You can test these on testnet. +The JSON-RPC service provides APIs for clients to query the Aptos Blockchain. This tutorial will guide you through the different methods you can use. You can test these on testnet. #### Assumptions @@ -19,9 +19,9 @@ If you have already completed the My First Transaction tutorial, you can use the * [Account address: Hex-coded account address](/tutorials/tutorial-my-first-transaction#step-4-optional-list-accounts) ## Get account information -To get information about Alice’s account, use [get_account](https://github.com/diem/diem/blob/main/json-rpc/docs/method_get_account.md). To run this method, you will need the hex-coded account address (see step 4 of My First Transaction). +To get information about Alice’s account, use [get_account](https://github.com/aptos/aptos/blob/main/json-rpc/docs/method_get_account.md). To run this method, you will need the hex-coded account address (see step 4 of My First Transaction). -In the example below, we have a request sent using [get_account](https://github.com/diem/diem/blob/main/json-rpc/docs/method_get_account.md) to learn information about Alice’s account and the response received. +In the example below, we have a request sent using [get_account](https://github.com/aptos/aptos/blob/main/json-rpc/docs/method_get_account.md) to learn information about Alice’s account and the response received. ``` // Request: fetches account for account address "5261f913eab22cfc448a815a0e672143"curl -X POST -H "Content-Type: application/json" --data '{"jsonrpc":"2.0","method":"get_account","params":["5261f913eab22cfc448a815a0e672143"],"id":1}' https://testnet.libra.org/v1 @@ -30,12 +30,12 @@ In the example below, we have a request sent using [get_account](https://github. ## Get transactions for an account -To see all the transactions sent by Alice’s account, you can use [get_account_transactions](https://github.com/diem/diem/blob/main/json-rpc/docs/method_get_account_transactions.md). You will need: +To see all the transactions sent by Alice’s account, you can use [get_account_transactions](https://github.com/aptos/aptos/blob/main/json-rpc/docs/method_get_account_transactions.md). You will need: * Alice’s hex-code account address * the starting sequence number * the maximum number of transactions you want returned for this method -In the example below, we have a request sent using [get_account_transactions](https://github.com/diem/diem/blob/main/json-rpc/docs/method_get_account_transactions.md) to learn transaction information about Alice’s account and the response received. +In the example below, we have a request sent using [get_account_transactions](https://github.com/aptos/aptos/blob/main/json-rpc/docs/method_get_account_transactions.md) to learn transaction information about Alice’s account and the response received. ``` // Request: fetches account for account address "5261f913eab22cfc448a815a0e672143"curl -X POST -H "Content-Type: application/json" --data '{"jsonrpc":"2.0","method":"get_account_transactions","params":["5261f913eab22cfc448a815a0e672143", 0, 100, false],"id":1}' https://testnet.libra.org/v1 @@ -44,7 +44,7 @@ In the example below, we have a request sent using [get_account_transactions](ht ## Get the latest ledger state -You can check the current state of the testnet using [get_metadata](https://github.com/diem/diem/blob/main/json-rpc/docs/method_get_metadata.md). +You can check the current state of the testnet using [get_metadata](https://github.com/aptos/aptos/blob/main/json-rpc/docs/method_get_metadata.md). The example below has the request and response received. @@ -55,7 +55,7 @@ The example below has the request and response received. ## Get currencies available -Use [get_currencies](https://github.com/diem/diem/blob/main/json-rpc/docs/method_get_currencies.md) to query the types of currencies supported by the Diem Blockchain. +Use [get_currencies](https://github.com/aptos/aptos/blob/main/json-rpc/docs/method_get_currencies.md) to query the types of currencies supported by the Aptos Blockchain. ``` // Request: fetches currencies supported by the systemcurl -X POST -H "Content-Type: application/json" --data '{"jsonrpc":"2.0","method":"get_currencies","params":[],"id":1}' https://testnet.libra.org/v1 @@ -68,12 +68,12 @@ You can use different methods to query the blockchain and get the information yo | Method | Description | | ------------------------------------------------------------ | ------------------------------------------------------------ | -| [get_transactions](https://github.com/diem/diem/blob/main/json-rpc/docs/method_get_transactions.md) | Get transactions on the Diem Blockchain. | -| [get_account](https://github.com/diem/diem/blob/main/json-rpc/docs/method_get_account.md) | Get the latest account information for a given account address. | -| [get_account_transactions](https://github.com/diem/diem/blob/main/json-rpc/docs/method_get_account_transactions.md) | Get transactions sent by a particular account. | -| [get_metadata](https://github.com/diem/diem/blob/main/json-rpc/docs/method_get_metadata.md) | Get the blockchain metadata (for example, state as known to the current full node). | -| [get_events](https://github.com/diem/diem/blob/main/json-rpc/docs/method_get_events.md) | Get the events for a given event stream key. | -| [get_currencies](https://github.com/diem/diem/blob/main/json-rpc/docs/method_get_currencies.md) | Get information about all currencies supported by the Diem Blockchain. | +| [get_transactions](https://github.com/aptos/aptos/blob/main/json-rpc/docs/method_get_transactions.md) | Get transactions on the Aptos Blockchain. | +| [get_account](https://github.com/aptos/aptos/blob/main/json-rpc/docs/method_get_account.md) | Get the latest account information for a given account address. | +| [get_account_transactions](https://github.com/aptos/aptos/blob/main/json-rpc/docs/method_get_account_transactions.md) | Get transactions sent by a particular account. | +| [get_metadata](https://github.com/aptos/aptos/blob/main/json-rpc/docs/method_get_metadata.md) | Get the blockchain metadata (for example, state as known to the current full node). | +| [get_events](https://github.com/aptos/aptos/blob/main/json-rpc/docs/method_get_events.md) | Get the events for a given event stream key. | +| [get_currencies](https://github.com/aptos/aptos/blob/main/json-rpc/docs/method_get_currencies.md) | Get information about all currencies supported by the Aptos Blockchain. | ###### tags: `core` \ No newline at end of file diff --git a/developer-docs-site/docs/tutorials/tutorial-run-local-validator-nw.md b/developer-docs-site/docs/tutorials/tutorial-run-local-validator-nw.md index d20bd782caf55..6b3a50b0e915d 100755 --- a/developer-docs-site/docs/tutorials/tutorial-run-local-validator-nw.md +++ b/developer-docs-site/docs/tutorials/tutorial-run-local-validator-nw.md @@ -5,26 +5,26 @@ hidden: false --- import BlockQuote from "@site/src/components/BlockQuote"; -You can run a local test validator network to test and develop against a Diem Blockchain, including Move changes. This network is not part of the Diem Ecosystem and is only for testing and development purposes. +You can run a local test validator network to test and develop against a Aptos Blockchain, including Move changes. This network is not part of the Aptos Ecosystem and is only for testing and development purposes. -You can also use the Diem CLI command dev to compile, publish, and execute Move programs on your local test validator network. +You can also use the Aptos CLI command dev to compile, publish, and execute Move programs on your local test validator network.
-Your local test network will not be connected to testnet or mainnet of the Diem Blockchain. +Your local test network will not be connected to testnet or mainnet of the Aptos Blockchain.
## Getting Started -You can run a local test validator network in two ways: using the Diem Core source code or Docker. The Diem Core source code is useful when testing modifications to the Diem Core code base. Docker is particularly useful when building services on top of the Diem Blockchain as there is no build overhead and the ledger state persists across restarts of the network by default. +You can run a local test validator network in two ways: using the Aptos Core source code or Docker. The Aptos Core source code is useful when testing modifications to the Aptos Core code base. Docker is particularly useful when building services on top of the Aptos Blockchain as there is no build overhead and the ledger state persists across restarts of the network by default. -### Using Diem Core source code +### Using Aptos Core source code -1. Download and clone the Diem Core repository from GitHub and prepare your developer environment by running the following commands: +1. Download and clone the Aptos Core repository from GitHub and prepare your developer environment by running the following commands: ``` - git clone https://github.com/diem/diem.git - cd diem + git clone https://github.com/aptos/aptos.git + cd aptos ./scripts/dev_setup.sh source ~/.cargo/env ``` @@ -57,17 +57,17 @@ After starting your local test validator network, you should see the following: validator_1 | Entering test mode, this should never be used in production! validator_1 | Completed generating configuration: -validator_1 | Log file: "/opt/diem/var/validator.log" -validator_1 | Config path: "/opt/diem/var/0/node.yaml" -validator_1 | Diem root key path: "/opt/diem/var/mint.key" +validator_1 | Log file: "/opt/aptos/var/validator.log" +validator_1 | Config path: "/opt/aptos/var/0/node.yaml" +validator_1 | Aptos root key path: "/opt/aptos/var/mint.key" validator_1 | Waypoint: 0:7ff525d33f685a5cf26a71b393fa5159874c8f0c2861c382905f49dcb6991cb6 validator_1 | JSON-RPC endpoint: 0.0.0.0:8080 validator_1 | FullNode network: /ip4/0.0.0.0/tcp/7180 validator_1 | ChainId: TESTING ``` -This output contains information required for starting the Diem CLI tool: -* Diem root key path - The root (also known as a mint or faucet) key controls the account that can mint. Available in the docker compose folder under `aptos_root_key`. +This output contains information required for starting the Aptos CLI tool: +* Aptos root key path - The root (also known as a mint or faucet) key controls the account that can mint. Available in the docker compose folder under `aptos_root_key`. * Waypoint - a verifiable checkpoint into the blockchain (available in the docker compose folder under waypoint.txt) * JSON-RPC endpoint - `http://127.0.0.1:8080`. * ChainId - uniquely distinguishes this chain from other chains. @@ -76,6 +76,6 @@ This output contains information required for starting the Diem CLI tool: Use the output from above to start a `aptos-client` in another terminal: ``` -$ cd ~/diem +$ cd ~/aptos $ cargo run -p cli -- -c $CHAIN_ID -m $ROOT_KEY -u http://127.0.0.1:8080 --waypoint $WAYPOINT ``` \ No newline at end of file