NEAR is a sharded blockchain. Both state and compute are sharded. It allows to achieve almost linear TPS scaling with the increase in the number of shards. The state can be rebalanced to a new number of shards on demand.
-
-
Prikaži ovu nit
-
A single shard TPS is bounded by sequential operations to access the same data in the state. That's why Ethereum 1.0 TPS is low, it has to execute every transaction consequently to be able to reuse previous modifications of the state.
Prikaži ovu nit -
It’s also why Ethereum has such a great cross-contract composability. Any contract can call any other contract and then commit or revert all state changes made during this transaction. Every transaction is either entirely succeeds or fails.
Prikaži ovu nit -
It has benefits and limitations. The benefits are the magical DeFi composability where a contract can borrow tokens, exchange on Uniswap, lend it back all in one transaction. Your only risk are the transaction fees that you may lose if the TX fails and changes are reverted.
Prikaži ovu nit -
This is is guaranteed by having single-threaded atomic access to the entire state. Essentially, a VM locks the state at the beginning of a transaction, executes everything and unlocks the state only at the end.
Prikaži ovu nit -
In a sharded system like NEAR (or Eth 2.0), the full state is not available at any given moment, because the compute is running in parallel asynchronously. The state in one shard can be modified at the same time as the state in another shard. Shard states are independent.
Prikaži ovu nit -
To better understand state sharding, think about an example with 2 shards. If the hash of an account ID ends with 0, it goes to shard #0, if the hash ends with 1, it goes to shard #1. Now every transaction that has to be processed by the corresponding shard based on account ID.
Prikaži ovu nit -
At NEAR once a transaction is verified and the signer’s account is charged with the full prepaid cost of the transaction, the transaction is transformed to a `Receipt`. To simplify, NEAR Runtime executes a list of receipts, modifies the state and produces a list of new receipts.
Prikaži ovu nit -
Each receipt has a predecessor account ID and the receiver account ID. The predecessor is the account which created this receipt. The receiver is the account on which the receipt is executed upon. NEAR Blockchain layer uses receiver IDs to route the new receipts across shards.
Prikaži ovu nit -
While NEAR Runtime is completely unaware of sharding, it operates on accounts. Runtime treats each account independently. Even if 2 accounts are collocated on the same shard, they are treated as accounts on different shards. So account collocation doesn’t give any benefits.
Prikaži ovu nit -
Now as we covered the basics of NEAR sharding, let’s jump to the composability!pic.twitter.com/aVcTDqv3r3
Prikaži ovu nit -
If a contract A wants to call another contract B, it creates an async promise P1. Then if contract A wants to act on top of the result of P1, contract A can attach a callback to P1 to call a method on A. It will create a promise P2. Internally in Runtime P1 and P2 are receipts.pic.twitter.com/nvneCP2q2t
Prikaži ovu nit -
Each contract can also call other contracts and instead of returning the result immediately, it can depend on some other callbacks. E.g. if in the above example B was depending on the call to C, the callback to A will only be called after callback back to B is completed.pic.twitter.com/j7h6FhglDc
Prikaži ovu nit -
If you are familiar with JS promise API, then NEAR promise API is going to be similar. API allows contracts to create multiple async promises, join them together and to create callbacks to other contracts. E.g. A calls B and C, then calls D on the joint result of B, C execution.pic.twitter.com/04EaSCuVZL
Prikaži ovu nit -
When B executes some call, it knows the predecessor A (the immediate caller), so it knows the context. The contract can use it to check access permission for a certain action. E.g. check that a Dex contract has an allowance for a token transfer from Alice.
Prikaži ovu nit -
Let’s look at the concrete example where a Dex contract wants to swap X wDAI tokens from Alice to Y wETH tokens from Bob. Dex doesn’t want to own the tokens even temporarily, but instead it has an allowance to spend them from Alice and Bob.pic.twitter.com/1GMbMEs3Xs
Prikaži ovu nit -
If a Dex doesn’t own tokens (but just has an allowance) it has to lock the tokens first to make sure they are still available on corresponding accounts, because the token states are located on different shards.
Prikaži ovu nit -
Dex calls wDAI to lock X tokens from Alice, and in parallel calls wETH to lock Y tokens from Bob. The results of the calls are acquired locks.
Prikaži ovu nit -
Once Dex has successfully acquired both locks, Dex calls wDAI and wETH to transfer tokens between Alice and Bob. If one of the locks failed, then Dex needs to unlock the other successfully acquired lock.pic.twitter.com/68AYGxx8kI
Prikaži ovu nit -
If for some reason the Dex contract after acquiring locks, the tokens might be stuck in a locked state. To avoid this issue we propose a WIP concept of a `Safe`. It has a secure auto-unlocking mechanism to avoid situations with lost locks. More details:https://github.com/nearprotocol/NEPs/pull/26/files?short_path=0ccd6ae#diff-0ccd6ae29ca4dfdda66ca7c7f58cd75d …
Prikaži ovu nit -
It may all sound complicated right now, but hopefully a lot of this is going to be addressed through examples and high-level APIs. Right now, NEAR provides Rust API and AssemblyScript API to write smart contracts which are complied to WebAssembly that can be deployed.
Prikaži ovu nit -
Please ask any questions here and I’ll try to answer them. Join discord https://near.chat for DEV discussions or telegramhttps://t.me/cryptonear
Prikaži ovu nit
Kraj razgovora
Novi razgovor -
-
Prikaži još odgovora, uključujući one koji mogu sadržavati uvredljiv sadržaj
Čini se da učitavanje traje već neko vrijeme.
Twitter je možda preopterećen ili ima kratkotrajnih poteškoća u radu. Pokušajte ponovno ili potražite dodatne informacije u odjeljku Status Twittera.
