chore: rename authority -> validator

doc/src/build/authorities.md

@@ -1,33 +1,33 @@
 ---
-title: Authorities
+title: Validators
 ---
 
-The Sui network is operated by a set of independent *authorities*, each running its own instance of the Sui software on a separate machine (or a sharded cluster of machines operated by the same entity). An authority participates in the network by handling read and write requests sent by clients. This section focuses on the latter.
+The Sui network is operated by a set of independent *validators*, each running its own instance of the Sui software on a separate machine (or a sharded cluster of machines operated by the same entity). A validator participates in the network by handling read and write requests sent by clients. This section focuses on the latter.
 
-Sui uses proof of stake (PoS) to determine which authorities operate the network and their voting power. Authorities are incentivized to participate in good faith via a share of transaction fees, staking rewards, and slashing to punish misbehavior.
+Sui uses proof of stake (PoS) to determine which validators operate the network and their voting power. Validators are incentivized to participate in good faith via a share of transaction fees, staking rewards, and slashing to punish misbehavior.
 
 ## Epochs
-Operation of the Sui network is temporally partitioned into non-overlapping, fixed-duration (e.g. 24-hour) *epochs*. During a particular epoch, the set of authorities participating in the network is fixed. At an epoch boundary, reconfiguration occurs and can change the set of authorities participating in the network and their voting power. Conceptually, reconfiguration starts a new instance of the Sui protocol with the previous epoch's final state as [genesis](wallet.md#genesis) and the new set of authorities as the operators.
+Operation of the Sui network is temporally partitioned into non-overlapping, fixed-duration (e.g. 24-hour) *epochs*. During a particular epoch, the set of validators participating in the network is fixed. At an epoch boundary, reconfiguration occurs and can change the set of validators participating in the network and their voting power. Conceptually, reconfiguration starts a new instance of the Sui protocol with the previous epoch's final state as [genesis](wallet.md#genesis) and the new set of validators as the operators.
 
 ## Committees
-A *committee* is a set of authorities whose combined voting power is >2/3 of the total during a particular epoch. For example, in a Sui instance operated by four authorities that all have the same voting power, any group containing three authorities is a committee.
+A *committee* is a set of validators whose combined voting power is >2/3 of the total during a particular epoch. For example, in a Sui instance operated by four validators that all have the same voting power, any group containing three validators is a committee.
 
-The committee size of >2/3 is chosen to ensure *[Byzantine fault](https://en.wikipedia.org/wiki/Byzantine_fault) tolerance (BFT)*. As we will see, an authority will  commit a transaction (i.e., durably store the transaction and update its internal state with the effects of the transaction) only if it is accompanied by cryptographic signatures from a committee. We call the combination of the transaction and the committee signatures on its bytes a *certificate*. The policy of  committing only certificates ensures Byzantine fault tolerance: if <2/3 of the authorities faithfully follow the protocol, they are guaranteed to eventually agree on both the set of committed certificates and their effects.
+The committee size of >2/3 is chosen to ensure *[Byzantine fault](https://en.wikipedia.org/wiki/Byzantine_fault) tolerance (BFT)*. As we will see, a validator will commit a transaction (i.e., durably store the transaction and update its internal state with the effects of the transaction) only if it is accompanied by cryptographic signatures from a committee. We call the combination of the transaction and the committee signatures on its bytes a *certificate*. The policy of  committing only certificates ensures Byzantine fault tolerance: if <2/3 of the validators faithfully follow the protocol, they are guaranteed to eventually agree on both the set of committed certificates and their effects.
 
 ## Write requests
-An authority can handle two types of write requests: transactions and certificates. At a high level, a client:
-* communicates a transaction to a quorum of authorities to collect the signatures required to form a certificate.
-* submits a certificate to an authority to commit state changes on that authority.
+A validator can handle two types of write requests: transactions and certificates. At a high level, a client:
+* communicates a transaction to a quorum of validators to collect the signatures required to form a certificate.
+* submits a certificate to a validator to commit state changes on that validator.
 
 ### Transactions
-When an authority receives a transaction from a client, it will first perform transaction validity checks (e.g., validity of the sender's signature). If the checks pass, the authority will sign the transaction bytes and return the signature to the client. The client repeats this process with multiple authorities until it has collected signatures on its transaction from a committee, thereby forming a certificate.
+When a validator receives a transaction from a client, it will first perform transaction validity checks (e.g., validity of the sender's signature). If the checks pass, the validator will sign the transaction bytes and return the signature to the client. The client repeats this process with multiple validators until it has collected signatures on its transaction from a committee, thereby forming a certificate.
 
-Note that the process of collecting authority signatures on a transaction into a certificate and the process of submitting certifcates can be performed in parallel. The client can simultaneously broadcast transactions/certificates to an arbitrary number of authorities. Alternatively, a client can outsource either or both of these tasks to a third-party service provider. This provider must be trusted for liveness (e.g., it can refuse to form a certificate), but not for safety (e.g., it cannot change the effects of the transaction).
+Note that the process of collecting validator signatures on a transaction into a certificate and the process of submitting certifcates can be performed in parallel. The client can simultaneously broadcast transactions/certificates to an arbitrary number of validators. Alternatively, a client can outsource either or both of these tasks to a third-party service provider. This provider must be trusted for liveness (e.g., it can refuse to form a certificate), but not for safety (e.g., it cannot change the effects of the transaction).
 
 ### Certificates
-Once the client forms a certificate, it submits the certificate to an authority, which will perform certificate validity checks (e.g., ensuring the signers are authorities in the current epoch, and the signatures are cryptographically valid). If the checks pass, the auhority will execute the transaction inside the certificate. Execution of a transaction will either succeed and commit all of its effects to the ledger, or abort (e.g., due to an explicit `abort` instruction, a runtime error such as divison by zero, or exceeding the maximum gas budget) and have no effects other than debiting the transaction's gas input. In either case, the transaction will durably store the certificate indexed by the hash of its inner transaction.
+Once the client forms a certificate, it submits the certificate to a validator, which will perform certificate validity checks (e.g., ensuring the signers are validators in the current epoch, and the signatures are cryptographically valid). If the checks pass, the auhority will execute the transaction inside the certificate. Execution of a transaction will either succeed and commit all of its effects to the ledger, or abort (e.g., due to an explicit `abort` instruction, a runtime error such as divison by zero, or exceeding the maximum gas budget) and have no effects other than debiting the transaction's gas input. In either case, the transaction will durably store the certificate indexed by the hash of its inner transaction.
 
-As with transactions, we note that the process of sharing a certificate with authorities can be parallelized and (if desired) outsourced to a third-party service provider. A client should broadcast its certificate to >1/3 of the authorities to ensure that (up to BFT assumptions) at least one honest authority has executed and committed the certificate. Other authorities may learn about the certificate via inter-authority state sync or via client-assisted state sync.
+As with transactions, we note that the process of sharing a certificate with validators can be parallelized and (if desired) outsourced to a third-party service provider. A client should broadcast its certificate to >1/3 of the validators to ensure that (up to BFT assumptions) at least one honest validator has executed and committed the certificate. Other validators may learn about the certificate via inter-validator state sync or via client-assisted state sync.
 
 ## The role of Narwhal and Tusk
 
@@ -38,7 +38,7 @@ Narwhal enables the parallel ordering of transactions into batches that are coll
 * Narwhal/Tusk operates in OX, rather than XO mode (O = order, X = execute); the execution occurs after the Narwhal/Tusk ordering.
 * The output of N/T is therefore a sequence of transactions, with interdependencies stored in the transaction data itself.
 
-What we sequence using consensus is certificates of transactions. These represent transactions that have already been presented to 2/3 of authorities that checked that all their owned objects are available to be operated on and signed the transaction. Upon a certificate being sequenced, what we do is set the *lock* of the shared objects at the next available version to map to the execution of that certificate. So for example if we have a shared object X at version 2, and we sequence certificate T, we store T -> [(X, 2)]. That is all we do synchronously when we reach consensus, and as a result we are able to ingest a lot of sequenced transactions.
+What we sequence using consensus is certificates of transactions. These represent transactions that have already been presented to 2/3 of validators that checked that all their owned objects are available to be operated on and signed the transaction. Upon a certificate being sequenced, what we do is set the *lock* of the shared objects at the next available version to map to the execution of that certificate. So for example if we have a shared object X at version 2, and we sequence certificate T, we store T -> [(X, 2)]. That is all we do synchronously when we reach consensus, and as a result we are able to ingest a lot of sequenced transactions.
 
 Now, once this is done we can process all certificates that had their locks set, on one or multiple cores (currently). Obviously, transactions for earlier versions of objects need to be processed first (causally), and that reduces the degree of concurrency. Both the read and write set is determined by the transaction itself, and not dynamically based on the contents of the object at a specific version (not currently). 
 

doc/src/build/index.md

@@ -8,7 +8,7 @@ Now that you've [learned about Sui](../learn/index.md), it's time to [install](.
 * [Sui Wallet](../build/wallet.md) - Sui wallet was developed to facilitate local experimentation with Sui features. In this document, we describe how to set up Sui wallet and execute wallet commands through its command line interface, Wallet CLI.
 * [REST Server](../build/rest-api.md) - This document walks you through setting up your own local Sui REST Server and using the Sui REST API interact with a local Sui network.
 * [SuiJSON](../build/sui-json.md) - SuiJSON is a JSON-based format with restrictions that allow Sui to align JSON inputs more closely with Move Call arguments. This table shows the restrictions placed on JSON types to make them SuiJSON compatible.
-* [Authorities](../build/authorities.md) - The Sui network is operated by a set of independent authorities, each running its own instance of the Sui software on a separate machine (or a sharded cluster of machines operated by the same entity).
+* [Validators](../build/authorities.md) - The Sui network is operated by a set of independent validators, each running its own instance of the Sui software on a separate machine (or a sharded cluster of machines operated by the same entity).
 * [Objects](../build/objects.md) - Sui has programmable objects created and managed by Move packages (a.k.a. smart contracts). Move packages themselves are also objects. Thus, Sui objects can be partitioned into two categories mutable data values and immutable packages.
 * [Transactions](../build/transactions.md) - All updates to the Sui ledger happen via a transaction. This section describes the transaction types supported by Sui and explains how their execution changes the ledger.
 

doc/src/build/objects.md

@@ -44,7 +44,7 @@ An object can be shared and mutable, meaning that anyone can use and mutate this
 There are a few different ways to concisely refer to an object without specifying its full contents and metadata, each with slightly different use cases:
 * ID: the globally unique ID of the object mentioned above. This is a stable identifier for the object across time, and is useful for querying the current state of an object or describing which object was transferred between two addresses.
 * Versioned ID: an (ID, version) pair. This describes the state of the object at a particular point in the object's history, and is useful for asking what the value of the object was at some point in the past or determining how fresh some view of an object is now.
-* Object Reference: an (ID, version, object digest) triple. The object digest is the hash of the object's contents and metadata. An object reference provides an authenticated view of the object at a particular point in the object's history. Transactions require object inputs to be specified via object references to ensure the transaction's sender and an authority processing the transaction agree on the contents and metadata of the object.
+* Object Reference: an (ID, version, object digest) triple. The object digest is the hash of the object's contents and metadata. An object reference provides an authenticated view of the object at a particular point in the object's history. Transactions require object inputs to be specified via object references to ensure the transaction's sender and a validator processing the transaction agree on the contents and metadata of the object.
 
 ## The transaction-object DAG: Relating objects and transactions
 
@@ -62,4 +62,4 @@ When this DAG contains all committed transactions in the system, it forms a comp
 
 ## Further reading
 * Objects are modified and created by [transactions](transactions.md).
-* Objects are stored by [authorities](authorities.md).
+* Objects are stored by [validators](authorities.md).

doc/src/build/rest-api.md

@@ -53,7 +53,7 @@ curl --location --request GET $SUI_GATEWAY_HOST/docs | json_pp
 
 ### POST /api/sync_account_state
 
-Synchronize client state with authorities:
+Synchronize client state with validators:
 
 ```shell
 curl --location --request POST $SUI_GATEWAY_HOST/api/sync_account_state \

doc/src/build/transactions.md

@@ -58,4 +58,4 @@ Inputs: A list of unique object references pointing to mutable objects owned by
 
 * See the [Move Quick Start](move.md) to learn about smart contracts.
 * Transactions take objects as input and produce objects as output--learn about the [objects](objects.md), their structure and attributes.
-* Transactions are executed by Sui [authorities](authorities.md).
+* Transactions are executed by Sui [validators](authorities.md).

doc/src/build/wallet.md

@@ -14,7 +14,7 @@ Follow the instructions to [install Sui binaries](install.md).
 
 ## Genesis
 
-The `genesis` command creates four authorities and five user accounts
+The `genesis` command creates four validators and five user accounts
 each with five gas objects. These are Sui [objects](objects.md) used
 to pay for Sui [transactions](transactions.md#transaction-metadata),
 such other object transfers or smart contract (Move) calls. These
@@ -68,7 +68,7 @@ The genesis process creates a configuration file `wallet.conf`, and a keystore f
 Sui wallet.  The config file contains information of the accounts and
 the Sui Network Gateway. The keystore file contains all the public-private key pairs of the created accounts.
 Sui wallet uses the network information in `wallet.conf` to communicate
-with the Sui network authorities  and create transactions using the key
+with the Sui network validators  and create transactions using the key
 pairs residing in the keystore file.
 
 Here is an example of `wallet.conf` showing the accounts and key pairs
@@ -113,7 +113,7 @@ The `accounts` variable contains the account's address that the wallet manages.
 be connecting to. Currently, only the `embedded` gateway type is supported.
 
 The `authorities` variable is part of the embedded gateway configuration. It contains
-the Sui network authority's name, host and port information. It is used to establish connections
+the Sui network validator's name, host and port information. It is used to establish connections
 to the Sui network.
 
 Note `send_timeout`, `recv_timeout` and `buffer_size` are the network
@@ -131,7 +131,7 @@ based on their use cases.
 
 As the name suggests, embedded gateway embeds the gateway logic into the application;
 all data will be stored locally and the application will make direct
-connection to the authorities.
+connection to the validators.
 
 #### Rest Gateway
 You can also connect the wallet to the Sui network via a [Rest Gateway](rest-api.md#start-local-rest-server);
@@ -212,7 +212,7 @@ The following commands are supported by the wallet:
     publish           Publish Move modules
     split-coin        Split a coin object into multiple coins
     switch            Switch active address
-    sync              Synchronize client state with authorities
+    sync              Synchronize client state with validators
     transfer          Transfer an object
 Use `help <command>` to see more information on each command.
 
@@ -956,7 +956,7 @@ Example `genesis.conf`:
 All attributes in `genesis.conf` are optional, and default values
 will be used if the attributes are not provided.
 For example, the
-config shown below will create a network of four authorities, and
+config shown below will create a network of four validators, and
 pre-populate two gas objects for four newly generated accounts:
 
 ```json

doc/src/contribute/index.md

@@ -41,7 +41,7 @@ You can start exploring Sui's source code by looking into the following primary
 
 * [sui](https://github.com/MystenLabs/sui/tree/main/sui) - the Sui binaries (`wallet`, `sui-move`, and more)
 * [sui_programmability](https://github.com/MystenLabs/sui/tree/main/sui_programmability) - Sui's Move language integration also including games and other Move code examples for testing and reuse
-* [sui_core](https://github.com/MystenLabs/sui/tree/main/sui_core) - authority server and Sui Gateway
+* [sui_core](https://github.com/MystenLabs/sui/tree/main/sui_core) - validator server and Sui Gateway
 * [sui_types](https://github.com/MystenLabs/sui/tree/main/sui_types) - coins, gas, and other object types
 * [explorer](https://github.com/MystenLabs/sui/tree/main/explorer) - object explorer for the Sui network
 * [network_utils](https://github.com/MystenLabs/sui/tree/main/network_utils) - networking utilities and related unit tests