From 87bddba53c069ebe30e17fd9e2da859f163fff98 Mon Sep 17 00:00:00 2001 From: Mark Spanbroek Date: Tue, 13 Sep 2022 17:00:10 +0200 Subject: [PATCH] Added evaluation of Sui --- evaluations/sui.md | 1 + papers/Sui/sui.md | 119 +++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 120 insertions(+) create mode 120000 evaluations/sui.md create mode 100644 papers/Sui/sui.md diff --git a/evaluations/sui.md b/evaluations/sui.md new file mode 120000 index 0000000..fc8a65d --- /dev/null +++ b/evaluations/sui.md @@ -0,0 +1 @@ +../papers/Sui/sui.md \ No newline at end of file diff --git a/papers/Sui/sui.md b/papers/Sui/sui.md new file mode 100644 index 0000000..14325dc --- /dev/null +++ b/papers/Sui/sui.md @@ -0,0 +1,119 @@ +The Sui Smart Contracts Platform +================================ + +* [Sui Whitepaper](https://github.com/MystenLabs/sui/blob/main/doc/paper/sui.pdf) +* [Sui Tokenomics paper](https://github.com/MystenLabs/sui/blob/main/doc/paper/tokenomics.pdf), May 2022 + + +Sui is an alternative to blockchains that is geared towards high performance. It +utilizes a UTXO and DAG based design that allows for parallelization. It uses a +delegated proof-of-stake model to keep the number of validators low while +keeping the design permissionless. It uses a storage fund to pay for persistent +storage. + +Main ideas +---------- + +### Consensus ### + +Transactions require approval from 2/3 of the validators (as measured by +delegated stake). Sui uses the minimum amount of consensus that is required for +a given transaction: + +* For transactions on owned objects (controlled by a key) it uses byzantine + consistent broadcast. (Whitepaper §4.3, "Sign once, and safety") +* For transactions on shared objects (modifiable by anyone) it uses a byzantine + agreement protocol only on the *order* of conflicting transactions. Execution + of the transaction happens after the order has been determined. (Whitepaper + §4.4, "Shared Objects" and §5, "Throughput") + +Transactions on owned objects require 2 roundtrips to a quorum for byzantine +broadcast. Transactions on shared objects require 4-8 round trips to a quorum +for byzantine agreement. (Whitepaper §5, "Latency") + +### Parallellism ### + +Sui uses the +[Move](https://github.com/MystenLabs/sui/blob/main/doc/paper/sui.pdf) language +for programming smart contracts. Unlike the EVM languages, this language is +geared towards the inherent parallelism that is afforded by the UTXO and DAG +design. The language is not unique to Sui, it is used in other projects as well. +(Whitepaper §2) + +### Storage ### +Persistent storage is paid for using a storage fund, whereby the storage fees +are collected, and the proceeds of investing (staking) this fund are used to pay +for future storage costs (Tokenomics §3.3, §5). Fees are rebated when deleting +data from storage (Tokenomics §5.1). This is designed in such a way that the +opportunity cost of locking up tokens is equal to the fees one would otherwise +pay for storage (Tokenomics §6.2).. + +### Proof of stake ### + +Avoids "rich-get-richer" forces of other proof-of-stake implementations, +specifically to ensure that validators enjoy viable business models regardless +of their delegated stake. Random selection is avoided, opting instead for a +model where everyone is rewarded according to their stake (Tokenomics §3.2, +§6.3) + +Gas fees are payed out to both validators and the people that delegated their +stake to the validators. This is an extra incentive for delegators to keep an +eye on their chosen validator, and to move stake when the validator is not +behaving well. (Whitepaper §4.7, "Rewards and cryptoeconomics") + +### Epochs ### +Keeps several parameters of the network constant during epochs, such as the +stake of the validators and (nominal) gas prices. Uses checkpointing to compress +state and allow for committee changes on epoch boundaries. (Whitepaper §4.7) + +Promotes predictable gas prices by having validators indicate a gas price +upfront, and diminish their rewards if they do not honour this upfront gas +price. (Tokenomics §4.1, §4.3) + +Observations +------------ + +### Contention ### + +The Sui design nicely sidesteps contention issues with shared mutable UTXO state +(e.g. such as in Cardano) by performing the byzantine agreement protocol on the +order of the transactions, not on its execution. Therefore there is no need to +resubmit a transaction when someone else used the object/UTXO that you intended +to use. Uses references to objects/UTXOs without their serial number for mutable +state, to enable this. (Whitepaper §4.4, "Shared objects") + +### Recovery ### + +It also nicely solves an issue with byzantine consistent broadcast (e.g. as in +ABC) whereby funds are locked forever when conflicting transactions are posted. +Conflicting transactions are cleared on every epoch boundary. (Whitepaper §4.3, +"Disaster recovery" and §4.7, "Recovery") + +### Inert stake ### + +Sui mitigates the problem whereby an increasing amount of delegated stake can no +longer be re-assigned because the associated keys are lost (as could happen in +e.g. ABC). Stake delegation is an explicit action, instead of an implicit +side-effect of every transaction. The staking logic is implemented in a smart +contract, which allows the network to update the logic to deal with such issues. + +### Validator reputation ### + +Stake rewards are influenced by the (subjective) reputation that validators +report about other validators. It is unclear how far this can be gamed by +validator wishing to increase their rewards. (Tokenomics §4.1.2, §4.1.3) + +### Storage fund viability ### + +The storage fund seems based on the assumption that there is enough money to be +made from computation fees to pay for continued storage. The fund ensures that +validators earn a bigger cut of the computation fees based on the size of the +storage fund. This could be problematic when the amount of storage heavily +outweighs the amount of computation; for instance if Sui were used primarily as +a storage network. This is good to keep in mind when comparing the storage fund +model with rent-based models such as employed in Codex. (Tokenomics §3.2, §3.3) + +The storage gas price remains constant within an epoch (Tokenomics §3.1). It is +unclear how the network should react when confronted with a sudden spike in +demand for storage. What would happen when the storage is price is low, and a +user decides to store massive amounts of data on the network?