I read Sui documentation so you don’t have to.

An overview by non-tech guy written in simple words.

Resources used:

• Sui docs

• Article by Blockchain Council

• Article by Pontem

• Article from 0xzx

Definition Structure Consensus Scalability Move vs. Solidity Afterwords

Sui – is a proof-of-stake layer 1 blockchain written in Rust and supports smart contracts written in the Move programming language.

You must have heard about Rust as one of the most usable languages (Solana, Polkadot, Near). Move, in turn, is something new to most of the readers. Current blockchains use Solidity for creating smart contracts while Sui is one of the firsts to use Move. We will talk more specific about programming languages in the next chapter. Let’s focus on Sui first.

Proof-of-stake concept means there are validators who stake $SUI tokens to validate transactions – similar to the other blockchains. But with some important details:

Before we continue. If such terms as validators, staking or Byzantine Fault Tolerance (BFT) are pretty complicated for you, check my previous article which can greatly prepare yourself.

Sui doesn’t compose transactions in blocks. Instead, validators can verify transactions in parallel what heavily increase the throughput. It becomes possible because you can send only one transaction at a time. The next one only after completion of the first.

The second reason is that there is a difference in design between simple transactions and more complicated ones when several parties are involved (various smart contracts). It’s called owned objects and shared objects.

So why objects? The basic unit of storage in Sui is object. It can be owned by account or by another objects. Each object has:

• Unique ID (something like hash or contract ID in Ethereum);

• Version (showing how many times this object was included in transactions, starting from 1);

• Transaction digest (indicating the last transaction that included this object as an output);

• Owner field (showing the owner: account address, another object, immutable or shared).

Every owned object is owned by a single address, and each address can own an arbitrary number of objects. However, shared object can be owned by several addresses. The ledger is updated via a transaction sent by a particular address. A transaction can create, destroy, and write objects, as well as transfer them to other addresses.

Don’t get so confused about this object stuff. That’s just another way of representing data in blockchains. We used to focus on accounts while Sui focuses on objects.

In Sui, the consensus is required only when a transaction involves shared objects. Long story short – Sui is well optimized for common transactions. As mentioned, transactions don’t compose in blocks but interact with validators directly using some simplified algorithms. It helps achieve almost instant approval for simple transactions. Moreover, not only general transfers are considered as owned objects, but also storage of user’s data, messages in web3 social networks, human vs. pc games, voting and even more!

Let’s have a look on how these are carried out:

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 (a collection of validators’ signatures) and broadcasts that back to all Sui validators. This settles the transaction, ensuring finality that the transaction will not be dropped (revoked).

However, when shared objects are involved, transaction submission follows these steps:

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, the certificate is sequenced through Byzantine Agreement (it means the validators have to come to consensus);

4. Once the transaction has been successfully sequenced, the user broadcasts again the certificate to the validators to settle the transaction.

The algorithms above show that single transactions can actually bypass the consensus and be instantly performed.

Sui can scale horizontally without need of shards (like Ethereum or Near). Network capacity grows in proportion to the increase in Sui validators' processing power, resulting in low gas fees even during high network traffic. In simple words – as more powerful machines validators use as more scalable the network is. Mostly the amount of CPU cores is considered.

That in theory solves various problems:

• Blockchain games are slow and expensive to play;

• A high traffic means high fees or slow transactions;

• Gas wars;

• Suspension of a network due to an excessive load.

It’s pretty hard to speak about programming languages in non-tech format. That’s why I’ll focus on some clear points only.

The first one – Move supports not only smart contracts as Solidity does, but also custom transactions. It makes Move more flexible for developers.

Second one – Move was created to solves problems with safety by implementing scarcity and access control. Scarcity prevents any double-spending and imposes restrictions on assets creation. Asses control deals with maintaining ownership and privileges. In other words – safety & security are set in the code of Move.

The third one – Move uses modules in relation to smart contract creation. It makes implementations and optimizations much easier. Once you update the module, all contracts using it will automatically use the lates version.

There are many technical details left to discuss. However, it’s out of range for this article. I hope I gave you an overall idea of how Sui actually works. I’d recommend you to read articles I mentioned at the beginning, try to run Sui node by yourself and engage in upcoming events within the Sui community. The first wave of incentives testnet is over but more is coming. Be early – be smart.

Join Sui community in discord and twitter.

If you found my article useful and interesting, you know what to do ;)

Thanks for your time and see ya soon!

My twitter.

I read Sui documentation so you don’t have to.

An overview by non-tech guy written in simple words.

Resources used:

• Sui docs

• Article by Blockchain Council

• Article by Pontem

• Article from 0xzx

Definition Structure Consensus Scalability Move vs. Solidity Afterwords

Sui – is a proof-of-stake layer 1 blockchain written in Rust and supports smart contracts written in the Move programming language.

You must have heard about Rust as one of the most usable languages (Solana, Polkadot, Near). Move, in turn, is something new to most of the readers. Current blockchains use Solidity for creating smart contracts while Sui is one of the firsts to use Move. We will talk more specific about programming languages in the next chapter. Let’s focus on Sui first.

Proof-of-stake concept means there are validators who stake $SUI tokens to validate transactions – similar to the other blockchains. But with some important details:

Before we continue. If such terms as validators, staking or Byzantine Fault Tolerance (BFT) are pretty complicated for you, check my previous article which can greatly prepare yourself.

Sui doesn’t compose transactions in blocks. Instead, validators can verify transactions in parallel what heavily increase the throughput. It becomes possible because you can send only one transaction at a time. The next one only after completion of the first.

The second reason is that there is a difference in design between simple transactions and more complicated ones when several parties are involved (various smart contracts). It’s called owned objects and shared objects.

So why objects? The basic unit of storage in Sui is object. It can be owned by account or by another objects. Each object has:

• Unique ID (something like hash or contract ID in Ethereum);

• Version (showing how many times this object was included in transactions, starting from 1);

• Transaction digest (indicating the last transaction that included this object as an output);

• Owner field (showing the owner: account address, another object, immutable or shared).

Every owned object is owned by a single address, and each address can own an arbitrary number of objects. However, shared object can be owned by several addresses. The ledger is updated via a transaction sent by a particular address. A transaction can create, destroy, and write objects, as well as transfer them to other addresses.

Don’t get so confused about this object stuff. That’s just another way of representing data in blockchains. We used to focus on accounts while Sui focuses on objects.

In Sui, the consensus is required only when a transaction involves shared objects. Long story short – Sui is well optimized for common transactions. As mentioned, transactions don’t compose in blocks but interact with validators directly using some simplified algorithms. It helps achieve almost instant approval for simple transactions. Moreover, not only general transfers are considered as owned objects, but also storage of user’s data, messages in web3 social networks, human vs. pc games, voting and even more!

Let’s have a look on how these are carried out:

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 (a collection of validators’ signatures) and broadcasts that back to all Sui validators. This settles the transaction, ensuring finality that the transaction will not be dropped (revoked).

However, when shared objects are involved, transaction submission follows these steps:

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, the certificate is sequenced through Byzantine Agreement (it means the validators have to come to consensus);

4. Once the transaction has been successfully sequenced, the user broadcasts again the certificate to the validators to settle the transaction.

The algorithms above show that single transactions can actually bypass the consensus and be instantly performed.

Sui can scale horizontally without need of shards (like Ethereum or Near). Network capacity grows in proportion to the increase in Sui validators' processing power, resulting in low gas fees even during high network traffic. In simple words – as more powerful machines validators use as more scalable the network is. Mostly the amount of CPU cores is considered.

That in theory solves various problems:

• Blockchain games are slow and expensive to play;

• A high traffic means high fees or slow transactions;

• Gas wars;

• Suspension of a network due to an excessive load.

It’s pretty hard to speak about programming languages in non-tech format. That’s why I’ll focus on some clear points only.

The first one – Move supports not only smart contracts as Solidity does, but also custom transactions. It makes Move more flexible for developers.

Second one – Move was created to solves problems with safety by implementing scarcity and access control. Scarcity prevents any double-spending and imposes restrictions on assets creation. Asses control deals with maintaining ownership and privileges. In other words – safety & security are set in the code of Move.

The third one – Move uses modules in relation to smart contract creation. It makes implementations and optimizations much easier. Once you update the module, all contracts using it will automatically use the lates version.

There are many technical details left to discuss. However, it’s out of range for this article. I hope I gave you an overall idea of how Sui actually works. I’d recommend you to read articles I mentioned at the beginning, try to run Sui node by yourself and engage in upcoming events within the Sui community. The first wave of incentives testnet is over but more is coming. Be early – be smart.

Join Sui community in discord and twitter.

If you found my article useful and interesting, you know what to do ;)

Thanks for your time and see ya soon!

My twitter.