| |
-| `bit_and` | `AND`: `&` |
-| `xor` | `XOR`: `^` |
-| `shl` | Shift left: `<<` |
-| `shr` | Shift right: `>>` |
-
-### Boolean
-
-| Parameter | Meaning |
-|-----------|---------------------------------|
-| `or` | `OR`: || |
-| `and` | `AND`: `&&` |
-| `not` | `NOT`: `!` |
-
-
-### Comparison
-
-| Parameter | Meaning |
-|------------------------|--------------------------------|
-| `lt` | Less than: `<` |
-| `gt` | Greater than: `>` |
-| `le` | Less than or equal to: `<=` |
-| `ge` | Greater than or equal to: `>=` |
-| `eq_base` | Base equality cost: `==` |
-| `eq_per_abs_val_unit` | |
-| `neq_base` | Base not equal cost: `!=` |
-| `neq_per_abs_val_unit` | |
-
-### Global storage
-
-| Parameter | Meaning |
-|----------------------------------|-------------------------------------------------------|
-| `imm_borrow_global_base` | Base cost to immutably borrow: `borrow_globalVMValidator::validate_transaction() on the VM to validate the transaction.
-
-## Consensus
-
--The AptosBFT consensus protocol provides fault tolerance of up to one-third of malicious validator nodes. -- -## Validator node components - - -### Mempool - -Mempool is a component within each node that holds an in-memory buffer of transactions that have been submitted to the blockchain, but not yet agreed upon or executed. This buffer is replicated between validator nodes and fullnodes. - -The JSON-RPC service of a fullnode sends transactions to a validator node's mempool. Mempool performs various checks on the transactions to ensure transaction validity and protect against DOS attacks. When a new transaction passes initial verification and is added to mempool, it is then distributed to the mempools of other validator nodes in the network. - -When a validator node temporarily becomes a leader in the consensus protocol, consensus pulls the transactions from mempool and proposes a new transaction block. This block is broadcasted to other validators and contains a total ordering over all transactions in the block. Each validator then executes the block and submits votes on whether or not to accept the new block proposal. - -### Consensus - -Consensus is the component that is responsible for ordering blocks of transactions and agreeing on the results of execution by participating in the consensus protocol with other validator nodes in the network. - -### Execution - -Execution is the component that coordinates the execution of a block of transactions and maintains a transient state. Consensus votes on this transient state. Execution maintains an in-memory representation of the execution results until consensus commits the block to the distributed database. Execution uses the virtual machine to execute transactions. Execution acts as the glue layer between the inputs of the system (represented by transactions), storage (providing a persistency layer), and the virtual machine (for execution). - -### Virtual machine (VM) - -The virtual machine (VM) is used to run the Move program within each transaction and determine execution results. A node's mempool uses the VM to perform verification checks on transactions, while execution uses the VM to execute transactions. - -### Storage - -The storage component is used to persist agreed upon blocks of transactions and their execution results to the local database. - -### State synchronizer - -Nodes use their state synchronizer component to “catch up” to the latest state of the blockchain and stay up-to-date. diff --git a/developer-docs-site/docs/guides/_category_.json b/developer-docs-site/docs/guides/_category_.json deleted file mode 100644 index e79050872b49e..0000000000000 --- a/developer-docs-site/docs/guides/_category_.json +++ /dev/null @@ -1,4 +0,0 @@ -{ - "label": "Guides", - "position": 2 -} diff --git a/developer-docs-site/docs/guides/account-management/key-rotation.md b/developer-docs-site/docs/guides/account-management/key-rotation.md deleted file mode 100644 index a0f5e2493ac00..0000000000000 --- a/developer-docs-site/docs/guides/account-management/key-rotation.md +++ /dev/null @@ -1,141 +0,0 @@ ---- -title: "Rotating an authentication key" -id: "key-rotation" ---- - -import Tabs from '@theme/Tabs'; -import TabItem from '@theme/TabItem'; - -Aptos Move accounts have a public address, an authentication key, a public key, and a private key. The public address is permanent, always matching the account's initial authentication key. - -The Aptos account model facilitates the unique ability to rotate an account's private key. Since an account's address is the *initial* authentication key, the ability to sign for an account can be transferred to another private key without changing its public address. - -In this guide, we show examples for how to rotate an account's authentication key using a few of the various Aptos SDKs. - -Here are the installation links for the SDKs we will cover in this example: - -* [Aptos CLI](../../tools/aptos-cli) -* [Typescript SDK](../../sdks/ts-sdk/index) -* [Python SDK](../../sdks/python-sdk) - -:::warning -Some of the following examples use private keys. Do not share your private keys with anyone. -::: - -## How to rotate an account's authentication key -
- -```json -$ curl http://127.0.0.1:8070 | jq . -{ - "ready": [ - { - "Http": [ - "http://127.0.0.1:43236/", - "processor_default_processor" - ] - }, - { - "Http": [ - "http://127.0.0.1:43240/", - "processor_token_processor" - ] - }, - { - "Http": [ - "http://127.0.0.1:43242/", - "processor_user_transaction_processor" - ] - }, - { - "Postgres": "postgres://postgres@127.0.0.1:5433/local_testnet" - }, - { - "Http": [ - "http://127.0.0.1:8081/", - "Faucet" - ] - }, - { - "IndexerApiMetadata": "http://127.0.0.1:8090/" - }, - { - "Http": [ - "http://127.0.0.1:8090/", - "Indexer API" - ] - }, - { - "NodeApi": "http://0.0.0.0:8080/" - }, - { - "Http": [ - "http://127.0.0.1:43239/", - "processor_stake_processor" - ] - }, - { - "DataServiceGrpc": "http://0.0.0.0:50051/" - }, - { - "Http": [ - "http://127.0.0.1:43235/", - "processor_coin_processor" - ] - }, - { - "Http": [ - "http://127.0.0.1:43237/", - "processor_events_processor" - ] - }, - { - "Http": [ - "http://127.0.0.1:43234/", - "processor_account_transactions_processor" - ] - }, - { - "Http": [ - "http://127.0.0.1:43241/", - "processor_token_v2_processor" - ] - }, - { - "Http": [ - "http://127.0.0.1:43238/", - "processor_fungible_asset_processor" - ] - } - ], - "not_ready": [] -} -``` - -
-Begin by setting up your Aptos development environment.
-Submit your first transaction, write your first Move module, deploy your first coin, and more.
-Learn the key concepts of the Aptos blockchain, including transactions, accounts, gas and transaction fees, nodes, and more.
-Learn how the Move programming language helps make the Aptos blockchain safe and reliable.
-How to build applications on Aptos.
-Install and run a validator or a fullnode.
-Run a validator node on your local testnet.
-Run a public fullnode and connect to devnet.
-|| | short-circuiting logical or | p || q is equivalent to `if (p) true else q` |
-| `!` | logical negation | `!p` is equivalent to `if (p) false else true` |
-
-### Control Flow
-
-`bool` values are used in several of Move's control-flow constructs:
-
-- [`if (bool) { ... }`](./conditionals.md)
-- [`while (bool) { .. }`](./loops.md)
-- [`assert!(bool, u64)`](./abort-and-assert.md)
-
-## Ownership
-
-As with the other scalar values built-in to the language, boolean values are implicitly copyable,
-meaning they can be copied without an explicit instruction such as
-[`copy`](./variables.md#move-and-copy).
diff --git a/developer-docs-site/docs/move/book/coding-conventions.md b/developer-docs-site/docs/move/book/coding-conventions.md
deleted file mode 100644
index 654557f22c896..0000000000000
--- a/developer-docs-site/docs/move/book/coding-conventions.md
+++ /dev/null
@@ -1,77 +0,0 @@
-# Move Coding Conventions
-
-This section lays out some basic coding conventions for Move that the Move team has found helpful. These are only recommendations, and you should feel free to use other formatting guidelines and conventions if you have a preference for them.
-
-## Naming
-
-- **Module names**: should be lower snake case, e.g., `fixed_point32`, `vector`.
-- **Type names**: should be camel case if they are not a native type, e.g., `Coin`, `RoleId`.
-- **Function names**: should be lower snake case, e.g., `destroy_empty`.
-- **Constant names**: should be upper camel case and begin with an `E` if they represent error codes (e.g., `EIndexOutOfBounds`) and upper snake case if they represent a non-error value (e.g., `MIN_STAKE`).
--
-- **Generic type names**: should be descriptive, or anti-descriptive where appropriate, e.g., `T` or `Element` for the Vector generic type parameter. Most of the time the "main" type in a module should be the same name as the module e.g., `option::Option`, `fixed_point32::FixedPoint32`.
-- **Module file names**: should be the same as the module name e.g., `option.move`.
-- **Script file names**: should be lower snake case and should match the name of the “main” function in the script.
-- **Mixed file names**: If the file contains multiple modules and/or scripts, the file name should be lower snake case, where the name does not match any particular module/script inside.
-
-## Imports
-
-- All module `use` statements should be at the top of the module.
-- Functions should be imported and used fully qualified from the module in which they are declared, and not imported at the top level.
-- Types should be imported at the top-level. Where there are name clashes, `as` should be used to rename the type locally as appropriate.
-
-For example, if there is a module:
-
-```move
-module 0x1::foo {
- struct Foo { }
- const CONST_FOO: u64 = 0;
- public fun do_foo(): Foo { Foo{} }
- ...
-}
-```
-
-this would be imported and used as:
-
-```move
-module 0x1::bar {
- use 0x1::foo::{Self, Foo};
-
- public fun do_bar(x: u64): Foo {
- if (x == 10) {
- foo::do_foo()
- } else {
- abort 0
- }
- }
- ...
-}
-```
-
-And, if there is a local name-clash when importing two modules:
-
-```move
-module other_foo {
- struct Foo {}
- ...
-}
-
-module 0x1::importer {
- use 0x1::other_foo::Foo as OtherFoo;
- use 0x1::foo::Foo;
- ...
-}
-```
-
-## Comments
-
-- Each module, struct, and public function declaration should be commented.
-- Move has doc comments `///`, regular single-line comments `//`, block comments `/* */`, and block doc comments `/** */`.
-
-## Formatting
-
-The Move team plans to write an autoformatter to enforce formatting conventions. However, in the meantime:
-
-- Four space indentation should be used except for `script` and `address` blocks whose contents should not be indented.
-- Lines should be broken if they are longer than 100 characters.
-- Structs and constants should be declared before all functions in a module.
diff --git a/developer-docs-site/docs/move/book/conditionals.md b/developer-docs-site/docs/move/book/conditionals.md
deleted file mode 100644
index d53b268ac5922..0000000000000
--- a/developer-docs-site/docs/move/book/conditionals.md
+++ /dev/null
@@ -1,62 +0,0 @@
-# Conditionals
-
-An `if` expression specifies that some code should only be evaluated if a certain condition is true. For example:
-
-```move
-if (x > 5) x = x - 5
-```
-
-The condition must be an expression of type `bool`.
-
-An `if` expression can optionally include an `else` clause to specify another expression to evaluate when the condition is false.
-
-```move
-if (y <= 10) y = y + 1 else y = 10
-```
-
-Either the "true" branch or the "false" branch will be evaluated, but not both. Either branch can be a single expression or an expression block.
-
-The conditional expressions may produce values so that the `if` expression has a result.
-
-```move
-let z = if (x < 100) x else 100;
-```
-
-The expressions in the true and false branches must have compatible types. For example:
-
-```move=
-// x and y must be u64 integers
-let maximum: u64 = if (x > y) x else y;
-
-// ERROR! branches different types
-let z = if (maximum < 10) 10u8 else 100u64;
-
-// ERROR! branches different types, as default false-branch is () not u64
-if (maximum >= 10) maximum;
-```
-
-If the `else` clause is not specified, the false branch defaults to the unit value. The following are equivalent:
-
-```move
-if (condition) true_branch // implied default: else ()
-if (condition) true_branch else ()
-```
-
-Commonly, [`if` expressions](./conditionals.md) are used in conjunction with expression blocks.
-
-```move
-let maximum = if (x > y) x else y;
-if (maximum < 10) {
- x = x + 10;
- y = y + 10;
-} else if (x >= 10 && y >= 10) {
- x = x - 10;
- y = y - 10;
-}
-```
-
-## Grammar for Conditionals
-
-> *if-expression* → **if (** *expression* **)** *expression* *else-clause**opt*
-
-> *else-clause* → **else** *expression*
diff --git a/developer-docs-site/docs/move/book/constants.md b/developer-docs-site/docs/move/book/constants.md
deleted file mode 100644
index c59f0107c57b1..0000000000000
--- a/developer-docs-site/docs/move/book/constants.md
+++ /dev/null
@@ -1,112 +0,0 @@
-# Constants
-
-Constants are a way of giving a name to shared, static values inside of a `module` or `script`.
-
-The constant's must be known at compilation. The constant's value is stored in the compiled module
-or script. And each time the constant is used, a new copy of that value is made.
-
-## Declaration
-
-Constant declarations begin with the `const` keyword, followed by a name, a type, and a value. They
-can exist in either a script or module
-
-```text
-const