Update sui-compared.md #762
Conversation
Build out Sui differences from other blockchains and add limitations
Replace epoch with transaction
Mostly: - fix a few bugs, - edit a few parts not on topic, - make the Limitations part more concise
gdanezis
added
the
Type: Documentation
doc/src/learn/sui-compared.md
Outdated
|
|
||
| ## Sui's approach to validating new transactions | ||
| - Easier developer experience |
There was a problem hiding this comment.
With the Move programming language, added.
doc/src/learn/sui-compared.md
Outdated
|
|
||
| This doesn't mean that Sui is a platform never orders transactions with respect to each other, or that it we allows owners to only affect their owned microcosm of objects. Sui will also process transactions that have an effect on some shared state, in a rigorous, consensus-ordered manner. They're just not the default use case. | ||
| ## A collaborative approach to transaction submission | ||
| 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. Broadly speaking, to deal with a transfer: |
There was a problem hiding this comment.
Are we trying to say that keeping authorities passive improves performance or is it just a general statement? Note that authorities are active (in the traditional term) when shared-objects or sync/checkpointing is involved
There was a problem hiding this comment.
I appended to read, "... passive for the main type of Sui transaction involving single-writer objects."
doc/src/learn/sui-compared.md
Outdated
| # Sui Limitations | ||
| In this manner, Sui enables multi-lane processing and eliminates [head-of-line blocking](https://en.wikipedia.org/wiki/Head-of-line_blocking). No longer must all other transactions in the world wait for the completion of the first transaction’s increment in a single lane. Sui provides a lane of the appropriate breadth for each transaction: simple sends require viewing only the sender account; more complex transactions may need to see more of the world’s state - but not all of it, and they will need to declare the required views explicitly. | ||
|
|
||
| Sui’s architecture minimizes the impact of checking the validity of a transaction: each sender can send only one, non-equivocating transaction at a time. And that transaction blocks no one else on the network from sending transactions. Sui assumes complex, interdependent transactions are the exception rather than the rule; most transactions are independent from one another. Sui and Move represent all of these transactions faithfully. |
There was a problem hiding this comment.
'exception rather than the rule' should we say why we think so? eg. payment transactions
There was a problem hiding this comment.
Good point. I appended, "... merely making payments online."
doc/src/learn/sui-compared.md
Outdated
|
|
||
| Because Sui limits the sender to one transaction at a time, it is imperative the transactions finish quickly. Sui offers these optimizations to speed transaction completion: | ||
|
|
||
| * Simpler algorithms are used to determine state, since less of the world’s state must be evaluated. These algorithms are based upon [Byzantine Consistent Broadcast](https://link.springer.com/book/10.1007/978-3-642-15260-3). |
There was a problem hiding this comment.
are we trying to say that simpler algorithm make our code faster?
There was a problem hiding this comment.
Yes, I believe so. Disagree? Desire more clarification?
There was a problem hiding this comment.
@huitseeker for comment
There was a problem hiding this comment.
Byzantine Consistent Broadcast has simpler worst-case communication complexity than the O(N^2) worst-case communication complexity of any consensus algorithm, and so makes us faster where that is sufficient to process the transaction.
TL;DR: outside of shared objects, the BCB is faster, except it's not an algorithm "to determine state". I'd reformulate to
For transactions dependent on a single writer, Sui uses a lighter communication algorithm, based on Byzantine Consistent Broadcast.
doc/src/learn/sui-compared.md
Outdated
| * Simpler algorithms are used to determine state, since less of the world’s state must be evaluated. These algorithms are based upon [Byzantine Consistent Broadcast](https://link.springer.com/book/10.1007/978-3-642-15260-3). | ||
| * Transaction sessions are interactive to ensure at-once processing and vote gathering. Instead of an asynchronous fire-and-forget model where transactions may take minutes or even hours, Sui transactions can finish in under a second. | ||
|
|
||
| A traditional blockchain client operates via a single send request and awaits approval of the transaction, polling the validators for an answer sometime later. Either end users or the gateway must do a little more work and then get: low latency and better security. Simple broadcast transactions are completed instantly. Remember, no private keys are ever exchanged. |
There was a problem hiding this comment.
'instantly' is a strong word (I have only seen it in the context of payment channels, that come with different tradeoffs)
There was a problem hiding this comment.
Good point. I replaced with "immediately" here.
Co-authored-by: Alberto Sonnino <[email protected]>
Fix "contrat" typo
Tidy up some punctuation and grammar
We are targeting potential adopters for this page, so tech leads and executives. And I've attempted to address your comments both here and from the Doc. I say we push and iterate. Please take a look. Thanks, all. |
doc/src/learn/sui-compared.md
Outdated
|
|
||
| Blockchain validators collectively build a shared accumulator: a representation of the state of the blockchain, a chain to which they add increments over time, called blocks. In blockchains that offer finality, every time validators want to make an incremental addition to the blockchain, i.e. a block proposal, they enter into a consensus protocol. This protocol lets them form an agreement over the current state of the chain, whether the proposed increment is suitable and valid, and what the state of the chain will be after the new addition. | ||
| - Move and object-centric data model (enables composable objects/NFTs) |
There was a problem hiding this comment.
Nit: instances of "Move" in this list would probably need a link since they're not really addressed in depth in this document.
Adding Francois's suggested rewrite of simpler algorithm bullet point
Adding links to Sui Move and Awesome Move docs
* fix: Make leader election select from the whole Committee Fixes #755 * fix: Make tests of binomial result more strict * fix: make the leader see a strict u64 (from usize) * fix: consensus behavior under tests
…#762) * fix: Make leader election select from the whole Committee Fixes MystenLabs#755 * fix: Make tests of binomial result more strict * fix: make the leader see a strict u64 (from usize) * fix: consensus behavior under tests
Build out Sui differences from other blockchains and add limitations