From 1040441e53fdba21eec79270df3d61f4f60d170e Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Fran=C3=A7ois=20Garillot?= Date: Fri, 15 Apr 2022 07:48:22 -0400 Subject: [PATCH 1/9] chore: rename authority -> validator --- doc/src/build/authorities.md | 28 ++++++------ doc/src/build/index.md | 2 +- doc/src/build/objects.md | 4 +- doc/src/build/rest-api.md | 2 +- doc/src/build/transactions.md | 2 +- doc/src/build/wallet.md | 12 ++--- doc/src/contribute/index.md | 2 +- doc/src/contribute/observability.md | 66 +++++++++++++-------------- doc/src/contribute/research-papers.md | 6 +-- doc/src/learn/about-sui.md | 14 +++--- doc/src/learn/how-sui-works.md | 34 +++++++------- doc/src/learn/index.md | 2 +- doc/src/learn/sui-compared.md | 34 +++++++------- doc/src/learn/sui-glossary.md | 24 +++++----- doc/src/learn/sui-security.md | 54 +++++++++++----------- doc/src/learn/why-move.md | 4 +- doc/src/navconfig.json | 2 +- 17 files changed, 146 insertions(+), 146 deletions(-) diff --git a/doc/src/build/authorities.md b/doc/src/build/authorities.md index 947348bacf66f..e393b31037978 100644 --- a/doc/src/build/authorities.md +++ b/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). An 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, an 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. +An 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 an 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 an 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 an 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). diff --git a/doc/src/build/index.md b/doc/src/build/index.md index f39669851576d..38f429629e0ee 100644 --- a/doc/src/build/index.md +++ b/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. diff --git a/doc/src/build/objects.md b/doc/src/build/objects.md index e9a05b48ad2b6..46fb618bd868d 100644 --- a/doc/src/build/objects.md +++ b/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 an 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). diff --git a/doc/src/build/rest-api.md b/doc/src/build/rest-api.md index d2269ec713264..275e9692308f9 100644 --- a/doc/src/build/rest-api.md +++ b/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 \ diff --git a/doc/src/build/transactions.md b/doc/src/build/transactions.md index 2f042863b90a0..547ef2ff1dd31 100644 --- a/doc/src/build/transactions.md +++ b/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). diff --git a/doc/src/build/wallet.md b/doc/src/build/wallet.md index a27321cc10dce..a2c911ea8213e 100644 --- a/doc/src/build/wallet.md +++ b/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 ` 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 diff --git a/doc/src/contribute/index.md b/doc/src/contribute/index.md index cd12a3b774b67..b0adec1b51d6d 100644 --- a/doc/src/contribute/index.md +++ b/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 diff --git a/doc/src/contribute/observability.md b/doc/src/contribute/observability.md index 7b8e6fc6781a7..6926f4ed11cc1 100644 --- a/doc/src/contribute/observability.md +++ b/doc/src/contribute/observability.md @@ -3,7 +3,7 @@ title: Logging, Tracing, Metrics, and Observability --- Good observability facilities are key to the development and growth of Sui. This is made -more challenging by the distributed and asynchronous nature of Sui, with multiple client and authority +more challenging by the distributed and asynchronous nature of Sui, with multiple client and validator processes distributed over a potentially global network. The observability stack in Sui is based on the [Tokio tracing](https://tokio.rs/blog/2019-08-tracing) library. @@ -11,7 +11,7 @@ The rest of this document highlights specific aspects of achieving good observab and metrics in Sui. NOTE: The output here is largely for the consumption of Sui operators, administrators, and developers. The -content of logs and traces do not represent the authoritative, certified output of authorities and are subject +content of logs and traces do not represent the authoritative, certified output of validators and are subject to potentially byzantine behavior. ## Contexts, scopes, and tracing transaction flow @@ -38,10 +38,10 @@ Here is a table/summary of context information that we will want: - Certificate digest, if applicable - For Client HTTP endpoint: route, method, status - Epoch -- Host information, for both clients and authorities +- Host information, for both clients and validators Example output which shows both context (tx digests) and key-value pairs enhancing observability/filtering, -and tracing a transaction across the gateway (`authority_aggregator`) as well as the authority: +and tracing a transaction across the gateway (`authority_aggregator`) as well as the validator: ``` 7ab7774d1f7bd40848}: sui_core::authority_aggregator: Broadcasting transaction request to authorities quorum_threshold=3 validity_threshold=2 timeout_after_quorum=60s @@ -54,7 +54,7 @@ and tracing a transaction across the gateway (`authority_aggregator`) as well as 2022-03-05T01:35:03.395917Z DEBUG test_move_call_args_linter_command:process_cert{tx_digest=t#7e5f08ab09ec80e3372c101c5858c96965a25326c21af27ab7774d1f7bd40848}: sui_core::authority: Finished execution of transaction with status Success { gas_used: 7 } gas_used=7 ``` -From the example above, we can see that `process_tx` is a span that covers handling the initial transaction request, and "Checked locks" is a single log message within the transaction handling method in the authority. +From the example above, we can see that `process_tx` is a span that covers handling the initial transaction request, and "Checked locks" is a single log message within the transaction handling method in the validator. Every log message that occurs within the span inherits the key-value properties defined in the span, including the tx_digest and any other fields that are added. Log messages can set their own keys and values. The fact that logs inherit the span properties allows us to trace, for example, the flow of a transaction across thread and process boundaries. @@ -68,18 +68,18 @@ and analyzed for tracing, performance analysis, etc. | Name | Place | Meaning | | ----------------------- | ------------------ | ------------------------------------------------------------------------------ | -| process_tx | Gateway, Authority | Send transaction request, get back 2f+1 signatures and make certificate | -| process_cert | Gateway, Authority | Send certificate to authorities to execute transaction | -| cert_check_signature | Authority | Check certificate signatures | -| process_cert_inner | Authority | Inner function to process certificates in authority | -| fetch_objects | Authority | Read objects from database | -| tx_execute_to_effects | Authority | Execute Move call and create effects | -| tx_execute | Authority | Actual execution of transfer/Move call etc. | -| handle_cert | Gateway | Send to one authority for certificate processing | -| quorum_map_auth | Gateway | Handle one network component with one authority | -| sync_cert | Gateway, Authority | Gateway-initiated sync of data to authority | -| db_set_transaction_lock | Authority | Database set transaction locks on new transaction | -| db_update_state | Authority | Update the database with certificate, effects after transaction Move execution | +| process_tx | Gateway, Validator | Send transaction request, get back 2f+1 signatures and make certificate | +| process_cert | Gateway, Validator | Send certificate to validators to execute transaction | +| cert_check_signature | Validator | Check certificate signatures | +| process_cert_inner | Validator | Inner function to process certificates in validator | +| fetch_objects | Validator | Read objects from database | +| tx_execute_to_effects | Validator | Execute Move call and create effects | +| tx_execute | Validator | Actual execution of transfer/Move call etc. | +| handle_cert | Gateway | Send to one validator for certificate processing | +| quorum_map_auth | Gateway | Handle one network component with one validator | +| sync_cert | Gateway, Validator | Gateway-initiated sync of data to validator | +| db_set_transaction_lock | Validator | Database set transaction locks on new transaction | +| db_update_state | Validator | Update the database with certificate, effects after transaction Move execution | | | | | ### Tags - keys @@ -89,18 +89,18 @@ These tags represent *fields* that can be analyzed and filtered by. For example, | Key | Place(s) | Meaning | | ------------------- | ------------------ | -------------------------------------------------------------------------- | -| tx_digest | Gateway, Authority | Hex digest of transaction | -| tx_kind | Gateway, Authority | Kind of transaction: Transfer/Publish/Call | +| tx_digest | Gateway, Validator | Hex digest of transaction | +| tx_kind | Gateway, Validator | Kind of transaction: Transfer/Publish/Call | | quorum_threshold | Gateway | Numeric threshold of quorum stake needed for a transaction | | validity_threshold | Gateway | Numeric threshold of maximum "bad stake" from errors that can be tolerated | -| num_errors | Gateway | Number of errors from authorities broadcast | -| good_stake | Gateway | Total amount of good stake from authorities who answered a broadcast | -| bad_stake | Gateway | Total amount of bad stake from authorities, including errors | -| num_signatures | Gateway | Number of signatures received from authorities broadcast | -| num_unique_effects | Gateway | Number of unique effects responses from authorities | -| num_inputs | Authority | Number of inputs for transaction processing | -| num_mutable_objects | Authority | Number of mutable objects for transaction processing | -| gas_used | Authority | Amount of gas used by the transaction | +| num_errors | Gateway | Number of errors from validators broadcast | +| good_stake | Gateway | Total amount of good stake from validators who answered a broadcast | +| bad_stake | Gateway | Total amount of bad stake from validators, including errors | +| num_signatures | Gateway | Number of signatures received from validators broadcast | +| num_unique_effects | Gateway | Number of unique effects responses from validators | +| num_inputs | Validator | Number of inputs for transaction processing | +| num_mutable_objects | Validator | Number of mutable objects for transaction processing | +| gas_used | Validator | Amount of gas used by the transaction | | | | | ## Logging levels @@ -112,7 +112,7 @@ This is always tricky, to balance the right amount of verbosity especially by de | Error | Process-level faults (not transaction-level errors, there could be a ton of those) | | Warn | Unusual or byzantine activity | | Info | High level aggregate stats, major events related to data sync, epoch changes. | -| Debug | High level tracing for individual transactions, eg Gateway/client side -> authority -> Move execution etc. | +| Debug | High level tracing for individual transactions, eg Gateway/client side -> validator -> Move execution etc. | | Trace | Extremely detailed tracing for individual transactions | | | | @@ -130,9 +130,9 @@ subscribers can be active at the same time. ```mermaid graph TB; -Authority1 --> S1(open-telemetry) -Authority1 --> S2(stdout logging) -Authority1 --> S3(bunyan-formatter) +Validator1 --> S1(open-telemetry) +Validator1 --> S2(stdout logging) +Validator1 --> S3(bunyan-formatter) S3 --> Vector Vector --> ElasticSearch S1 --> Jaeger @@ -146,7 +146,7 @@ Vector2 --> ElasticSearch In the graph above, there are multiple subscribers, JSON logs can be for example fed via a local sidecar log forwarder such as [Vector](https://vector.dev), and then onwards to destinations such as ElasticSearch. -The use of a log and metrics aggregator such as Vector allows for easy reconfiguration without interrupting the authority server, +The use of a log and metrics aggregator such as Vector allows for easy reconfiguration without interrupting the validator server, as well as offloading observability traffic. ### Stdout (default) @@ -191,4 +191,4 @@ NOTE: separate spans (which are not nested) are not connected as a single trace 2. Start Sui with `SUI_TOKIO_CONSOLE` set to 1. 3. Clone the console repo and `cargo run` to launch the console. -NOTE: Adding Tokio-console support may significantly slow down Sui authorities/gateways. +NOTE: Adding Tokio-console support may significantly slow down Sui validators/gateways. diff --git a/doc/src/contribute/research-papers.md b/doc/src/contribute/research-papers.md index 83924a0712d80..62992dbbb53f9 100644 --- a/doc/src/contribute/research-papers.md +++ b/doc/src/contribute/research-papers.md @@ -12,11 +12,11 @@ our latest design, inspired from previous works below. * **Link:** https://arxiv.org/abs/2003.11506 * **Publication:** ACM Conference on Advances in Financial Technologies (AFT), 2020 * **Relevance:** FastPay describes the core protocol at the heart of Sui. -* **Summary:** FastPay allows a set of distributed authorities, some of which are Byzantine, to maintain a high-integrity and availability +* **Summary:** FastPay allows a set of distributed validators, some of which are Byzantine, to maintain a high-integrity and availability settlement system for pre-funded payments. It can be used to settle payments in a native unit of value (crypto-currency), or as a financial side-infrastructure to support retail payments in fiat currencies. This is not the protocol Sui uses, yet it proposes the basic safety mechanism that Sui extends. FastPay is based on Byzantine Consistent Broadcast as its core primitive, foregoing the expenses of full atomic commit channels - (consensus). The resulting system has low-latency for both confirmation and payment finality. Remarkably, each authority can be sharded across many + (consensus). The resulting system has low-latency for both confirmation and payment finality. Remarkably, each validator can be sharded across many machines to allow unbounded horizontal scalability. ## Narwhal and Tusk: A DAG-based Mempool and Efficient BFT Consensus @@ -44,7 +44,7 @@ our latest design, inspired from previous works below. to add strong privacy to FastPay transactions (but Sui does not plan to do this). * **Summary:** We introduce Zef, the first Byzantine-Fault Tolerant (BFT) protocol to support payments in anonymous digital coins at arbitrary scale. Zef follows the communication and security model of FastPay: both protocols are asynchronous, low-latency, linearly-scalable, and powered by partially-trusted - sharded authorities. Zef further introduces opaque coins represented as off-chain certificates that are bound to user accounts. In order to hide the face + sharded validators. Zef further introduces opaque coins represented as off-chain certificates that are bound to user accounts. In order to hide the face values of coins when a payment operation consumes or creates them, Zef uses random commitments and NIZK proofs. Created coins are made unlinkable using the blind and randomizable threshold anonymous credentials of [Coconut](https://arxiv.org/pdf/1802.07344.pdf). To control storage costs associated with coin replay prevention, Zef accounts are designed so that data can be safely removed once an account is deactivated. Besides the specifications and a detailed diff --git a/doc/src/learn/about-sui.md b/doc/src/learn/about-sui.md index 3ba8c0c55ff62..d79980e500338 100644 --- a/doc/src/learn/about-sui.md +++ b/doc/src/learn/about-sui.md @@ -6,13 +6,13 @@ Sui is the first permissionless Layer 1 blockchain designed from the ground up t ## What Sui is -Sui is a smart contract platform maintained by a permissionless set of authorities that play a role similar to validators or miners in other blockchain systems. +Sui is a smart contract platform maintained by a permissionless set of validators that play a role similar to validators or miners in other blockchain systems. Sui offers scalability and unprecedented low-latency for common use cases. Sui makes the vast majority of transactions processable in parallel, which makes better use of processing resources, and offers the option to increase throughput with more resources. Sui forgoes consensus to instead use simpler and lower-latency primitives for common use cases, such as payment transactions and assets transfer. This is unprecedented in the blockchain world and enables a number of new latency-sensitive distributed applications, ranging from gaming to retail payment at physical points of sale. Sui is written in [Rust](https://www.rust-lang.org) and supports smart contracts written in the [Move programming language](https://golden.com/wiki/Move_(programming_language)-MNA4DZ6) to define assets that may have an owner. Move programs define operations on these assets including custom rules for their creation, the transfer of these assets to new owners, and operations that mutate assets. -Sui has a native token called SUI, with a fixed supply. The SUI token is used to pay for gas, and is also used as [delegated stake on authorities](https://learn.bybit.com/blockchain/delegated-proof-of-stake-dpos/) within an epoch. The voting power of authorities within this epoch is a function of this delegated stake. Authorities are periodically reconfigured according to the stake delegated to them. In any epoch the set of authorities is [Byzantine fault tolerant](https://pmg.csail.mit.edu/papers/osdi99.pdf). At the end of the epoch, fees collected through all transactions processed are distributed to authorities according to their contribution to the operation of the system. Authorities can in turn share some of the fees as rewards to users that delegated stake to them. +Sui has a native token called SUI, with a fixed supply. The SUI token is used to pay for gas, and is also used as [delegated stake on validators](https://learn.bybit.com/blockchain/delegated-proof-of-stake-dpos/) within an epoch. The voting power of validators within this epoch is a function of this delegated stake. Validators are periodically reconfigured according to the stake delegated to them. In any epoch the set of validators is [Byzantine fault tolerant](https://pmg.csail.mit.edu/papers/osdi99.pdf). At the end of the epoch, fees collected through all transactions processed are distributed to validators according to their contribution to the operation of the system. Validators can in turn share some of the fees as rewards to users that delegated stake to them. Sui is backed by a number of state-of-the-art [peer-reviewed works](../contribute/research-papers.md) and years of open source development. @@ -20,7 +20,7 @@ Sui is backed by a number of state-of-the-art [peer-reviewed works](../contribut Sui scales horizontally with no upper bound to meet application demand while maintaining extremely low operating costs per transaction. Its system design breakthrough eliminates a critical bottleneck in existing blockchains: the need to achieve global consensus on a total-ordered list of transactions. This computation is wasteful given most transactions are not contending for the same resource against other transactions. -Sui takes a significant leap in scalability by enabling parallel agreement on causally independent transactions. Sui authorities commit such transactions using Byzantine Consistent Broadcast, eliminating global consensus's overhead without sacrificing safety and liveness guarantees. +Sui takes a significant leap in scalability by enabling parallel agreement on causally independent transactions. Sui validators commit such transactions using Byzantine Consistent Broadcast, eliminating global consensus's overhead without sacrificing safety and liveness guarantees. This breakthrough is possible only with Sui's novel data model. Thanks to its object-centric view and Move’s strong ownership types, dependencies are explicitly encoded. As a result, Sui both agrees on and executes transactions on most objects in parallel, while a minority of transactions that affect shared state are ordered via Byzantine Fault Tolerant consensus and executed in parallel. @@ -42,13 +42,13 @@ Today, users of existing blockchains pay a considerable tax as network usage inc * High-volume, low-value, per-transaction mass-market services like micropayments and coupons are priced out of the network * Artificially high floor prices on assets due to high gas prices -Sui scales horizontally to meet the demands of applications. Network capacity grows in proportion to the increase in Sui authorities' processing power by adding workers, resulting in low gas fees even during high network traffic. This scalability characteristic is in sharp contrast to other blockchains with rigid bottlenecks. +Sui scales horizontally to meet the demands of applications. Network capacity grows in proportion to the increase in Sui validators' processing power by adding workers, resulting in low gas fees even during high network traffic. This scalability characteristic is in sharp contrast to other blockchains with rigid bottlenecks. -By design, Sui authorities (nodes) can effectively scale the network throughput infinitely to meet the demand of builders and creators. We believe Sui can do for web3 what broadband internet did for web2. +By design, Sui validators (nodes) can effectively scale the network throughput infinitely to meet the demand of builders and creators. We believe Sui can do for web3 what broadband internet did for web2. -> **Note:** As of Mar. 19, 2022, an unoptimized single-worker Sui authority running on an 8-core M1 Macbook Pro can execute and commit 120,000 token transfer transactions per second (TPS). Throughput scales linearly with the number of cores–the same machine processes 25,000 TPS in a single core configuration. +> **Note:** As of Mar. 19, 2022, an unoptimized single-worker Sui validator running on an 8-core M1 Macbook Pro can execute and commit 120,000 token transfer transactions per second (TPS). Throughput scales linearly with the number of cores–the same machine processes 25,000 TPS in a single core configuration. -This experiment uses a configuration where each client submits a batch of 100 transactions (i.e., transfers to 100 distinct recipients) with a single signature. This configuration captures the anticipated usage pattern of a highly scalable blockchain--e.g., a custodial wallet or game server operating at scale will likely need to submit hundreds or thousands of on-chain transactions per second. With a batch size of 1, an authority running on the same machine can process 20,000 TPS with 8 cores, and exhibits the same linear growth in throughput as more cores are added. +This experiment uses a configuration where each client submits a batch of 100 transactions (i.e., transfers to 100 distinct recipients) with a single signature. This configuration captures the anticipated usage pattern of a highly scalable blockchain--e.g., a custodial wallet or game server operating at scale will likely need to submit hundreds or thousands of on-chain transactions per second. With a batch size of 1, an validator running on the same machine can process 20,000 TPS with 8 cores, and exhibits the same linear growth in throughput as more cores are added. We will publish a full performance report for optimized Sui networks in a variety of configurations when our testnet is released. diff --git a/doc/src/learn/how-sui-works.md b/doc/src/learn/how-sui-works.md index 9b0848853e82b..11d629376ef68 100644 --- a/doc/src/learn/how-sui-works.md +++ b/doc/src/learn/how-sui-works.md @@ -10,7 +10,7 @@ This document is written for engineers, developers, and technical readers knowle The Sui blockchain operates at a speed and scale previously thought unimaginable. Sui assumes the typical blockchain transaction is a simple transfer and optimizes for that use. Sui does this by making each request idempotent, holding network connections open longer, and ensuring transactions complete immediately. Sui optimizes for single-writer objects, allowing a design that forgoes consensus for simple/common transactions. -Instead of the traditional blockchain’s fire-and-forget broadcast, Sui ensures a two-way handshake between the requestor and approving authorities, with simple transactions having near instant finality. With this low latency, transactions can easily be incorporated into games and other settings that need completion in real time. Furthermore, Sui supports smart contracts written in Move, a language designed for blockchains with strong inherent security and a more understandable programming model. +Instead of the traditional blockchain’s fire-and-forget broadcast, Sui ensures a two-way handshake between the requestor and approving validators, with simple transactions having near instant finality. With this low latency, transactions can easily be incorporated into games and other settings that need completion in real time. Furthermore, Sui supports smart contracts written in Move, a language designed for blockchains with strong inherent security and a more understandable programming model. In a world where the cost of bandwidth is diminishing steadily, we are creating an ecosystem of services that will find it easy, fun, and perhaps profitable to ensure transaction voting on behalf of users. @@ -38,7 +38,7 @@ flowchart LR AC2 <==>|Network TCP| Authority2 ``` -Sui authorities agree on and execute transactions in parallel with high throughput using [Byzantine Consistent Broadcast](https://en.wikipedia.org/wiki/Byzantine_fault). +Sui validators agree on and execute transactions in parallel with high throughput using [Byzantine Consistent Broadcast](https://en.wikipedia.org/wiki/Byzantine_fault). ## System overview @@ -48,16 +48,16 @@ Sui assumes the typical blockchain transaction is a user-to-user transfer or ass Sui mitigates a major hindrance to blockchain growth: [head-of-line blocking](https://en.wikipedia.org/wiki/Head-of-line_blocking). Blockchain nodes maintain an accumulator that represents the state of the entire blockchain, such as the latest certified transactions. Nodes participate in a consensus protocol to add an update to that state reflecting the transaction’s modification to blocks (add, remove, mutate). That consensus protocol leads to an agreement on the state of the blockchain before the increment, the validity and suitability of the state update itself, and the state of the blockchain after the increment. On a periodic basis, these increments are collected in the accumulator. -In Sui, this consensus protocol is required only when the transaction involves shared objects. When shared objects are involved, the Sui authorities play the role of more active validators in other blockchains to totally order the transaction with respect to other transactions accessing shared objects. +In Sui, this consensus protocol is required only when the transaction involves shared objects. When shared objects are involved, the Sui validators play the role of more active validators in other blockchains to totally order the transaction with respect to other transactions accessing shared objects. Because Sui focuses on managing specific objects rather than a single aggregation of state, it also reports on them in a unique way: (i) every object in Sui has a unique version number, and (ii) every new version is created from a transaction that may involve several dependencies, themselves versioned objects. -As a consequence, a Sui authority – or any other entity with a copy of the state – can exhibit a causal history of an object, showing its history since genesis. Sui explicitly makes the bet that in most cases, the ordering of that causal history with the causal history of another object is irrelevant; and in the few cases where this information is relevant, Sui makes this relationship explicit in the data. +As a consequence, a Sui validator – or any other entity with a copy of the state – can exhibit a causal history of an object, showing its history since genesis. Sui explicitly makes the bet that in most cases, the ordering of that causal history with the causal history of another object is irrelevant; and in the few cases where this information is relevant, Sui makes this relationship explicit in the data. Sui guarantees transaction processing obeys *[eventual consistency](https://en.wikipedia.org/wiki/Eventual_consistency)* in the [classical sense](https://hal.inria.fr/inria-00609399/document). This breaks down in two parts: -* Eventual delivery - if one honest authority processes a transaction, all other honest authorities will eventually do the same. -* Convergence - two authorities that have seen the same set of transactions share the same view of the system (reach the same state). +* Eventual delivery - if one honest validator processes a transaction, all other honest validators will eventually do the same. +* Convergence - two validators that have seen the same set of transactions share the same view of the system (reach the same state). But contrary to a blockchain, Sui does not stop the flow of transactions in order to witness the convergence. @@ -71,9 +71,9 @@ Sui validates transactions individually, rather than batching them into traditio The process of submitting a Sui transaction is thus a bit more involved than in traditional blockchains. Whereas a usual blockchain can accept a bunch of transactions from the same author in a fire-and-forget mode, Sui transaction submission follows these steps: -1. The sender broadcasts a transaction to all Sui authorities. -2. Each Sui authority replies with an individual vote for this transaction. Each vote has a certain weight based on the stake owned by the authority. -3. The sender collects a Byzantine-resistant-majority of these votes into a _certificate_ and broadcasts that back to all Sui authorities. This settles the transaction, ensuring _finality_ that the transaction will not be dropped (revoked). +1. The sender broadcasts a transaction to all Sui validators. +2. Each Sui validator replies with an individual vote for this transaction. Each vote has a certain weight based on the stake owned by the validator. +3. The sender collects a Byzantine-resistant-majority of these votes into a _certificate_ and broadcasts that back to all Sui validators. This settles the transaction, ensuring _finality_ that the transaction will not be dropped (revoked). 4. Optionally, the sender collects a certificate detailing the effects of the transaction. While those steps demand more of the sender, performing them efficiently can still yield a cryptographic proof of finality with minimum latency. Aside from crafting the original transaction itself, the session management for a transaction does not require access to any private keys and can be delegated to a third party. Sui takes advantage of this observation to provide [Sui Gateway services](#sui-gateway-services). @@ -85,24 +85,24 @@ Complex smart contracts may benefit from shared objects where more than one user Transactions involving shared objects also contain at least one owned object to pay for gas fees. It is thus essential to carefully compose the protocol dealing with owned objects with the protocol sequencing the transaction to guarantee Sui’s security properties. When shared objects are involved, transaction submission follows these steps: -1. The sender broadcasts a transaction to all Sui authorities. -2. Each Sui authority replies with an individual vote for this transaction. Each vote has a certain weight based on the stake owned by the authority. -3. The sender collects a Byzantine-resistant-majority of these votes into a certificate and broadcasts it back to all Sui authorities. _This time however, the certificate is sequenced through Byzantine Agreement._ -4. Once the transaction has been successfully sequenced, the user broadcasts again the certificate to the authorities to settle the transaction. +1. The sender broadcasts a transaction to all Sui validators. +2. Each Sui validator replies with an individual vote for this transaction. Each vote has a certain weight based on the stake owned by the validator. +3. The sender collects a Byzantine-resistant-majority of these votes into a certificate and broadcasts it back to all Sui validators. _This time however, the certificate is sequenced through Byzantine Agreement._ +4. Once the transaction has been successfully sequenced, the user broadcasts again the certificate to the validators to settle the transaction. ## Scalability -As mentioned, Sui does not impose a total order on the transactions containing only owned objects. Instead, transactions are [causally ordered](sui-compared.md#causal-order-vs-total-order). If a transaction `T1` produces an output object `O1` used as input objects in a transaction `T2`, an authority must execute `T1` before it executes `T2`. Note that `T2` does not need to use these objects directly for a causal relationship to exist, e.g., `T1` might produce output objects which are then used by `T3`, and `T2` might use `T3`'s output objects. However, transactions with no causal relationship can be processed by Sui authorities in any order. This insight allows Sui to massively parallelize execution, and shard it across multiple machines. +As mentioned, Sui does not impose a total order on the transactions containing only owned objects. Instead, transactions are [causally ordered](sui-compared.md#causal-order-vs-total-order). If a transaction `T1` produces an output object `O1` used as input objects in a transaction `T2`, an validator must execute `T1` before it executes `T2`. Note that `T2` does not need to use these objects directly for a causal relationship to exist, e.g., `T1` might produce output objects which are then used by `T3`, and `T2` might use `T3`'s output objects. However, transactions with no causal relationship can be processed by Sui validators in any order. This insight allows Sui to massively parallelize execution, and shard it across multiple machines. -Sui employs the [state-of-the-art Narwhal consensus protocol](https://arxiv.org/abs/2105.11827) to totally order transactions involving shared objects. The consensus sub-system also scales in the sense that it can sequence more transactions by adding more machines per authority. +Sui employs the [state-of-the-art Narwhal consensus protocol](https://arxiv.org/abs/2105.11827) to totally order transactions involving shared objects. The consensus sub-system also scales in the sense that it can sequence more transactions by adding more machines per validator. ## Sui Gateway services The Sui model encourages third parties to assist with transaction submissions. For example, if an app developer (e.g., a game developer) has many users, they can manage votes aggregation and certificate submission on behalf of their users. The app developer may use their own servers (e.g., where they store the state of the game) to run a _Sui Gateway service_. We provide a reference implementation of such a service. -Instead of the app users attempting to send transactions to multiple authorities from their mobile device, which may degrade user experience, users may submit their transactions to the app, which forwards it to the Sui Gateway service run by the app developer. The Sui Gateway service conducts the entire transaction session and returns the results to the users. Security is assured since the app doesn’t need to know the users’ private keys; the app owner merely provides the bandwidth. +Instead of the app users attempting to send transactions to multiple validators from their mobile device, which may degrade user experience, users may submit their transactions to the app, which forwards it to the Sui Gateway service run by the app developer. The Sui Gateway service conducts the entire transaction session and returns the results to the users. Security is assured since the app doesn’t need to know the users’ private keys; the app owner merely provides the bandwidth. -More specifically, this service plays the role of an accumulator and makes sure the transaction is received by a quorum of authorities, collects a quorum of votes, submits the certificate to the authorities, and replies to the client. The Sui Gateway is trusted for availability only and not safety. +More specifically, this service plays the role of an accumulator and makes sure the transaction is received by a quorum of validators, collects a quorum of votes, submits the certificate to the validators, and replies to the client. The Sui Gateway is trusted for availability only and not safety. In a world where the cost of bandwidth is diminishing steadily, Sui fosters an ecosystem of services that will find it easy, fun, and perhaps profitable to ensure transaction voting and certificates broadcast on behalf of end-users. diff --git a/doc/src/learn/index.md b/doc/src/learn/index.md index 1d678890c9fa4..d9cde0cd691a8 100644 --- a/doc/src/learn/index.md +++ b/doc/src/learn/index.md @@ -36,7 +36,7 @@ Finish with the [Sui Tutorial](../explore/tutorials.md) for a summary view of se Navigate and search this site however you see fit. Here is the order we recommend if you are new to Sui: 1. Learn [about Sui](../learn/about-sui.md), how [Sui differs from Move](../learn/why-move.md), and [how Sui works](../learn/how-sui-works.md) starting in this very section. -1. [Build](../build/index.md) smart contracts, wallets, authorities, transactions, and more. +1. [Build](../build/index.md) smart contracts, wallets, validators, transactions, and more. 1. [Explore](../explore/index.md) NFTs, make transfers, and see the Sui API. 1. [Contribute](../contribute/index.md) to Sui by joining the community, making enhancements, and learning about Mysten Labs. diff --git a/doc/src/learn/sui-compared.md b/doc/src/learn/sui-compared.md index 5e261e8f653eb..e4f02ce42dead 100644 --- a/doc/src/learn/sui-compared.md +++ b/doc/src/learn/sui-compared.md @@ -32,10 +32,10 @@ Sui validates transactions individually, rather than batching them in the tradit But the process of submitting a transaction is a bit more involved. That little more work occurs on the network. (With bandwidth getting cheaper, this is less of a concern.) Whereas a usual blockchain can accept a bunch of transactions from the same author in a fire-and-forget mode, Sui transaction submission follows these steps: -1. Sender broadcasts a transaction to all Sui authorities. -1. Sui authorities send individual votes on this transaction to the sender. -1. Each vote has a certain weight since each authority has weight based upon the rules of [Proof of Stake](https://en.wikipedia.org/wiki/Proof_of_work). -1. Sender collects a Byzantine-resistant-majority of these votes into a *certificate* and broadcasts it to all Sui authorities, thereby ensuring *finality*, or assurance the transaction will not be dropped (revoked). +1. Sender broadcasts a transaction to all Sui validators. +1. Sui validators send individual votes on this transaction to the sender. +1. Each vote has a certain weight since each validator has weight based upon the rules of [Proof of Stake](https://en.wikipedia.org/wiki/Proof_of_work). +1. Sender collects a Byzantine-resistant-majority of these votes into a *certificate* and broadcasts it to all Sui validators, thereby ensuring *finality*, or assurance the transaction will not be dropped (revoked). 1. Optionally, the sender collects a certificate detailing the effects of the transaction. While those steps demand more of the sender, performing them efficiently can still yield a cryptographic proof of finality with minimum latency. Aside from crafting the original transaction itself, the session management for a transaction does not require access to any private keys and can be delegated to a third party. @@ -47,19 +47,19 @@ Because Sui focuses on managing specific objects rather than a single aggregate * Every object in Sui has a unique version number. * Every new version is created from a transaction that may involve several dependencies, themselves versioned objects. -As a consequence, a Sui authority -- or any other authority with a copy of the state -- can exhibit a causal history of an object, showing its history since genesis. Sui explicitly makes the bet that in most cases, the ordering of that causal history with the causal history of another object is irrelevant; and in the few cases where this information is relevant, Sui makes this relationship explicit in the data. +As a consequence, a Sui validator -- or any other validator with a copy of the state -- can exhibit a causal history of an object, showing its history since genesis. Sui explicitly makes the bet that in most cases, the ordering of that causal history with the causal history of another object is irrelevant; and in the few cases where this information is relevant, Sui makes this relationship explicit in the data. -## Authorities vs. validators/miners +## Validators vs. validators/miners -An authority plays a role similar to "validators" or "miners" in other blockchain systems. The key distinction between these roles (and the reason we insist on using a separate term) is that validators/miners are *active*, whereas authorities are *passive* for the main type of Sui transaction involving single-writer objects. Broadly speaking, to deal with a transfer: +An validator plays a role similar to "validators" or "miners" in other blockchain systems. The key distinction between these roles (and the reason we insist on using a separate term) is that validators/miners are *active*, whereas validators are *passive* for the main type of Sui transaction involving single-writer objects. Broadly speaking, to deal with a transfer: * Miners/validators continuously participate in a global consensus protocol that requires multiple rounds of all-to-all communication between the participants. The goal is typically to agree on a *totally ordered* block of transactions and the result of their execution. -* Authorities do nothing until they receive a transaction or certificate from a user. Upon receiving a transaction or certificate, an authority need not communicate with other authorities in order to take action and advance its internal state machine. It may wish to communicate with other authorities to share certificates but need not do so. +* Validators do nothing until they receive a transaction or certificate from a user. Upon receiving a transaction or certificate, an validator need not communicate with other validators in order to take action and advance its internal state machine. It may wish to communicate with other validators to share certificates but need not do so. ## Causal order vs. total order -Unlike most existing blockchain systems (and as the reader may have guessed from the description of write requests above), Sui does not always impose a total order on the transactions submitted by clients, with shared objects being the exception. Instead, most transactions are *causally* ordered--if a transaction `T1` produces output objects `O1` that are used as input objects in a transaction `T2`, an authority must execute `T1` before it executes `T2`. Note that `T2` need not use these objects directly for a causal relationship to exist--e.g., `T1` might produce output objects which are then used by `T3`, and `T2` might use `T3`'s output objects. However, transactions with no causal relationship can be processed by Sui authorities in any order. +Unlike most existing blockchain systems (and as the reader may have guessed from the description of write requests above), Sui does not always impose a total order on the transactions submitted by clients, with shared objects being the exception. Instead, most transactions are *causally* ordered--if a transaction `T1` produces output objects `O1` that are used as input objects in a transaction `T2`, an validator must execute `T1` before it executes `T2`. Note that `T2` need not use these objects directly for a causal relationship to exist--e.g., `T1` might produce output objects which are then used by `T3`, and `T2` might use `T3`'s output objects. However, transactions with no causal relationship can be processed by Sui validators in any order. ## Where Sui excels @@ -69,18 +69,18 @@ This section summarizes the main advantages of Sui with respect to traditional b Sui’s main selling point is its unprecedented performance. The following bullet points summarize the main performance benefits of Sui with respect to traditional blockchains: -* Sui forgoes consensus for most transactions while other blockchains always totally order them. Causally ordering transactions allows Sui to massively parallelize the execution of most transactions; this reduces latency and allows authorities to take advantage of all their CPU cores. -* Sui pushes the complexity at the edges: the client is involved in a number of protocol steps. This minimizes the interactions between authorities and keeps their code simpler and more efficient. Sui always gives the possibility to offload most of the client’s workload to a Sui Gateway service for better user experience. In contrast, traditional blockchains follow a fire-and-forget model where clients monitor the blockchain state to assess the success of their transaction submission. +* Sui forgoes consensus for most transactions while other blockchains always totally order them. Causally ordering transactions allows Sui to massively parallelize the execution of most transactions; this reduces latency and allows validators to take advantage of all their CPU cores. +* Sui pushes the complexity at the edges: the client is involved in a number of protocol steps. This minimizes the interactions between validators and keeps their code simpler and more efficient. Sui always gives the possibility to offload most of the client’s workload to a Sui Gateway service for better user experience. In contrast, traditional blockchains follow a fire-and-forget model where clients monitor the blockchain state to assess the success of their transaction submission. * Sui operates at network speed without waiting for system timeouts between protocol steps. This significantly reduces latency when the network is good and not under attack. In contrast, the security of a number of traditional blockchains (including most proof-of-work based blockchains) need to wait for predefined timeouts before committing transactions. -* Sui can take advantage of more machines per authority to increase its performance. Traditional blockchains are often designed to run on a single machine per validator (or even on a single CPU). +* Sui can take advantage of more machines per validator to increase its performance. Traditional blockchains are often designed to run on a single machine per validator (or even on a single CPU). ### Performance under faults -Sui runs a leaderless protocol to process common transactions (i.e. containing only owned objects). As a result, faulty authorities do not impact performance in any significant way. For transactions involving shared objects, Sui employs a state-of-the-art consensus protocol requiring no [view-change sub-protocol](https://pmg.csail.mit.edu/papers/osdi99.pdf) and thus experiences only slight performance degradations. In contrast, most leader-based blockchains experiencing even a single validator’s crash see their throughput fall and their latency increase (often by more than one order of magnitude). +Sui runs a leaderless protocol to process common transactions (i.e. containing only owned objects). As a result, faulty validators do not impact performance in any significant way. For transactions involving shared objects, Sui employs a state-of-the-art consensus protocol requiring no [view-change sub-protocol](https://pmg.csail.mit.edu/papers/osdi99.pdf) and thus experiences only slight performance degradations. In contrast, most leader-based blockchains experiencing even a single validator’s crash see their throughput fall and their latency increase (often by more than one order of magnitude). ### Security assumptions -Contrary to many traditional blockchains, Sui does not make strong synchrony assumptions on the network. This means that Sui maintains its security properties under bad network conditions (even excessively bad), network splits/partitions, or even powerful DoS attacks targeted on the authorities. Sustained network attacks on synchronous blockchains (i.e., most proof-of-work based blockchains) can lead to double-spend of resources and deadlocks. +Contrary to many traditional blockchains, Sui does not make strong synchrony assumptions on the network. This means that Sui maintains its security properties under bad network conditions (even excessively bad), network splits/partitions, or even powerful DoS attacks targeted on the validators. Sustained network attacks on synchronous blockchains (i.e., most proof-of-work based blockchains) can lead to double-spend of resources and deadlocks. ### Efficient local read operations @@ -106,7 +106,7 @@ While traditional blockchains require implementing only a single consensus proto Transactions involving shared objects require a little overhead (adding two extra round trips - 200ms for well-connected clients using a Sui Gateway service) before submitting it to the consensus protocol. This overhead is required to securely compose the two protocols described above. Other blockchains can instead directly submit the transaction to the consensus protocol. Note the finality for shared object transactions is still in the 2-3 second range even with this overhead. -Building an efficient synchronizer is harder in Sui than in traditional blockchains. The synchronizer sub-protocol allows authorities to update each other by sharing data, and it allows slow authorities to catch up. Building an efficient synchronizer for traditional blockchains is no easy task, but still simpler than in Sui. +Building an efficient synchronizer is harder in Sui than in traditional blockchains. The synchronizer sub-protocol allows validators to update each other by sharing data, and it allows slow validators to catch up. Building an efficient synchronizer for traditional blockchains is no easy task, but still simpler than in Sui. ### Sequential writes in the common case @@ -118,11 +118,11 @@ The downside of allowing head-of-line blocking on the sender for these simple tr ### Complex total queries -Sui can make total queries more difficult than in traditional blockchains since it does not always impose total order of transactions. Total queries are fairly rare with respect to local reads (see above) but useful in some scenarios. For example, a new authority joins the network and needs to download the total state to disk, or an auditor wishes to audit the entire blockchain. +Sui can make total queries more difficult than in traditional blockchains since it does not always impose total order of transactions. Total queries are fairly rare with respect to local reads (see above) but useful in some scenarios. For example, a new validator joins the network and needs to download the total state to disk, or an auditor wishes to audit the entire blockchain. Sui mitigates this with checkpoints. A checkpoint is established every time an increment is added to a blockchain resulting from a certified transaction. Blocks work much like a [write ahead log](https://en.wikipedia.org/wiki/Write-ahead_logging) that stores state prior to full execution of a program. The calls in that program represent a smart contract in a blockchain. A block contains not only the transactions but also commitments to the state of the blockchain before and after the transactions. -Sui uses the state commitment that arrives upon epoch change. Sui requires a single answer from the multiple authorities and leverages an accessory protocol to derive the hash representing the state of the blockchain. This protocol consumes little bandwidth and does not impede the ingestion of transactions. Authorities produce checkpoints at every epoch change. Sui requires the authorities to also produce checkpoints even more frequently. So users may use these checkpoints to audit the blockchain with some effort. +Sui uses the state commitment that arrives upon epoch change. Sui requires a single answer from the multiple validators and leverages an accessory protocol to derive the hash representing the state of the blockchain. This protocol consumes little bandwidth and does not impede the ingestion of transactions. Validators produce checkpoints at every epoch change. Sui requires the validators to also produce checkpoints even more frequently. So users may use these checkpoints to audit the blockchain with some effort. ## Conclusion diff --git a/doc/src/learn/sui-glossary.md b/doc/src/learn/sui-glossary.md index 13f94a4229335..b4549146db586 100644 --- a/doc/src/learn/sui-glossary.md +++ b/doc/src/learn/sui-glossary.md @@ -7,22 +7,22 @@ Find terms used in Sui defined below. Where possible, we link to a canonical def ### Accumulator -An *accumulator* makes sure the transaction is received by a quorum of authorities, collects a quorum of votes, submits the certificate to the authorities, and replies to the client. The accumulator enables transactions to be certified. Sui offers a Gateway service that can assume the role of accumulator and collect votes on transactions from authorities in Sui, saving end-users bandwidth. +An *accumulator* makes sure the transaction is received by a quorum of validators, collects a quorum of votes, submits the certificate to the validators, and replies to the client. The accumulator enables transactions to be certified. Sui offers a Gateway service that can assume the role of accumulator and collect votes on transactions from validators in Sui, saving end-users bandwidth. -### Authority +### Validator -An authority in Sui plays a passive role analogous to the more active role of validators and minors in other blockchains. In Sui, -authorities do not continuously participate in the consensus protocol but are called into action only when receiving a transaction or +An validator in Sui plays a passive role analogous to the more active role of validators and minors in other blockchains. In Sui, +validators do not continuously participate in the consensus protocol but are called into action only when receiving a transaction or certificate. -For more information, see [Authorities vs validators/miners](sui-compared#authorities-vs-validatorsminers). +For more information, see [Validators vs validators/miners](sui-compared#validators-vs-validatorsminers). ### Causal order [Causal order](https://www.scattered-thoughts.net/writing/causal-ordering/) is a representation of the relationship between transactions -and the objects they produce, laid out as dependencies. Authorities cannot execute a transaction dependent on objects created by a prior +and the objects they produce, laid out as dependencies. Validators cannot execute a transaction dependent on objects created by a prior transaction that has not finished. Rather than total order, Sui uses causal order (a partial order). For more information, see [Causal order vs total order](sui-compared#causal-order-vs-total-order). @@ -30,8 +30,8 @@ For more information, see [Causal order vs total order](sui-compared#causal-orde ### Certificate -A certificate is the mechanism proving a transaction has been approved, or certified. Authorities vote on transactions, and an aggregator collects -a Byzantine-resistant-majority of these votes into a certificate and broadcasts it to all Sui authorities, thereby ensuring finality. +A certificate is the mechanism proving a transaction has been approved, or certified. Validators vote on transactions, and an aggregator collects +a Byzantine-resistant-majority of these votes into a certificate and broadcasts it to all Sui validators, thereby ensuring finality. ### Equivocation @@ -41,15 +41,15 @@ Equivocation in blockchains is the malicious action of dishonest actors giving c ### Epoch -Operation of the Sui network is temporally partitioned into non-overlapping, fixed-duration *epochs*. During a particular epoch, the set of authorities participating in the network is fixed. +Operation of the Sui network is temporally partitioned into non-overlapping, fixed-duration *epochs*. During a particular epoch, the set of validators participating in the network is fixed. For more information, see [Epochs](../build/authorities.md#epochs). ### Eventual consistency -[Eventual consistency](https://en.wikipedia.org/wiki/Eventual_consistency) is the consensus model employed by Sui; if one honest authority -certifies the transaction, all of the other honest authorities will too eventually. +[Eventual consistency](https://en.wikipedia.org/wiki/Eventual_consistency) is the consensus model employed by Sui; if one honest validator +certifies the transaction, all of the other honest validators will too eventually. ### Causal history @@ -91,7 +91,7 @@ those affecting only single-writer objects, which require only a confirmation of ### Proof-of-stake -[Proof-of-stake](https://en.wikipedia.org/wiki/Proof_of_stake) is a blockchain consensus mechanism where the voting weights of authorities or validators is proportional to a bonded amount of the network's native currency (called their stake in the network). This mitigates [Sybil attacks](https://en.wikipedia.org/wiki/Sybil_attack) by forcing bad actors to gain a large stake in the blockchain first. +[Proof-of-stake](https://en.wikipedia.org/wiki/Proof_of_stake) is a blockchain consensus mechanism where the voting weights of validators or validators is proportional to a bonded amount of the network's native currency (called their stake in the network). This mitigates [Sybil attacks](https://en.wikipedia.org/wiki/Sybil_attack) by forcing bad actors to gain a large stake in the blockchain first. ### Smart contract diff --git a/doc/src/learn/sui-security.md b/doc/src/learn/sui-security.md index b795540a383aa..4da99d1d8c5e3 100644 --- a/doc/src/learn/sui-security.md +++ b/doc/src/learn/sui-security.md @@ -17,7 +17,7 @@ the basic components of Sui. We designed Sui to provide very high security guarantees to asset owners. We ensure that assets on Sui can be used only by their owners, according to the logic pre-defined by smart contracts that can be audited, and that the network will be available -to process them correctly despite some of the authorities operating Sui not following the protocol correctly (fault tolerance). +to process them correctly despite some of the validators operating Sui not following the protocol correctly (fault tolerance). The security features of the Sui system ensure a number of properties: @@ -26,28 +26,28 @@ The security features of the Sui system ensure a number of properties: * Transactions operate on assets according to predefined rules set by the smart contract creator that defined the asset type. These are expressed using the Move language. * Once a transaction is finalized, its effects - namely changes to the assets it operates on or new assets created - will be persisted, and the resulting assets will be available for further processing. -* The Sui system operates through a protocol between a set of independent authorities. Yet all its security properties are preserved - when a small subset of the authorities do not follow the protocol. +* The Sui system operates through a protocol between a set of independent validators. Yet all its security properties are preserved + when a small subset of the validators do not follow the protocol. * All operations in Sui can be audited to ensure any assets have been correctly processed. This implies all operations on Sui are visible to all, and users may wish to use multiple different addresses to protect their privacy. -* Authorities are determined periodically through users of Sui locking and delegating SUI tokens to one or more authorities. +* Validators are determined periodically through users of Sui locking and delegating SUI tokens to one or more validators. ## Security architecture -The Sui system is operated by a set of authorities that process transactions. They implement the Sui protocol that allows them to +The Sui system is operated by a set of validators that process transactions. They implement the Sui protocol that allows them to reach agreement on valid transactions submitted and processed in the system. -The agreement protocols Sui uses tolerate a fraction of authorities not following the Sui protocol correctly, through -the use of Byzantine fault tolerant broadcast and consensus. Specifically, each authority has some voting power, +The agreement protocols Sui uses tolerate a fraction of validators not following the Sui protocol correctly, through +the use of Byzantine fault tolerant broadcast and consensus. Specifically, each validator has some voting power, assigned to it through the process of users delegating / voting for them using their SUI tokens. Sui maintains -all its security properties if over 2/3 of the stake is assigned to authorities that follow the protocol. However, -a number of auditing properties are maintained even if more authorities are faulty. +all its security properties if over 2/3 of the stake is assigned to validators that follow the protocol. However, +a number of auditing properties are maintained even if more validators are faulty. ### Addresses and ownership A Sui transaction is valid and can proceed only if the owner of all owned assets it operates on digitally signs it with their private signature key (currently using the EdDSA algorithm). This signature key can be kept private by the user and not be shared with -anyone else. As a result, it is not feasible for any other party to operate on an owned asset of a user undetected, even if all authorities +anyone else. As a result, it is not feasible for any other party to operate on an owned asset of a user undetected, even if all validators do not follow the protocol. A private signature key also corresponds to a public address on the Sui network that can be used to send a user assets or @@ -77,12 +77,12 @@ on which address and how the shared assets may be used. ### Transaction finality -A valid transaction submitted to all authorities to be certified and its certificate also has to be submitted to all authorities -to be finalized. Even if a subset of authorities do not follow the protocol, the transaction can be finalized through the -remaining authorities that correctly follow the Sui protocol. This is achieved throught the use of cryptographic +A valid transaction submitted to all validators to be certified and its certificate also has to be submitted to all validators +to be finalized. Even if a subset of validators do not follow the protocol, the transaction can be finalized through the +remaining validators that correctly follow the Sui protocol. This is achieved throught the use of cryptographic Byzantine fault tolerant agremment protocols for broadcast and consensus defined by the Sui protocol. These protocols -ensure both safety, meaning that the incorrect authorities cannot convince correct clients of incorrect state, and -liveness, meaning that incorrect authorities cannot prevent transaction processing. +ensure both safety, meaning that the incorrect validators cannot convince correct clients of incorrect state, and +liveness, meaning that incorrect validators cannot prevent transaction processing. All transactions in Sui have to be associated with a gas asset to cover the cost of processing by Sui. A valid transaction may result in a status of successful execution or an aborted execution. An execution may abort due to a @@ -92,18 +92,18 @@ assets in the transaction is not changed. However, the gas asset is always charg denial-of-service attacks on the system as a whole. A user client can perform the process of submitting the transaction and certificate itself or rely on third party -services to submit the transaction and interact with authorities. Such third parties need not have user private signature keys and cannot forge transactions on the users' behalf. +services to submit the transaction and interact with validators. Such third parties need not have user private signature keys and cannot forge transactions on the users' behalf. They can reassure a user client a transaction has been finalized through a set of signatures from -authorities attesting to the transactions finality and its effects. After that point, the users can be assured that +validators attesting to the transactions finality and its effects. After that point, the users can be assured that changes the transaction resulted in are final. ### Auditing and privacy -Sui authorities provide facilities for users to read all asserts they store, as well as the historical record of -transactions they have processed that led to these assets. Authorities also provide cryptographic evidence of the full +Sui validators provide facilities for users to read all asserts they store, as well as the historical record of +transactions they have processed that led to these assets. Validators also provide cryptographic evidence of the full chain of transactions that contributed to an asset state. User clients can request and validate this chain of -evidence to ensure all operations were correct and the result of the collective agreement between authorities. -Services that operate full replicas, mirroring the state of one or more authorities, perform such audits routinely. +evidence to ensure all operations were correct and the result of the collective agreement between validators. +Services that operate full replicas, mirroring the state of one or more validators, perform such audits routinely. The extreme public auditability of Sui also implies that all transactions and assets within Sui are publicly visible. Users that are mindful of their privacy may use multiple addresses to benefit from some degree of @@ -111,14 +111,14 @@ pseudonymity, or third-party custodial or non-custodial services. Specific smart ### Censorship-resistance and openness -Sui uses the established Delegated Proof-of Stake model to periodically determine its set of authorities. Users can lock and delegate their SUI tokens in each epoch to determine the committee of authorities that operate the Sui network in the next epoch. Anyone with over a minimum -amount of delegated stake may operate an authority. +Sui uses the established Delegated Proof-of Stake model to periodically determine its set of validators. Users can lock and delegate their SUI tokens in each epoch to determine the committee of validators that operate the Sui network in the next epoch. Anyone with over a minimum +amount of delegated stake may operate an validator. -Authorities operate the network and provide -rewards to users that delegated their Sui to support them as validators, through gas fee income. Authorities with poor reliability, and in turn the users that delegated their stake to them, may receive a lower reward. But user stake cannot be confiscated away either by malicious authorities or anyone in the network. +Validators operate the network and provide +rewards to users that delegated their Sui to support them as validators, through gas fee income. Validators with poor reliability, and in turn the users that delegated their stake to them, may receive a lower reward. But user stake cannot be confiscated away either by malicious validators or anyone in the network. -This mechanism ensures that authorities are accountable to Sui users and can be rotated out at the first sign -of unreliability or misbehavior, including noticed attempts to censor valid transactions. Through choices of authorities, and the protocol +This mechanism ensures that validators are accountable to Sui users and can be rotated out at the first sign +of unreliability or misbehavior, including noticed attempts to censor valid transactions. Through choices of validators, and the protocol they are willing to operate, Sui users also have a meaningful say on the future evolution of the Sui system. ## Further reading diff --git a/doc/src/learn/why-move.md b/doc/src/learn/why-move.md index f92a9a6350337..6d870e3bcc04e 100644 --- a/doc/src/learn/why-move.md +++ b/doc/src/learn/why-move.md @@ -14,8 +14,8 @@ One fundamental difference between the EVM and Move is the data model for assets - EVM assets are encoded as entries in `owner_address -> ` hash maps. Asset updates and transfers work by updating entries in this map. There is no type or value representing an asset, and thus an asset cannot be passed as an argument, returned from a function, or be stored inside of another asset. Only unstructured bytes can be passed across contract boundaries, and thus each asset is forever trapped inside the contract that defines it. - Move assets are arbitrary user-defined types. Assets can be passed as arguments, returned from functions, and stored inside other assets. In addition, assets can flow freely across contract boundaries without losing their integrity thanks to Move's built-in *resource safety* [1](https://diem-developers-components.netlify.app/papers/diem-move-a-language-with-programmable-resources/2020-05-26.pdf) [2](https://arxiv.org/abs/2004.05106) protections. -Sui heavily leverages the Move data model for performance. Sui's persistent state is a set of programmable Move objects that can be updated, created, and destroyed by transactions. Each object has ownership metadata that allows Sui authorities to both execute and commit transactions using the object in parallel with causally unrelated transactions. Move's type system ensures the integrity of this ownership metadata across executions. The result is a system where developers write ordinary Move smart contracts, but validators leverage the data model to execute and commit transactions as efficiently as possible. +Sui heavily leverages the Move data model for performance. Sui's persistent state is a set of programmable Move objects that can be updated, created, and destroyed by transactions. Each object has ownership metadata that allows Sui validators to both execute and commit transactions using the object in parallel with causally unrelated transactions. Move's type system ensures the integrity of this ownership metadata across executions. The result is a system where developers write ordinary Move smart contracts, but validators leverage the data model to execute and commit transactions as efficiently as possible. -This is simply not possible with the EVM data model. Because assets are stored in dynamically indexable maps, an authority would be unable to determine when transactions might touch the same asset. Sui's parallel execution and commitment scheme needs a language like Move with the vocabulary to describe structured assets that can flow freely across contracts. To be blunt: **even if we preferred the EVM/Solidity to Move, we could not use them in Sui without sacrificing the performance breakthroughs that make Sui unique**. +This is simply not possible with the EVM data model. Because assets are stored in dynamically indexable maps, an validator would be unable to determine when transactions might touch the same asset. Sui's parallel execution and commitment scheme needs a language like Move with the vocabulary to describe structured assets that can flow freely across contracts. To be blunt: **even if we preferred the EVM/Solidity to Move, we could not use them in Sui without sacrificing the performance breakthroughs that make Sui unique**. One of the main advantages of Move is data composability. It is always possible to create a new struct (asset) Y that will hold initial asset X in it. Even more - with addition of generics, it is possible to define generic wrapper Z(T) that will be able to wrap any asset, providing additional properties to a wrapped asset or combining it with others. See how composability works in our [Sandwich example](https://github.com/MystenLabs/sui/tree/main/sui_programmability/examples/basics/sources/Sandwich.move). diff --git a/doc/src/navconfig.json b/doc/src/navconfig.json index 19cecff536d0a..2c4751c414892 100644 --- a/doc/src/navconfig.json +++ b/doc/src/navconfig.json @@ -71,7 +71,7 @@ "fileName": "build/sui-json" }, { - "label": "Understand Authorities", + "label": "Understand Validators", "fileName": "build/authorities" }, { From 58194bf211e3c63cc49fa3be81e6872fb08f66aa Mon Sep 17 00:00:00 2001 From: Clay-Mysten <100217682+Clay-Mysten@users.noreply.github.com> Date: Fri, 15 Apr 2022 10:32:37 -0700 Subject: [PATCH 2/9] Update authorities.md Fix instances of "an validator" with proper article --- doc/src/build/authorities.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/doc/src/build/authorities.md b/doc/src/build/authorities.md index e393b31037978..4b57676a02416 100644 --- a/doc/src/build/authorities.md +++ b/doc/src/build/authorities.md @@ -2,7 +2,7 @@ title: Validators --- -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). An validator 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 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. @@ -12,20 +12,20 @@ Operation of the Sui network is temporally partitioned into non-overlapping, fix ## Committees 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 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. +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 validator can handle two types of write requests: transactions and certificates. At a high level, a client: +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 an validator to commit state changes on that validator. +* submits a certificate to a validator to commit state changes on that validator. ### Transactions -When an 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. +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 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 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. +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 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. From 55fb879121d5416642a1d6f2188750c5c6a1d3f4 Mon Sep 17 00:00:00 2001 From: Clay-Mysten <100217682+Clay-Mysten@users.noreply.github.com> Date: Fri, 15 Apr 2022 10:33:44 -0700 Subject: [PATCH 3/9] Update objects.md Fix instance of "an validator" with proper article --- doc/src/build/objects.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/src/build/objects.md b/doc/src/build/objects.md index 46fb618bd868d..ab45f41c01b03 100644 --- a/doc/src/build/objects.md +++ b/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 validator 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 From de08128b00c621e20ca3a63684141e25ddc0091d Mon Sep 17 00:00:00 2001 From: Clay-Mysten <100217682+Clay-Mysten@users.noreply.github.com> Date: Fri, 15 Apr 2022 10:34:40 -0700 Subject: [PATCH 4/9] Update about-sui.md Fix instance of "an validator" with proper article --- doc/src/learn/about-sui.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/src/learn/about-sui.md b/doc/src/learn/about-sui.md index d79980e500338..01e680221fdef 100644 --- a/doc/src/learn/about-sui.md +++ b/doc/src/learn/about-sui.md @@ -48,7 +48,7 @@ By design, Sui validators (nodes) can effectively scale the network throughput i > **Note:** As of Mar. 19, 2022, an unoptimized single-worker Sui validator running on an 8-core M1 Macbook Pro can execute and commit 120,000 token transfer transactions per second (TPS). Throughput scales linearly with the number of cores–the same machine processes 25,000 TPS in a single core configuration. -This experiment uses a configuration where each client submits a batch of 100 transactions (i.e., transfers to 100 distinct recipients) with a single signature. This configuration captures the anticipated usage pattern of a highly scalable blockchain--e.g., a custodial wallet or game server operating at scale will likely need to submit hundreds or thousands of on-chain transactions per second. With a batch size of 1, an validator running on the same machine can process 20,000 TPS with 8 cores, and exhibits the same linear growth in throughput as more cores are added. +This experiment uses a configuration where each client submits a batch of 100 transactions (i.e., transfers to 100 distinct recipients) with a single signature. This configuration captures the anticipated usage pattern of a highly scalable blockchain--e.g., a custodial wallet or game server operating at scale will likely need to submit hundreds or thousands of on-chain transactions per second. With a batch size of 1, a validator running on the same machine can process 20,000 TPS with 8 cores, and exhibits the same linear growth in throughput as more cores are added. We will publish a full performance report for optimized Sui networks in a variety of configurations when our testnet is released. From 9954c1f1da4ce79041a9d8ad9da5dc38cd3fd685 Mon Sep 17 00:00:00 2001 From: Clay-Mysten <100217682+Clay-Mysten@users.noreply.github.com> Date: Fri, 15 Apr 2022 10:35:54 -0700 Subject: [PATCH 5/9] Update how-sui-works.md Fix instance of "an validator" with proper article --- doc/src/learn/how-sui-works.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/src/learn/how-sui-works.md b/doc/src/learn/how-sui-works.md index 11d629376ef68..cfff69e2aa3f7 100644 --- a/doc/src/learn/how-sui-works.md +++ b/doc/src/learn/how-sui-works.md @@ -92,7 +92,7 @@ Transactions involving shared objects also contain at least one owned object to ## Scalability -As mentioned, Sui does not impose a total order on the transactions containing only owned objects. Instead, transactions are [causally ordered](sui-compared.md#causal-order-vs-total-order). If a transaction `T1` produces an output object `O1` used as input objects in a transaction `T2`, an validator must execute `T1` before it executes `T2`. Note that `T2` does not need to use these objects directly for a causal relationship to exist, e.g., `T1` might produce output objects which are then used by `T3`, and `T2` might use `T3`'s output objects. However, transactions with no causal relationship can be processed by Sui validators in any order. This insight allows Sui to massively parallelize execution, and shard it across multiple machines. +As mentioned, Sui does not impose a total order on the transactions containing only owned objects. Instead, transactions are [causally ordered](sui-compared.md#causal-order-vs-total-order). If a transaction `T1` produces an output object `O1` used as input objects in a transaction `T2`, a validator must execute `T1` before it executes `T2`. Note that `T2` does not need to use these objects directly for a causal relationship to exist, e.g., `T1` might produce output objects which are then used by `T3`, and `T2` might use `T3`'s output objects. However, transactions with no causal relationship can be processed by Sui validators in any order. This insight allows Sui to massively parallelize execution, and shard it across multiple machines. Sui employs the [state-of-the-art Narwhal consensus protocol](https://arxiv.org/abs/2105.11827) to totally order transactions involving shared objects. The consensus sub-system also scales in the sense that it can sequence more transactions by adding more machines per validator. From 78caea9d466fe9f0a25a35f62c32343d568ac1d2 Mon Sep 17 00:00:00 2001 From: Clay-Mysten <100217682+Clay-Mysten@users.noreply.github.com> Date: Fri, 15 Apr 2022 10:38:17 -0700 Subject: [PATCH 6/9] Update sui-compared.md Fix instances of "an validator" with proper article --- doc/src/learn/sui-compared.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/doc/src/learn/sui-compared.md b/doc/src/learn/sui-compared.md index e4f02ce42dead..19d51ad483a3c 100644 --- a/doc/src/learn/sui-compared.md +++ b/doc/src/learn/sui-compared.md @@ -51,15 +51,15 @@ As a consequence, a Sui validator -- or any other validator with a copy of the s ## Validators vs. validators/miners -An validator plays a role similar to "validators" or "miners" in other blockchain systems. The key distinction between these roles (and the reason we insist on using a separate term) is that validators/miners are *active*, whereas validators are *passive* for the main type of Sui transaction involving single-writer objects. Broadly speaking, to deal with a transfer: +A validator plays a role similar to "validators" or "miners" in other blockchain systems. The key distinction between these roles (and the reason we insist on using a separate term) is that validators/miners are *active*, whereas validators are *passive* for the main type of Sui transaction involving single-writer objects. Broadly speaking, to deal with a transfer: * Miners/validators continuously participate in a global consensus protocol that requires multiple rounds of all-to-all communication between the participants. The goal is typically to agree on a *totally ordered* block of transactions and the result of their execution. -* Validators do nothing until they receive a transaction or certificate from a user. Upon receiving a transaction or certificate, an validator need not communicate with other validators in order to take action and advance its internal state machine. It may wish to communicate with other validators to share certificates but need not do so. +* Validators do nothing until they receive a transaction or certificate from a user. Upon receiving a transaction or certificate, a validator need not communicate with other validators in order to take action and advance its internal state machine. It may wish to communicate with other validators to share certificates but need not do so. ## Causal order vs. total order -Unlike most existing blockchain systems (and as the reader may have guessed from the description of write requests above), Sui does not always impose a total order on the transactions submitted by clients, with shared objects being the exception. Instead, most transactions are *causally* ordered--if a transaction `T1` produces output objects `O1` that are used as input objects in a transaction `T2`, an validator must execute `T1` before it executes `T2`. Note that `T2` need not use these objects directly for a causal relationship to exist--e.g., `T1` might produce output objects which are then used by `T3`, and `T2` might use `T3`'s output objects. However, transactions with no causal relationship can be processed by Sui validators in any order. +Unlike most existing blockchain systems (and as the reader may have guessed from the description of write requests above), Sui does not always impose a total order on the transactions submitted by clients, with shared objects being the exception. Instead, most transactions are *causally* ordered--if a transaction `T1` produces output objects `O1` that are used as input objects in a transaction `T2`, a validator must execute `T1` before it executes `T2`. Note that `T2` need not use these objects directly for a causal relationship to exist--e.g., `T1` might produce output objects which are then used by `T3`, and `T2` might use `T3`'s output objects. However, transactions with no causal relationship can be processed by Sui validators in any order. ## Where Sui excels From 92395b37bd1e36d6d9d1e37056b999716c267021 Mon Sep 17 00:00:00 2001 From: Clay-Mysten <100217682+Clay-Mysten@users.noreply.github.com> Date: Fri, 15 Apr 2022 10:38:52 -0700 Subject: [PATCH 7/9] Update sui-glossary.md Fix instance of "an validator" with proper article --- doc/src/learn/sui-glossary.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/src/learn/sui-glossary.md b/doc/src/learn/sui-glossary.md index b4549146db586..07e49858521e4 100644 --- a/doc/src/learn/sui-glossary.md +++ b/doc/src/learn/sui-glossary.md @@ -12,7 +12,7 @@ An *accumulator* makes sure the transaction is received by a quorum of validator ### Validator -An validator in Sui plays a passive role analogous to the more active role of validators and minors in other blockchains. In Sui, +A validator in Sui plays a passive role analogous to the more active role of validators and minors in other blockchains. In Sui, validators do not continuously participate in the consensus protocol but are called into action only when receiving a transaction or certificate. From 70ac2c45f161f1ed53d23e6e53b2ab1bc894a919 Mon Sep 17 00:00:00 2001 From: Clay-Mysten <100217682+Clay-Mysten@users.noreply.github.com> Date: Fri, 15 Apr 2022 10:39:27 -0700 Subject: [PATCH 8/9] Update sui-security.md Fix instance of "an validator" with proper article --- doc/src/learn/sui-security.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/src/learn/sui-security.md b/doc/src/learn/sui-security.md index 4da99d1d8c5e3..3399b69d34bf6 100644 --- a/doc/src/learn/sui-security.md +++ b/doc/src/learn/sui-security.md @@ -112,7 +112,7 @@ pseudonymity, or third-party custodial or non-custodial services. Specific smart ### Censorship-resistance and openness Sui uses the established Delegated Proof-of Stake model to periodically determine its set of validators. Users can lock and delegate their SUI tokens in each epoch to determine the committee of validators that operate the Sui network in the next epoch. Anyone with over a minimum -amount of delegated stake may operate an validator. +amount of delegated stake may operate a validator. Validators operate the network and provide rewards to users that delegated their Sui to support them as validators, through gas fee income. Validators with poor reliability, and in turn the users that delegated their stake to them, may receive a lower reward. But user stake cannot be confiscated away either by malicious validators or anyone in the network. From e88fdeee22f968c2c4dcbd23bd548172f84b3158 Mon Sep 17 00:00:00 2001 From: Clay-Mysten <100217682+Clay-Mysten@users.noreply.github.com> Date: Fri, 15 Apr 2022 10:40:29 -0700 Subject: [PATCH 9/9] Update why-move.md Fix instances of "an validator" with proper article --- doc/src/learn/why-move.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/src/learn/why-move.md b/doc/src/learn/why-move.md index 6d870e3bcc04e..147a79eee221f 100644 --- a/doc/src/learn/why-move.md +++ b/doc/src/learn/why-move.md @@ -16,6 +16,6 @@ One fundamental difference between the EVM and Move is the data model for assets Sui heavily leverages the Move data model for performance. Sui's persistent state is a set of programmable Move objects that can be updated, created, and destroyed by transactions. Each object has ownership metadata that allows Sui validators to both execute and commit transactions using the object in parallel with causally unrelated transactions. Move's type system ensures the integrity of this ownership metadata across executions. The result is a system where developers write ordinary Move smart contracts, but validators leverage the data model to execute and commit transactions as efficiently as possible. -This is simply not possible with the EVM data model. Because assets are stored in dynamically indexable maps, an validator would be unable to determine when transactions might touch the same asset. Sui's parallel execution and commitment scheme needs a language like Move with the vocabulary to describe structured assets that can flow freely across contracts. To be blunt: **even if we preferred the EVM/Solidity to Move, we could not use them in Sui without sacrificing the performance breakthroughs that make Sui unique**. +This is simply not possible with the EVM data model. Because assets are stored in dynamically indexable maps, a validator would be unable to determine when transactions might touch the same asset. Sui's parallel execution and commitment scheme needs a language like Move with the vocabulary to describe structured assets that can flow freely across contracts. To be blunt: **even if we preferred the EVM/Solidity to Move, we could not use them in Sui without sacrificing the performance breakthroughs that make Sui unique**. One of the main advantages of Move is data composability. It is always possible to create a new struct (asset) Y that will hold initial asset X in it. Even more - with addition of generics, it is possible to define generic wrapper Z(T) that will be able to wrap any asset, providing additional properties to a wrapped asset or combining it with others. See how composability works in our [Sandwich example](https://github.com/MystenLabs/sui/tree/main/sui_programmability/examples/basics/sources/Sandwich.move).